The AI in the Room

Before the detail — Decision: let an assistant draft under Review mode with per-tool ask gates, never Autonomous, during a live incident. Outcome: faster first drafts of timelines, summaries, hypotheses, and comms — each one checked by a named person before it enters the record. Artifact: the record’s ai_drafted: marker — draft id, evidence referenced, verifier, verification time, and accepted changes — required by process on every AI-drafted Timeline or Decisions row. validate.py checks completeness and timestamp order once a marker or loose provenance field is present; it cannot detect a fully unmarked AI draft. Status of what follows: reusable guidance.

Prompt first: four drafts, none of them verified yet

Here is the raw material for this incident so far [paste: log lines,
the alert that fired, the chat transcript, anything already
mitigated] and the incident record's timeline table [paste section 3,
filled or empty].

Draft a TIMELINE from this material only - one row per event, with
the source line or message it came from. Where the material is
ambiguous or missing a timestamp, write MISSING; do not infer one.

Then, separately, draft: (1) a one-paragraph SUMMARY for the next
shift, (2) up to three ranked HYPOTHESES for the cause with the
evidence for each, (3) a first customer-facing STATUS UPDATE using
our comms template.

Do not mark any of this reviewed or verified. Propose a short draft_id
for this run and list the evidence_referenced you actually used (file
or message locations, not paraphrases) so both are ready to paste into
the record's ai_drafted marker. Leave verifier, verified_at, and
accepted_changes blank - I fill those in after I check your work
against the raw material.

Review mode, four drafting tasks

The assistant can read logs, rank hypotheses, and draft a first customer update well inside the calendar time a commander would spend on any one of them alone. Zero Trust 5.2 (a separate training in this series) drew the line this lesson inherits — the assistant triages, a human closes — and Grounded Answers adds the limit that comes with it: a citation makes a draft defensible, not correct. This lesson adds incident-time provenance: which evidence the draft used, who verified it, when, and what changed. The commander changes incident state, the clock desk records determinations, and the named signer sends required notices.

Reconstructing the timeline itself, in depth, is 5.2’s job, later in this training; drafting the comms update belongs to 4.3’s template. What this lesson owns is narrower and comes first: the mode the assistant runs in while it drafts any of that, and what the record has to say about it afterward.

The record’s provenance: what an AI-drafted row must carry

The record has no separate section for AI output, and it does not need one — any Timeline (section 3) or Decisions-under-uncertainty (section 4) row that an assistant drafted carries a compact marker appended to its own cell, on top of whatever the row already says:

ai_drafted: draft_id=<id>; evidence_referenced=<what it read>;
verifier=<human>; verified_at=<UTC instant>;
accepted_changes=<what changed, or "none">

All five fields — draft identifier, evidence referenced, verifier, verification time, accepted changes — are required whenever the marker appears. The committed NON-PRODUCTION example, INC-2026-041’s own record, carries the worked case at 14:31: an assistant drafted the first reconstruction of the incident timeline from the alert firings and the pool-saturation reading, and the row closes with

ai_drafted: draft_id=ai-2026-041-01; evidence_referenced=sim/replay.excerpt.jsonl#L61-L90, alerts/promtool.test.transcript.txt; verifier=j.whitfield; verified_at=2026-08-18T14:36:00Z; accepted_changes=corrected the deploy timestamp and the first observed 504

Five minutes between the draft and j.whitfield’s check, two corrections found and named — the deploy timestamp and the first observed 504 — that gap is the verification the marker exists to prove happened, not just assert.

incident/validate.py checks completeness and timestamp order once a marker or loose provenance field is present: all five fields when the marker appears, a verified_at that is not earlier than the entry’s own timestamp — verification cannot precede the draft — and a row that carries one of these field names as loose text with no ai_drafted: marker around it fails closed, because a dropped tag is not a way to skip verification. The self-test proves the rule holds: 38 mutations, three of them this one, all 38 caught — but the check only runs once a marker or loose provenance field is present; a fully unmarked AI draft is invisible to it, which is why marking is a process rule the assistant is prompted to start, not a safety net the validator supplies on its own.

