Earlier this year, we ran a test with an early pilot partner, a California fresh-produce operation that distributes leafy greens and fresh herbs to regional retail accounts. They had an existing spreadsheet-based traceability system: a set of Excel workbooks maintained by two team members, covering receiving logs, lot tracking, and outbound shipment records. It was organized, consistently updated, and genuinely better than what many operations of their size maintain.
We posed a mock FDA recall request: provide all records for any shipments containing product from a specific supplier, with harvest dates falling in a defined two-week window, that left your facility between January 15 and February 15 of that year. The operations team responded to that request twice: once using their existing spreadsheet system, and once using the Loamy graph that we had loaded with the same underlying data. This post describes what we observed.
The Spreadsheet Response: How It Went
The spreadsheet-based response required three people and took approximately three hours and forty minutes to produce a complete answer. This is not a criticism of the team or their record-keeping practices. The time is a product of how spreadsheet systems are structurally organized, not how carefully maintained they are.
Step one was identifying the relevant receiving events. The receiving log workbook organized entries by date of receipt. To find receipts from the specific supplier in the target harvest window, the operations manager opened the workbook and manually filtered by supplier name, then reviewed the resulting rows to identify which lot codes had harvest dates in the target window. The supplier had shipped under three different lot codes during that period, which was consistent with their normal shipment cadence.
Step two was locating the certificates for those three lots. Certificates for this operation were stored as email attachments in a dedicated folder, organized by month and supplier. The food safety coordinator retrieved the certificates for the three lots, confirmed the harvest dates matched the recall window, and noted that one of the three lots had a harvest date entry in the receiving log that differed by one day from the date on the certificate. Resolving that discrepancy required a phone call to the supplier's quality contact, which added about 20 minutes.
Step three was tracing outbound shipments for those three lot codes. The shipping log workbook was organized by shipment date. There was no automated cross-reference between lot codes in the receiving log and lot codes in the shipping log. The coordinator performed a manual VLOOKUP across the two workbooks, filtered for the relevant lot codes, and assembled a list of customer shipments. This step produced seven outbound shipments.
The final output was a manually assembled table in a new spreadsheet document. Total elapsed time: three hours forty minutes. We also noted that the process produced one error: the lot code discrepancy described in step two was corrected during the process, but had the phone call not been made, one lot code match would have been missed.
The Graph Response: How It Went
We loaded the same receiving records, certificates, and shipping records into the Loamy graph prior to the test. The load process extracted the relevant fields from the certificates (lot codes, harvest dates, supplier identifiers) and created the node-and-edge structure linking supplier nodes to lot nodes to shipment nodes.
The mock FDA request was submitted as a graph query: find all outbound shipments linked to lots received from this supplier with harvest dates in this window. The query returned seven shipment records in approximately four seconds. The result set included the lot code discrepancy as a flagged data quality note, because the extraction at load time had identified the one-day mismatch between the receiving log entry and the certificate field and had recorded both values on the lot node.
The operations manager reviewed the result, confirmed the flagged discrepancy, and marked the lot as verified after checking their notes from the original receiving event. Including that human review step, the complete response took approximately eleven minutes.
What the Test Reveals About the Structural Difference
The comparison is not "technology vs. no technology." This operation was using technology (spreadsheets) for their traceability records. The comparison is between a flat-file structure that requires manual joins and a graph structure where the joins are precomputed.
In a flat-file system, the relationship between a receiving lot code and an outbound shipment containing that lot exists only as a shared value in two separate tables. Querying that relationship requires a manual or scripted cross-reference. When the query spans multiple tables (receiving log, certificate files, shipping log) and involves matching on fields that may not be consistently formatted across all three, the manual process is slow and prone to the kind of one-day date discrepancy that nearly produced a missed record in this test.
In a graph structure, the relationship between receiving lot, certificate, and outbound shipment is represented as an explicit edge between nodes. The query does not perform a join; it traverses an already-established connection. The result is structurally complete by design.
An Honest Assessment of Where Spreadsheets Work
We are not arguing that spreadsheets are always inadequate for traceability. For very small operations with five or fewer active suppliers, tight shipment volumes, and consistent receiving staff, a well-maintained spreadsheet system can produce an acceptable recall response in well under 24 hours. The key variable is search complexity: when the number of lot codes involved in a recall is small (one or two) and the operation has a single facility and a short distribution network, manual cross-referencing is manageable.
The spreadsheet approach also has meaningful advantages: zero software cost, no implementation period, no training burden, and complete data portability. For an operation that does not yet have the volume to justify dedicated traceability software, a well-designed spreadsheet system maintained consistently is the right choice.
The test showed that the graph approach becomes substantially faster when the recall query involves multiple lot codes, multiple origin suppliers, or a distribution network that spans many customers. At those scales, the manual join process that spreadsheets require introduces both time and error risk in ways that compound with each additional data relationship.
The Data Quality Insight
The more unexpected finding from the test was the data quality signal. The one-day harvest date discrepancy between the receiving log and the certificate would not have been visible in the spreadsheet process unless someone explicitly checked. The graph surface it automatically because the extraction loaded both values and flagged the mismatch.
Data quality issues in traceability records are common and usually invisible until they matter. Lot code formats that shift slightly when a supplier changes their template, harvest dates that reflect receiving date rather than actual harvest date, quantity discrepancies between receipt and certificate, certificates attached to the wrong purchase order in the filing system. These are not catastrophic errors in routine operations. In a recall response, they become the questions that a food safety officer has to resolve under time pressure, while the FDA is waiting.
The graph approach surfaces these discrepancies at load time, not at recall time. That distinction does not change what happened, but it changes when you find out about it, and finding out a week before a recall request is more useful than finding out during one.