All four platforms available

AI agent audit trail · The proof record

Every write leaves 16 fields. Never a seventeenth.

A proof record is elan1's audit trail entry for one AI agent action. It has exactly 16 fields, including who acted, which declaration and rules version ran, the record that changed and the previous record's digest. Records are SHA-256 hash-chained, so a change to any earlier record is evident. Refused actions are recorded too, each metered at 40% of a governed action.

Status: Available · L1 Guarded and L2 Attested

01Inspector

Two records, one chain. Check it in your browser.

Select a field name to read what it holds. Recompute the chain to hash both records with SHA-256 on this device. Then change a field and recompute again.

  • Outcome, approver and refusal code sit in a rendering strip, never as a seventeenth field.
  • Record 1041 is a refusal. It still joins the chain and is metered at 0.4 of a governed action.
  • Nothing you type is sent anywhere.

Illustrative specimen. Not customer data.

Two records in sequence. Select any field name to read what it holds. Record 1042 carries the digest of record 1041 in F03; that is the chain.

Press “Recompute records 1041–1042” to hash both records with SHA-256 in this browser.

Illustrative specimen. Not customer data.seq 1041 · L1 · Guarded

Rendering · shown beside the record, never a seventeenth field

Outcome
Refused Refused at rung 3 · PRE-GATES
Approver
None. The write stopped before approval.
Refusal code
GATE.PRECONDITION_FAILED (illustrative)
Meter
0.4 governed action
4 of 16 fields: F01–F03, F14
tnt_specimen_01
1041
wr_specimen_7c1
purchase_invoice.post
decl_ap_purchase
4
2027.06.1
agt_specimen_ap01
agent
A1
00000000-0000-0000-0000-000000000000
0
sha256:5f105d2d818bc7fe36a7c1b7e367196610df5ee6e8d4c5296c9d8cc4b28428d8
sha256:1d967c9d1c583efd0a3135e57aa1035ebdd5ab4766f0572f10304feae7516d53
2027-07-14T10:39:12+05:30
Digest of seq 1041Not yet recomputed in this browser

Checked and recorded by elan1 Govern · tamper-evident (L1)

Record 1042 points back to record 1041 by digest (F03 prev_digest).

Illustrative specimen. Not customer data.seq 1042 · L1 · Guarded

Rendering · shown beside the record, never a seventeenth field

Outcome
Committed Committed at rung 7 · ACT
Approver
usr_specimen_approver, a named person who is not the asker
Refusal code
None
Meter
1 governed action
4 of 16 fields: F01–F03, F14
tnt_specimen_01
1042
wr_specimen_7c2
journal_entry.post
decl_month_end_close
7
2027.06.1
usr_specimen_approver
human
A2
je_specimen_5531
2
sha256:e1eb0d8f0a7399695abf290e8fd2b6abc738ffd2fbdb8297f9ae44eb1a32ab6a
sha256:fd8e4d0b12b24bf22a591e735f211d8d7bb2bdf480058fdf89bb9d44666b2633
2027-07-14T10:42:07+05:30
Digest of seq 1042Not yet recomputed in this browser

Checked and recorded by elan1 Govern · tamper-evident (L1)

Next record · seq 1043 · F03 prev_digestsha256:f2423aa3d4559b7fd54b390a724f2a989744c10db034caa4a0e047cb5aca2c18

Verify offline (simulated)

L2 · Available Simulated here. The real check runs in the free offline verifier.

  1. 01

    Signature

    Check the Ed25519 signature on record 1042 against the residency domain's public key, obtained out of band.

  2. 02

    Anchoring

    Check the Merkle root that contains record 1042 against timestamps from two RFC 3161 authorities, anchored within 15 minutes.

  3. 03

    Evidence bundle

    Open the eight-member evidence bundle and run the free offline verifier, elan1-verify, on your own machine with no network.

At L1 records are hash-chained, not signed, and the check needs elan1. The three steps above describe the L2 design. Nothing on this page was signed or anchored.

How the browser recomputes: the preimage is the 19-octet domain string elan1.proof.seal.v6, then each of the 16 fields as a 4-octet big-endian length followed by its bytes. SHA-256 runs through WebCrypto on this device; nothing is sent. Where this is weak: the specimen encodes every field as UTF-8 text, while Seal v6 encodes identifiers and digests as fixed binary octets. It shows the method, not a production verifier.

02Sixteen fields

Every field, explained.

Field names come from Seal v6, which is frozen: no optional fields, no seventeenth field, no v6.1. A refusal carries zeroes, not omissions. The example values are invented.

