Evidence kinds/L12 receipt chain

L12 receipt chain

audit output evidence

Hash-chained, Ed25519-signed log of every LLM-in-the-loop decision a Promethean-built product makes.

What it is

The L12 receipt chain is the substrate's primary output. Every time an LLM-in-the-loop decision happens through Promethean, a structured entry is appended to the chain: an id, a recordedAtMs timestamp, productId, specId, specHash, inputHash (SHA-256), outputCanonicalHash, category, modelIdentity (provider/model/version), latencyMs, schemaValid flag, reviewerVerdict, fallbackTriggered flag, prevHash linking to the previous entry's hash, and per-entry Ed25519 attestation.

The chain is byte-stable across implementations: a JavaScript emitter and a hypothetical Python emitter would produce hash-identical canonical forms for the same logical entry. This makes cross-language verification possible and meaningful.

Heads can be anchored to Bitcoin via OpenTimestamps at tier-dependent cadence (daily on Dev/Team, hourly on Production, 30-min on Scale, 15-min Bitcoin-anchored on Enterprise). The chain is the operator's tamper-evident audit trail for regulated AI decisioning.

What it guarantees

  • Tamper-evidence — retroactive edits to any entry break the hash chain, detectable by verify.mjs.
  • Per-decision integrity — each entry's signature can be verified independently.
  • Cross-implementation byte-stability via the canonical form rule.
  • PII-safety by construction — only SHA-256 hashes of inputs + outputs in the chain, not raw content.
  • Operator-owned signing keys — the operator (not Promethean) holds the private seed for their workspace.

What it does NOT guarantee

Honest limits. Every primitive has them.

  • That the AI model itself was correct — the chain records what happened, not whether the answer was right.
  • That the operator's source data is uncorrupted — the chain commits hashes of what was supplied.
  • Real-time alerting — the chain is record-of-decision, not active monitoring.
  • Retention beyond what the operator chooses to keep.

Regulations that engage this kind

EU AI Act Art. 12

Record-keeping for high-risk AI

HIPAA §164.312(b)

Audit controls

DORA Art. 17–18

ICT incident reconstruction

NIS2 Art. 23

Incident timeline reconstruction

GDPR Art. 22 + 32

Automated-decision evidence + security of processing

Sectors that rely on this kind

Related evidence kinds

Spec hash commitment

Every L12 entry includes a SHA-256 of the active RuntimeAISpec, making silent spec drift detectable.

Ed25519 attestation

Per-entry Ed25519 signature using the operator's workspace signing key.

OpenTimestamps Bitcoin anchor

Bitcoin blockchain commitment of a chain head, providing third-party timestamp evidence.

Audit bundle

Operator-downloadable .zip containing verifier + workspace identity + chain metadata + framework handoff.

FAQ

What does 'L12' stand for?

L12 is the substrate's chain identifier (Layer-12 in our internal architecture nomenclature). It's the receipt log layer sitting above the SDK + verifier. Operationally there's no significance to the number; the name is stable.

How big does the chain get?

Each L12 entry is ~600-800 bytes of JSON. At 1M entries/month (Production tier ceiling), that's ~720MB-1GB/year of raw JSONL. With OpenTimestamps anchor metadata + signed-head observations, double that. Operationally insignificant for most operators; archival storage governs retention strategy.

Can I delete entries?

Not without breaking the chain. Retroactive deletion would change all subsequent prevHash values; verify.mjs would report 'prevHash mismatch at entry N'. For GDPR Art. 17 erasure rights, the substrate's design is that raw PII is operator-side; chain entries contain only hashes. Erasing the source data invalidates rehydration via inputHash but doesn't break the chain integrity.