The Center’s open source Traceability Driver is already converting traceability data into common formats — and a new AI-based data aggregation tool is in beta-testing now
In this SAFET blog series, we spotlight the organizations behind the global technology success stories highlighted in our Sea Tech in Motion project map. We recently connected with Blake Harris, managing director of the Institute of Food Technologists’ Global Food Traceability Center, to discuss the importance of interoperability in seafood traceability data, how the open-source Traceability Driver is already helping organizations document catch, and why he’s so excited about the Center’s new AI-powered tool, Quantum Leap.
SAFET: At a high level, why is traceability important, yet so difficult to achieve?
Blake Harris: Traceability matters because food supply chains are being asked to support more than basic product movement. Whether the goal is food safety, managing supply chain disruption risk, market access, sustainability, labor assurance, or another business or regulatory priority, traceability depends on understanding where a product came from, what processes it went through, and who handled it along the way. That information is what allows companies and regulators to make credible claims about a product. And when something goes wrong — such as a food safety outbreak or recall — traceability helps identify the source, conduct root cause analysis, and implement remediation steps that reduce the chance of the same problem happening again.
But traceability on its own is not enough if the information is locked in disconnected systems, inconsistent formats, or records that are difficult to access quickly. That is where interoperability becomes so important. Interoperability means data can move between companies, software platforms, and supply chain partners in a consistent and usable way. The value is not just having the information somewhere — it is being able to find it, understand it, and share it quickly enough to support action.
The biggest barrier has not been a lack of interest in traceability, but the difficulty of aligning what information is captured, when it is captured, and how it is recorded — whether through handwritten records, Excel files, or structured digital systems — and how it can be shared across different platforms.
At the Institute of Food Technologists’ Global Food Traceability Center (IFT’s GFTC), our vision is a fully traceable food system enabled by interoperable digital solutions accessible to all. We work on both sides of that challenge: helping develop and advance interoperable data standards, while also building practical tools and resources that help implementers align with those standards wherever they are starting from. That role is reflected in our long-standing support for the Global Dialogue on Seafood Traceability (GDST). IFT’s GFTC was an original co-convener of GDST alongside the World Wildlife Fund, and we continue to work closely with GDST to advance interoperable seafood traceability standards and the practical tools needed to support their implementation.
SAFET: Tell us about the Traceability Driver. When did you launch it, what does it do at a high level, and what inspired its development?
Blake Harris: The Traceability Driver is a great example of a tool designed to support interoperability in practice. We began building and testing it in early 2025 and officially launched it in August 2025. At a high level, it automates much of the hardest part of aligning with interoperable traceability standards: translating the data a software solution already collects into the format required by the standard. It also includes a pre-built API that aligns with the standard’s data-sharing requirements, so solution providers do not have to build that infrastructure from scratch. The tool is completely open source, and solution providers deploy it locally — meaning no data is shared with IFT or anyone else beyond the partners they were already planning to share data with.
The inspiration came from a practical implementation barrier we kept seeing through our work with the GDST. In many cases, traceability platforms were already collecting much of the data required by the GDST Standard. The challenge was interoperability — knowing exactly what data points to share, how those data points should be formatted, and how the data should be exchanged between systems. We would often tell solution providers, “You do not need to rebuild your entire system; you need to translate your existing data into the standard format and expose it through the right API.” The thinking behind the Traceability Driver followed from that: we know what the data needs to look like and how the API should work based on the GDST Standard, and solution providers know their own systems. If we could give them something to map their data into, and the tool handled the rest, we could remove a major barrier to interoperability.
This is also where the power of standards really shows up. Because there is a standardized approach, we can build tools like the Traceability Driver once and allow many different solution providers to use, adapt, and scale from it. Since launching, the Driver has been pulled nearly 700 times from our GitHub repository, which shows real demand for practical tools that help the ecosystem move from standards on paper to implementation in the real world.
SAFET: How does the tool work in the seafood space in particular? Please walk us through who might use it, and what they might experience when they do.
Blake Harris: In seafood, the Traceability Driver was built to help technology solution providers align with the GDST standard without rebuilding their existing systems. A seafood traceability provider, for example, may already be collecting information about products, companies, locations, and key supply chain events. The Driver helps them map that existing data into the format required by the GDST standard and makes it available through a standardized way of sharing data with authorized partners.
For the user, the experience is meant to be practical and low-disruption. They do not need to change their core system. The Driver is set up within their own technology environment, only reads from their existing system, and does not change the original data. They can control who has access, monitor whether information is syncing correctly, see any errors that need attention, and use the tool to help test whether their system is aligned with the GDST standard. In seafood, the Driver is really a bridge: it connects to the systems solution providers already use and makes their existing data easier to share in a standardized and interoperable way, without requiring them to rebuild or change their core platform.
SAFET: Our Sea-Tech-in-Motion database features a case study of a traceability tech provider called Koltiva. Could you please share the story of the effort and its impacts?
Blake Harris: Once we built the Traceability Driver, we needed to test it in a real implementation setting. Koltiva was a great fit because they had expressed interest in passing the GDST Capability Test, which is an objective assessment of whether a technology system can produce and share traceability data in the format required by the GDST standard. They were still early in understanding the requirements, so we offered the Traceability Driver as a pathway, provided support to walk them through the process, and agreed to document the experience as a case study.
Because this was our first beta test with an external solution provider, we scheduled calls to explain the tool, walk through the concept and implementation process, and work through questions with their developers as they came up. In total, we put in around 10 hours to support them — and the payoff was huge. For us, it helped us see our documentation and guidance through the eyes of a solution provider and improve it for future users. For Koltiva, the results were extremely exciting: they estimated that the Driver reduced implementation time by about 60%, from months to weeks, and avoided the need to bring on an additional back-end developer.
A second study with Aqua Exchange reinforces that point even more strongly. Aqua Exchange used the Traceability Driver to pass the GDST Capability Test with no implementation support from our team, relying on the available documentation. What was especially interesting is that their platform uses Neo4j, a graph database, while the Driver was originally designed around more common database structures. Even so, they were able to create the necessary mapping layer, use the Driver, and pass the test without rebuilding their existing system. They estimated that the Driver reduced development time by about 75%, turning what could have been one to two additional months of custom development into roughly one to two weeks of setup, configuration, testing, and deployment. That is exactly the kind of result we hoped to see: a tool that can be useful beyond the narrow environment it was first designed for, without requiring one-on-one support from our team.
SAFET: Accessibility and interoperability seem to go hand in hand. Please comment on the importance of this being open source.
Blake Harris: One of the most important benefits of a standardized approach is that it can reduce the system-wide cost of implementation, and the Traceability Driver is a good illustration of what that looks like in practice. If a tool can produce major reductions in implementation time with little to no external support, that is exactly the kind of efficiency digital interoperability needs in order to work at scale.
Making it open source matters because this need exists across the market. Large enterprise platforms may use the Driver to accelerate implementation or reduce internal development time, while smaller or more specialized providers may use it because they do not have the time or budget to deeply interpret how global data standards apply to their system — whether they are built around a specific species, geography, supply chain segment, or local use case. In that sense, the Driver helps open the field: it gives solution providers a practical starting point to connect to the systems they already use, map their existing data into the standard, and participate in interoperable data sharing without building everything from scratch.
We also wanted access itself to be low-friction. The tool is free and open source, with no requirement to provide a name, email address, or other information to use it. The goal is not to gatekeep the resource; it is to help the ecosystem learn, experiment, and implement faster.
SAFET: Stepping back, what has surprised you most — either in building this solution or in watching communities actually adopt it?
Blake Harris: Two things have really stood out. The first is how much attention the tool has received. The Traceability Driver is a fairly niche resource — mainly for solution providers or in-house IT teams working to align their systems with traceability data standards like the GDST. So, the fact that it has been pulled nearly 700 times since we launched it last August tells us there is real demand for practical implementation support.
The second is recognizing that adoption is happening in ways we may never fully know about. I am often asked, “How many companies are actually implementing GDST?” and the reality is that no one knows for sure. Even years ago, when the GDST Capability Test was first launched, one of the earliest solution providers to pass was an organization we had never interacted with before. We see something similar with Aqua Exchange, which used the Traceability Driver to pass the GDST Capability Test before anyone even knew they had used it.
I love thinking about that because, even with all the momentum and activity we can see around GDST — which has accelerated significantly over the last several years — there is likely much more happening that we do not see. To me, that is a powerful signal that the demand is real. Solution providers are actively looking for resources that help them achieve interoperability faster and more efficiently. Our job is to create resources that support that demand without requiring direct involvement every time those resources are used. We want to be a catalyst, not a bottleneck for broader implementation.
SAFET: Speaking of being a catalyst, you’re currently beta-testing another potentially game-changing tool: Quantum Leap. Please tell us about this new AI-based tool.
Blake Harris: Quantum Leap is something I am actually even more excited about than the Traceability Driver, because it addresses one of the most persistent questions in traceability: what about the parts of the supply chain that cannot, or will not, invest in digital technology right now? A lot of important traceability information is still captured in everyday business records — purchase orders, bills of lading, processing slips, farm logs — that are commonly produced for business purposes and often contain pieces of the traceability puzzle. Those records may exist on paper, as PDFs, in spreadsheets, in emails, or as photos, in formats that are difficult to use in interoperable digital systems.
The goal of Quantum Leap is to use AI to identify the Key Data Elements embedded in those records, understand the Critical Tracking Events they represent — such as shipping, receiving, or transformation (i.e. processing) — and reorganize that information into a more usable digital format, such as CSV or JSON. In plain terms, it is about taking the pieces from each document and stitching them together so we can better understand how a product moved through those parts of the supply chain. It is not meant to replace full digital traceability systems — in fact, it supports them by automating one of the major headaches many of their customers face: manually transcribing data from supplier PDFs, spreadsheets, or other records into the software they use to share information with their customers. We are currently beta-testing this tool with industry users and welcome others who are interested to reach out using this link: Quantum Leap Beta Testing.
SAFET: Where does all this go from here — what’s the big-picture vision?
Blake Harris: The bigger vision is interoperable traceability harmonization across commodities. Seafood has been an important proving ground through the GDST, where years of work and investment have gone into developing and implementing a common approach to digital traceability. The opportunity now is to take those well-established concepts and apply them across other commodities in a harmonized way. We are already seeing that happen through efforts like the Global Traceability Framework for Beef and Leather, which builds on the same event-based, interoperable traceability concepts and applies them to cattle-derived supply chains.
This matters because seafood, coffee, beef, produce, and other products do not stay in isolated supply chains. They move through the same distribution facilities, retail locations, and food service operations. If every commodity has a completely different traceability approach, we create unnecessary complexity for the businesses that need to implement these systems. The goal is to align around common traceability foundations across commodities, while still allowing for commodity-specific needs where they are necessary.
The way we support that vision is by building tools that meet supply chain actors where they are across the traceability data pipeline. Quantum Leap helps with unstructured or paper-based records by extracting useful traceability information and turning it into a structured format that can be used more easily by industry, software solutions, regulators, or certifiers. The Traceability Driver helps when structured data already exists but does not yet follow global data standards. And the Diagnostic Tool helps when two systems are already trying to exchange standardized data but something breaks in the real world.
Together, these tools are about helping more actors move toward interoperable traceability without requiring everyone to start from the same level of digital maturity. But there is more to do. The next phase is not just building individual tools — it is connecting them into a broader implementation ecosystem that makes traceability easier, less costly, and more consistent across supply chains.
That brighter future is within reach, but it will take continued investment in standards, tools, and practical implementation support. It will also require industry, regulators, NGOs, and other stakeholders to help bring these resources to life through real-world use. The encouraging part is that this is already happening: tools that started in seafood are proving useful in other commodity contexts, and those lessons are feeding back in. Such cross-learning is how we reduce duplication, simplify implementation, and build a traceability ecosystem that can scale.