Decision ledger: what actually goes on chain

Whenever I explain on-chain anchoring of a decision ledger, the first objection is always the same, and it deserves to be: "I can't put my clients' data on a public chain."

You don't. That's the point.

The fingerprint, not the content

The ledger stays where it belongs: in the client's database, inside their perimeter, under their retention and deletion rules. What gets anchored is a cryptographic fingerprint computed over a block of ledger rows, at regular intervals.

Anyone reading the chain sees nothing legible. They see a string. That string does exactly one job: if someone later claims the ledger was edited after the fact, you recompute the fingerprint and compare.

• The content stays private and erasable, which is what data protection law requires
• The ordering in time becomes provable to a third party
• The cost per anchor is negligible once you aggregate by window

Why a signed log isn't enough

A signed log proves I signed it. It doesn't prove when. The value of a chain is precisely what people hold against it: it's slow, it's public, and it's inconvenient to rewrite.

That last property is the only one you're buying.