ADR-0023: Evidence sealing — opt-in third tier of statement-backing

Status

Accepted

Date

2026-07-03

Context

Where the kernel’s records carry money and legal weight — measurement books, acceptance certificates, expense claims — the parties are mutually distrusting (contractor, verifier, auditor, and the platform operator), and procurement now writes the requirement down explicitly: the BSNL CNOC tender demands hash-sealed Measurement Books, tamper-proof capture metadata, payment computed only from verified data, and audit packages a third party can check (see the buyer landscape). ADR-0011 gives us statement-backing and ResolvedValue fusion; ADR-0010 gives offline invariants; ADR-0013 gives idempotent replay over deterministic serialization. None of them yet gives tamper-evidence, non-repudiation, or verifiability by a party who does not trust our database.

What is needed is not a blockchain in the consensus sense — parties are known and an arbiter exists. It is hash-chain + signature + published-root mechanics (git / certificate-transparency shape). The design was resolved branch-by-branch in a grilling session (2026-07-03); this ADR records the outcome.

Decision

Sealing is the opt-in third tier of the evidence ladder: plain → statement-backed → sealed. The kernel owns what must be enforced at the seam; chains and anchoring are rebuildable projections above it.

Kernel seal, service chains. The kernel owns: content hashes on evidence artifacts, canonical (deterministic) serialization of sealable records, seal-as-authority-state, and attestation (signature) records. Hash-chains, Merkle trees, anchoring, and verifier tooling are Serving-plane projections and Materialization exports — rebuildable, off the hot path, pinned externally only by their published roots.
The sealable unit is the committed act record — the Truth-plane record of a governed Act (payload, produced statement ids, evidence content-hashes), canonically serialized to an entry hash. Realm/package definitions declare which act types are sealable; a verifier’s approval is itself an Act that references and seals a prior act. The kernel names no domain types (no “Measurement Book” in kernel source).
Chain scope is a realm-declared grouping key (e.g. work-order for construction books). Chains give ordering + completeness per scope; Merkle roots per period give set commitment. Because chains are projections, scope choices are changeable going forward without invalidating previously published roots.
A seal freezes the record, never the truth. The Truth plane keeps the sealed record immutable; the World plane’s ResolvedValue stays alive — later, higher-authority statements may still supersede a sealed value’s current interpretation. Ledger-class projections consume only sealed records and sealed corrections. Divergence between a sealed record and the living ResolvedValue is surfaced as a first-class signal feeding correction/dispute flows — never silently reconciled.
Corrections are reversal + restatement acts — new sealable acts referencing the corrected one, with justification and authoriser; ledgers compute net effect; published roots are never invalidated (corrections live in later trees). Supersede-and-link, the same discipline as statements and ADRs.
Schema day one, keys later (extends ADR-0010’s invariant list): every evidence record carries contentHash, hashOrigin (device-minted vs server-minted, honestly distinguished), and attestation slots from the first build; client-side hashing ships with the first mobile capture. Device signatures (secure-enclave keys, enrollment, rotation, revocation) land with the offline client stack and upgrade hashOrigin strength without schema change.
Two-ring PKI. Inner ring: platform-issued identities for field devices/users and for machine validators (service identity + model version — machine attestations are how AI co-signatures are recorded). Outer ring: seal-level signatures use external legal identities where the jurisdiction provides them (DSC in India, eIDAS-class in the EU), platform identity as documented fallback. Key lifecycle events are themselves recorded acts.
Anchoring is multi-channel distribution + RFC 3161 timestamps. Signed period roots are embedded in the artifacts counterparties already receive (scorecards, audit packages), published on the portal, and TSA-timestamped. Distribution is the security property; no public blockchain. A verifier tool (offline inclusion-proof checking) ships in the anchoring phase.

Phasing: (1) content-hash + canonical entry hash + seal-on-approval; (2) per-scope chains, correction-by-append, period Merkle roots; (3) external anchoring + verifier tool + inclusion proofs. Each phase pays for itself; only phase 1’s schema is a day-one invariant.

Alternatives Considered

Full kernel third tier (chains/Merkle/anchoring in the write path). Strongest single-story guarantee; rejected — enlarges the kernel for a small team and puts crypto bookkeeping in the hot path when rebuildable projections + published roots give the same external guarantee.
Product-layer evidence vault only. Keeps the kernel lean; rejected — the World/Serving planes could not enforce “ledger consumes sealed only”, and every product rebuilds the machinery.
Seal as supreme authority (pins the World plane). Contractually intuitive; rejected — the map would show what was paid for, not what is in the ground: institutionalized twin-rot.
Unseal ceremonies for corrections. Rejected — “the book can be rewritten if enough people agree” forfeits the core guarantee and breaks published roots.
Public-blockchain anchoring. Rejected for now — adds dependency and procurement optics while adding little over widely distributed roots + TSA among counterparties who already archive them.
External legal PKI for every signer. Rejected — DSC-class enrollment for thousands of churning contractor field workers puts the burden on the persona least able to carry it.

Consequences

ADR-0011’s ladder gains a tier; schema/fusion tooling must support sealed as a declared property of act types, and ledger-class projections gain a kernel-enforced “sealed-only” consumption rule.
ADR-0010’s invariant list grows by one: evidence hash schema (contentHash, hashOrigin, attestation slots) from day one. Deterministic serialization is already required by ADR-0013 — sealing reuses it rather than adding cost.
New kernel surface to design: attestation records (human and machine), seal state on act records, divergence signals (sealed-vs-ResolvedValue mismatch), and the realm-declared grouping-key contract for chain projections.
We owe: a key-lifecycle runbook (enrollment, rotation, revocation, lost devices, valid-at-time-T verification), a canonical-serialization spec shared with ADR-0013, and the phase-3 verifier tool.
Honesty boundary: sealing proves integrity-since-capture and who-signed-what. It does not prove a photo depicts reality (pair with CV validators and sampled physical audits) nor that GPS was unspoofed (attested location, plausibility checks). Content stays access-controlled and even erasable — deleting a payload orphans a hash without breaking chains (compatible with data-protection erasure).
Sensitive to: the statement/fusion implementation shape under ADR-0011 (if ResolvedValue fusion moves into the write transaction, divergence signaling moves with it), and jurisdiction PKI availability (outer ring degrades to platform identity + anchoring where no DSC/eIDAS equivalent exists).