Evidence for auditors: reading an elan1 proof record

An auditor asked to rely on an AI agent’s change needs three things: who proposed it, under which rules it was checked, and who approved it. This brief shows where each answer sits in an elan1 proof record, and how to test that the record has not changed since it was sealed.

It covers the L1 Guarded checks you can run yourself, the evidence bundle and offline verifier of L2 Attested, and a plain table of what verification proves and what it does not. It is written to be handed to an audit team without a sales conversation.

When an AI agent changes a ledger, an invoice or a claim, the audit question is familiar even if the actor is not. Was the change authorised? Was it checked against the rules in force? Is the evidence complete, and has it been altered since? An application log can answer some of this, but rarely all of it, and almost never in a form an auditor can test without trusting the system that wrote it.

An elan1 proof record answers those questions for one kind of event: a consequential write that took the governed write path. Every such write — committed, refused or expired — produces exactly one record of sixteen fields, written synchronously before the caller receives its answer, and chained by hash to the record before it in the same tenant.

It is evidence about the control, not about the transaction. It tells you that a write was proposed, checked against named rules at a named version, decided by a named actor at a named autonomy level, and recorded at a stated time. It does not tell you that the invoice was genuine or that the journal entry was the right one. That distinction runs through every section of this brief.

Seal v6 fixes the record at sixteen fields: no optional fields, no seventeenth field, no minor versions. Refusals carry zeroes, not omissions, so every record has the same shape. Figure 1 groups the fields by the question they answer; the table below gives each one the question an auditor should put to it.

Three fields that matter most

F07 declaration_version and F08 policy_version let you replay a decision against the rules that were in force, rather than the rules as they are today. Ask for the declaration at that version; every version is retained, and changing a declaration is itself a governed write.

F11 autonomy_level, read with F10 actor_kind, tells you whether the actor was permitted to act alone. An agent at A1 or A2 cannot commit a write without a person; a committed record whose actor is an agent at those levels is an exception.

F14 payload_hash holds a hash of the payload, not the payload. Personal data stays in your system of record, under your retention and erasure rules. To test it, obtain the payload from the system of record and hash it in the canonical form the declaration’s proof_binding block specifies. The canonical form is declared per write type; the exact procedure comes with the verifier.

Each record’s digest is SHA-256 over a preimage: the 19-octet domain string elan1.proof.seal.v6, followed by the sixteen fields in order, each with its length in front. Length-prefixing means there is only one way to read the bytes, so two different records cannot serialise to the same preimage. In the site’s inspector each field is written as a 4-octet big-endian length and its UTF-8 bytes; the normative encoding is the one published with Seal v6.

1. 01

   Build the preimage of record n

   The domain string, then the sixteen fields of record n in order, each length-prefixed.

   Check You have one byte string per record; field order follows F01 to F16.

2. 02

   Hash it with SHA-256

   The result is record n’s digest.

   Check A 64-character hexadecimal digest.

3. 03

   Compare with F03 on record n + 1

   The digest must equal F03 prev_digest on the next record, octet for octet.

   Check Identical. Any difference is an exception at that link.

4. 04

   Check F02 on record n + 1

   seq must be exactly one more than on record n, in the same tenant (F01).

   Check No gap, no repeat, no reordering.

5. 05

   Repeat across the population

   Walk the whole chain for the period, from the first record to the last.

   Check Every link holds and the sequence is unbroken.

What a break looks like

The kernel’s own conformance test C9 plants four faults — a flipped octet, a reordered pair, a duplicate and a gap — and requires each to be found. An auditor walking the chain sees the same four signatures:

A hash chain shows that something changed to anyone who holds an earlier digest. On its own, it does not stop a party with full control of the store from rewriting a stretch of history and recomputing every digest after it. If you have kept digests — in a prior-period working paper, an export, a report — you would see the break. That is the honest scope of L1: tamper-evident to you, the holder of the records.

Evidence rows cannot be updated or deleted, and the kernel is the single writer. Those design facts make tampering harder. They are not something a third party can check without elan1, which is why they are not the claim. At L1 you recompute the chain on records elan1 provides; the provenance of those records rests on elan1.

L2 Attested sits on the same write path, the same sixteen fields and the same packs. It adds exactly four things, so that someone who does not trust elan1 can check a record without us.

• Signing. From L2, each record’s digest is signed with Ed25519, against the key of the residency domain it was written in — “in” for India.
• Anchoring. Records are batched into Merkle roots, anchored to two independent RFC 3161 timestamp authorities, one of them in India, within 15 minutes. An anchor shows that a record existed, in that form, by that time. It is not a blockchain.
• Verifier profiles. A profile binds a regime’s clauses to write types, gates and record fields, by name. Profiles are listed per pack; the ledger1 pack carries one for the MCA audit trail.
• The evidence bundle. One folder, exportable for a period or a set of records, that needs nothing from elan1.

The free offline verifier, elan1-verify --bundle <path> --profile <path>, has no dependencies, needs no network and no account, and is built so anyone can reproduce the build. It reports one of six results: PASS, FAIL_INTEGRITY, FAIL_PROFILE, INCOMPLETE, UNSUPPORTED or USAGE. You or your auditor can run it on an air-gapped machine, without us.

