Immutability · PG-15 # An immutable ledger for accounting — and not a blockchain Append-only enforced at the storage layer, a chain hash on every Final entry, and an independently runnable verifier — no vendor trust required. - chain on by default - verify offline - SHA-256, algorithm-tagged - typed corrections only An immutable ledger for accounting means posted records cannot be altered or deleted: the final store rejects UPDATE and DELETE at the storage level, every Final entry carries a cryptographic chain hash, and later economic changes enter as new, typed entries — reversal, adjustment or restatement — linked to the original. Ledgerbook AI implements that without blockchain: append-only storage, a hash-chained event stream with per-batch Merkle roots and per-event inclusion proofs, an online or offline verifier any third party can run, and as-of reads that reconstruct both the balance and what was believed on a past date. Chain hashing is on by default and cannot be switched off. Verified 2026-09-19 · Sources: Ledgerbook product docs — immutability (FR-214, FR-118–121) and corrections (FR-205) · Phase: PH-1 Phase legend: ✓ PH-1 shipped now · ◇ Roadmap arrives with PH-2. Labels are always present — colour is never the only signal. ## How the chain works — and why it cannot quietly change Immutability here is a property of the data path, not a policy promise: each layer removes a different way to rewrite history, and each fails closed when it cannot verify. Together they are the answer to the non-rewriteable, non-erasable record condition regulators test for — WORM-grade audit trails without WORM media, in the SEC Rule 17a-4 pattern, where the evidence is a verification you can run rather than a media certificate. | Layer | Mechanism | What it forecloses | |---|---|---| | **Storage** | The final store rejects UPDATE and DELETE at storage level — role revocation plus a database trigger — and offers no soft-delete that could detach Final entries from reports. | In-place mutation; "deleted but reported" ambiguity · FR-214 | | **Entry** | Every Final entry is sealed with a chain hash: hash_n = H(prev_hash ‖ canonical_payload), with a defined genesis per ledger and SHA-256 by default. The chain is on for every ledger and cannot be disabled by writers or configuration shortcuts. | Retroactive rewrite of sealed entries · FR-118/119 | | **Event stream** | Every event carries prev_hash/hash over its canonical serialization, in insertion order — every commit, even micro-edits — with batch-level Merkle roots at volume. | History surgery between checkpoints; provenance tampering · FR-237/524, FR-208 | | **Algorithms** | The hash payload carries its serialization/schema version and algorithm id; the algorithm registry is data, migration is segment-wise, and unknown or missing algorithm ids fail closed on both writes and verification. | Silent downgrades; migration invalidating old proofs · FR-120/122/810 | Scope note: "every entry is chain-hashed" always means every entry once Final — pre-finalization entries are protected by the append-only event chain and per-revision content hashes until sealed. ◇ Roadmap The post-quantum hybrid suite (ML-KEM / ML-DSA) and external anchoring ride the PH-2 schedule; the crypto-agility seams that make them a migration rather than a re-architecture ship at PH-1. ## Verify it yourself — do not take the vendor's word Verification must be reproducible, not asserted. Ledgerbook chain-hashes every event, publishes per-batch Merkle roots and per-event inclusion proofs, and ships an independently runnable verifier: given a root and an audit tuple, it recomputes the balance from chain data alone and detects any retroactive rewrite. - **Online.** A verify operation recomputes the chain and returns PASS — or the first divergent entry with its location and expected/actual hash. - **Offline.** The same check runs against a signed ledger export in an air-gapped environment; the same signed export replays into a fresh deployment, materialising ledger state — air-gap transfer and host migration are first-class operations, not bespoke tooling. - **Against published roots.** The verifier reproduces any balance from the audit tuple plus inclusion proofs, so an auditor detects a retroactive rewrite without ledger access. ◇ Roadmap The published correctness-evidence regime (repeated build evidence for auditors) and external timestamp/witness anchoring are PH-2 — deliberately off the critical path. Recompute the chain over a range and get PASS, or the first divergence with expected and actual hashes. A tampered payload fails at the offending sequence — the error names it. FR-121 · PH-1 For the tuple (E, K, scope): checkpoint hash, redo sequence range and inclusion proofs — enough for a third party to recompute the balance from the chain alone. FR-813, FR-516 · PH-1 `# online — recompute the chain from genesis $ ledgerbook verify --chain grp-eu --from genesis chain grp-eu sealed ledger_seq 184220 result PASS root sha256:3d81…c04e (batch 1847 · 2026-09-19) # divergence is named, never summarised result FAIL at ledger_seq 120411 expected 7ab3… actual c19f… # offline — same check against a signed export, air-gapped $ ledgerbook verify --export grp-eu-2026-Q3.ocel.json result PASS` The verifier runs from the chain alone; a fixture chain ships with the developer preview so the check can be reproduced before deployment. FR-121/813 · PH-1 ## The same query, the honest answer: not blockchain Chain-hash tamper-evidence and distributed-ledger technology solve different problems. One is a data-integrity mechanism inside your accounting record; the other is a consensus system for multi-party truth. Ledgerbook uses only the first. | Dimension | Ledgerbook chain-hash | Public blockchain / DLT | |---|---|---| | What seals the record | A per-entry chain hash over the canonical payload, genesis per ledger, every event chained in insertion order. | Consensus over a replicated, shared ledger. | | Who verifies | Any third party with the export, the published roots and the verifier — offline, no vendor access. | Network participants, per the protocol's rules. | | Where the data lives | Your infrastructure. PII never enters hashed ledger payloads — off-ledger vault, on-ledger commitments only. | Replicated across the network; erasure is protocol-dependent. | | Corrections | Typed new entries — reversal, adjustment, restatement — linked to the original; nothing is edited. | Protocol-dependent, often immutable-by-default with no accounting vocabulary. | | Independent time | ◇ Roadmap External timestamp/witness anchoring ships PH-2, off the critical path. | Intrinsic to consensus — this is where public chains genuinely win. | | Erasure story | Commitments stay verifiable while per-subject keys are destroyed — crypto-shredding ships at PH-1, within 30 days including backups and caches, with legal hold suspending it. | Not an accounting-grade erasure model; legal-hold conflicts are unsolved in practice. | **The design in one line:** hashes on the ledger, PII off it. Commitments keep the audit trail verifiable through erasure, and the erasure act itself is a provenance event. Legal-hold regimes suspend erasure for affected subjects. FR-808, NFR-11 · PH-1 ## Why can't you edit a finalized journal entry? Because an edit would destroy the evidence trail — the audit question is not only what the number is, but what it was and who changed it. Once Final, an entry's postings cannot be modified or deleted; a later change is recorded as a new typed entry — reversal, adjustment (for IAS 10 adjusting events) or restatement (error corrections) — linked to the original. Both the mistake and its fix stay visible and attributable. Verified 2026-09-19 · Sources: Ledgerbook product docs — correction semantics (FR-205, FR-123–125, FR-228) · Phase: PH-1 The original entry stays byte-identical and gains a corrected-by relationship to the new one; the correction carries its type on every surface — REST, events, MCP and OCEL exports. "Revision" is provisional-edit vocabulary only and is never used as a correction type. Full lifecycle mechanics live on [the Provisional → Final lifecycle page](/provisional-lifecycle#corrections). ## Immutability FAQ In accounting, an immutable ledger means posted records cannot be altered or deleted — corrections are added as new, typed, attributable entries. Ledgerbook implements that with append-only storage, chain-hashed event history and typed corrections (reversal, adjustment, restatement); no blockchain is involved and no wallet-custody semantics apply. Third parties can verify the chain without trusting the vendor. Three layers. Storage refuses UPDATE and DELETE for posted rows — revoked privileges plus a defending trigger, with no soft-delete that could detach Final entries from reports. Every Final entry carries a chain hash over its canonical payload, on by default and not disableable. And any later economic change enters as a new, typed entry linked to the original: history is appended, never rewritten. FR-214, FR-118/119 · PH-1 Verification must be reproducible, not asserted. Ledgerbook chain-hashes every event, publishes per-batch Merkle roots and per-event inclusion proofs, and ships an independently runnable verifier: given a root and an audit tuple, it recomputes the balance from chain data alone and detects any retroactive rewrite. External anchoring with a timestamp or witness service is a roadmap item, deliberately designed to sit off the critical path. Related: [Run the verifier](#verify) · [Provenance & OCEL 2.1](/provenance-ocel2) · FR-524/813/516 · PH-1 (anchoring Roadmap) Yes — that is the point. The original entry stays byte-identical and gains a corrected-by relationship to a new entry typed reversal, adjustment or restatement. Both the mistake and its fix stay visible, attributable and chain-linked — and the correction is itself a chain-sealed event like any other. [Correction semantics](#corrections). ## Verify the ledger — don't take our word Chain-hashed by default, verifiable offline, correctable only by provable, attributable entries.