How Do You Know It's Right? The Case for a Split Ledger

I've spent my career as an architect, as a developer for many years, and I've led as a CTO in organizations big and small. On the most ambitious projects, three forces always compete: the speed of innovation, compliance, and architectural soundness.

Move fast, and compliance catches up with you. Lock everything down, and you stop shipping. Get the architecture right, and someone asks why it took so long.

In that tug of war, two questions tend to fall through the cracks:

• What happens when something goes wrong?
• How do you know it's right?

Tap the diagram to open it full size.

Like many technologists, I've worked in organizations where the first response to a bug that captured the wrong data was to fix it behind the scenes, straight in the database. It happened again and again, with no audit trail. When we realized what was going on, it was frightening. It was also the evidence we needed: this wasn't a one-off bug, it was a pattern. And the older the systems and processes, the worse it gets.

The question nobody budgets for

Every project I've led had a plan for features, scale and the security review. Far fewer had a real answer to this one: if a value in production changes when it shouldn't, how would we know?

Usually, the database is its own witness. The logs sit right next to the data, often under the same administrators. Whoever can change the data can usually change the record of the change, and that isn't anyone's fault; it's simply how most systems are built.

Blockchain isn't just Bitcoin

When I say "ledger," a lot of people hear "cryptocurrency." That's understandable: Bitcoin made blockchain famous. But public, anonymous coins are only one use of the idea.

Private, permissioned chains such as Hyperledger Fabric were built for the enterprise. The participants are known. Access is controlled. There's no mining, no tokens and no speculation. What they keep is the part that matters for security: an append-only record where every entry is chained to the one before it, so history can't be quietly rewritten. It isn't a science project either: in 2026, almost 30% of live financial platforms that disclose their technology run on Linux Foundation ledger projects such as Fabric (LF Decentralized Trust).

In security terms, that's a witness. And the idea is proven at internet scale: Certificate Transparency, the public logs browsers rely on to check website certificates, works on the same principle of tamper-evident records checked by independent parties.

Two ways to wire it

Prevention where you can, detection everywhere else. There are two patterns, and most organizations will use both.

• The ledger as the system of record. The most critical values are only ever written through the ledger's own transaction logic, under a policy that says who must approve a change. An undocumented change is rejected outright, because it never gets the approvals it needs.
• The ledger as a witness to your existing database. The data stays where it is, and the ledger holds a fingerprint of every approved state. A change made behind the scenes shows up as a mismatch. The system refuses to trust it, rolls back to the last verified value, and raises the alarm.

A data point changes. Now what?

Undocumented changes get rejected. Documented changes get recorded. Here's the pattern I want in every system that matters:

1. A data point changes.
2. The system checks the ledger. Is there a documented, approved change behind it?
3. If it's documented, it goes through, and a new block records what changed, who approved it, and why.
4. If it's an emergency, it goes through too, flagged. Real incidents need a break-glass path. The change is allowed, and its block is marked as an emergency change pending review.
5. If it's undocumented, it's rejected or rolled back. The last verified value stays, and the right people are told at once.
6. Emergencies and blocked attempts open a root-cause analysis. Why did someone go around the process, and is the cause really fixed? The RCA closes the loop for audit.

Tap the diagram to open it full size.

The result is a system that defends its own data. It doesn't just log what happened. It refuses what shouldn't happen, writes down what should, and heals itself back to the last verified state.

Why split the ledger

A ledger that lives next to the data it protects has the same weakness as a database log: whoever controls one controls both.

So split it. Run ledger peers in different clouds, under different identities, different administrators and different control planes. The data lives in one place. The other cloud holds only fingerprints. Hyperledger Fabric supports this directly with private data collections: members outside the collection hold the hashes, never the data. Every block has to agree.

Tap the diagram to open it full size.

Now, quietly rewriting history means compromising unrelated platforms at the same time. And if they ever disagree, the disagreement itself is the alarm.

Planning for the bad day

A split ledger is only as strong as the decisions around it.

• Separate the keys, not just the clouds. If one administrator holds the signing keys for both sides, two clouds don't help. Each side needs its own identities, with keys in its own hardware security modules.
• Add a third witness. The protocols that order a ledger need a majority to agree. With only two clouds, losing one stops writes. A small third witness keeps the majority. It can sit in another zone or region of one of your clouds, which is simple and inexpensive, though that provider then holds two of the three votes. A third cloud or your own data center means no single provider ever holds the majority. For the most critical data, deciding to fail closed, pausing writes rather than letting them go unwitnessed, is a legitimate choice. Just make it on purpose.
• Keep personal data off the chain. Immutable records and the right to be forgotten don't mix. Keep the data off-chain and only fingerprints on it, and encrypt each tenant's data with its own key, so erasing the key erases the data.

Where this is going

Every day, more and more machines are joining the people who change data, and that makes this matter more than ever.

AI agents already read, decide and write at machine speed. Two in five organizations with over $1 billion in revenue already report scaling AI agents (McKinsey, 2026). Every change an agent makes should be documented, approved under policy and on the record, exactly like a person's. A split ledger is the guardrail that makes autonomy auditable.

It changes audit, too. Instead of sampling evidence once a year, auditors can check the ledger continuously. And root-cause analysis can start from facts, because the ledger already knows what changed, who approved it and why, instead of starting from interviews.

Speed, compliance and soundness, together

That's why I like the split ledger as an approach. It doesn't slow innovation: teams keep shipping, and documented changes flow straight through. It gives compliance something it rarely gets, which is proof instead of promises. And architecturally, it answers the two questions that usually fall through the cracks.

What happens when something goes wrong? The system catches it, refuses it and tells you.

How do you know it's right? Independent clouds agree.

Questions I always get

What happens when one cloud is down, and how do the two sides resync?

The service that orders the ledger only needs a majority to keep working, so with a small third witness, losing one cloud doesn't stop writes. When the missing side comes back, it doesn't just copy what it's sent. It replays the blocks it missed and verifies every one, the fingerprints, the signatures and the approvals, before accepting them. You can't slip a rewritten history past a node that's catching up. If the two sides still disagree afterwards, that isn't a sync problem. It's the alarm. For the most critical data, you can choose to pause writes until both sides can witness them.

Doesn't a ledger slow everything down?

Less than people expect. Bitcoin is slow on purpose, because strangers have to compete to agree. A private ledger has known participants and no mining, so agreement is fast. The rest is design: put fingerprints on the ledger, not payloads; keep reads off it entirely; witness most changes a moment after they're written; and save in-line approval for the values that truly need it, like payments, entitlements and safety thresholds. You pay a little on every important change, and you never again reconstruct what happened from interviews.

Andrea Garrymore is the founder and CTO of Feathergrid. An architect by craft and a developer for many years, she has led technology in organizations big and small.