Blockchain's Role in the Produce Supply Chain: Part One--Traceability and Blockchain
on Feb 8, 2018
We discuss blockchain and three other approaches to achieving traceability, as the foundation for providing provenance assurance and improved recall capabilities. This includes a discussion of the impact of FSMA, industry standards, and networked SaaS systems.
The buzz around blockchain and distributed ledgers has reached a fevered pitch,1 with numerous applications2 being bandied about including its use in supply chains. A lot has been written specifically about the potential use of blockchain technologies in fresh food supply chains. The vision is that industry-wide blockchains can provide:
Provenance—stronger assurance of origin and chain-of-custody
Recalls—faster and more precise recalls
Freshness—fresher produce and meat, reduce waste and spoilage
Safety—fewer contamination incidents
A strong case can be made that the greatest value potential is in these last two, improving freshness and safety. Nevertheless, most of the pilots and discussion to date have focused on the first two; how blockchain can help establish provenance and recall capabilities, in particular by providing traceability. To understand the role of blockchain in providing traceability (and hence provenance and recall), we examine four ways to achieve traceability:
1-up/1-back proprietary—The most common approach today, traceability data is held within each firm in a proprietary format
1-up/1-back standards-based—Data is still stored in each firm, but in a standard way
Centralized Networked SaaS—The best way to get end-to-end traceability, this emerging approach has a chain-wide database
Decentralized Blockchain-based—Blockchain is getting lots of buzz but is most powerful when combined with a networked SaaS platform.
Then we take a look at what is required for the four use cases (provenance, recalls, improving freshness, and safety) and blockchain’s potential contribution to these, including the role of smart contracts.
Provenance and Recall Capabilities
The Desire for Better Provenance Assurance and Recall Capabilities
Provenance Assurance—Increasingly consumers, retailers, and brand owners want more precision and confidence in knowing where their food has come from. Consumers desire authenticity for food that claims to be grown in a particular region or following a particular regime (e.g. organic, grass fed, etc.). Some brand owners want to correlate the quality, robustness, and yield of produce with the specific location and date of harvest, in order to tease out farming and harvesting best practices and/or to help in identifying and breeding fruits and vegetables with desirable characteristics such as color, taste, shelf life, and yield.
What is Blockchain
Blockchain is technology providing an immutable, secure, decentralized, shared ledger. Breaking down this definition (in reverse order):
Ledger—Similar to a financial ledger, a blockchain is an ordered list of ‘transactions.’ Transactions can be financial exchanges (as on bitcoin and other crypto-currency blockchains) or the record of an event, such as a hand-off in a chain of custody, the completion of a task, or even a temperature reading at a specific time and place. The sequence of validated transactions is strictly maintained. For cryptocurrencies, this prevents double-spend, as the oldest transaction prevails and newer duplicates are invalidated.
Shared—The ledger provides a common view (aka the single-version-of-the-truth) across many parties, even if they lack trust or a longstanding relationship.
Decentralized—The ledger is broadly replicated and verified by a large number of different entities. This makes blockchains robust and resistant to cyberattacks and system failures, as an attacker or outage would have to impact a large portion of the network of entities in order to compromise the blockchain. The degree of decentralization varies between different blockchains, depending on the goals and design.
Immutable—The ledger is immutable, meaning that transactions can never by deleted or modified.
If there is an error in a transaction, it can only be corrected by writing a new transaction undoing the error. This makes blockchains highly auditable, as there can be no after-the-fact rewriting without a clear trail of what happened.
Secure—Cryptographic technology (e.g. hashes, digital signatures) is used to ensure there is no tampering with the data in the blockchain. The way in which hashes are used to link the content of each block of transactions from/to the previous and next blocks is how blockchain got its name.
Recall—Brand owners and retailers would like to identify any incidents of contamination at the earliest possible time, reliably and swiftly trace the contamination back to its source, reliably and swiftly trace forward to where all potentially contaminated produce has been sent, and execute high-confidence, rapid, precise recalls. Ideally, tainted produce or meat is caught before product has been put on the retail shelf.
Traceability’s Central Role in Provenance and Recall Capabilities
Traceability is fundamental to achieving provenance assurance and robust recall capabilities. Upstream traceability (aka backwards traceability) is the ability to trace an item3 back to its original source.
Downstream or forward traceability is the ability to start atthe source or any intermediate point and find out where each end item from any particular batch ended up. A traceability system should provide both upstream/backwards and downstream/forward traceability.
The most widely used approach to traceability in the food supply chain is one-up/one-back traceability
(aka 1-up/1-down), where each participant in the end-to-end chain (grower, processing plants, distribution centers, retailer, etc.) keeps track of where every item (or batch of items) they received came from, and where each item (or batch or lot) is sent to. One-up/one-down food traceability is mandated in the United States by Section 306 of the 2002 Bioterrorism Act.
If everyone in the chain does 1-up/1-down traceability record keeping properly, then when a problem occurs, such as a batch of food is contaminated, the problem can be traced back to the source of contamination anywhere in the chain. Contamination can happen at different points in the chain, not just at the origin. When contaminated food is discovered (either by testing or when people get sick), backwards traceability can help find the convergence point; the common location that all of the contaminated food came through. Then authorities and the operator of that farm or facility can diagnose the problem further, identifying the exact source, such as an improperly sanitized shredding machine in a processing plant. Once the source of contamination has been identified and rectified, forward traceability can be used to identify where all the tainted items ended up. In practice however, much of the industry uses paper or manual systems, so the actual traceback process is very slow and fraught with error.4 In fact, this inadequacy was a key impetus for including traceability in the 2010 Food Safety Modernization Act (FSMA).
Recommended Event Data Elements
For each event, the FSMA pilots report recommends recording the following data:
Event owner (firm submitting the info)
Date, time, location of event
Quantity, unit of measure
And event-specific data, such as:
Work Order # (for processing events)
BOL # (for shipping events)
Carrier ID (shipping)
Trailer ID (shipping)
Traceability Events and Data
The FSMA (Food Safety Modernization Act) directs the FDA to improve traceability, starting by running a set of traceability pilot projects. The final report from those pilot projects recommends that data be recorded for each of the following events as produce travels through the supply chain:
Ship—sending produce to a customer
Receive—receiving produce from a supplier
Transform/process—e.g. clean, shred, bag
Consume or dispose—sold to consumer or disposed
Transform/process events (e.g. preparing a bagged or boxed salad mix) will have two separate set of records: one for the inputs and another for the outputs. Data such as the items shipped/received, quantities, and lot numbers are to be recorded for each event (see sidebar at right). With this data, produce can be tracked at each step from origin to final consumption or disposal.
Industry Traceability Standards
The FSMA specifically does not say what technology to use and only mandates 1-up/1-back traceability. When contamination events occur, this leaves government agencies and agents with the work of contacting each party in the chain to request their 1-up or 1-back trace information, in order to stitch together an end-to-end picture. Companies have 24 hours to respond to such requests. The FSMA pilot report encourages the use of industry standards, which makes it easier to correlate the various records received from the different parties in the end-to-end chain. Traceability standards have been developed by GS1 working with PTI (Product Traceability Initiative). The standards focus on the item, quantity, lot/batch/serial #, harvest date (lot and harvest are optional). This data is put on a standardized label on each item, case, and/or pallet. Figure 1 below shows the 1-up/1-back approach using proprietary data and using industry standard data.
Figure 1 - 1-up/1-back Traceability—Proprietary vs. Standard Data Formats
The Role of Networked Cloud-based Systems and Blockchain
While not mandated by regulations, a networked cloud-based (aka SaaS) system provides a far better solution than 1-up/1-back. First, it is important to distinguish between Enterprise SaaS vs. Networked SaaS architectures. Both have a shared code model (run in a single multi-tenant instance), but the enterprise SaaS model lacks a shared data model, where things like supply chain events can be written and shared across a network of trading partners.5 In a networked SaaS system, the chain-of-custody data (hand-offs of batches or individual items from one party to the next) are recorded in a shared networked database, instantly accessible to authorized parties. This makes the trace-back and trace-forward processes virtually instantaneous. End-to-end tracing that used to take days or weeks can now be done in a couple of seconds. A blockchain architecture can bring similar network-wide data-sharing benefits.
Figure 2 - Centralized SaaS/Cloud-based vs. Decentralized Blockchain-based Architectures
Figure 2 above illustrates the difference between a cloud-based vs. blockchain-based approach. In the cloud-based approach, a single central authority controls the system. The nodes may be physically distributed
(and often are, to increase robustness and availability), but control is centralized. In contrast, control of the blockchain nodes is decentralized, allowing many parties to participate in ongoing verification and validation of the data. The blockchain architecture makes it much harder for someone to change data after the fact.
We will further explore the differences between centralized cloud vs. blockchain below.
Freshness and Safety
Data/Capabilities Required for Improving Freshness
Arguably the most valuable improvements for the produce supply chain come from increasing freshness and safety. Growers and retailers are always looking to reduce waste and spoilage in the supply chain and provide produce that has a longer post-purchase shelf life, with superior freshness. Improving freshness and reducing spoilage requires a number of additional data elements and capabilities, beyond those needed for traceability for provenance and recall:
End-to-end temperature monitoring—Continuous tracking of the temperature of each pallet or case of product, starting at the point of harvest in the field all the way through delivery at the retail store. Without this information, accurate remaining freshness cannot be calculated.
Condition-based Expiration Date—Based on the temperature exposure history of a given pallet of produce, a precise expiration date can be calculated that is much more accurate than the average
shelf-life estimates based purely on days-since-harvest, that don’t take into account the temperature exposure history of the pallet.
Temperature Response Profiles—A model for predicting the Condition-based Expiration Date must be tailored to each produce variety, location, and time of season if it is to have any validity and accuracy. This requires testing and observing how each variety responds when exposed to different temperature histories. Without this, a model can generate only a crude estimate of the remaining shelf life, even if it has the end-to-end temperature history.
Per Customer/Location Requirements (Transit-time and Days-of-Freshness)—In order to match each pallet to its optimal destination, the system needs to know the transit time and days-of-freshness requirements for each customer order.
Prescriptive Optimized Logistics (aka Intelligent Routing)—Armed with the above pieces of information—the end-to-end temperature history, an accurate Condition-based Expiration Date, and per customer/location requirements—the system can tell line workers exactly what to do with each pallet or case at each key decision point in the supply chain. This includes local decisions, such as which pallets to put into the precool next, and intersite decisions, such as which pallets to send to which customers.
Figure 3 - Intelligent Routing—Matching Remaining Shelf Life to Customer Requirements in Distribution Decisions
In part two of this series, we will cover the data and capabilities required for improving freshness and how produce safety can be ensured.