The evidence pack: what must exist before each AI hand-off

In this lesson you'll learn:

• what makes an artefact owed rather than merely useful;
• the minimum set at each of the four hand-offs, and the test for each;
• why "enforced, or only written?" is the most important column in the pack.

Sound familiar?#

• An auditor asks why the refund cap is $400, and the answer is in somebody's memory.
• A new engineer spends the first week asking questions the design documents should have answered.
• Every document exists, every checkbox is ticked, and the control it describes still failed in production.

The pack exists for all three, and the third is why existence is the weakest thing you can check.

What is the evidence pack?#

The evidence pack is the minimum artefact set of the agentic PDLC: the few documents owed at each hand-off between phases. Together they are what you show an auditor, a new team member, or yourself in six months when nobody remembers why the cap is what it is.

An artefact is owed when the next phase cannot start properly without it: the test is not whether someone wants it, but whether the next phase would otherwise have to invent it. Everything else is optional: keep it if somebody reads it, delete it if not.

Build the pack, step by step#

Step 1 · Sort every document into one of four states#

The dangerous state is the second one. A stale artefact passes every check that asks whether a document exists.

Step 2 · Check each hand-off against its test#

Each hand-off has a one-line test, drawn in the map at the top, which also counts what each one owes: seven artefacts at P0 → P1, nine at the hard gate, eight at P2 → P3 and six at P3 → P0. The two tests that matter most:

• P0 → P1. Can the architect start designing without asking the product manager a question?
• P1 → P2, the hard gate. Hand the pack to an engineer who was not in the room. If they can build the first bolt without a conversation, the gate is passable.

Step 3 · Add the column nobody adds: enforced, or only written?#

For every control an artefact describes, record where it should live and run a command that proves it does. A cap belongs in a tool signature; an approval rule belongs in the tool and the access policy; "the bar blocks the merge" belongs in branch protection.

Any control found only in a prompt, a runbook or a document is not enforced, and the pack says so in capitals. SkyWays crossed its hard gate with the authority budget written and not enforced; on day 82 a $2,000 refund went out that the budget forbade. This single column is the difference between a gate and a formality.

Step 4 · Date every artefact#

Give every row a version and a last-changed date, and ask at each review whether the system has moved past it. A spec at version 3 while the code is on the behaviour of version 7 is an owed artefact in the stale state, and it is the one a new engineer will trust.

Step 5 · Keep it on one index page#

The pack is one page: one row per owed artefact, with its hand-off, owner, link, version, last-changed date, whether it is current, and who has read it. Everything else is a link from it. A pack that is a folder of documents is a pack nobody reviews.

Where you'll use it#

• At every hand-off, as the checklist the receiving owner signs.
• Before an audit or a regulator's question, as the answer that does not depend on who is in the room.
• When onboarding an engineer or a new agent session, as the reading list that lets them start.

Why it matters#

The pack is the difference between a decision that was made and a decision that was kept. Most of what goes wrong in an agentic system was decided correctly somewhere (the cap, the approver, the bar) and then never enforced, or enforced once and allowed to go stale.

Key takeaways#

1. An artefact is owed when the next phase would otherwise have to invent it: thirty across four hand-offs.
2. Stale is the dangerous state: date every artefact, because existence checks pass it.
3. "Enforced, or only written?" is the column that turns the pack from paperwork into a gate.

FAQ#

What documentation does an AI project need?#

The minimum is what each phase owes the next: the measured pain, AI-fit verdict, value line and autonomy decisions from framing; the spec, bar sheet, decision records, authority budget and first fifty golden cases from design; the proof and cut-over plan from the build; and the two-number report, drift readout and incident briefs from operation.

What is an AI audit trail?#

A record that lets someone reconstruct, later, what a system decided, why, and under whose authority. In the evidence pack it is the dated index of owed artefacts plus the redacted trace of every consequential action: which model and prompt version decided it, what it did, and who approved it.

How is the evidence pack different from a definition of done?#

A definition of done applies to a piece of work; the evidence pack applies to a hand-off between phases. It also asks a question a definition of done rarely does: whether each control that a document describes is actually enforced.

Is this only for regulated industries?#

No. The pack is small on purpose (thirty short artefacts, most of them one screen) and the enforcement column pays for itself the first time it finds a cap that lives only in a prompt.

Apply it in your role#

Across the enterprise. Make the evidence pack the unit of audit: the same index for every product, so an internal auditor can read any team's agent in an hour.

The ten-minute workflow. Check that the controls you describe are the controls you run:

Here is our evidence pack index: <paste>, and the repository is attached. For every control the pack
describes (caps, redaction, gates, bars) find where it is enforced in code and quote the line.
Mark each: enforced with a test, enforced without a test, described only, or missing.

Sources and credits#