Run report and handoff

By the end, you can

• Assemble a complete run report from a run's own history — what happened, the evidence that backs it, the disposition and its reasoning, and the residual risk — into one document a next owner can act on without re-deriving it (LA-4, LA-5).
• Write a named next owner and explicit, checkable fail criteria for a run report — who is responsible for acting, and the specific condition that would mean the decision needs revisiting (LA-4, LA-5).

Before you start

This is Module 5, Lesson 3 — the last lesson of the Local AI Agents course. It assumes everything the course has built: Module 4's evidence packet and disposition decision, Lesson 1's rollback-versus-revision choice, and Lesson 2's honest residual-risk statement. This lesson does not introduce new evidence or new judgement. It is the assembly step — turning a run's whole history into one report a person who was not there can read and act on.

A run report has five parts

A run report is not a paragraph of reassurance and it is not a full re-statement of every artifact in the evidence packet. It is a short document with five specific parts, each pointing at what already exists rather than repeating it at length.

The first four parts assemble what this course has already taught. The fifth is new, and it is what turns a report from a record of the past into something a reader can actually use going forward.

• What happened — the bounded task, in one or two sentences, and the disposition reached: accept, revise or roll back.
• Evidence — the specific artifacts from Module 4 that back the disposition: which diff, which test result, which command log, which review note, named specifically enough that a reader could go look at them.
• Disposition and reasoning — the decision and the reasoning behind it, per Module 4 Lesson 3: which criteria were checked, against what evidence.
• Residual risk — the honest, specific statement from Lesson 2: what remains unresolved, and the condition under which it would matter.
• Next owner and fail criteria — who is responsible if that residual risk becomes real, and the specific condition that means this decision needs revisiting.

Next owner: naming who, not "the team"

A residual risk that nobody is specifically responsible for tends to get quietly forgotten, however carefully it was written down in Lesson 2. "Next owner" means a named person or role — not "the team," not "someone should look into this." NIST's Appendix C states the standard this satisfies: "Human roles and responsibilities in decision making and overseeing AI systems need to be clearly defined and differentiated." A named owner is where that differentiation actually lands on paper — the specific person or role responsible for noticing if the residual risk turns into a real problem, and for acting on it.

Naming an owner does not require inventing new structure. It usually means naming whoever already has the closest relationship to the affected system: the on-call engineer for the service that changed, the maintainer of the file that was touched, the person who would be first to see the effect if the residual risk materialises. The test is simple: could this specific person or role plausibly notice and act, or is the name just a formality nobody expects to actually do anything?

Fail criteria: what would make this decision wrong, and who acts

Fail criteria are the specific, checkable condition that, if it occurs, means the disposition decided in this report should be revisited — not a vague "if problems arise." Google's Site Reliability Engineering practice models exactly this kind of pre-committed threshold, for a different purpose: an error budget is "the difference between" a service's reliability target and its actual measured reliability, decided in advance so that crossing it triggers a predetermined response rather than a fresh judgement call made under pressure. Fail criteria apply the same discipline to a run report's decision: decide, while writing the report, exactly what observation would mean "this decision was wrong," rather than leaving that judgement to be improvised later by whoever happens to notice something looks off.

A usable fail criterion has three parts: the specific condition to watch for, what it would mean if it occurred, and what should happen next. "If [specific, observable condition], then this decision should be treated as wrong, and [named owner] should [specific action]." This is the same forward-looking discipline Module 2's stop rules applied to a run while it was still in progress, applied here to a decision after the run has already ended and been handed off.

A worked example: a full run report for the request-timeout run

Returning to the request-timeout example this course has used since Module 4: a local agent raised a service's request-timeout constant from 5 seconds to 15.

What happened: the agent raised the service's request-timeout constant from 5 to 15 seconds. Disposition: accept.

Evidence: the diff shows only the timeout constant changed, nothing else in the config file. A test result shows the service starting successfully with the new value. A review note records a person weighing the diff and the test result against their knowledge of the service's downstream call pattern, and judging 15 seconds a safe change.

Disposition and reasoning: accept — every claim about the change is backed by evidence of a type that can actually settle it, and no unscoped or unexplained action appears anywhere in the record.

Residual risk: the change was tested against the local development server's startup behaviour only, not against production load or the service's slowest downstream dependency — so behaviour at 15 seconds under real peak load is unverified.

Next owner and fail criteria: next owner is the service's on-call engineer, named by role rather than "the team." Fail criteria: if requests to this service begin timing out or queueing under production load within the next release cycle, or if the downstream dependency's own timeout turns out to be shorter than 15 seconds — which would mean the new value does not actually help — the accept decision should be treated as wrong, and the on-call engineer should reduce the timeout or investigate further before the next release.

That is the complete shape this lesson has been building toward, and it is the run report's specific place in this course's final assessment. The assessment asks for four artifacts, not one: a bounded task brief (Module 2), a permission and data boundary checklist (Module 3), an evidence packet for a sample run (Module 4), and a disposition note with reasoning (Modules 4 and 5). The run report is the evidence, disposition and handoff layer of that set — it carries the packet, the disposition and this module's next owner and fail criteria, and it is produced alongside the task brief and boundary checklist, not instead of them. The exercise below practises exactly this lesson's contribution. Completing the course's final assessment shows that you can carry a bounded task from brief through evidence to a decision someone else can act on; it is not a credential or an accreditation, and it does not promise anything beyond that specific, checkable skill.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Site Reliability Engineering, Chapter 15: Postmortem Culture: Learning from Failure — Google SRE Book. Models a written record of what happened, its evidence and its follow-up actions — the shape this lesson's run report gives a single local-agent run.
2. Appendix C: AI Risk Management and Human-AI Interaction — NIST AI Resource Center. Calls for clearly defined, differentiated human roles — the standard a run report's named next owner exists to satisfy.
3. Site Reliability Engineering, Chapter 3: Embracing Risk — Google SRE Book. Models a pre-committed, measurable threshold decided in advance rather than judged by feel later — the same discipline this lesson applies to writing fail criteria before they are needed.
4. Guardrails and human review — OpenAI API documentation. Describes pausing a run so a person can decide — the handoff mechanism a run report's next owner and fail criteria put into a permanent, written form.