Recall tracing in minutes, not days, across a six-member consortium
A permissioned Hyperledger Fabric network gives six competing members a shared, verifiable batch history, fed directly from their ERPs, while commercially sensitive data stays in private data collections.
Client
- A European food-supply consortium
Industry
- Supply chain
Engagement
- Architecture + build, 9 months
Team
- 7 engineers, 1 architect, 1 delivery lead
- end-to-end batch trace, down from about two days
- 25 min
- ERP estates integrated, none replaced
- 6
- network availability over the first six months
- 99.95%
- fewer delivery disputes between trading partners
- 41%
end-to-end batch trace, down from about two days
ERP estates integrated, none replaced
network availability over the first six months
fewer delivery disputes between trading partners
Context
Two days to trace a batch, and nobody willing to host the data.
The consortium brings together two food processors, a growers’ cooperative, a cold-chain logistics provider and two retail groups. Between them they handle several thousand production batches a week, and each batch passes through three to five organizations before it reaches a store.
When a contamination alert arrived, each member searched its own systems and emailed spreadsheets to the next. A full trace took around two days and still depended on phone calls. Regulators and retail customers wanted faster, verifiable answers, and no member was willing to host the others’ data.
Challenge
A shared record between competitors.
The members had already considered a shared database hosted by one of them and rejected it. Our discovery work confirmed that a ledger was justified: several competing writers, no neutral operator acceptable to all, and a need for each member to verify the record independently. The constraints were demanding.
- Confidentiality between competitors: prices, volumes and supplier terms could never be visible to members outside a transaction.
- Six ERP estates, including two SAP S/4HANA instances and an IBM i system, none of which could be replaced or significantly modified.
- Food-safety traceability: one step forward and one step back as a minimum, with full-chain traces available to authorities on request.
- Member independence: each company runs its own nodes and keys, and can leave the network without breaking anyone else’s history.
Architecture
What goes on the ledger, and what stays off it.
The ledger holds batch events, handover signatures and document hashes. Everything else stays in systems the members already run.
-
01
Fabric network with per-member peers
Each member runs two endorsing peers in its own cloud tenancy. A Raft ordering service is spread across three members, so no single company controls transaction ordering. Go chaincode encodes the batch lifecycle: create, transform, split, merge, ship, receive and recall.
-
02
Channels and private data collections
One consortium channel carries batch events visible to all members. Prices, quantities and supplier terms sit in private data collections shared only by the two parties to a handover, with hashes on the channel for verification.
-
03
Identity, MSP and PKI
Each member operates its own Fabric certificate authority under a consortium root, mapped to a membership service provider. Keys for peers and gateway identities are held in HSMs, and certificate rotation is automated.
-
04
Integration gateway
A per-member service that exposes idempotent REST APIs to internal systems, validates payloads, submits transactions through the Fabric Gateway SDK and handles retries safely.
-
05
ERP adapters
Change data capture and native connectors for two SAP S/4HANA instances, Microsoft Dynamics 365, an IBM i system via managed file transfer and two mid-market ERPs via API, mapping goods movements to batch events.
-
06
Event bus
Kafka in each member’s estate decouples the ERPs from the ledger. It buffers events during maintenance windows and replays them safely after an outage.
-
07
Indexer and read models
An indexer listens to block events and builds query-optimized read models in PostgreSQL, so traces never require scanning the ledger.
-
08
Partner portal
A web portal and trace API for members’ quality teams. Every trace result links to its on-ledger proof, and exports are formatted for food-safety authorities.
Key decisions
Four decisions from the architecture dossier.
Each was recorded as an architecture decision record, with the options considered and the trade-offs accepted.
-
Decision 1
Hyperledger Fabric rather than a permissioned EVM network
Why
- Members needed data visible only to the parties in a transaction. Fabric’s channels and private data collections fit that natively, and there was no requirement for tokens or public-chain interoperability.
Trade-off
- A smaller talent pool and a more involved upgrade process than EVM networks. We offset this with detailed runbooks and a chaincode test harness the members can run themselves.
-
Decision 2
One shared channel with private data collections, not a channel per trading pair
Why
- A trace has to follow a batch across every member. Channels per pair would have fragmented the history and multiplied operational overhead.
Trade-off
- Collection policies and purge rules need careful design. Every collection definition is covered by tests and recorded in the ADR log.
-
Decision 3
Hashes on-chain, documents off-chain
Why
- Certificates, lab results and delivery notes stay in each member’s document store, and the ledger holds their hashes. Anyone can verify a document without it being replicated to competitors, and personal data stays off an immutable ledger.
Trade-off
- Verification depends on members keeping source documents available, so retention obligations were written into the consortium’s operating agreement.
-
Decision 4
An event bus between ERPs and the ledger, not direct writes
Why
- ERPs must keep running while the network is under maintenance, and the ledger must not record duplicates when an ERP retries. Kafka plus idempotent gateway APIs handles both.
Trade-off
- Ledger records trail ERP transactions by a few seconds, and each member operates one more component. Both were accepted as well within the consortium’s requirements.
Delivery
Thirty-nine weeks, in four phases.
A six-week pilot ran alongside the existing email process, including two simulated recalls, before the production rollout.
Weeks 1 → 39
-
Weeks 1–6
Discovery and architecture
Workshops with all six members, trust and data-flow mapping, and the architecture dossier: network topology, data model, privacy design and integration approach, signed off by the consortium’s technical committee.
-
Weeks 7–18
Network foundation and first integrations
Infrastructure as code with Terraform in each member’s cloud, the Fabric network and certificate hierarchy, chaincode for the core batch lifecycle, and the first two ERP integrations running end to end on a test network.
-
Weeks 19–32
Remaining integrations and pilot
Adapters for the remaining four ERPs, the indexer, read models and partner portal. A six-week pilot on two product lines ran in parallel with the existing email process and included two simulated recalls.
-
Weeks 33–39
Rollout, handover and support
Production rollout across all product lines, load and failover testing, runbook drills with each member’s operations team, documentation handover and transition to an SLA-backed support agreement.
Outcome
Traces in minutes, answers regulators can verify.
All six members now write to the network directly from their own ERPs, and Milesbreed provides second-line support under a Managed Support & Maintenance agreement. The figures cover the first six months of production, compared with the year before go-live where relevant.
- Two simulated recalls during the pilot were traced end to end in under 30 minutes, with each step linked to a signed ledger record.
- Members answer regulator and retailer provenance requests from the partner portal instead of assembling spreadsheets by email.
- The consortium’s own operations team has since added two product lines using the documented runbooks, without Milesbreed involvement.
“The hardest decisions on this project were not about the ledger. They were about what to keep off it, and how six very different IT estates could feed it without anyone’s operations changing overnight. We spent the first six weeks writing those decisions down, and the consortium still uses that document to settle technical questions.”
Tobi Adeyemi
Head of Blockchain & DLT · Engagement lead
What we documented and handed over
- Architecture dossier: network topology, privacy design, data model and integration patterns
- ADR log: 31 architecture decision records, each with context, options considered and trade-offs
- Test plan and evidence: chaincode unit and property-based tests, per-ERP integration suites, load and failover results
- Operations runbook: certificate rotation, peer and chaincode upgrades, backup and restore, incident playbooks
- Member onboarding guide: technical prerequisites and a step-by-step process for adding a new participant
Stack
- Hyperledger Fabric
- Go
- Kafka
- PostgreSQL
- Kubernetes
- Terraform
- SAP S/4HANA
More work
Other engagements
Fintech
Settlement reconciliation that closes before the business day starts Read the case studyPublic sector
A tamper-evident registry, built on a database instead of a blockchain Read the case studyFintech
Same-day fund-unit transfers, with investor eligibility enforced on-chain Read the case studyPlanning something similar?
Start with a 30-minute technical consultation, or a fixed-price feasibility assessment if a ledger is on the table.