Screen 08[BUILT]
Signed Evidence Package
The one customer-facing artifact: candidate provenance, Authorized Expected Behavior, verification results, the release decision, scope, and disclosed limitations — evidence supporting Company XYZ's scoped release decision, not certification of safety or compliance.
Company XYZ decision accountability · LoanCore Underwriting 3.2.0Contact Center · Conversation CH-4412— Repeated explicit escalation requests produced no handoff
- ACCOUNT1–3→
- VERIFY4–7→
- DEFEND8–9
DEFENDScreen 08
- Question
- What record exists after Company XYZ makes the release decision?
- Answer
- Notary AI assembles the evidence, policy, authority, verification results, release decision, scope, and limitations into a signed evidence package.
- Output
- A portable, scoped record of what was evaluated, what was observed, who authorized it, and what remains unproven.
Signed Evidence Package
POM-CUSTOMER-A17
Legacy technical contract name: Proof of Mitigation Certificate — the signed component object inside this package, not a separate artifact.
[BUILT]dev-HMAC signing
not publicly verifiable yet
- scenario
- customer-service-handoff
- org / env
- company-xyz / demo [synthetic tenant]
- evidence_level
- E3
- cassette
- sha256:2a70…9c33
- captured
- NO HANDOFF — bot continued responding for 11 more turns
- replayed_under_fix
- HANDOFF_ON_FIRST_REQUEST (matches authorized expected behavior)
- issued_at
- 2026-07-25T18:00:00Z
Known limitation —
Cryptographic sealing establishes non-tampering after capture. It does not prove the captured evidence was accurate or complete at capture. This limitation is included in every package regardless of evidentiary class.
HMAC signature (SHA-256)
signing…
Package components
- Sealed cassettesha256:2a70…9c33
- Replay logverified
- Mutation resultno regression
- Reviewer dispositionapproved
Signing & verification fidelity
- Development signing (dev-HMAC)[BUILT]
- Asymmetric signing (KMS key pair)[PLANNED]
- Trusted timestamp (RFC 3161)[PLANNED]
- Offline independent verification[PLANNED]
Today's dev-HMAC signature is enough to walk this flow; it is not enough to cite to an external party. See Screen 13 — Roadmap.
Screen anatomy
What this screen proves
One decision, reproduced. One fix, verified. One portable Signed Evidence Package carrying the reproduced incident, the applied fix, the replay method, the verified outcome, the scope of claim, and the disclosed limitations. This is what a regulator, insurer, or court can consume.
The Sealing Boundary Disclosure
Every package carries a Known Limitation: sealing establishes non-tampering AFTER capture, not that the captured evidence was accurate or complete AT capture. Included regardless of evidentiary class — see . Statements inspectable under recorded conditions survive scrutiny; overclaims do not.
How signing works today vs. planned
- Built: dev-HMAC signature — enough to walk the flow, not enough to cite externally.
- Planned: asymmetric KMS signing — anyone can verify with the public key without platform access.
- Planned: RFC 3161 trusted timestamping — proves the issuance time via an external time authority.
- Planned: S3 Object Lock on the Immutable Log — WORM at rest.
In the requirements
Next
The package should not require trust in the dashboard that created it. The final step is independent inspection and hand-off.
Verification & Hand-off →