The System of Trust · Beyond Healthcare
The same append‑only, tamper‑evident ledger architecture engineered for HIPAA and 21 CFR Part 11 produces evidence in the shape SOX, GxP, GDPR, FedRAMP, and ISO 27001 reviewers already know how to read.
One architecture, many narratives. Magellan's ledger doesn't ship a SOX module, a GxP module, and a GDPR module. It ships four primitives — append‑only ULID storage, a SHA‑256 hash chain, role‑at‑time‑of‑action, and two‑component e‑signatures — and each regulatory framework is a different vocabulary over the same evidence. That's why the same ledger row that satisfies HIPAA §164.312(b) also satisfies ISO 27001 A.12.4.2.
The Four Pillars
Each pillar is a property of the data structure — not a process the application has to remember to follow, and not a checkbox tied to one regulator's wording.
Every ledger entry stores a SHA‑256 hash of the previous entry's content. Tampering with any historical row invalidates every hash from that row forward. ICFR walkthroughs, GxP data‑integrity reviews, and ISMS log‑protection controls all reduce to the same operation: re‑walk the chain, in O(n).
Every row is keyed by a ULID, not a UUID. The first 48 bits are a millisecond timestamp, so the primary key itself is the order. "Show me the ICFR control state on the last day of Q3" or "reconstruct the processing record at the time of the breach" becomes a primary‑key range scan — no separate timestamp index to keep honest under independent review.
Each ledger entry records the actor's role at the moment of action — not just the role they hold today. If a contributor is later promoted to approver, last quarter's ledger still shows them acting as a contributor. Segregation‑of‑duties testing, GxP qualification checks, and processor‑instruction audits work against the role that was in effect, not the role that exists now.
Production releases require a Contributor's draft signature plus an Approver's release signature — and the two signers must be distinct identities. Quarterly attestations require a Compliance Officer signature. Both signatures are themselves ledger entries, which means SOX §302 sub‑certifications, GxP release approvals, and ISMS change‑advisory‑board sign‑offs all leave the same evidence shape.
Live Demo
Four sample ledger entries, hashed with SHA‑256 in the Web Crypto API. Toggle a row to tamper with its content and watch every downstream hash fail.
Hashes computed with crypto.subtle.digest("SHA-256") · chain link = SHA‑256(ulid|ts|actor|role|action|prevHash)
The Vocabulary Choice That Matters
Why audit committees, control owners, and regulators respond to one of these phrases — and recoil from the other.
CIO / CMIO Brief — Predictive vs. AI‑powered, in 80 seconds.
| Dimension | "AI‑powered" | "Predictive mapping" |
|---|---|---|
| Specificity | Generic — applies to any product | Names the technique: candidate prediction over schemas |
| Audit committee fatigue | Triggers buzzword filtering | Reads as engineering vocabulary, not marketing |
| Audit posture | Suggests autonomous decisions | Implies proposals reviewed and signed by humans |
| Segregation of duties | Vendor implied accountable for the output | Named SME signs each mapping; SoD is explicit |
| Regulator‑safe | Triggers transparency questions | Aligns with predicate‑logic and human‑in‑the‑loop framing |
| ICFR / GxP fit | Implies model‑driven control execution | Frames AI as an upstream accelerator, not the control |
Specificity
"AI‑powered": Generic — applies to any product
"Predictive mapping": Names the technique: candidate prediction over schemas
Audit committee fatigue
"AI‑powered": Triggers buzzword filtering
"Predictive mapping": Reads as engineering vocabulary, not marketing
Audit posture
"AI‑powered": Suggests autonomous decisions
"Predictive mapping": Implies proposals reviewed and signed by humans
Segregation of duties
"AI‑powered": Vendor implied accountable for the output
"Predictive mapping": Named SME signs each mapping; SoD is explicit
Regulator‑safe
"AI‑powered": Triggers transparency questions
"Predictive mapping": Aligns with predicate‑logic and human‑in‑the‑loop framing
ICFR / GxP fit
"AI‑powered": Implies model‑driven control execution
"Predictive mapping": Frames AI as an upstream accelerator, not the control
Magellan is a predictive mapping platform — the Semantic Match Engine proposes; named SMEs approve; the SHA‑256 ledger proves it.
Multi‑Framework Crosswalk
The shortest defense of any audit system: the evidence already exists in the form the auditor needs it — regardless of which auditor walks in.
| Framework | Requirement | Source clause | How Magellan satisfies it | Brief |
|---|---|---|---|---|
| SOX | Internal control over financial reporting — change integrity | Sarbanes‑Oxley §404 / PCAOB AS 2201 | Append‑only ULID ledger + SHA‑256 hash chain over every mapping change | |
| SOX | Segregation of duties between preparer and approver | PCAOB AS 2201 (entity‑level controls) | Two‑component e‑signature: distinct Contributor and Approver identities, RBAC‑enforced | |
| GxP | Audit trails generated independently and protected from alteration | EU GMP Annex 11 §9 | Append‑only ULID ledger + SHA‑256 hash chain (verifier walks O(n) to detect any silent rewrite) | |
| GxP | Electronic signatures linked to their records | EU GMP Annex 11 §14 / FDA 21 CFR Part 11 §11.70 | Signatures are themselves ledger entries, hash‑chained to the record they sign | |
| GDPR | Records of processing — categories, recipients, retention, transfers | GDPR Art. 30(1) | Schema, mapping target, and downstream system are first‑class ledger fields, primary‑key‑ordered by ULID | |
| GDPR | Demonstrate that processing follows controller instructions | GDPR Art. 32(4) | Role‑at‑time‑of‑action shows which controller‑authorized identity made each change | |
| FedRAMP | Configuration change control with approval workflow | NIST SP 800‑53 CM‑3 | Contributor draft + distinct Approver release, both captured as signed ledger entries | |
| FedRAMP | Audit record retention with integrity protection | NIST SP 800‑53 AU‑9 / AU‑11 | ULID‑keyed retention by date range; SHA‑256 chain detects any post‑hoc modification | |
| ISO 27001 | Logging facilities and log information protected against tampering | ISO/IEC 27001 Annex A.12.4.2 | SHA‑256 hash chain over append‑only ledger; tamper attempts are mathematically detectable | |
| ISO 27001 | Change management approval evidence | ISO/IEC 27001 Annex A.12.1.2 | Two‑component e‑signature on every release, recorded as ledger entries |
Internal control over financial reporting — change integrity
Append‑only ULID ledger + SHA‑256 hash chain over every mapping change
Download SOX brief (PDF)Segregation of duties between preparer and approver
Two‑component e‑signature: distinct Contributor and Approver identities, RBAC‑enforced
Download SOX brief (PDF)Audit trails generated independently and protected from alteration
Append‑only ULID ledger + SHA‑256 hash chain (verifier walks O(n) to detect any silent rewrite)
Download GxP brief (PDF)Electronic signatures linked to their records
Signatures are themselves ledger entries, hash‑chained to the record they sign
Download GxP brief (PDF)Records of processing — categories, recipients, retention, transfers
Schema, mapping target, and downstream system are first‑class ledger fields, primary‑key‑ordered by ULID
Download GDPR brief (PDF)Demonstrate that processing follows controller instructions
Role‑at‑time‑of‑action shows which controller‑authorized identity made each change
Download GDPR brief (PDF)Configuration change control with approval workflow
Contributor draft + distinct Approver release, both captured as signed ledger entries
Download FedRAMP brief (PDF)Audit record retention with integrity protection
ULID‑keyed retention by date range; SHA‑256 chain detects any post‑hoc modification
Download FedRAMP brief (PDF)Logging facilities and log information protected against tampering
SHA‑256 hash chain over append‑only ledger; tamper attempts are mathematically detectable
Download ISO 27001 brief (PDF)Change management approval evidence
Two‑component e‑signature on every release, recorded as ledger entries
Download ISO 27001 brief (PDF)The Auditor's View
The first three questions don't change much between an SOX walkthrough, a GxP inspection, and an ISO 27001 surveillance audit.
01
Filter by mapping ULID and date range. Result is in chronological order because the primary key is the order — works the same for an SOX walkthrough, a GxP data‑integrity review, or a GDPR Art. 30 records‑of‑processing request.
02
Export the ledger range with its SHA‑256 hash chain. Re‑walk the chain. A single altered character would break every downstream hash — the same evidence satisfies ISO 27001 A.12.4.2, FedRAMP AU‑9, and Annex 11 §9.
03
The release row carries both the Contributor's draft signature and the Approver's release signature, and RBAC enforces that the two identities differ — directly addressing SOX segregation‑of‑duties, FedRAMP CM‑3, and GxP §14.
Related Reading
Six posts that walk the architecture from primary key to attestation — every clause cited across SOX, GxP, GDPR, FedRAMP, and ISO 27001.
The four moving parts mapped to HIPAA, SOX, GxP, GDPR, FedRAMP, and ISO 27001 clauses.
Read postThe seven‑role model behind SoD for SOX §404, FedRAMP AC‑5, and ISO A.5.3.
Read postWhat the verification script actually checks — under NIST AU‑9 and ISO A.8.15.
Read postWhy the primary key is the chronological order — for GDPR Art. 30 and AU‑11.
Read postThe Compliance Officer's workflow that satisfies §11.10(j), Annex 11 §9, and ISO A.5.35.
Read postThe same five questions across SOX, GxP, GDPR, FedRAMP, and ISO 27001 walkthroughs.
Read postPer‑Framework Briefs
Same shape as the Audit Ledger Brief, recast against the specific clauses your assessor will cite. Hand the right one to the right room.
PCAOB AS 2201 walkthrough
Download21 CFR Part 11 · EU GMP Annex 11
DownloadArticles 30, 32, 5(1)(c)
DownloadNIST SP 800‑53 AU & AC families
DownloadAnnex A.5, A.8, A.5.35
DownloadFor procurement
Need a single attachment? All 6 briefs (Audit Ledger + 5 frameworks) bookmarked in one PDF.
Healthcare framing
Read the same architecture under HIPAA §164.312(b) and 21 CFR Part 11, with the four‑post audit blog cluster and the SME briefs your compliance team will ask for.
Bring a sample mapping and the regulator your team is preparing for. We'll walk the ledger, the role split, and the hash‑chain verification end‑to‑end against the clause you have to defend.