E015 evidence an auditor checks
without trusting you, or us.

The case

LN-30417. After storm-related income disruption, a credit model recommends withdrawing a pre-approved loan offer. A lending officer checks with the employer and approves a smaller amount instead. The scenario is fictional. The seals and the public log entries are real.

1. Step 1Credit model recommends withdrawalser_a383778f88ae4f060279d8ba137926f8Rekor log index 3247822463 · logged 2026-10-14T02:19:05Z
2. Step 2Lending officer approves a reduced amountser_5086c93c22af206a567fa06cf634682eRekor log index 3247822472 · logged 2026-10-14T02:19:06Z

Open the case and verify it in your browser → Download the evidence map (JSON) for your workpapers →

How it lines up

Each control below, as AIUC-1 labels it, with what this sample gives you and what stays with the team you audit.

• E015.1Logging implementationIn the sample
  E015 Log AI system activity (mandatory, every 12 months) · Core · “should include”
  What the sample showsExample log entries. Each record holds the input and output summaries, the source system, the model version, the review state, the caller's event time and Verdict's receipt time, all inside the hashed content.

  What stays with your teamThe logging code or configuration that decides what is captured, and when your system calls Verdict.
• E015.2AI agent logging implementationPartly in the sample
  E015 Log AI system activity (mandatory, every 12 months) · Supplemental · “may include”
  What the sample showsAn approval event linked to the step before it. Step 2 holds the reviewer's role and decision, and carries step 1's commitment inside its own hashed content, so step 2 was made after step 1.

  What stays with your teamTool-call parameters and results, sub-agent handoffs and reasoning traces, which your agent framework records.
• E015.3Log storageNot covered
  E015 Log AI system activity (mandatory, every 12 months) · Core · “should include”
  What the sample showsNothing. The public sandbox stores no records and keeps no copy.

  What stays with your teamRetention periods, access control and masking for the records you keep.
• E015.4Log integrity protectionPartly in the sample
  E015 Log AI system activity (mandatory, every 12 months) · Supplemental · “may include”
  What the sample showsCryptographic hashing of each entry, with the commitment logged on Sigstore Rekor, a public log Verdict does not run. Anyone can recompute it. An edited record no longer matches the log entry made when it was sealed.

  What stays with your teamSequence integrity across the whole log. The standard's example asks that gaps, omissions and reordering be detectable. Verdict does not detect a missing record today.
• D003.4Human-approval workflowsSupporting only
  D003 Restrict unsafe tool calls (mandatory) · Core · “should include” · Moved from supplemental to core in the October 15, 2026 release
  What the sample showsA sealed record that an approval decision was logged, with the reviewer's role, and when it was logged.

  What stays with your teamThe approval workflow itself: its configuration, code or ticketing, and what it holds back until a person confirms.

Check it yourself

Needs git, curl, Python 3, openssl and a network connection. Run end to end on 2026-10-20. The verifier is Verdict’s code, one file of standard-library Python plus openssl, so read it before you trust it. Rekor and its key are Sigstore’s.

1. 1.Get the open verifier and the two records.
   Command 1a

   git clone https://github.com/verdictsystems/ser-specCOPY
   Command 1b

   curl -sO https://verdict.systems/samples/ser_a383778f88ae4f060279d8ba137926f8.jsonCOPY
   Command 1c

   curl -sO https://verdict.systems/samples/ser_5086c93c22af206a567fa06cf634682e.jsonCOPY
2. 2.Take Rekor's public key from Sigstore's own repository, not from the log being checked.
   Command 2

   curl -sL https://raw.githubusercontent.com/sigstore/root-signing/main/targets/rekor.pub -o rekor.pemCOPY
3. 3.Check each record: its content and commitment, the Rekor entry and its signature, Rekor's signed entry timestamp, the inclusion proof and the signed checkpoint. Each run ends with "RESULT: content self-consistent and anchor confirmed".
   Command 3a

   python3 ser-spec/tools/verify.py ser_a383778f88ae4f060279d8ba137926f8.json --anchor --rekor-key rekor.pemCOPY
   Command 3b

   python3 ser-spec/tools/verify.py ser_5086c93c22af206a567fa06cf634682e.json --anchor --rekor-key rekor.pemCOPY
4. 4.Confirm the link: step 2 names step 1's commitment inside its hashed content. It prints True.
   Command 4

   python3 -c "import json; a=json.load(open('ser_a383778f88ae4f060279d8ba137926f8.json')); b=json.load(open('ser_5086c93c22af206a567fa06cf634682e.json')); print(b['record']['metadata']['prior_merkle_root'] == a['merkle_root'])"COPY

What this sample does not show

Each of these is a limit of the public sandbox today.

• Who made either record. The public sandbox signs each request with a one-time key that names no one. A published registry of signer keys is planned. Until it ships, a record does not identify its maker.
• That no record is missing or out of order. A record can name the one before it, but no public verifier walks a sequence and nothing marks where a sequence ends. A dropped or reordered record goes unnoticed.
• That every consequential action reached Verdict. Nothing is sealed unless your system calls Verdict. Whether every approval and sensitive tool call is sent is a property of your system, and an auditor should test it like any other logging control.
• That the events happened as described. A record shows what was sent and, through its log entry, when it was logged.
• Anything outside the record block. chain_of_custody, legal_review, notice and surface are display copies outside the hash, and the verifier says so. Read the values inside record.

What a Verdict record proves, and what it doesn’t →

Working with us