A Certificate of Analysis is a one-to-two page document, often a PDF scan of a printed form, that a supplier sends to confirm a lot meets the chemical, microbiological, or physical standards required by the buyer. In theory, the COA is a clean, structured record. In practice, it is a heterogeneous collection of formats, field names, date conventions, and lot code schemas that varies by supplier, laboratory, and crop type.
At Loamy, the COA is the primary input to our traceability graph. When we built the parsing layer, the variation in certificate format was the central engineering problem. This post describes how that parsing works, where it is reliable, and where it requires intervention.
Why COA Format Variation Is a Hard Problem
Consider three common COA formats for fresh produce. A large commercial testing laboratory might produce a structured PDF with consistent field names, a specific header layout, and lot identifiers formatted as alphanumeric codes in a designated field. A smaller regional laboratory might produce a word-processor document with a narrative format: "Sample received from Supplier X on date Y representing harvest from field Z, tested as follows." A grower's in-house quality control department might produce a simple spreadsheet exported as PDF with a layout that changes when someone modifies the template in Excel.
All three are valid COAs under food safety certification standards. All three communicate roughly the same categories of information. None of them share a common field structure that a traditional rule-based parser can rely on.
Traditional approaches to extracting data from PDFs depend on either explicit structure (machine-readable PDFs with embedded text and consistent field positions) or templates (known-format documents where field values are at fixed coordinates). Both approaches break down when the universe of input documents comes from dozens of suppliers using different laboratory services across multiple seasons.
What LLM-Based Extraction Handles Well
Large language model extraction handles this problem differently. Rather than defining fields by position or template, the model reads the document text as natural language and maps what it finds to a fixed output schema. The output schema for a COA includes fields like: lot identifier, product description, test date, laboratory identifier, list of analytes tested, result values with units, and pass/fail status relative to stated limits.
The model is good at this because the documents, despite format variation, use a constrained vocabulary. Pesticide residues appear under headings like "residues," "chemical analysis," or "active ingredients detected," and the analyte names (chlorpyrifos, malathion, permethrin, etc.) are consistent scientific names regardless of which laboratory ran the test. The model recognizes these patterns across formats without requiring a new template for each laboratory.
We tested extraction accuracy across a set of COA documents spanning multiple produce categories and laboratory sources. For lot identifier extraction, the model correctly identifies the field in roughly 94% of cases on first pass. For test date, the accuracy is similar. The harder cases are documents where a lot identifier appears in multiple fields with slightly different formats (a sample ID, a grower lot number, and a client reference number all present in the same document) and the model must determine which one corresponds to the FSMA 204 Traceability Lot Code definition.
Where Human Review Remains Necessary
We are not claiming fully automated processing with zero human review. That would be inaccurate about the current state of the technology, and it would be a dangerous design choice for a compliance context.
There are three categories of COA that require human review before their extracted fields are committed to the traceability graph. First, documents where the lot identifier field is ambiguous because multiple codes appear in different positions with no clear label hierarchy. In these cases, Loamy surfaces the extraction result with a confidence flag and asks the user to confirm which code maps to the traceability lot. Second, documents where the extracted analyte results include values near the action limit for a particular pesticide. Not because those results are automatically a compliance issue, but because the stakes of a parsing error are high when a value is close to a threshold. Third, documents where OCR quality is poor because the original scan was low resolution or skewed, producing garbled text that the model cannot reliably interpret.
On a typical day of inbound certificates from a mid-size produce operation, roughly 8 to 12 percent of documents fall into one of these review queues. That is a meaningful reduction from the alternative, which is reviewing every document manually, but it is not a fully hands-off workflow. The goal is to concentrate human attention on the documents that genuinely need it, not to eliminate human review from a compliance-critical process.
From Extracted Fields to Graph Nodes
Once a COA is successfully parsed, the extracted fields become the properties of a supplier node and a lot node in the traceability graph. The lot node carries the traceability lot code, product description, test date, and a reference to the underlying certificate document. Edges connect the lot node to the supplier node that sent it, and later to receiving and shipping events as those are recorded.
The graph representation is what makes lot-level querying fast at recall time. When FDA issues a notice about a pathogen associated with a specific produce category from a specific growing region and date range, the query is: find all lot nodes whose supplier node is tagged with that growing region, whose harvest date falls in that range, and which have been shipped to a downstream location within the recall window. A graph database can traverse those relationships in seconds. A collection of disconnected PDFs in email folders cannot.
The quality of the graph depends entirely on the quality of the extraction. A lot node with a missing or incorrect lot code is a dead end in a recall trace. That is why we apply the confidence thresholds and human review queue, and why we surface extraction quality metrics to operations teams, not just compliance officers. If a supplier's certificates are consistently producing low-confidence extractions, that is a signal to address the certificate format issue at the supplier level, before it becomes a 24-hour records request problem.
A Word on Certificate Format Standardization
The deeper fix to the format variation problem is upstream standardization, not better parsing. If suppliers submit certificates in formats that include consistently labeled lot codes, standard date fields, and machine-readable analyte tables, extraction accuracy increases and human review queues shrink. We have seen operations teams use supplier onboarding conversations as an opportunity to request specific certificate format changes, sometimes with good results from Tier-1 suppliers who have enough customer relationships to motivate updating their templates.
That said, standardization is a multi-year project for most supply chains, and enforcement is here now. The parsing approach handles the current reality of heterogeneous documents while the upstream quality work proceeds. We view them as complementary, not as alternatives.