Appendix F. Evidence-Package Template

F.1 What an evidence package is

An evidence package is what an agent's change must carry for a person to decide whether to merge it. It replaces "here is a diff" with "here is the change, the proof, and what was left alone" (Chapter 12). The reviewer inspects evidence, not only code. Prediction P9 is that this finds more seeded defects per reviewer-hour than reading the raw diff.

One package per change. Either the agent drafts it and a person checks it, or a person writes it. In both cases a named human is responsible for its contents.

F.2 Skeleton

EVIDENCE PACKAGE    ID: ____   Spec / mission ID: ____
1. THE CHANGE        summary, files touched, lines added/removed
2. INDEPENDENT RESULTS   commands, who ran them, commit, output
3. ACCEPTANCE PROPERTIES  property -> check -> result -> link
4. NON-CHANGES        what was in reach and left alone, and why
5. SURPRISES          anything unexpected, found or done
6. PROVENANCE         the trailer keys of Section F.4
REVIEWER DECISION: merge / revise / reject
Named human: ______   Date: ______   Reasons: ______

F.3 The six parts

1. The change. What the change does, in a paragraph a person can check against the diff. List the files touched and the size. State which specification items it implements. If the summary says more or less than the diff does, that is the first thing to look at.
2. Tests and results, run independently. The commands, the commit they ran against, and the output, from a run the author did not control: a clean checkout, in CI, or by the reviewer. A test result the agent reports about its own work is a self-report, not evidence (Chapter 16, condition 2). A run outside the author's control separates the evidence from the author; it does not make the check statistically independent of the generator's blind spots.
3. Acceptance properties, each bound to a check. Every property the change must satisfy, paired with the check that tests it. A property with no check is not yet a property of the system. Use Table F.1.
4. Manifest of deliberate non-changes. What the change could have touched but did not (public interfaces, tests, configuration, dependencies, neighboring modules), and why. The reviewer compares the manifest with the diff. Anything in the diff that the manifest or summary does not explain is a finding.
5. Surprise log. What the author did not expect: a failing test that passed on rerun, a library behavior that differed from its documentation, an assumption that turned out to be wrong, a step the agent skipped. An empty surprise log from a nontrivial change is itself a flag.
6. Provenance trailer. Who and what produced the change (Section F.4).

Table F.1. Binding acceptance properties to checks (one illustrative row).

Fill in one row per property. The last column is yes only if the check was written and run without relying on the agent's own tests.

F.4 The provenance trailer

Every agent-authored commit carries these trailers, in the form Chapter 14 defines (Section 14.5.2). A trailer is a key: value line at the end of the commit message.

Mission: <spec or work-package ID, with version>
Agent-Model: <exact model ID reported by the harness>
Agent-Harness: <harness name and version>
Baseline: <baseline ID, e.g. B-007>
Autonomy: <tier and mode, e.g. tier-1, pull-request-only>
Evidence: <path or link to the evidence package>
Directed-by: <named human who directed the work>
Approved-by: <named human who approved the merge>

Trailers point; the baseline manifest (Appendix C, Section C.3) and the evidence package hold the detail, so no trailer repeats a digest. The harness writes the trailers, and a CI check rejects a commit that lacks a required key, names a baseline that does not exist, or carries an evidence link that does not resolve. A trailer the agent writes itself is a self-report.

Directed-by is the person who directed the work. Approved-by is the person who read the evidence and merged the change; it is recorded separately, even when the same person did both, and it is never an agent.

F.5 Reviewer's checklist for agent defect classes

This checklist is generic; Chapter 12 develops the defect classes (Table 12.3) and the rates at which to inspect, and Table B.1 shows how they map to the root-cause codes. Work through the groups in order. Answer each question with evidence, not with a feeling.

Does it exist?

• Does every function, method and endpoint called actually exist in the version of the library you use? Check against the documentation or the installed source.
• Does every imported package exist, from a source you recognize, at a version in the lock file? Be suspicious of a package you have never heard of.

Does the test test anything?

• Does each new test contain an assertion about a result? Would it fail if the code under test returned the wrong answer?
• Were any existing tests, expected values or fixtures changed in this diff? If so, why, and who approved it?
• Did the author's tests encode the same misreading as the code? Check the edge cases (dates, time zones, empty input, limits) against the specification yourself.
• Where available, does mutation testing show the tests catch seeded faults?

Does it do only what was asked?

• Does every line of the diff appear in the summary or the non-changes manifest?
• Are there new dependencies, configuration changes, permissions or network calls not requested?
• Was any code deleted, disabled or commented out to make something pass?

Does it do what was meant?

• Where the specification was ambiguous, which reading did the agent choose, and was that choice visible to you?
• Is every authorization or validation rule enforced where it matters (in the API as well as the interface)?
• What happens on the failure path, not only the happy path (errors, timeouts, partial failure)?

Is the evidence outside the author's control?

• Were the results produced somewhere the author could not alter?
• Does the verifier share a model, a prompt or an assumption with the generator? If so, do not count its agreement as a second, independent check. Ask what it found that the generator's own checks missed (incremental detection, Chapter 16, condition 1) and, where you have the data, how often both missed (Chapter 15).
• Is any claim in the package supported only by the agent's own statement?

F.6 Recording the decision

Record the decision on the package: merge, revise or reject, with reasons, your name and the date. Log the review time in the work log under review (Appendix B), and record any defect you find with its root-cause code (Table B.1). If an AI reviewer took part, record what it found that the human review and the CI checks missed, and what all of them missed. Those records are the data for P9.