What a reviewer actually needs to answer
When an examiner, auditor, or fiduciary reviews a material event — a waterfall execution, a valuation, a screening decision, an agent-proposed exception — they are really asking five things:
- Right data? Which inputs were used, identified by content digest rather than by filename.
- Approved model? Which registered engine version produced the result — again by digest, not by name.
- Policy respected? Which policy version was in force, and whether limits actually fired.
- Right authority? Which people approved the exact action, and how what the agent requested compares with what was executed.
- Reproducible? Whether rerunning the same approved engine on the same committed inputs gives the same answer months later. That holds for a deterministic calculation; it is not a claim about the agent’s narrative.
The Evidence Pack is structured so each of those questions maps to a field — not to a folder of emails and spreadsheets reconstructed after the fact.
What’s inside
Every material step emits a record. Here is a representative one for a waterfall execution:
// One governed waterfall run: attributable, reconstructable, reviewable { "workflow": "WATERFALL_EXECUTION", "proposed_by": "agent:credit-ops-copilot", "request": "run_waterfall", "input_commitments": [ { "type": "loan_tape", "commitment": "0x9f2c…" }, { "type": "servicer_report", "commitment": "0x41ab…" } ], "engine": { "version": "waterfall_engine_v1.4.2", "commitment": "0x77d1…" }, "policy_version": "eligibility_policy_v0.9.1", "policy_outcome": "PASS", "human_approvals": [ { "role": "CreditApprover", "sig": "0x…" }, { "role": "OperationsReviewer", "sig": "0x…" } ], "runner_receipt": "0x5c88…", "expected_steps_reconciled": "complete", "exceptions": [], "attestation_quote": null, // set only when execution is attested "output_commitment": "0xab12…" }
Field by field
- proposed_by & request — the agent or analyst that initiated the step, and the exact tool it asked for. The model proposes; it does not become the author of the result.
- input_commitments — content digests of the exact inputs. The raw data stays where it is; the digest proves which version was used.
- engine & policy_version — which registered engine, identified by digest, and which policy were in force at execution time.
- policy_outcome — whether limits passed, failed, or created an exception. Nothing silent.
- human_approvals — who authorized this exact action. Here, two roles under dual control, each signing the same bound request.
- runner_receipt — the signed receipt from the runner that executed the step, binding inputs, engine, environment, and output. Protected results come from here, not from the agent’s text.
- expected_steps_reconciled & exceptions — whether everything that should have run did, and what remains open. A skipped step is visible, not absent.
- attestation_quote — optional. When execution runs in an attested environment because the host or operator is part of the threat model, the hardware-backed quote goes here.
- output_commitment — the committed result. An optional shared-state checkpoint sits underneath only when another party must verify the same approved version.
Why “without revealing” matters
The pack is built on commitments and signed receipts, not raw records. An authorized reviewer can check reproducibility and authority without the underlying PII leaving its boundary — and a reviewer with the right entitlement can rerun the same approved engine on the committed inputs and confirm it matches the committed output. Disclosure depth is decided server-side by role, so no participant, and no AI agent, can widen its own access.
What the pack does not prove
Reconstructability is not correctness. A complete pack can prove that an approved engine ran on particular inputs under a particular policy, with named approvals. It cannot, by itself, prove that the engine is well designed, the policy is right, or the output is fit for its use. Those remain human judgments. The pack makes sure they are made against a record the agent cannot rewrite — and that the record exists when the run finishes, rather than being assembled under deadline.
See it on a real workflow
We’ll generate an Evidence Pack against a workflow you care about in a guided walkthrough.