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 → Workpaper package for auditors: reading guide, eleven test procedures, specimen, request list → Watch the 4:20 film for auditors →

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 teamThe approver's identity: the sample names the reviewer's role, not the person. Agent provenance metadata, tool-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 protectionIn 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. The chain check then walks the two records: each names the one before it inside its hashed content, the steps run 1 to 2, the records commit to a length of 2, and each was logged no later than the next. A missing, reordered or dropped record fails that check.

  What stays with your teamA fork. A second record sealed off the same predecessor is not visible to this check until a chain head is published. Keeping every record available to the auditor is the storage control, E015.3.
• D003.3Tool call logNot covered
  D003 Restrict unsafe tool calls (mandatory, every 12 months, for agents that take actions) · Core · “should include”
  What the sample showsNothing. A record is sealed when your system sends a step. It is not a log of each tool call.

  What stays with your teamThe tool-call log: the originating MCP server, the tool name and version, the input parameters and a timestamp for each call, with alerts on unauthorized attempts.
• D003.4Human-approval workflowsSupporting only
  D003 Restrict unsafe tool calls (mandatory, every 12 months, for agents that take actions) · 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.

AIUC-1’s own E015 page cross-references EU AI Act Articles 12 and 19, ISO 42001 A.6.2.8, NIST AI RMF MEASURE 2.4 and 2.8 and SOC 2 CC2.1, P4.2 and PI1.5. The crosswalk is AIUC’s, not Verdict’s. In AIUC’s joint SOC 2 and AIUC-1 engagement, auditors typically share one request list and overlapping requests are submitted once.

Where it sits in an AIUC-1 audit

Six facts about how an AIUC-1 audit runs, paraphrased from AIUC’s public pages for accredited auditors, read on 2026-11-12. They are AIUC’s statements. Each links to its source.

1. 01 · Requirements in scopeSupplemental controls are a choice.E015.2 and E015.4 are supplemental. A team opts in to them on its Statement of Applicability, and can do so until the evidence pack is handed to the auditor. AIUC's guide says opted-in controls are highlighted in the audit report.Read it at standard.aiuc-1.com →
2. 02 · Auditor fieldworkThe core controls carry the verdict.A Pass on E015 rests on its core controls, E015.1 and E015.3, or on alternative evidence the auditor accepts. A sealed record is not a storage control, so it does not carry E015 by itself.Read it at standard.aiuc-1.com →
3. 03 · Auditor fieldworkThe audit is point in time.AIUC-1 audits assess controls at a point in time, and the auditor gives no opinion on a historical record of compliance. A record's log entry shows when that one record existed. It does not widen the audit's opinion.Read it at standard.aiuc-1.com →
4. 04 · Requirements in scopeThe version is fixed at kickoff.Audits run against the latest release, with a grace period of up to 30 days, and the version stays fixed through fieldwork and the report. This page is written against the October 15, 2026 release. The next is due January 15, 2027.Read it at standard.aiuc-1.com →
5. 05 · Evidence collectionEvidence goes to a shared platform.The team uploads its evidence pack where the auditor and AIUC can reach it. AIUC's guide names Drata, Vanta and Fieldguide as examples. A sealed record and the evidence map are JSON files and upload with the rest.Read it at standard.aiuc-1.com →
6. 06 · Maintaining certificationAIUC runs the technical evaluations.Third-party testing, including E018 for accountability risk, is run by AIUC today and repeated on a subset each quarter. Verdict's Acceptance Test is not that testing and does not count toward it.Read it at standard.aiuc-1.com →

Check it yourself

Needs git, curl, Python 3, openssl and a network connection. Run end to end on 2026-11-12. 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.Walk the chain: step 2 names step 1's commitment inside its hashed content, the steps run 1 to 2, the declared length matches, and each record was logged no later than the next. It ends with "RESULT: chain of 2 records intact: each record self-consistent and anchored, each names the one before it, steps 1..2 unbroken". Change one character in either file and it fails.
   Command 4

   python3 ser-spec/tools/verify.py --chain ser_a383778f88ae4f060279d8ba137926f8.json ser_5086c93c22af206a567fa06cf634682e.json --anchor --rekor-key rekor.pemCOPY

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.
• Who approved. The approval record names the reviewer's role and decision, not the person. AIUC-1 lists approver identity among the evidence for E015.2. It comes from your approval workflow.
• A fork, or records past the end. The chain check catches a missing, reordered or dropped record among the records you hold, against the length they declare or a head record held separately. It does not see a second record sealed off the same predecessor, and a chain with no declared length or held head can be cut after the last record you hold.
• 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