Evidence each cause before you name it: assemble the timeline, keep the facts and the conclusion in separate fields, and hold the review for the named engineer who signs it.
A review is written, because DORA Art. 13(2) compels one and no rule consulted protects it.
02
A cause is named, and 49 CFR 835.2 shields a conclusion while letting the facts beneath it in.
Reason
03
A factor is added, and Burrage reads each one as another but-for antecedent open to a plaintiff.
04
An action item is opened, and the gap before it closes is the theory Wyndham lost on.
05
An action item is never taken, and Rule 407 excludes a fix that happened, not one that did not.
Decide
06
A report is drawn for a regulator, and any divergence from the internal review is surfaced first.
07
A review is written by norm alone, and Dowling read voluntary safety reviews as unprotected.
Out
08
A cause is written for engineers, and FRE 801(d)(2)(D) admits it against the company unqualified.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Assembling the timeline, attaching the evidence and holding the draft belong to the agent. Naming the cause and signing the review belongs to a named engineer, who answers for it afterwards.
Example workflow
One review, incident to sign-off
AgentHuman
1Incident record receivedThe incident channel, the paging record, deploy history, tickets or telemetry
2Evidence assembledWhat each system shows, the source of each line, the hour it was seen and what is still unexplained
3Review draftedThe timeline, the candidate causes, the evidence under each and confidence
4Controls appliedEvidence checks, conclusion-form checks, action-item checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is signed at any of them — the agent is evidencing, and the engineer lane opens at the sign-off gate.
5DecisionSplits at the sign-off gate
Evidenced throughout
Goes to the named engineer to sign.
Anything unevidenced
Adds a service-owner read first.
Engineer review
The review is held with its timeline, its evidence and what it does not establish.
Sign · Amend · Send to owner review
Signed — by the named engineer▼
6Incident and tracker records updatedOnly where write access and records policy allow it
7Outcome evaluatedEvidence accuracy, amended causes, action items closed and what the next incident found
Corrections
Each engineer objection is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Naming the cause a review stands on.
Deciding what the regulator-facing report says.
Running a second, counsel-directed investigation.
Signing off a review for circulation.
Automation boundaryAgent acts unaided
✓Assemble the timeline from the systems of record.
✓Attach the evidence under each candidate cause and mark what is missing.
✓Keep the stated cause and the facts beneath it in separate fields.
✓Hold the review for the engineer who signs it.
Nothing is signed or circulated except by a named engineer, inside the agreed boundaries.
Closing an action item as done.
Judging whether an incident was preventable.
Deciding what a customer is told afterwards.
Changes to review rules or circulation scope.
Example output
One review, annotated
A telecom copilot ranks hypotheses against alarms and a manufacturing agent reconciles stop records; this one writes the software postmortem, a document with a second readership. Below is one review as the agent leaves it.
Review output · single incidentIllustrative example
Incident
Recorded as
Stated cause
Evidence of record
Confidence
Held for
Checkout API, failed writes
Connection pool exhausted under retry
Candidate cause
Deploy log, 3 August 2026
Held unsigned
The named engineer, by name
As receivedTaken from the deploy log and the trace store — the agent vouches for what was read, not for what it caused.
What the record holdsDeploy log linesTrace samplesPaging record
Why no cause is fixed hereNaming the root cause is a determination a named engineer owns.
ActionSignAmendSend to owner review
What the score decidesBelow the configured threshold a review gets an owner read before the engineer sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Each reviewFrom the incident that raised it
03Evidence
Where the evidence is used
Medicine has 42 U.S.C. 299b-22. Software has four district courts that split, and the two upholding privilege did so where the engineers were kept from the report.
01Approved path
The record outlives the outage
Six years of retention under 45 CFR 164.316(b)(2)(i), a search index and a link from the ticket: the reach that makes a review useful is the reach that makes it evidence.
02Human review
What was checked, and not found
No rule consulted confers a privilege on the internal review, requires the analysis to be correct, or requires an action item to be closed. NIS2 Art. 23(4)(d)(ii) asks only for the cause likely to have triggered the incident, and CIRCIA shields the report handed to CISA, not the wiki.
04Build an evidence trail
The cause, the evidence beneath it and the engineer who signed it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
A service-level evidence figure can read clean while repeat incidents on one service carry most of the amended causes. Nestack reports the amendment rate by service class, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Repeat incidents on one service
7.9%
3.7×
Review
Multi-service cascading failures
5.6%
2.6×
Review
Third-party and vendor causes
3.5%
1.6×
Watch
Single-service degradations
1.8%
0.8×
Normal
Bar: amendment-rate lift vs. single-service baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What one open action item cost
A cycle ends when the action item nobody closed is a standing case. That suite is what the next review written is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Amendment rate rises on one service class.
02Diagnose
The sentence that reads as candour in the room and as notice in a deposition is worked back through the evidence until one cause is left standing.
03Improve
The change ships numbered, with the reviews that prompted it filed beneath.
04Verify
One red review case is enough to hold the release back.
05Learn
It is kept for good, and the reviewing rules are amended in that same commit.
Learn → DetectThe return edge. The next review is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, review workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Review discovery and automation-boundary definition.
02Telemetry, deploy and tracker sources.
03Review-format and action-item-tracking rule mapping.
04Incident-record ingestion.
05Evidence binding and review logic.
06Confidence scoring and review routing.
07Engineer sign-off workflow.
08Tracker-and-incident integration.
09Cause and evidence cases.
10Guardrails and circulation controls.
11Review-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne service, one incident classProductionProduction review workflowAdvancedMultiple services / regimes
Introduced at Pilot
Reviews to your evidence rules✓✓✓
Named engineer sign-off✓✓✓
Incident-history baseline✓✓✓
Introduced at Production
Reporting by service class—✓✓
Owner review workflow in your systems—✓✓
Approved tracker write-back—✓✓
Telemetry-and-tracker integration—✓✓
Introduced at Advanced
Multi-regime review rules——✓
Cross-team review packs——✓
High incident volume——✓
Multi-service review controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, incident volume, review controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your live services and the incidents each one raises→Incident capture and review-rule versioningWeek 1
02Representative postmortems, tickets and telemetry→Evidence binding, causal logic and the review baselineWeek 2
03Your on-call rota and the service owners it names→Review-format mapping, evidence binding and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Telemetry, deploy and tracker assessment, then integration setupWeek 2
05Reviews you would not want disclosed→Evidence cases and the evaluation roundWeek 4
06What no review may conclude→Confidence scoring, review routing, guardrails and circulation controlsWeek 3
07A named engineer who signs the review→Release to the named reviewer, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Widths come from the work and not the grid, and week five carries two because both truly run there.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Review-workflow discovery, review rules and the automation boundaryW2Telemetry and tracker integration and the incident-history baselineW3Evidence binding, causal logic and circulation controlsW4Evaluation suite, evidence cases and failure-mode testingW5Tracker integration, pilot reviews and targeted correctionsW6One reliability quarter run under the service owner, then Agent Care handover
Reading the bandA band spans the weeks its own work is named in, and nothing else. The week five overlap is real.
At the end of W6Once the review record validates, Agent Care takes the agent on.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Engineering AI agent
Build a root-cause analysis agent around the postmortem your last incident left behind.
Show us one postmortem you would rather not produce, and the action item still open in it. It is read later by a regulator, by a plaintiff under FRE 801(d)(2)(D), and by whoever holds your job in six years. Aviation bought candour with statute; software bought a norm.
