An anchored record proves it hasn't changed. Not that it was true

Anchoring a hash on chain is the part of a decision ledger that gets oversold, sometimes by the people who build them. It gives two real guarantees and none of the others that tend to be implied. Knowing which is which decides where the engineering effort should go.

What the anchor proves

When the hash of an entry, or the root of a batch of entries, is written to a public chain, two things become verifiable by anyone. The entry existed before a given block. It has not been modified since. Nobody, including the operator, can quietly rewrite it. With an inclusion proof, a third party can check both without trusting your servers.

That is valuable. A log that can be edited by whoever has database access is a promise; an anchored one is evidence of integrity. But integrity of what was written is all it is.

What it does not prove

It does not prove the entry was correct when it was written. If the agent recorded a wrong reason, or the model produced a plausible but false justification, the anchor makes that wrong reason permanent and verifiable.

It does not prove the log is complete. An entry that was never written leaves no hash to check. If a step can be skipped without trace, the ledger shows a clean history with a hole in it that nobody can see.

It does not prove the writer was honest. If whoever controls the logging component can decide what gets recorded and when, anchoring protects their version of events. The chain faithfully preserves whatever it was given.

Where the design work actually sits

The useful work happens before the hash.

Capture at the source. The entry is written in the same step as the action, ideally in the same transaction, so an action without an entry cannot commit. Logging after the fact, from a separate job, is where gaps are born.

Make gaps detectable. Give entries a sequence number and chain each one to the previous with its hash. A missing entry then breaks the sequence in a way any verifier can see, instead of disappearing silently.

Separate duties. The component that writes the ledger should not be configurable by the people whose decisions it records. Its configuration and deployment are themselves part of what an auditor will ask about.

Record enough to judge correctness later. The anchor will not tell you whether a decision was right, but an entry that holds the inputs, the configuration it ran on and the stated reason lets someone else judge it.

Then the anchor means what people assume it means.

What does your audit trail prove today, and what does it only claim?