Verification

How anyone can check a ledger, precisely what a passing check proves, and — just as importantly — what it does not prove.

Checking a ledger

Every published organization has a verification page at /transparency/<slug>/verify. It requires no account. It reports the ledger's head — the current sequence number, head hash, and entry count — and will walk the chain on request, recomputing each entry's hash and confirming that each entry commits to the one before it.

A check fails loudly and specifically. It does not return a verdict; it returns the sequence number of the first entry that does not reconcile.

The endpoints

The same checks are available directly, which is how an automated agent should read them:

GET /api/ledger/<slug>/head

The ledger's current head: sequence number, head hash, entry count. Returns the construction identifier sha256-canonical-json-v1 in an X-Ledger-Algo header.

GET /api/ledger/<slug>/verify?from=&to=

Walks a range and streams one NDJSON line per entry, each carrying chain_ok and hash_ok, followed by a summary. Where the chain breaks, the summary names the sequence number it broke at.

GET /api/ledger/<slug>/anchor.json

The most recent nightly checkpoint. Returns 404 where a ledger has not yet been checkpointed.

What a passing check proves

The chain is recomputed from the stored rows: each entry's canonical form is re-serialized and re-hashed, the result compared against the stored hash, and each entry's prior_hash compared against its predecessor's hash.

A pass establishes exactly this:

No entry's contents, actor, or timestamp has been altered without every subsequent hash also being recomputed.
No entry has been silently removed from the middle of the sequence.
No entry has been reordered.

In short: the records are internally consistent with each other. Combined with the database triggers that reject every update and delete outright (see The Ledger), the ordinary paths by which a record gets quietly revised are both blocked and detectable.

What it does not prove

This section is the reason this page exists, and it is longer than the section above on purpose. Verification is routinely over-read, and an auditor who over-reads it will draw conclusions the mathematics does not support.

It does not prove the transactions happened as recorded. This is the big one. A hash chain protects the record, not the reality behind the record. An organization that enters a payment that never occurred, or omits one that did, produces a ledger that verifies perfectly — because it is internally consistent, which is all a chain can speak to. Verification is evidence that the record has not been altered since it was written. It is not evidence that the record was true when written. What speaks to that is the underlying source evidence and the officer approvals attached to it — and, in the end, the accountability of the people who signed.

It does not prove the ledger was not wholly rewritten. The triggers prevent updates and deletes, but an operator with database-level access could in principle discard a chain and replay a fresh, internally consistent one. Only an attestation held by an independent party would foreclose this, and there is not one: the nightly checkpoint is written to the same database, by the same system, under the same credentials. It is a record the publisher made about itself, and it does not close this gap.

It does not prove when entries were appended. An entry's created_at is supplied by the writing system and included in the hash, so it is tamper-evident within the chain — but it is not independently attested. Nothing outside OpenBooks witnessed the time.

It does not prove the ledger is complete. See below; this is the gap least likely to be guessed at.

Known gaps

Independent recomputation does not currently work

The verification stream emits each entry's seq, event_type, event_hash, prior_hash, created_at, and the chain_ok / hash_ok results.

It does not emit content, actor_id, actor_email, or tenant_id — four of the nine fields in the preimage (see The Hash Chain). A client therefore cannot rebuild the preimage and cannot recompute the hashes. It receives chain_ok and hash_ok as computed by the server.

The practical consequence should be stated without softening: verification today is checkable by the publisher and reported to the reader. A reader who wants to verify independently must read entries from the public profile and reconstruct the preimage themselves. Instructions in the application that invite a reader to recompute from the stream do not work as written.

Reading this fairly

None of the above makes the chain worthless, and the honest summary is narrower than the marketing of such systems usually allows. What OpenBooks offers is a record that cannot be quietly edited, whose every entry names a responsible party, whose corrections survive alongside the things they correct, and whose integrity is arithmetic rather than assertion.

What it does not offer — today — is independence. Every check described here is ultimately performed by the publisher and reported to the reader. Closing that requires an attestation held by someone else, and until it exists, a reader is entitled to weigh these records as strong evidence about an organization's own consistency and not as proof of its honesty.

# What a verified chain says:
#   "These records have not been altered since they were written."
#
# What it does not say:
#   "These records were true when they were written."
#   "These records are all of the records."