A specification is often treated as a document.
It may be stored in a quality system, attached to a product record, exported as a PDF, or shared in a controlled folder. That document matters. But the specification itself is more than a file. It is product data.
A specification defines the measurable expectations that connect a product to a quality decision. It tells a team what to test, what range is acceptable, which method applies, and in many cases what action to take when a result falls outside the expected range.
For formulation-driven manufacturers, the specification sits at the intersection of product lifecycle management, quality control, and quality management. That position makes it easy for no single function to own the full problem.
PLM may own the approved product definition. QC LIMS may execute the tests and record the results. QMS may govern controlled documents, approvals, change control, training, and quality events.
If those systems are disconnected, a company can have a controlled specification document and still struggle to answer a basic operational question: which version of the specification applied to this product, this batch, this test, at this point in time?
A Specification Is the Contract Between Product and Quality
The formulation describes what the product is. The specification describes how the organization will verify that the product meets its agreed requirements.
That distinction matters.
A formula can include ingredients, quantities, sub-recipes, processing instructions, and permitted substitutions. A specification may include tests for viscosity, color, pH, density, particle size, gloss, purity, appearance, or other attributes relevant to the product and market.
A test method explains how the measurement is performed. Release criteria define the decision logic used to accept, hold, or investigate a result.
These records are related, but they are not the same record. When they are managed as disconnected documents, teams can lose the relationships that explain which formulation revision, product status, method version, and specification version were in force when quality decisions were made.
The right model treats the specification as a governed product object with relationships and history.
Where Specification Drift Begins
Specification drift happens when the controlled record used by quality stops matching the approved product definition it is meant to represent.
This can happen after a formula revision, a raw-material substitution, a product transfer, a new test method, a changed customer requirement, or an update to a release range. It can also happen when teams duplicate specifications for convenience and then update only one copy.
The risk is not always an obvious error.
A batch can pass every listed test and still have been assessed against an outdated or inapplicable specification. A formulation revision can be approved while its downstream release criteria remain unchanged. A site can use a local copy of a document after the enterprise record has changed.
These are data-relationship problems as much as document-control problems.
.png)
What Connected Specification Management Looks Like
Connected specification management preserves the links between the product definition, the applicable specification, the test method, the quality result, and the change history.
That means teams can see:
- Which specification applies to a specific product and revision
- Which tests and methods are required for that specification
- Which quality results were evaluated against it
- When the specification became effective or was superseded
- What product or regulatory change triggered a revision
- Which related products, sites, or materials may be affected
The exact division of system ownership will vary. A company may keep master product definitions and revisions in PLM, execute routine quality testing in a QC LIMS, and govern change-control workflows in QMS.
The essential requirement is not that one system does every job. It is that the systems preserve the same controlled relationships.
When a Formula Changes, the Spec Must Be Part of the Change
A formulation change is not complete simply because the ingredient list has been updated.
A new raw material, concentration, supplier, processing range, or formulation ratio can affect the product properties that quality needs to verify. It may require no specification change. It may require new targets, a different method, an updated sampling plan, or a review of whether existing tolerances still make sense.
The important step is to make the specification review explicit.
When a revision moves through product change control, the associated specifications should be visible as part of the impact assessment. Teams should be able to identify which specifications are linked to the product, whether they remain applicable, and what must be approved before the new revision takes effect.
Without that link, the organization relies on institutional memory: someone needs to remember that a formula change may affect a release specification.
The Batch Question That Matters
For any quality result, teams should be able to answer four questions quickly:
- What product and revision was this result associated with?
- Which specification and method applied at the time of testing?
- What was the result, and how was it evaluated?
- What changed before or after that result was generated?
A complete answer requires more than a PDF repository. It requires connected lifecycle and quality data.
That connection is especially useful during deviations, customer questions, investigations, reformulation work, and audits. Instead of reconstructing the record from folders, exports, and email threads, teams can follow the relationship from product to specification to result to change history.
Specifications Belong Between PLM and Quality
The question is not whether specifications belong in PLM or QMS.
They belong in the operating model that connects product definition and quality execution.
PLM needs specifications because an approved product is not fully governed without the requirements used to assess it. QC LIMS needs specifications because testing cannot be interpreted without the correct acceptance criteria. QMS needs specifications because changes, approvals, training, and deviations require controlled evidence.
A connected environment makes those responsibilities complementary rather than competitive.
See how Product Lifecycle Management and Integrated QC LIMS can keep formulations, specifications, test methods, and quality results connected through the product lifecycle with a free demo.
.png)
.png)
.png)
