Specification management is the discipline of writing, approving, versioning, and controlling the specifications that define every raw material, packaging component, and finished product a food plant buys and makes. A specification is the agreed standard a material must meet, and the reference every certificate of analysis and incoming inspection is judged against.
Specifications are the quiet backbone of a food quality system. Every supplier approval, every incoming check, every customer complaint, and every recall investigation eventually points back to a spec: what were we supposed to receive, what were we supposed to ship, and did it meet the standard we agreed to? When specs are current and controlled, those questions have fast answers. When they live in scattered spreadsheets and email attachments, the same questions turn into archaeology. This guide covers the three types of food specification, what belongs in one, how version control and approval work, and how specs tie into COAs, incoming inspection, and audits.
What is specification management?
Specification management is the system that keeps every specification accurate, approved, current, and available to the people who use it. It is not the specs themselves, it is the control around them: who can write one, who approves it, how a change is reviewed, which version is active, and how the shop floor and the supplier both know they are working from the same standard.
The reason it needs a system is drift. Suppliers change formulations, customers tighten tolerances, a line finds that a moisture spec is unrealistic, an ingredient gets a new allergen statement. Each change is small; uncontrolled, they accumulate into a plant running on specs nobody has looked at in three years, with the receiving team checking against one version and the supplier shipping to another. Specification management is the discipline that stops that drift.
What are the three types of food specification?
Food specifications come in three types that together define the full path from purchased inputs to shipped product. Each protects a different point in the process.
- Raw material specifications define each ingredient and additive: identity, grade, physical and chemical parameters, microbial limits, allergen status, and the tests a supplier's certificate of analysis must report. They are the basis for supplier approval and incoming inspection.
- Packaging specifications define films, cartons, closures, and labels, dimensions, materials, barrier properties, food-contact compliance, and print or artwork requirements. Packaging is a food-contact material and a food-safety input, not just a cost line.
- Finished product specifications define what ships: composition, net weight, sensory attributes, microbial and chemical limits, shelf life allergen and label declarations, and defect tolerances. This is the standard your customer holds you to.
What goes into a specification?
A good specification is complete enough that two parties can agree on exactly what “acceptable” means and test for it the same way. The common contents:
| Section | What it defines |
|---|---|
| Identity | Material name, code, grade, supplier, and country of origin |
| Physical / chemical parameters | Measurable attributes with target and tolerance: moisture, pH, water activity, particle size, fat, etc. |
| Microbiological limits | Pathogen criteria and indicator organism limits with sampling and methods |
| Allergen and regulatory | Allergen status, additive compliance, food-contact status, and required declarations |
| Sensory | Expected appearance, color, odor, flavor, and texture, with defect limits |
| Testing and COA | Which tests the supplier must run and report on the certificate of analysis, and acceptance criteria |
| Control | Version number, effective date, author, approver, and revision history |
The trap is specifying attributes you never measure or, worse, ones you cannot. A number with no test method and no acceptance criterion is decoration; it looks rigorous and settles nothing when a load is borderline. Every parameter in a spec should map to a test, a limit, and a decision.
How do version control and approval work?
Version control and approval are what separate a managed specification from a stale document. Every spec carries a version number, an effective date, and a record of who wrote and approved it, and no version becomes active until it is approved and issued. When a change is needed, it goes through review and approval, the version increments, the effective date is set, and the old version is retired, not deleted, but retained so you can reconstruct what standard applied to product made last year.
This is the same document-control logic behind good manufacturing practice and HACCP records, and it matters for the same reason: a control you cannot prove was in effect on a given date is a control you cannot defend. Approval also forces cross-functional sign-off, quality, procurement, and often R&D, so a spec change does not surprise the people who have to buy or make to it.
How do specs connect to COAs and incoming inspection?
The specification is the yardstick; the certificate of analysis and the incoming inspection are the measurements taken against it. A COA is the supplier's declaration that a lot meets the agreed parameters, and it only means something when it is checked against a current spec, the same tests, the same limits. An incoming inspection then verifies at receipt: confirming identity, checking the COA against the raw material spec, and doing whatever on-site checks the spec calls for before the material is released to production.
This is where specification management earns its keep. If receiving is checking against an outdated spec, a COA can “pass” a material the customer would reject, or fail one that is actually fine. When a lot does not conform, the spec is what a non-conformance report cites, and the resulting decision, accept, reject, use-as-is with deviation, is only defensible against a controlled version. Specs, COAs, and receiving records have to move together, and they feed directly into the plant's traceability chain: the spec version, the COA, and the receiving lot are part of the story you tell in a recall.
How do you build a specification management system?
A workable specification management system comes down to a handful of controlled habits:
- Inventory every spec you rely on raw material, packaging, and finished product, and confirm each has an owner.
- Put every spec in one controlled format with a mandatory control block: version, effective date, author, and approver.
- Define the approval workflow. Decide who reviews and who signs, and require cross-functional approval so quality, procurement, and R&D agree before a version goes active.
- Link each spec to its verification the COA parameters and the incoming-inspection checks that prove a lot meets it.
- Control change and retain history. Route every change through the workflow, increment the version, retire the old one, and keep superseded versions retrievable.
- Review on a schedule and on trigger periodically, and whenever a supplier, formula, customer requirement, or regulation changes.
What do auditors expect from specifications?
Auditors expect specifications that are documented, agreed, current, and controlled, and that match what the plant actually does. Every GFSI-recognized scheme requires specifications for raw materials, packaging, and finished products, kept up to date and formally agreed with suppliers and customers. What an auditor probes is not whether specs exist but whether they are live: is the version on the receiving desk the current one, does the COA acceptance match the spec, was the last change approved and dated, and can you produce the spec that governed a lot made months ago?
The common findings are drift findings: an expired spec still in use, a customer requirement that never made it into the finished-product spec, a COA checked against a superseded version, no evidence of review. Under FDA's preventive controls framework, raw material and ingredient hazards must be evaluated and, where controlled through suppliers, managed under a supply-chain program, which assumes you have defined specifications to approve suppliers and receive against. Specifications are the paper trail all of that rests on.
Specification management by the numbers
The regulatory and standards backing for controlled specifications:
- FDA's preventive controls rule requires evaluating the hazards associated with raw materials and ingredients as part of the hazard analysis, the basis for setting material specifications (eCFR, 21 CFR 117.130).
- The supply-chain program in 21 CFR Part 117 Subpart G requires approving suppliers and conducting receiving activities for raw materials whose hazards are controlled by the supplier, work that runs on defined specifications and COAs (eCFR, 21 CFR Part 117 Subpart G).
- FDA's preventive controls framework ties supplier approval, receiving, and records together under FSMA, documented specifications are what make those verifications meaningful (FDA, FSMA Preventive Controls for Human Food).
Specifications fail the same way records do: not because they are wrong when written, but because the current version and the version in use quietly drift apart. Harmony makes specs, COAs, and incoming-inspection results live, searchable data on one system, layered on the tools a plant already runs, with no rip-and-replace, so the receiving team, the quality manager, and the auditor are all looking at the same current standard, and decades of specs and production history are answerable in plain English. A spirits manufacturer moved its production and quality records off paper entirely on that foundation. When a customer asks which spec a lot was made to, the answer should be a search, not a search party.