Cold Trail
Federated claims lineage across legacy stack
Public-sector agency couldn't trace a benefits claim through their stack. The data lived across four legacy systems that had each been 'the source of truth' at different points over 20 years: a z/OS mainframe at intake, an Oracle eligibility engine bolted on in the mid-2000s, a Java EE adjudication service from 2011, and a .NET payout and AR ledger that came in with a 2016 modernisation that stalled halfway. Audit cycles took 6 weeks of analyst archeology per quarter, half of which was reconciling fields that meant slightly different things in each system. New data-residency rules raised the stakes: every observation about a claim now had to be provably captured, attributed, and stored inside the jurisdiction. The regulator had stopped accepting 'we are working on it' as an answer.
Read-only CDC taps on each legacy system
Source modification was off the table, the regulator forbade it and most of the original vendors are gone. Debezium handles the Oracle, Java EE and .NET sides; a custom z/OS hook reads the mainframe journal without writing back. Each tap emits a stream of raw state events tagged with source, timestamp and a CDC offset for replay.
Normalizer translates into a shared event vocabulary
Each system used its own status codes, its own date formats, its own idea of what a claim_id was. The normalizer reduces all four into one vocabulary: subject, scheme, observed_state, observed_at, source_system, source_offset. Disagreements are preserved, not flattened; the ledger keeps every observation, the conflict surfaces in the trace UI for the auditor to resolve.
Hash-chained ledger captures every observation
Postgres in append-only mode. Each row carries the previous row's hash; every write is signed. Backfill of 4M+ historical claims ran with idempotency keys so the job was restartable, and so a partial replay never produced a different chain than a full one. Reads are role-scoped: caseworkers see their queue; auditors see everything in their jurisdiction.
Daily notary anchor for external-of-system tamper detection
Tamper resistance inside one system is theatre, an admin can always rewrite a row. Once a day the ledger publishes its head hash to an external timestamp authority. Any altered node breaks the chain at the next read, and the anchor makes the break provable against an external party even if the entire database is rewritten.
Trace UI plus regulator export
Two surfaces sit on top: a caseworker search (find a claim, see its full trail across the four systems in one view) and an auditor portal that exports the regulator's prescribed format directly, no spreadsheet stitching. The 6-week analyst archeology cycle collapses into a query.
Four legacy systems on the left, each fronted by a read-only CDC tap so the source is never touched. Streams funnel into the normalizer, which maps every system's events into one vocabulary, then a state-transition recorder timestamps each observation and a hash + sign stage chains and signs it. Writes land in an append-only ledger; a daily notary anchor publishes the head hash externally. The trace API serves both an auditor portal (regulator export) and a caseworker UI (per-claim search).
Legacy systems had no audit hooks and the regulator forbade modifying them, the chain of custody had to be reconstructable from outside.
Read-only CDC taps on every source (Debezium for the modern stacks, a custom z/OS journal reader for the mainframe). Every tap is one-way write; the source database never sees a transaction from the lineage layer.
Source-of-truth conflicts: the four systems regularly disagreed on the same claim's state, especially around adjudication and re-adjudication.
The ledger records each system's observation as a separate row, not a merged truth. The trace UI surfaces the conflict to the auditor with provenance and timestamps; resolution is a human decision, recorded back to the ledger as its own event.
Volume: 4M+ historical claims to backfill, on top of live capture, with no maintenance window the agency was willing to take.
Batched ingestion with idempotency keys so the backfill was restartable; throttled writes against a read-replica of each source so live operations stayed unaffected; full backfill ran over a single 18-day window, end-of-day reconciliation report flagged any source-vs-ledger drift each morning.
Data-residency mandate, nothing could leave the jurisdiction, including the supporting infra.
Entire pipeline runs on in-jurisdiction Kubernetes. No managed services, no external SaaS, no cross-border egress. The notary anchor uses a domestic timestamp authority. Per-tenant isolation between the two ministries: separate namespaces, separate ledgers, separate keys.
Tampering had to be DETECTABLE, not just discouraged, a malicious admin with database access is in scope.
Hash chain per claim plus a daily notary anchor to an external timestamp authority. Any altered row breaks the chain at the next read; the daily anchor makes the break provable against an external party even if the ledger is rewritten end-to-end. The interactive on this page demonstrates the local break; the anchor is what makes it stick in court.
Ingest
- ·Debezium CDC against Oracle, Java EE, .NET
- ·Custom z/OS mainframe journal tap, read-only
- ·Batched backfill framework with idempotency keys
Ledger
- ·PostgreSQL append-only schema, per-tenant
- ·sha-256 hash chain + ed25519 signing
- ·Daily notary anchor to external timestamp authority
Trace API
- ·FastAPI + GraphQL, server-side cursor pagination
- ·Read-only role enforcement, scoped to jurisdiction
- ·Per-claim trace IDs end-to-end
Ops
- ·Kubernetes, in-jurisdiction nodes only
- ·No managed services, no external egress
- ·Per-tenant isolation, separate keys per ministry
UI
- ·Next.js + React, caseworker + auditor portals
- ·Regulator export format, generated server-side
- ·Conflict surfacing in trace view, provenance preserved
Lineage Tracer
Eight sample claims, each with a six-node trail across the federated pipeline. Pick a claim to see its observations and the hash chain that links them. Press tamper on any node to simulate an admin going back into the source system and altering a value, the chain visibly breaks at the next node, and the diff surfaces. Restore reverses it. The mechanic teaches what the ledger guarantees and what it doesn't.
- 01INGEST · MFmainframedate:2025-09-04status:RECEIVEDamount:$ 1,240.00hash_prev:0x0000:genesishash_self:0xad38e7e10551
- 02ELIGIBILITYoracle · eligibilitydate:2025-09-04status:PASS · tier 2hash_prev:0xad38e7e10551hash_self:0x6a55be8b5f0e
- 03ADJUDICATIONjava ee · adjudicationdate:2025-09-05status:APPROVEDhash_prev:0x6a55be8b5f0ehash_self:0xb0a77fd0443e
- 04PAYOUT.net · payoutdate:2025-09-07status:DISBURSEDamount:$ 1,240.00hash_prev:0xb0a77fd0443ehash_self:0x48eacd5573c6
- 05RECONCILIATION.net · ARdate:2025-09-08status:MATCHEDhash_prev:0x48eacd5573c6hash_self:0x676993a1a021
- 06ARCHIVEledgerdate:2025-09-09status:SEALEDhash_prev:0x676993a1a021hash_self:0x0c0f364788ce
- → End-to-end traceability for 4M+ claims, queryable in seconds
- → Audit cycle compressed from 6 weeks of analyst archeology to 4 days
- → Zero compliance findings in the subsequent audit year
- → Two ministries live, separate tenants, shared platform
Live across [REDACTED] ministries in the Asia-Pacific region. Two tenants in production, third in pre-prod against historical backfill. Notary anchor audited quarterly by the client's GRC team.
Live across two ministries in the Asia-Pacific region. Notary anchor audited quarterly by the client's GRC team. Reference available on request under NDA.