Writing the marker costs the verifier verification effort per drafted item; skipping it costs a reviewer assessor-hours reconstructing, after the fact, which parts of the record came from a person watching the system and which came from a model reading about it.

One cloud provider’s SRE agent, and what “Review mode” actually means

The categories here are worth more than any one product, but a dated example makes them concrete. One cloud provider’s SRE agent (generally available per a page dated 2026-08-26) “suggests or, when configured, executes mitigations.” Its two modes are named plainly: “In Review mode, an SRE Agent Administrator approves the write actions that require approval before the agent runs them. In Autonomous mode, the agent applies them without waiting.” Underneath both modes sits a per-tool setting — “allow, ask, or deny” — so the same agent can be trusted to read logs freely while every write action still waits on a person.

As of 2026-08-28, Datadog’s fetched Bits Investigation description says it shares findings for engineers to review; treat that as vendor-described behavior, not proof of every capability boundary. Resolve AI says it “autonomously troubleshoots and resolves production issues”; without an independently published method, treat that only as vendor positioning, not a benchmark.

This training teaches Review mode with tools set to ask, full stop. Autonomous mode is a real, named setting — not a hypothetical — and it is the door Training 09 opens, where standing per-action authorization is the whole subject. Whether an assistant may run inside Meridian’s environment at all is a different question still, decided upstream by AI Assurance’s authorization boundary. This is a CROSS-TRAINING HANDOFF, not a federal seam: no clause, no regulator, no determination changes hands here — just a mode setting this training stops short of, and names the training that picks it up. Naming the boundary here is what keeps anyone from discovering mid-incident that “the AI” quietly had standing authority nobody signed off on.

What has not happened yet

State this plainly, because the marketing in the previous section makes it easy to lose: no verified public case exists, as of 2026-08-28, of an AI assistant misleading incident responders during a live response. Every claim circulating about an assistant’s reliability — including the ones quoted two paragraphs up — comes from the party selling the product. That is not a reason to trust the claims; it is a reason to notice that the absence of a documented failure and the presence of a confident one are not the same fact, and only one of them is currently on record.

Teaching the absence honestly, instead of inventing a cautionary story to fill the gap, is the same discipline this lesson has been asking for all along: a hypothesis with no evidence does not become true because it would make a better lesson.

Stop and escalate when anyone on the call proposes moving a tool’s setting from ask to allow, or switching the assistant to Autonomous mode, to move faster mid-incident. That is not the on-call commander’s call to make alone at 03:00 — it is Training 09’s autonomy question and AI Assurance’s authorization boundary, and it routes to whoever owns those decisions outside the incident, not to whoever is fastest to type “yes” on the call.

Key takeaway

An assistant in Review mode, with tools gated to ask, can draft a timeline, a shift summary, ranked hypotheses, and a first comms update faster than the room can read the raw logs — and grounding is not truth for any of the four: a citation makes a draft defensible, not correct, and closing actions stay a named person’s to take. The record carries that provenance in the ai_drafted: marker on the row itself — a draft identifier, the evidence referenced, the verifier, the verification time, and what was corrected — rather than in a section of its own, and validate.py fails closed on a marker missing a field or a dropped tag. Autonomous mode is real and named; this training stops at its edge and hands the CROSS-TRAINING HANDOFF to Training 09, while AI Assurance keeps the separate question of whether the assistant may run at all. No verified case of a misleading assistant exists today — say so, and do not invent one. The next module turns from the room during the incident to the clocks that started running the moment it began.

LEADERSHIP DECISION   authorize incident-time AI assistance in Review
                      mode only, tools gated to ask, with every draft
                      the record keeps carrying a named verifier
PRACTITIONER ACTION   draft timelines, summaries, hypotheses, and
                      comms with the assistant; verify each against
                      the raw material and attach the ai_drafted
                      marker before it enters the record; never move
                      a tool to allow or the agent to Autonomous
                      mid-incident
SUCCESS MEASURE       zero record entries with an AI-drafted origin
                      and no named verifier - every draft either
                      verified and kept, or discarded