> > > SpecAdr008BitemporalAuditingViaHashBinding

ADR-008: Bitemporal Auditing via Hash-Binding and Claim Check

Status

Accepted

Context

SOTER needs an auditable history of user events and the context in which those events occurred.

Three problems drive this decision:

A user may act based on a generated .view, and audits must later prove what was shown.
Privacy rules may require removal or encryption of personal payloads.
Heavy payloads should not bloat the cryptographic chain.

Decision

SOTER adopts the Claim Check pattern and context hash-binding for fact records.

The main ledger stores technical metadata and cryptographic links. Business payloads live in separate content storage and are referenced by hash or key.

Every generated .fact is bound to the relevant visual and engine context, including view/projection hashes and engine commit identity where applicable.

Rationale

The ledger must preserve auditability without forcing every payload into the hash-chain row itself. Separating metadata from payload allows erasure or crypto-shredding of sensitive content while preserving chain integrity.

Context hash-binding supports a "what you see is what you sign" audit model.

Consequences

Positive

Hash-chain verification stays lightweight.
Payloads can be governed separately for privacy and retention.
Audits can reconstruct the model/view context of an action.

Negative

Payload storage becomes a required companion to the ledger.
Auditors must understand the relationship between metadata rows and payload claims.

Neutral or Operational

Execution blueprints, instance migration, and configuration-as-fact are deferred to later versions.

Alternatives Considered

Store Full Payloads in the Main Ledger Row

Rejected because it would bloat hashing and make privacy compliance harder.

Store Only Business Payloads Without Context Binding

Rejected because it would not prove what the user saw at action time.

Migration or Adoption

Ledger schema work should preserve a technical metadata table and separate payload storage. Fact writers must inject context hashes before canonicalization.