April 19, 20264 min read

Hash-Chain Integrity for the Magellan Audit Ledger

Why a Hash Chain Sits Under the Ledger

An append-only table is not enough. "Append-only" is a *policy* — until you can prove a historical row has not been quietly rewritten, you are asking the regulator to trust your operations team. A hash chain converts that trust into a check anyone can run.

Magellan's audit ledger uses a SHA-256 hash chain: every entry contains the SHA-256 hash of the previous entry. Tampering with any row in history invalidates every hash from that row forward. The verification is deterministic and runs on the exported evidence, not on Magellan's running system.

What Each Entry Contains

Every ledger entry stores, in addition to its ULID primary key:

The actor's user identifier
The actor's role at time of action
The action payload (what was decided, signed, or attested)
An ISO 8601 UTC timestamp
The SHA-256 hash of the previous entry's serialized content
(Where applicable) an electronic signature

The previous-entry hash is what makes the chain. The very first entry — the genesis row — uses a fixed all-zeros previous hash so the chain has a defined start.

The Verification, in Three Lines of Pseudocode

```

prev_hash = GENESIS // 32 bytes of 0x00

for entry in ledger_export ordered by ULID:

assert entry.prev_hash == prev_hash

prev_hash = SHA256(canonical_serialize(entry))

```

That's the entire integrity check. If a single byte of any historical entry was changed, the recomputed prev_hash for the *next* entry will not match what is stored, and the assertion fails. The same is true for inserting a forged row, deleting a real row, or reordering rows.

What "Canonical Serialize" Means and Why It Matters

The hash is computed over a canonical serialization of the entry — fields in a fixed order, no whitespace variation, no implementation-defined floating-point formatting. Two correct verifiers must produce byte-identical hashes from the same entry, otherwise the chain cannot be re-walked outside Magellan's own runtime. Magellan publishes the canonicalization spec inside the evidence pack alongside the verification script, so an external auditor's tooling can confirm the chain independently.

Three Tampering Scenarios

Scenario	Detection
Edit a historical row	Next row's stored `prev_hash` no longer matches the recomputed hash → assertion fails on that row.
Insert a forged row	The forged row's own `prev_hash` may be made plausible, but the real next row's `prev_hash` was computed against a different predecessor → fails on the next row.
Delete a row	The row after the deletion has a stored `prev_hash` pointing at the deleted row → fails because the predecessor in the export is now a different entry.

In all three cases, the failure is localized: the verifier reports the exact ULID where the chain breaks, which is itself a useful incident-response signal.

How This Maps to 21 CFR Part 11 §11.10(e)

§11.10(e) requires "secure, computer-generated, time-stamped audit trails… [that] shall not obscure previously recorded information." A hash chain is the strongest practical demonstration of that property short of cryptographic notarization to a third party:

Secure — tampering is mathematically detectable.
Computer-generated — the hash is computed at write time, not by the actor.
Time-stamped — every entry carries an ISO 8601 UTC timestamp *and* a ULID whose first 48 bits encode the same instant.
Shall not obscure — any obscuring attempt fails verification.

A regulator can go further if they want: anchor a periodic Merkle root of the chain to a trusted timestamping authority. Magellan exposes a hook for this, but the chain is defensible without it.

What the Chain Does Not Defend Against

Honest accounting:

Compromised write path. If an attacker has live access to the audit-write code, they can write entries that hash correctly. The hash chain protects *historical* integrity, not write-time authenticity. That is what the seven-role RBAC model and the §11.200 two-component signature defend.
Coordinated rewrite of every entry from the tampered point forward. This is technically possible but requires offline access to recompute every hash and re-sign every signature — and breaks any external Merkle anchor.

These are the right limits to be honest about. They are also why hash chain, RBAC, and signatures are layered, not chosen between.