Skip to content

ADR-001: Single append-only sigchain as the primary audit abstraction

Date: 2026-05-06 Status: Accepted Deciders: Aevum Labs Confidence: High

Context and Problem Statement

An AI agent produces many event types across multiple components: ingest decisions, query results, review checkpoints, LLM calls (via complication), tool invocations (via complication), consent grants and revocations. Should these be recorded into a single hash-chained ledger or distributed across per-component audit streams that are later correlated?

Decision Drivers

  • EU AI Act Art. 12 requires automatic recording of events "over the lifetime of the system" — a single chain satisfies this with no correlation step
  • FDA 21 CFR §11.10(e) requires that audit trails "independently record" — a single chain that fails closed on write failure is a stronger implementation than a distributed system where one component's chain may diverge
  • Auditor usability: a single chain can be exported as one file and verified with one tool — no JOIN across component logs
  • replay() semantics require a total ordering of events to reconstruct past context faithfully — a single HLC-ordered chain provides this directly

Considered Options

  1. Single append-only sigchain (this decision)
  2. Per-component chains with a meta-chain linking them
  3. IETF AAT-style per-agent ledgers correlated by episode_id

Decision Outcome

Option 1. A single sigchain provides the strongest tamper-evidence guarantee (one chain = one verification step), the simplest auditor experience, and a natural implementation of replay() semantics.

Consequences

Good: Direct EU AI Act Art. 12 compliance posture; single verification tool; complete ordering for replay; fail-closed write atomicity is simpler with one ledger.

Bad: All five public functions write to the same chain — write contention under high concurrency. Mitigation: single-writer semantics via threading.Lock in the ledger implementation.

Residual risk: The single chain is a single point of failure. Mitigation: persistent backends (PostgresLedger) + cross-session causation_id linking.

Additional integrity property (discovered implementation): The signing digest covers 16 fields including sequence. This means events cannot be reordered within the chain without invalidating their signatures — insertion, deletion, and reordering attacks all break both the hash chain AND the per-event signatures. See docs/spec/aevum-signing-v1.md for the complete signing field set.

Evidence

  • FINRA Consolidated Audit Trail (CAT) uses a single-chain audit record per reportable event, correlated by a single order/event identifier
  • Hyperledger Fabric uses single-channel ledgers with ordering-service guarantee of finality: "the blocks generated by the ordering service are final"
  • AWS CloudTrail uses a hash-chained digest file per region with a single starting digest per enablement period — the closest analogue to Aevum's model
  • Certificate Transparency uses a single Merkle tree log per log operator; multi-log coordination is external (monitor/auditor infrastructure)
  • ADR-002 (HLC bounds)
  • ADR-004 (Signer trust boundary)