Skip to content

Extracting Fields From a Certificate of Conformance

10 min read · updated August 11, 2026

A certificate of conformance is a supplier saying, in writing, that what it shipped meets what was specified. The extraction is easy and almost always wrong in the same place: the specification it cites is not a name, it is a name plus a revision, and dropping the revision turns a compliance record into a sentence.

What a CoC asserts, and what it does not

A typical certificate is half a page of header fields and one declarative paragraph. The fields: supplier, customer, purchase order number and line, part number, part revision, description, quantity shipped, lot or batch number, date of manufacture, and the signature and title of the quality representative. The paragraph says the parts conform to the drawing and to the listed specifications, and lists any deviations or waivers.

What it does not assert is worth naming, because the confusion is common and it reaches into the schema. A certificate that mentions ISO 9001 is telling you the supplier operates a certified quality management system. That is a statement about the supplier’s processes, not about the parts in the box. Conformance to a product specification — a drawing revision, a material standard, a test method — is a different claim entirely. Give them separate fields: management_system_certifications and product_specifications. A single standards[] array merges two kinds of claim and downstream nobody can tell which was asserted.

The other field with outsized importance is deviations. A CoC citing an approved deviation or waiver number is a conforming shipment with a documented exception, which is materially different from an unqualified certificate. Extract deviation references as structured objects with their own numbers, and treat any free-text qualification in the conformance paragraph as a deviation candidate — “except as noted” is the phrase that turns a clean certificate into a conditional one.

The revision suffix is the field

Standards carry a revision identifier and it changes what was certified. ISO 9001:2015 replaced ISO 9001:2008 and the requirements differ. AS9100 revisions are lettered. ASTM designations carry a year of adoption or last reapproval, so ASTM A240/A240M-20 and an earlier revision of the same designation are different documents with different acceptance criteria. Drawings have their own revision letters, and a part conforming to Rev C is not evidence about Rev D.

So the extracted specification is not a string, it is:

{
  "body": "ASTM",
  "designation": "A240/A240M",
  "revision": "20",
  "revision_type": "year",
  "raw": "ASTM A240/A240M-20",
  "revision_stated": true
}

revision_stated is the field that earns its place. A certificate citing “ISO 9001” with no year is not the same input as one citing “ISO 9001:2015”, and a pipeline that quietly defaults the missing revision to the current one has invented a fact.Record the absence and let the receiving inspection decide whether to query it.

Parsing the designation is finicky in ways worth anticipating. The separator between designation and revision varies — ISO 9001:2015 uses a colon, ASTM uses a hyphen, AS9100D appends a bare letter with no separator at all, and military specifications use forms like MIL-STD-nnn Rev X where the revision is a separate token. A single regular expression across all of them will misclassify part of the designation as the revision on at least one family. Parse per issuing body, keyed on the leading token, and keep everything you could not parse in raw rather than discarding it.

One more: a hyphen inside an OCRed designation is regularly read as an en dash or lost entirely at a line break, and a line-wrapped A240/A240M- followed by 20 on the next line is the same rejoining problem as a wrapped ISBN. Join before you parse.

Revision numbering conventions belong to each issuing body and change on their own schedules; ISO’s catalogue is published at iso.org and ASTM, SAE and the defence standardisation bodies each publish their own. Confirm a designation’s current revision from the issuing body rather than from a copy.

Lots, heats and serial ranges

A certificate covers a defined set of physical units, and how that set is expressed decides whether you can answer “is this part certified” later.

  • A lot or batch number covers everything produced in one run. The join to a physical part is via a label on the container, so lot-level certification means unit-level traceability does not exist by design.
  • A heat number is the metals equivalent: one melt of steel, from which many parts are made. Heat numbers link a certificate to a mill test report and are frequently stamped on the material itself.
  • A serial rangeSN 001001 through 001050 — covers fifty individually identified units. This is the one that breaks extraction.

A range extracted as the string 001001-001050 cannot answer a query about unit 001037. Expand it, and store both the range and the expansion, because the range is what the document said and the expansion is what you will query. Expansion needs care: serials with alphabetic prefixes increment only in the numeric portion, zero padding must be preserved, and a range whose endpoints have different prefixes is not a range at all but two values joined by a dash — which happens, and should be an exception rather than a guess. Ranges expressed as 001001 thru 001050 (50 pcs) give you a free check: the expanded count must equal the stated quantity, and when it does not, one of the two was misread.

Inspection certificates are a different animal

In materials supply, EN 10204 defines types of inspection document and they are not interchangeable. A type 2.1 is a declaration of compliance with the order, with no test results. A 2.2 is a test report based on non-specific inspection. A 3.1 is an inspection certificate with actual test results on the delivered material, validated by the manufacturer’s inspection representative who is independent of the manufacturing department. A 3.2 is countersigned by a representative of the purchaser or an external inspector.

A purchase order specifying 3.1 is not satisfied by a 2.1, and the two documents look similar at a glance — both are one page with a supplier letterhead and a signature. So document_type is a required field, and its value comes from an explicit citation on the page (“EN 10204 3.1”) rather than from inference. When a document carries test results, it also carries a table of measured values against specified limits, and each row is an extractable triple of property, specified range and actual value — which lets you check conformance arithmetically instead of trusting the declaration.

EN 10204 is published by CEN and adopted as a national standard by its members. The type numbering above is long-standing; confirm the current text through your national standards body rather than a summary.

Where it breaks

The certificate is a scan of a scan. CoCs travel by email attachment through several parties, and each hop can add a re-scan. Small type in the specification list degrades first, which is exactly the text whose revision digits you need. Resolution triage before extraction is worth more here than a better prompt.

One PDF, many certificates. A shipment’s paperwork arrives as a single file containing a CoC, a packing list, a mill certificate and an invoice. Splitting on document boundaries comes before extraction, and the boundary signal is usually a letterhead change rather than a page break — document ingestion covers the splitting step this depends on.

The signature is a name in a box. Most CoCs are signed by typing a name and a title. Treat that as content, exactly as with a signature block in a PDF contract, and do not describe it as verified in any field name.

Quantity units are implicit. “Qty 500” may be pieces, feet, kilograms or boxes, and the certificate often omits the unit because everyone in that supply chain knows it. Extract the unit as nullable rather than defaulting to pieces, and reconcile against the purchase order line rather than the certificate.