Causal Attribution and the Five-Chain Ledger
A consequential machine action becomes operationally attributable only when its intent, identities, authority, evidence and verified effect are bound into one inspectable record.
TLDR
- An observed outcome does not reveal who meant it, who caused it, whether they were permitted, what evidence supported it or whether the intended state actually resulted.
- A five-chain ledger joins intent, identity, authority, evidence and effect through immutable proposal and evidence digests, a decision receipt and an authoritative effect receipt.
- The design turns a distributed trace into an accountable action record that can support replay, incident investigation, contestation and bounded recovery.
- It cannot make false evidence true, rescue a compromised recorder or prove philosophical actual causation; simple atomic workflows may need only an ordinary audit record.
- Before releasing a consequential action, require the strength of each chain to rise with irreversibility, then deny or escalate when any binding is absent or stale.
Two identical credits, two incompatible histories
At 16:03, a customer account receives a £420 credit labelled “fee reversal”. The balance is correct. The transaction identifier is valid. A distributed trace shows a customer-service interface, an agent service, a policy service and the account platform. Every span is green. An outcome-only dashboard marks the case successful.
Now imagine two histories behind that same credit. In the first, the customer asks for reversal of a duplicate fee. A named employee opens the case. An assistant prepares a typed proposal for exactly £420 against exactly one account. The evidence snapshot contains both fee entries, the applicable policy version and the current account state. A policy engine returns an allow decision for that immutable proposal. The employee approves it. A one-use capability reaches the account platform, which commits the credit and returns an authoritative readback.
In the second history, a retrieved complaint contains an injected instruction. A shared runtime proposes a reversal under a broad service token. The employee sees only a fluent summary, not the exact amount or target account. The policy check used a stale account tier. The account platform commits the credit, but its response times out. The agent retries with a new request identifier. A later balance query happens to show a £420 increase. The same surface outcome now hides an untrusted purpose, an ambiguous actor, stale authority, substituted evidence and a possible duplicate attempt.
The effect alone cannot tell these histories apart. Neither can a trace identifier. One follows requests across components; the other answers a harder question: which bounded intent, principals, permission, evidence and execution produced this specific state transition?
Figure 1. One visible effect can be reached through accountable or defective histories
History A: bounded and attributable
History B: correlated but unattributable
An outcome is not its history
Operational systems often use the word “cause” loosely. A span says which service called which endpoint. A log says which process emitted an event. A provenance graph says which entities, activities and agents contributed to an artefact. Each is useful. None, by itself, establishes that one authorised purpose, held by identified principals and supported by specified evidence, produced one verified effect.
W3C PROV provides a general language for entities, activities, derivations and responsible agents.[1] W3C Trace Context gives distributed requests a portable identity so observations from different components can be correlated.[2] These standards solve different parts of the problem. Provenance can describe a lineage. Tracing can preserve continuity. Neither requires an application to bind the exact proposal approved by policy to the exact command accepted by the authoritative resource.
That distinction matters because consequential actions cross several semantic boundaries. A customer’s request becomes a model proposal. The proposal becomes a policy input. An allow decision becomes a capability. The capability becomes a command. A successful response becomes a claim about world state. At each boundary, something can be substituted while the trace remains unbroken.
Trace Context is designed to let distributed trace data be linked and forwarded across components. Its specification does not claim that a trace identifier authenticates a principal, conveys permission, validates evidence or proves the final resource state.[2] Those are application and control obligations.
Operational attribution, not metaphysical proof
This paper uses causal attribution in a deliberately bounded engineering sense: the ability to reconstruct and challenge the control path that led to a consequential effect. Philosophical and statistical accounts of actual causation ask a stronger counterfactual question. Halpern and Pearl, for example, use structural equations to test whether changing candidate causes under specified contingencies changes an outcome.[14]
A ledger does not perform that proof. It records variables that make a later causal model possible: the proposal, policy state, evidence snapshot, actors, command, resource version and observed postcondition. It can show that a particular command was authorised and committed. It cannot show that no unrecorded factor mattered, that the evidence was true or that the approver understood every consequence.
Complete means all five chains exist. Cross-bound means they refer to the same immutable proposal and evidence snapshot. Fresh means time-sensitive authority and evidence remained valid at execution. Untampered concerns record integrity. Verified requires an authoritative postcondition, not merely a successful request.
Figure 2. A trace answers “where did the request travel?” while attribution asks five additional questions
Keep the outcome fixed and swap one hidden cause
Take a correctly executed £420 reversal and make five copies of its record. In copy one, replace the customer request with an unrelated intent. In copy two, replace the employee identity with a shared service account. In copy three, keep the policy result but change its input amount to £42. In copy four, replace the duplicate-fee evidence with a stale screenshot. In copy five, remove the account readback and retain only an HTTP 200 from an intermediary.
Every copy can preserve the same final balance and even the same trace shape. Yet each supports a different answer to “why was this action legitimate?” If a system treats the copies as equivalent, its audit trail is correlational rather than attributable.
flowchart LR A["Two identical credits, two<br/>incompatible histories"] --> B["An outcome is not its history"] B --> C["Five chains, one action"] C --> D["From correlated logs to<br/>governed receipts"] D -. "re-test" .-> A classDef first fill:#0a1424,stroke:#087A98,stroke-width:2px,color:#e6f3ff classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff class A first class B,C,D step
Five chains, one action
The five chains are not five columns added to one log row. Each has its own producer, trust boundary, freshness rule and failure mode. Their value appears when they cross-bind. A valid identity chain without an intent chain can tell us who acted but not what they were entitled to mean. A valid authority chain without an effect chain can tell us what was allowed but not what happened.
Figure 3. Five interlocked evidence chains converge on one attributable effect
target
bounds
expiryproposal digest
subject
proposer
executorprincipal IDs
versions
freshness
entitlementsnapshot digest
commit
readback
postconditioneffect ID
1. Intent: the purpose that authority is allowed to serve
An intent record answers more than “what did the user type?” Natural-language instructions can contain several purposes, implied targets and unsafe expansions. The record should therefore express a typed action proposal: operation, resource, amount or range, purpose, constraints, expiry and the source from which the intent was derived. It should also distinguish the requesting principal from any affected subject.
Intent must survive translation. When a model converts “please reverse the duplicate charge” into a command, the system should freeze a canonical proposal and calculate its digest. Approval, policy evaluation and execution then refer to that digest. A later wording improvement can be stored as explanation, but it cannot silently change the authorised object.
Intent is the semantic boundary against goal drift. Without it, an executor may possess valid credentials and valid API permission yet apply them to a purpose no person or policy accepted.
2. Identity: the principals whose roles must not collapse
A consequential action normally involves several principals: the person whose interests are affected, the person or system that requested work, the model or workflow that proposed an action, the approver, the executing workload and the authoritative resource. OAuth token exchange can represent delegation and identify a current actor through the act claim; nested actors can preserve an informational history.[3] Workload identity systems such as SPIFFE provide cryptographically verifiable identities to software workloads.[5]
Those mechanisms identify actors. They do not decide whether one actor’s purpose may be adopted by another. The ledger must retain role semantics. “Employee 71 approved” differs from “service X executed”, and both differ from “customer 9 requested”. A shared service account may authenticate successfully while destroying the distinction needed for accountability.
NIST’s zero-trust guidance for cloud-native applications emphasises identity-tier policies and granular, application-level access control.[4] The five-chain design extends that discipline into the action record: identity is attributable only when the principal, role, credential context and delegation path remain visible at the decision point.
3. Authority: permission for this proposal under this state
Authority is not the presence of an access token. It is the result of evaluating a policy against a principal, proposal, resource and relevant world state at a known time. An authority event should retain the policy identifier and version, the decision identifier, material inputs, result, obligations, scope and expiry. Open Policy Agent decision logs, for example, can record the queried policy, input, bundle revision, result, timestamp and a unique decision identifier.[6]
The allow decision should produce an attenuated capability rather than expose ambient runtime permission. Its scope might permit one £420 reversal against one account before 16:05, bound to one proposal digest and one evidence digest. The executor cannot change the amount, target or purpose without obtaining a new decision.
Freshness matters. A policy result can be valid at approval and invalid at execution because the balance, sanction status, case state or approval threshold changed. High-consequence actions therefore need a local precondition check at the authoritative boundary. Authority is a time-bounded relationship between a proposal and state, not a reusable property of an agent.
4. Evidence: the sources that justified the decision
Evidence is the selected, authorised and time-specific material used to form and approve the proposal. It is not every document retrieved during a case. The chain should identify source, version, retrieval time, applicable time, entitlement, extraction or transformation, and a digest of the decision snapshot. W3C PROV offers relations for generation, use, derivation and agent responsibility that can represent parts of this lineage.[1]
The snapshot digest prevents a common substitution: a human approves a summary while the executor acts on different underlying fields. It also supports historical reconstruction when a source later changes. That does not make the source accurate. A forged document can be perfectly hashed. A wrong policy can be faithfully versioned. The evidence chain proves which evidence governed the decision, not that reality agreed with it.
Evidence minimisation is equally important. The ledger should store stable references, selected facts, digests and policy-relevant metadata rather than replicate sensitive source content. OPA’s decision-log facilities explicitly support masking fields before export, illustrating the wider requirement to preserve audit usefulness without turning control records into a secondary privacy breach.[6]
5. Effect: the state transition the resource can attest
The effect chain begins where ordinary request logging often stops. “Command accepted” is not “state committed”. “Response sent” is not “response received”. “Later state looks plausible” is not “this command produced that state”. Distributed transaction work formalises the difficulty of reaching agreement about commit or abort under failures.[9]
An effect receipt should come from the authoritative resource or a verifier with an explicit trust relationship. It records the command or idempotency identifier, prior and resulting resource versions, commit status, effect identifier, postcondition and readback time. If the caller times out after dispatch, the action enters unknown outcome. The correct next step is reconciliation by idempotency key or authoritative readback, not blind repetition.
HTTP defines an idempotent method as one whose intended server effect is the same after multiple identical requests, and notes that idempotence enables safe retry after some communication failures.[8] Many consequential operations use POST and need application-level idempotency. Even then, a duplicate-suppression key prevents repeated effect; it does not by itself prove that the intended postcondition holds. The effect chain closes only when the resource verifies what changed.
Ablate one chain and ask whether execution changes
Build a test case that normally passes. Then delete the evidence digest from the policy input while leaving the evidence visible in a dashboard. Does the action still execute? Replace the workload identity after approval. Change the command amount by one penny. Expire the capability one second before dispatch. Return an accepted response but suppress the authoritative readback.
If these interventions alter only the audit display, the ledger is decorative. If they cause deny, re-authorise, reconcile or escalate states, the chains participate in control. A causal ledger must change execution when its bindings change.
From correlated logs to governed receipts
The implementation does not require one database or one vendor. It requires a typed event contract and verifiable joins. Each system can retain its native logs, while a governed ledger stores the minimum action events and references needed to reconstruct the decision. The trace identifier remains useful for finding operational detail. It is one join key among several, not the root of trust.
Freeze the decision before execution
A decision receipt is the smallest immutable record that a downstream authority kernel can verify before accepting a command. It binds the canonical proposal digest, evidence snapshot digest, requester and affected subject, proposer, approver, policy decision and version, obligations, expiry and permitted executor. The receipt can be signed or authenticated by the policy service.
HTTP Message Signatures provides a standard mechanism for signing selected components of an HTTP message, while warning that insufficient coverage and replay remain application concerns.[7] The lesson is structural: sign the fields that give the command its meaning, include freshness and replay controls, and verify them at the resource boundary. A valid signature over the wrong subset is faithfully wrong.
Close the record after the resource changes
An effect receipt binds the accepted command to the authoritative outcome. It should carry the same proposal digest and idempotency key as the decision receipt, plus the resource’s own effect identifier, commit result, previous and new state version, postcondition result and verification time. Where the resource cannot issue such a receipt, an outcome observer can perform readback, but its authority and delay must be explicit.
Figure 4. Cross-bindings prevent approval, command and effect from drifting apart
Decision receipt
p:98c1…e:4d27…req/pro/approvedec-731 · v18cap-1 · one useEffect receipt
p:98c1…cmd-220acct:synthetic-42v7 → v8verifiedTamper evidence without pretending the ledger is a blockchain
The ledger can be append-only and hash-linked without using a distributed blockchain. Each event includes the previous event hash, so deletion or modification becomes detectable when a later trusted checkpoint is compared. Certificate Transparency demonstrates how Merkle trees and signed tree heads can support append-only commitments and consistency proofs.[10] Earlier secure-audit-log work likewise shows how cryptographic chaining can make prior modification detectable after compromise.[11]
The trust boundary remains. SLSA provenance explicitly treats the builder as part of the trusted base that must faithfully run the process and record provenance.[12] A five-chain ledger has the same constraint. Hashes reveal mutation after a trusted event was recorded. They do not expose a recorder that fabricated the event at creation. High-consequence designs therefore separate event producers, use hardware-backed or service-held signing keys, checkpoint to an independently controlled witness and compare ledger claims with authoritative resource state.
Record control evidence, not private cognition
The ledger does not need a model's hidden chain-of-thought. Such text may be unavailable, unfaithful, privacy-sensitive or easy to optimise for appearances. What control and review need is observable material: the typed proposal, selected evidence references, tool calls, policy inputs, policy result, human decision, command and resource receipt. A concise model-supplied rationale can be retained as one fallible artefact, but it should never replace the bindings.
This also prevents two stores from being confused. World state is the current authoritative condition of the account, payment, case or device. The evidence ledger is a historical record of what the decision process observed and relied upon. The balance can change after approval without rewriting the evidence snapshot. The ledger can record an approval without making that approval part of the account's current state. Keeping these roles separate allows temporal questions to be answered honestly: what was known then, what is true now and which change followed the command?
Retention should follow the same separation. A digest and stable source reference may remain in the attribution record while sensitive content stays in an access-controlled evidence vault with its own deletion and legal-hold rules. When content expires, the ledger can preserve that a particular version was used without pretending the content remains available. Auditability requires durable joins, not permanent duplication of every input.
Figure 5. Unknown outcome is a state to reconcile, not a reason to repeat blindly
Two worked examples
A £42 duplicate-fee reversal
A synthetic customer submits case case-160-demo. The context compiler selects two fee events and current account version 7. The agent proposes reverse_fee(account-42, GBP 42). Canonical serialisation produces proposal digest p; the evidence snapshot produces digest e.
The policy service evaluates employee identity, customer relationship, amount, duplicate-fee match, account status and proposal digest. It returns allow with decision dec-731, policy version 18 and a capability usable once against account 42 for two minutes. The authority kernel verifies the receipt and sends command cmd-220 with idempotency key idem-160.
The account service records effect eff-902, advances the account from version 7 to 8 and returns a readback showing a £42 delta. The effect receipt repeats p, idem-160 and the resource identity. A reviewer can now test that the amount approved equals the amount executed and that the resource, rather than the agent, attested the result.
A £240,000 payment exception
Consider a synthetic corporate payment held because beneficiary details changed within 24 hours. The task is not simply “release payment”. The intent chain names the payment, beneficiary, amount, currency, requested execution window and exception reason. The identity chain retains the initiating employee, customer mandate subject, model proposer, two independent approvers and payment-service workload.
The evidence chain contains stable references and digests for the mandate, beneficiary-change event, call-back confirmation, screening result, available balance, payment instruction and applicable control version. The authority policy requires dual approval, separation of duties, a fresh screening result and unchanged beneficiary data. Its decision receipt grants a one-use capability for the exact payment hash and expires in five minutes.
Immediately before commit, the payment platform rechecks beneficiary version and screening status. A version change invalidates the capability rather than relying on yesterday’s approval. After commit, the platform issues its own transaction identifier and status. An independent readback confirms amount, beneficiary, value date and debit state. If the client times out, it queries by idempotency key; it does not create a second payment instruction.
This record is larger because the consequence is larger. Yet it still avoids storing every source document or model token. The ledger preserves decision-sufficient evidence, not an indiscriminate transcript.
Figure 6. A typed ledger stores joins and control evidence, not hidden reasoning
Executable artefact: five-chain ledger validator
Run a clean synthetic case, then mutate an approved amount, remove the effect receipt or replay a one-use capability. The validator uses Web Crypto SHA-256 when available, with a self-contained SHA-256 fallback for local files, and makes no network calls.
Scenario
Validation result
Artefact assumptions, expected outputs and implementation excerpt
The demonstration assumes canonical JSON serialisation, a trustworthy initial event producer, browser support for Web Crypto and synthetic public-safe data. A clean case should return PASS. Amount tampering should fail cross-binding even after the event chain is re-hashed. Removing the effect receipt should return UNKNOWN OUTCOME. Reusing a one-use capability should fail replay control.
const proposalDigest = await sha256(canonical(proposal));
const evidenceDigest = await sha256(canonical(evidenceSnapshot));
// A decision receipt binds policy to the immutable objects.
authority.payload.proposalDigest = proposalDigest;
authority.payload.evidenceDigest = evidenceDigest;
// An effect receipt must repeat the action binding and verify state.
effect.payload.proposalDigest = proposalDigest;
effect.payload.idempotencyKey = action.payload.idempotencyKey;
effect.payload.postconditionVerified = true;
// Validation rejects a coherent but semantically re-hashed mutation.
const executedDigest = await sha256(canonical(action.payload.command));
assert(executedDigest === authority.payload.proposalDigest);Where the ledger fails, and where it is unnecessary
A five-chain ledger adds schemas, storage, signing, key management, policy joins, reconciliation and operational review. Those costs should earn a measurable improvement. The strongest objection is that many systems already place user identity, request, authorisation and result in one transaction log. For a small deterministic workflow, splitting the record into five named chains may add ceremony without new discriminating power.
The negative control: one service, one transaction, one operator
Imagine an internal tool in which an authenticated employee corrects a non-financial label. One service renders the form, evaluates a fixed rule, writes the change and audit row in the same database transaction, and offers immediate undo. The row contains employee ID, old and new values, reason code, rule version, transaction ID and committed version. There is no model, delegation, external evidence source or asynchronous executor.
That ordinary audit row may already instantiate the five questions atomically. A separate ledger would duplicate it. The discriminating test is failure injection: substitute the operator, alter the value after approval, replay the request, suppress commit acknowledgement and tamper with the row. If the baseline detects and reconstructs these faults as well as the proposed ledger, at lower cost, the five-chain architecture should be rejected for that workflow.
The ledger ceases to support trustworthy attribution when every event producer and witness can be compromised together; when important intent or action occurs outside the observed boundary; when source evidence is false; when identities are borrowed; or when postconditions cannot be read from an authoritative system. It narrows uncertainty. It does not abolish it.
Seven ways a complete-looking ledger can still mislead
Recorder compromise. Hash chaining can expose later alteration, but a malicious producer can originate a false event. Independent witnesses and resource-side receipts reduce this trust concentration.
Semantic aliasing. Two systems can hash different canonical meanings under fields that look equivalent. Shared typed schemas, units, currencies and resource identifiers must precede digest comparison.
Rubber-stamp approval. A valid approver signature proves an approval event, not comprehension. Interfaces should expose exact high-consequence fields, changes since evidence collection and unresolved conflicts.
Borrowed identity. Strong workload identity does not prevent a human credential from being shared or coerced. Authentication assurance and behavioural investigation sit outside the ledger’s formal joins.
Truthful but obsolete evidence. A source can be correct for yesterday and unsafe now. Applicable time, source version and pre-execution rechecks are part of the evidence and authority chains.
Overcollection. Storing prompts, documents and personal data “for audit” creates a durable privacy and security target. Digests, references, selective fields, retention limits and access-separated evidence vaults are safer defaults.
Schema rot. A ledger can remain syntactically valid while new action types escape old fields. Contract versioning, unknown-field rejection at authority boundaries and replay tests are needed when schemas change.
Test attribution by breaking it
Reviewing a perfect sample proves little. A release gate should inject faults at the boundary between every pair of chains. The system should distinguish deny, fail and unknown outcome. Deny means a precondition or authorisation rejected the action before effect. Fail means execution or verification established that the intended effect did not occur. Unknown means evidence is insufficient to choose between them.
Figure 7. Failure injection tests whether each chain changes the system’s conclusion
| Injected fault | Weak logging conclusion | Required ledger response | Residual risk |
|---|---|---|---|
| Proposal amount changes after approval | Trace still green | Reject digest mismatch | Canonicalisation defect |
| Executor workload identity changes | Same service name | Reject principal binding | Stolen workload key |
| Evidence snapshot is superseded | Old source still retrievable | Re-evaluate policy or escalate | Source itself is wrong |
| Response times out after commit | Mark failure, retry | Enter unknown, reconcile by key | Resource lacks readback |
| Ledger event is deleted | Gap may go unnoticed | Fail hash or checkpoint consistency | All witnesses compromised |
Useful operating measures follow from these states. Track the proportion of consequential effects with all five chains, proposal-digest mismatches, stale-policy rejects, one-use capability replays, orphan effect receipts, unknown-outcome duration, readback failures and ledger-checkpoint inconsistency. Do not compress them into one “trust score”. Different failures require different owners and recovery actions.
A consequence-shaped release gate
The same record strength should not be imposed everywhere. Consequence and reversibility determine the minimum chain. A low-impact, easily reversible action may use one atomic audit record. A material but reversible action needs complete cross-binding and verified postconditions. A hard-to-reverse action needs independent approval, one-use authority, local state rechecks, tamper-evident witnessing and demonstrated recovery from unknown outcomes.
Figure 8. Required attribution evidence rises with consequence and recovery difficulty
| Chain | Release question | Block or escalate when |
|---|---|---|
| Intent | Is there one canonical proposal with explicit target, bounds, purpose and expiry? | The executor can reinterpret or expand it after approval. |
| Identity | Are requester, subject, proposer, approver, executor and verifier distinguished? | A shared or missing principal prevents role attribution. |
| Authority | Does a fresh policy decision bind this proposal, evidence and resource? | Permission is ambient, stale, reusable or broader than the action. |
| Evidence | Can the decision snapshot be reconstructed with source, version, time and entitlement? | Approval and execution refer to different evidence or unresolved conflict. |
| Effect | Can the authoritative resource attest commit and postcondition exactly once? | The result is inferred from transport success or remains unknown beyond its limit. |
The release decision is conjunctive for the chosen tier. Four strong chains do not compensate for one absent chain. A verified effect does not cure unauthorised intent. Valid authority does not cure an unverified outcome. Attribution fails at its weakest required binding.
stateDiagram-v2 [*] --> Claim state "Figure 1. One visible effect<br/>can be reached through<br/>accountable or defective<br/>histories" as Claim state "Operational attribution, not<br/>metaphysical proof" as Test state "Figure 2. A trace answers<br/>“where did the request<br/>travel?” while attribution<br/>asks five additional questions" as Revision Claim --> Test: expose mechanism Test --> Decision: evidence survives Test --> Revision: rival survives Revision --> Claim: narrow or rebuild Decision --> [*]
Compact glossary
- Decision receipt
- An immutable, verifiable record that binds a proposal, principals, policy decision and evidence snapshot before execution.
- Effect receipt
- An authoritative record of command acceptance, commit, resulting resource version and verified postcondition.
- Proposal digest
- A cryptographic digest of the canonical typed action, used to detect semantic substitution across approval and execution.
- Unknown outcome
- A state in which dispatch may have produced an effect but available evidence cannot yet establish commit or non-commit.
- Witness
- An independently controlled service or store that checkpoints ledger commitments so later alteration is detectable outside the primary recorder.
Source ledger
- Primary standard: W3C, PROV-DM: The PROV Data Model. Used for the entity, activity, agent and derivation vocabulary; it does not supply application authorisation.
- Primary standard: W3C, Trace Context. Used for the scope and limits of request correlation across distributed components.
- Primary standard: IETF RFC 8693, OAuth 2.0 Token Exchange. Used for delegation, impersonation and actor-chain semantics.
- Official guidance: NIST SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications. Used for identity-tier and granular application-policy framing.
- Official specification: SPIFFE, SPIFFE concepts and the Workload API. Used for workload identity, not as evidence of user purpose.
- Official implementation documentation: Open Policy Agent, Decision logs. Used for policy input, result, bundle revision, traceability and data masking fields.
- Primary standard: IETF RFC 9421, HTTP Message Signatures. Used for component-level message integrity and its replay and coverage boundaries.
- Primary standard: IETF RFC 9110, HTTP Semantics. Used for idempotence and retry semantics.
- Primary paper: Jim Gray and Leslie Lamport, Consensus on Transaction Commit. Used to ground commit uncertainty and agreement under failure.
- Primary standard: IETF RFC 9162, Certificate Transparency Version 2.0. Used for append-only Merkle-tree commitments and consistency proofs.
- Primary paper: Bruce Schneier and John Kelsey, Secure Audit Logs to Support Computer Forensics. Used for tamper-evident audit-log design.
- Official specification: SLSA, Provenance v1.0. Used to make the trusted recorder and provenance-generation boundary explicit.
- Primary paper: Santiago Torres-Arias and colleagues, in-toto: Providing farm-to-table guarantees for bits and bytes. Adjacent evidence for signed step attestations across a multi-party supply chain.
- Primary paper: Joseph Y. Halpern and Judea Pearl, Causes and Explanations: A Structural-Model Approach, Part I. Used to distinguish operational reconstruction from stronger counterfactual actual-causality claims.
- Official guidance: NIST SP 800-92, Guide to Computer Security Log Management. Used as the baseline discipline for log infrastructure and lifecycle management.
- Official implementation documentation: OpenTelemetry, Traces and context propagation. Used as an implementation example for operational correlation.
sequenceDiagram participant Q as Question participant M as Mechanism participant E as Evidence participant D as Decision Q->>M: Two identical credits, two incompatible histories M->>E: Figure 1. One visible effect can be reached through accountable or defective histories E-->>M: compare rival explanations E->>D: Attribution must precede action D-->>Q: revise scope or act
Attribution must precede action
A post-hoc investigation cannot recover a proposal that was never frozen, a principal that was collapsed into a shared account, a policy input that was not retained, evidence that was silently refreshed or a commit that no authoritative system can attest. Logging more prose after the event does not repair those omissions.
The architectural decision changes from “capture a detailed trace” to “make every consequential effect consume a verifiable decision receipt and produce a verifiable effect receipt”. The trace remains valuable. Provenance remains valuable. Identity, policy and signatures remain valuable. The five-chain ledger makes their boundaries explicit and requires them to meet at one action.
For low-consequence atomic workflows, an ordinary audit transaction may already be enough. For distributed, delegated or hard-to-reverse actions, release should stop when intent, identity, authority, evidence or effect cannot be bound. The resulting system makes a modest promise: not that it knows every cause, but that it can defend which authorised control path produced the effect it claims.