Illustrative human review packet
Article 2 companion · Illustrative example · Published October 9, 2026
Illustrative packet for candidate B. Its outcomes are stipulated in the example history, not measured. A production packet would replace the candidate labels and narrative observations with links to exact code and recorded outputs. Human acceptance is undecided.
Decision requested: assess whether the proposed storage-failure behavior and its supporting evidence are sufficient to accept this change, or identify the additional work needed.
Automated finding in the illustration: all eleven declared obligation cases matched their expected observations. This permits review under the example's policy; it does not establish complete intent coverage or authorize a merge.
Follow the requirement through the evidence
| Review item | Evidence or explanation |
|---|---|
| Required behavior | TD-08 in the contract excerpt: report a read failure and preserve original storage. |
| Proposed code change | In the story, B removes the storage write from the unsupported-data failure branch. An actual packet must link the exact changed lines and surrounding control flow. |
| Earlier defect | In the story, candidate A's observations show a correct error result, overwritten bytes and one unexpected save call. |
| Check applied | Four deterministic fixtures and their assertions. |
| Result after repair | In the story, B returns read-failure, preserves the original bytes and makes zero saves in all four fixtures. A real packet must link those recorded assertions. |
| Adjacent behavior | The story assumes a fresh passing evaluation of all eleven cases, including absent storage in TD-07 and failed-write handling in TD-09. |
| Failure-mode attribution | Unresolved. No construction trace has been supplied to attribute this illustrative defect to a catalogue entry. |
Where human attention is most useful
| Question for the reviewer | Why the current evidence leaves it open | What to inspect or decide |
|---|---|---|
| Does this behavior reflect product intent? | Tests implement the chosen policy; they cannot establish whether silently starting over, preserving data or offering recovery is what the user needs. | Confirm preservation and a distinguishable failure are appropriate. If a recovery experience is required, add it through design. |
| Does the application use the evaluated path? | The check calls the model through an injected storage interface. It does not establish every application's wiring or caller behavior. | Inspect the actual integration and error handling, or request an integration check where relevant. |
| Is the selected coverage sufficient for this change? | Four representative cases leave other shapes and real storage conditions unexamined. | Compare the change and operating conditions with the fixture inventory; request specific additional evidence if needed. |
| Does the evidence still match the code being reviewed? | A later edit can invalidate an earlier result. The teaching labels A and B provide no byte identity. | In a real packet, verify the candidate identity and check versions before relying on the results. |
These questions direct attention without making other code off-limits. The reviewer can inspect the preserved history and source as needed. An unresolved issue should be recorded with its consequence and next action, so it can return to Build, Human Design or the learning loop.
Record the human decision
| Field | Current value |
|---|---|
| Decision | Not made |
| Reasoning and evidence relied upon | To be supplied by the reviewer |
| Required follow-up | To be supplied by the reviewer |
| Accepted limitations | None recorded |
| Reviewer and time | Not recorded |
AI can prepare the links, summarize the failed and passing observations, and flag missing evidence. The person making the decision supplies the judgment and any acceptance of limitations. Whether this packet actually saves review time is a question for measurement.
Continue to the learning record.