Why a Merkle ledger is the cheapest way to make an audit trust you
What actually makes an audit tamper evident, and why it has nothing to do with trust.
A few months into building Balise, a procurement officer asked me a question I didn’t have a good answer for yet: “who’s stopping the vendor from just changing this number after we sign off on it?” The number in question was a carbon estimate, sitting in a spreadsheet, next to a methodology note that nobody downstream would ever open. Nothing technical was stopping anyone. That’s the actual problem environmental disclosure has, and it’s not a measurement problem.
The problem isn’t the number, it’s the edit history
Most audit trails are a folder of files with timestamps you have to take on faith. A spreadsheet’s “last modified” date is metadata the same application can rewrite. A PDF’s creation date lives in a header nobody checks. If the only record of a claim is a mutable file sitting on someone’s drive, then the claim is exactly as trustworthy as the person holding the drive, no more. For public procurement, where the vendor grading their own homework and the vendor supplying the numbers are the same company, that’s not good enough.
What you actually want is boring: a record where changing anything after the fact is expensive to hide, and cheap for anyone else to check. That’s what a Merkle structure buys you, and it buys it for the price of a hash function.
What changing one line actually costs
Hash every entry, then hash pairs of hashes going up, until one root hash is left. That root is a fingerprint of every leaf underneath it, in order. Publish the root somewhere you can’t quietly edit later, a timestamped commit, a public log, even just an email you send yourself. Now try to change one entry from three months ago without anyone noticing.
You can’t just edit the leaf. Its hash changes, which changes its parent’s hash, which changes its parent’s hash, all the way to the root. The root you published no longer matches the root your edited data produces. You’d have to recompute the entire path back to the root and somehow get everyone who saw the old root to forget it. That’s the whole mechanism. No permission system, no audit log that itself needs auditing.
You don’t need to trust the ledger. You need the ledger to make lying expensive.
This is not blockchain
I want to be clear about this because the word “ledger” drags baggage with it. Balise doesn’t need consensus, doesn’t need mining, doesn’t need a token, and doesn’t need a network of strangers agreeing on anything. It needs one append-only structure and one published root. Blockchains solve the much harder problem of agreeing on shared state with no trusted party at all. Public procurement has a trusted party, it’s the buyer. The buyer just needs proof that what they’re looking at is what was actually submitted, not a friendlier version assembled after the fact.
Reaching for a blockchain here would mean paying for a distributed consensus mechanism to solve a problem that a hash tree and a strictly typed criteria engine already solve, at a fraction of the complexity and none of the operational cost.
Where it stops helping
A ledger makes the record tamper evident. It says nothing about whether the first entry was honest. If the initial measurement is wrong, or the methodology is generous in the vendor’s favor, the ledger will faithfully preserve that dishonesty forever, with a very convincing cryptographic guarantee attached to it. This is the part people skip when they get excited about tamper-evident anything: it protects the history of a claim, not the truth of the claim on day one. You still need a real measurement pipeline upstream, and you still need someone with the authority to reject a bad submission before it ever becomes a leaf.
What it does buy you is the one guarantee spreadsheets can’t: once something is in, quietly taking it back out is no longer an option. For an audit trail, that turns out to be most of the job.