Illustrative walkthrough using seeded data. Product capabilities are marked Built or Planned.
NOTARY AI
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.0Healthcare Prior-Auth · PA-8843— Auto-determination issued without clinician review evidence
  1. ACCOUNT1–3→
  2. VERIFY4–7→
  3. DEFEND8–9
  1. ✓Connect→
  2. ✓Landscape→
  3. ✓Readiness→
  4. ✓Scenarios→
  5. ✓Authorize→
  6. ✓Verify→
  7. ✓Release→
  8. 8Package→
  9. 9Hand-off
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-PRIOR-AU-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
prior-auth-denial
org / env
company-xyz / demo [synthetic tenant]
evidence_level
E4
cassette
sha256:6b41…c02e
captured
AUTO-DENIED
replayed_under_fix
ROUTE_TO_CLINICIAN_REVIEW (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…
→ Add to → Push to
Package components
  • Sealed cassettesha256:6b41…c02e
  • 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 →