The sixteen fields of a Seal v6 proof record
FieldNameWhat it holdsExample (seq 1042)
F01tenant_idThe tenant this record belongs to. Chains never cross tenants.tnt_specimen_01
F02seqThe record's position in this tenant's chain. It only ever goes up by one.1042
F03prev_digestThe digest of the record before this one. It is what links the chain.sha256:8e37839e9548dfa9a4a8948b723c1517afb532a7eaceb617a7db6eff0ffdeac0
F04write_idThe identifier of the write intent. Every invoice line must carry one.wr_specimen_7c2
F05write_typeThe kind of write, from the declaration's list of allowed write types.journal_entry.post
F06declaration_idThe declaration — the process's rules in seven blocks — that was checked.decl_month_end_close
F07declaration_versionWhich version of that declaration was in force at the time.7
F08policy_versionThe version of the policy rules evaluate() ran. No model, only rules.2027.06.1
F09actor_idWho acted: the named approver, or the agent that proposed the write.usr_specimen_approver
F10actor_kindWhether the actor was a human or an agent.human
F11autonomy_levelThe autonomy level A0–A5 the write ran at; above the ceiling a person decides.A2
F12record_idThe record in your system of record that changed, or would have.je_specimen_5531
F13record_versionThe version of that record after the write.2
F14payload_hashA hash of the payload, not the payload itself, so personal data stays out of evidence.sha256:e1eb0d8f0a7399695abf290e8fd2b6abc738ffd2fbdb8297f9ae44eb1a32ab6a
F15lexicon_hashA hash of the vocabulary the write was expressed in, so meanings cannot drift.sha256:fd8e4d0b12b24bf22a591e735f211d8d7bb2bdf480058fdf89bb9d44666b2633
F16recorded_atWhen the record was sealed, with the time-zone offset.2027-07-14T10:42:07+05:30
Rendered beside the record, never inside it. The outcome (committed, refused or escalated), the approver's name and the refusal code are shown next to the record. The record itself stays at sixteen fields.
No personal data in evidence. F14 holds a hash of the payload, not the payload, so the chain carries no personal data.

03elan1.proof.seal.v6

Sixteen fields, length-prefixed, SHA-256, chained per tenant.

The preimage is a 19-octet domain string followed by the sixteen encoded fields, each with its length in front, so no two different records can produce the same bytes. The digest goes into the next record's F03.

How to check it at L1

  1. Take record n and build its preimage: the 19-octet domain string elan1.proof.seal.v6, then the sixteen fields in order, each length-prefixed.
  2. Hash the preimage with SHA-256. That is record n's digest.
  3. Compare it with F03 prev_digest on record n + 1. They must be identical, octet for octet.
  4. Walk the whole chain for the tenant. A changed record breaks its link; a missing record leaves a gap in F02 seq.

What holds the chain together

  • One chain per tenant. Chains never cross tenants.
  • F02 seq only ever goes up by one, so a missing record leaves a visible gap.
  • Evidence rows cannot be updated or deleted: there is no UPDATE or DELETE on them.
  • Refusals are sealed like commits, with a zeroed record_id and record_version 0.
  • The record is written synchronously, at rung 8, before the caller gets its answer.

At L1, the records are tamper-evident to you; they are not signed, and checking them needs elan1.

04L1 and L2

Tamper-evident to you now. Checkable without us from L2.

The record format does not change between levels. What changes is who can check it, and how.

What the proof record offers at L1 and at L2
L1 GuardedL2 Attested
IntegrityHash-chained with SHA-256. Tamper-evident to you.Also signed with Ed25519, against the residency domain's key.
TimeF16 recorded_at, with its time-zone offset.Merkle roots anchored to two RFC 3161 timestamp authorities within 15 minutes.
Who can checkYou, with elan1. At L1 verification needs us.Anyone with the bundle, offline, using the free verifier elan1-verify.
What you hand overAn internal record of every attempt.An eight-member evidence bundle.
StatusAvailableAvailable

Records written before L2 stay L1. An L2 bundle verifies on an air-gapped machine, with no network and no account with us.

05Limits

What the record proves, and what it doesn't.

A proof record is evidence that a write took a governed path. It is not evidence that the business was right.

What a proof record proves and does not prove
ProvesDoes not prove
The record has not changed since it was sealedThe business decision was right
Which rules and which version appliedThe rules were good
Who acted, and at what autonomy levelNothing happened outside elan1 (Mode B)
That a refusal happened, with its code and rungThe transaction itself was genuine

07FAQ

The AI agent audit trail, in five answers.

// SEE IT

Watch a refusal write its record.

Follow one write intent up the Right Path. Refuse it at the gate and see the record still join the chain, metered at 0.4 of a governed action.