Magellan's Audit Architecture, in One Page
> Where to read this in context: the same primitives are described under healthcare framing on /audit (HIPAA + 21 CFR Part 11) and under cross-industry framing on /audit/regulated-industries (SOX, GxP, GDPR, FedRAMP, ISO 27001).
Why a Single-Page Tour
Magellan's audit ledger has a small number of moving parts, but every one of them is load-bearing for at least one regulator. The same four primitives map onto HIPAA §164.312(b), 21 CFR Part 11, SOX §404 ITGCs, EU GMP Annex 11 §9, GDPR Art. 30, FedRAMP (NIST SP 800-53 AU-2/AU-9/AU-10/AU-12), and ISO 27001:2022 A.8.15. This post puts the whole picture on one page so a CIO, a compliance lead, an external assessor, or a partner architect can decide whether to dig into the deeper material.
The Four Parts
1. ULID-keyed entries. Every ledger row uses a ULID as its primary key, not a UUID. The first 48 bits of the ULID are a millisecond timestamp, so the key itself is the chronological order. Range-scanning to a moment in time becomes a primary-key lookup, and there is no separate timestamp index to keep honest. This is what makes "show me every action between these two moments" a single seek instead of a sort.
2. SHA-256 hash chain. Every entry stores a SHA-256 hash of the previous entry's content. Tampering with any historical row invalidates every hash from that row forward. A verifier walks the chain in O(n) and can prove the ledger has not been silently rewritten — which is exactly what 21 CFR Part 11 §11.10(e), NIST SP 800-53 AU-9 ("Protection of Audit Information"), and ISO 27001 A.8.15 ("Logging") all require in different language.
3. Role-at-time-of-action. Each entry stores the actor's role *at the moment the action occurred*, not just the user identifier. If a contributor is later promoted to approver, last quarter's ledger still shows them acting as a contributor. This is what makes the seven-role RBAC model defensible against §164.312(b), SOX §404 segregation-of-duties, and FedRAMP AC-5 — the role split is preserved retroactively, not just enforced going forward.
4. Two-component electronic signatures. Production releases require a Contributor's draft signature plus an Approver's release signature, satisfying 21 CFR Part 11 §11.200's two-component requirement and the SOX four-eyes control on production change. Quarterly attestations require a Compliance Officer signature, satisfying §11.10(j) and the periodic-review obligations in EU GMP Annex 11 §9 and ISO 27001 A.5.35. Both signatures are themselves ledger entries.
What Each Part Defends Against
| Failure mode | Defended by | Where regulators name it |
|---|---|---|
| Entry inserted after the fact with a fake timestamp | ULID primary key + hash chain | 21 CFR Part 11 §11.10(e); NIST AU-10 |
| Historical entry quietly modified | SHA-256 chain | HIPAA §164.312(b); ISO 27001 A.8.15; NIST AU-9 |
| Role-change rewrites who-did-what | Role-at-time-of-action | SOX §404 SoD; FedRAMP AC-5; HIPAA §164.308(a)(3) |
| Single user releases to production unilaterally | Two-component e-signature | 21 CFR Part 11 §11.200; SOX change-management ITGC |
| Quarterly review never actually happens | Compliance Officer attestation entry | 21 CFR Part 11 §11.10(j); EU GMP Annex 11 §9; ISO A.5.35 |
| Administrator silently grants themselves audit access | RBAC: Administrator cannot grant audit roles | NIST AC-6(7); SOX SoD |
Each row is a control an external assessor will ask about, regardless of which framework they arrived under. Each defense is a property of the data structure, not a process the application has to remember to follow.
What Lives Outside the Ledger
A few things deliberately do *not* live in the ledger:
- The mappings themselves. The ledger records *decisions about* mappings — who approved what, when, with which role — not the mapping payload. Mapping bodies live in their own versioned store, identified by ULID, and the ledger references them.
- Authentication tokens. Sessions, JWTs, and refresh tokens are not in the ledger. Login *events* are.
- Sensitive payloads. Whatever is sensitive in your domain — PHI in healthcare, PII under GDPR, materially non-public financial figures under SOX, controlled unclassified information under FedRAMP — is referenced indirectly by mapping ULID. The ledger itself contains no sensitive payloads, so a §164.312(b) ledger export does not become a §164.502(b) minimum-necessary problem, and a GDPR Art. 30 record-of-processing export does not become an Art. 5(1)(c) data-minimization problem.
Read Next
- ULID vs UUID — why the primary key matters.
- Why Three Roles Aren't Enough — the role model the ledger preserves.
- Hash-Chain Integrity Deep Dive — how the SHA-256 chain works in practice.
- Audit Evidence Export and Attestation — what the Compliance Officer actually does each quarter.
- What an Auditor Actually Sees — the same five questions across HIPAA, SOX, GxP, GDPR, FedRAMP, and ISO 27001 walkthroughs.
- Why the Ledger Lives in the Same Container — the structural splits that make co-location defensible.
- The Audit Ledger Brief (PDF) is the one-page technical summary.
To see the full ledger demonstrated against your own scenarios — pick the framework you need to defend against — request a demo.
*Magellan AI Corporation — Charting every data connection.*