Audit sampling usually starts with an act of faith: that the population you sample from is complete. The chain removes most of it. Because F02 rises by exactly one and every F03 links to the record before, you can show that no record is missing between the first and last sequence numbers of a period before you draw a sample (Figure 3).

Establishing the population

Fix the period by F16 recorded_at, then take the first and last seq inside it. Walk the chain between them as in section 3. Then reconcile in both directions. The kernel itself reconciles meter events, proof records and the target system (conformance test C10); the auditor’s version of that test is simpler:

• Records to the system of record. Every committed record should match a change in the target: F12 record_id at F13 record_version.
• System of record to records. Every change to a governed record type in the target should have a committed record. In Mode A, a change with no record is a significant exception. In Mode B, it is expected to be possible, and is the main limit of the evidence (section 8).
• Records to the meter. Committed records should equal governed actions on the invoice; each refusal appears as 0.4 of a governed action.

Stratifying

A useful stratification follows the fields: by F05 write_type, by outcome, by F11 autonomy level, and by F10 actor kind. Writes committed by agents acting alone (A3 to A5) and writes committed by a person after an escalation are different control populations and deserve separate samples. Include refusals and expiries in the frame; they are evidence too (section 7). How many items to select is a matter for your own methodology.

Testing a sampled item

1. Obtain the declaration at F06/F07 and confirm it was in force at F16.
2. Confirm F05 is on that declaration’s list of write types.
3. Confirm F11 permitted the F10 actor kind to act as it did; for an approved write, confirm the approver was named in the declaration and was not the proposer. The approval request is linked by F04 write_id.
4. Trace F12 and F13 to the system of record; recompute F14 from the payload there.
5. For a refusal, confirm that no corresponding change exists in the target.

A control that has never said no is hard to distinguish from a control that cannot. Refusals are how the record shows that a rule was applied, not only written. For that reason a refused write leaves the same sixteen-field record as a committed one, sealed into the same chain.

A refusal record is recognisable by its zeroes: F12 record_id is zeroed and F13 record_version is 0, because nothing changed. Beside the record, the rendering strip shows the refusal code from a closed register and the rung where the write stopped. The meter shows 0.4 of a governed action, always less than an allowed write, so a refusal never costs more than letting the same write through.

Two points of reading. First, a write that is held for approval has no record yet; exactly one is sealed when it resolves — committed, refused or expired. A period-end cut-off may therefore show writes that are still pending; ask for the held queue at the cut-off date. Second, refusal codes shown on this site, such as GATE.PRECONDITION_FAILED, are illustrative; the closed register is part of KernelPort v1 and is shared with customers.

The mode decides the coverage of the evidence, and it is the first thing to establish for any system under review.

In Mode A, elan1 holds the write credential through a single writer with a single-use credential that lasts 10 minutes. No write reaches the system of record without a gate decision and a proof record. Only in Mode A do we say “enforced”. A change to a governed record type with no matching record is therefore a significant finding: it means a write took a path the architecture says does not exist.

In Mode B, elan1 is reached over MCP or HTTP and does not hold the credential. Every write intent the caller sends is evaluated and recorded, and the caller makes the write itself. A Mode B record shows what elan1 was asked and what it decided. It cannot show that the caller asked every time, or that it honoured a refusal.

Ask the system owner which consumers connect in which mode. Hosted elan1 Work on ERPNext runs in Mode A. elan1 Work Attach, elan1 Decide and elan1 Run tooling run in Mode B. Third-party agents run in Mode B, or Mode A by agreement after conformance tests C1–C14 pass.

Reading record 1041: a refusal

An agent, agt_specimen_ap01 at autonomy A1, proposed purchase_invoice.post under declaration decl_ap_purchase version 4 and policy 2027.06.1. F12 is zeroed and F13 is 0: nothing changed. The rendering strip shows the outcome “refused at rung 3” with the illustrative code GATE.PRECONDITION_FAILED from G9, and 0.4 of a governed action on the meter. No approver is shown, because the write stopped before approval.

Tests: confirm declaration 4 was in force at 10:39:12 +05:30; confirm no purchase invoice was posted for wr_specimen_7c1; note the refusal in the population of refusals.

Reading record 1042: an approved commit

A person, usr_specimen_approver, committed journal entry je_specimen_5531 at version 2 under decl_month_end_close version 7, at autonomy A2 — where a person approves before the write. The record was sealed at 10:42:07 +05:30, after record 1041, as seq order requires.

Tests: confirm the approver is named in declaration 7 and, through F04 wr_specimen_7c2, that the approval request’s proposer was someone else; trace je_specimen_5531 version 2 in the ledger; recompute F14 from the posted entry.

Walking the link

Record 1041 recomputes to sha256:8e37839e…0ffdeac0. F03 on record 1042 holds the same value in full, and F02 rises from 1041 to 1042. The link holds. Record 1042 recomputes to sha256:f2423aa3…5aca2c18, which is what record 1043 carries in F03.

The review raises no exception on what the records alone can show, and leaves four items that need evidence from outside the record: two declarations, one ledger entry and one payload. That is the normal shape of a proof-record review. The record tells you exactly what to ask for; it does not replace asking.

A checklist for one period of governed writes in one tenant. It assumes L1; items marked “from L2” apply once L2 Attested is available.

Readers who want a vendor-neutral version of these questions, to put to any supplier whose agents write to their records, will find it in the RFP question set.