Specifications as data, not as documents
Most manufacturers hold their specifications as prose in documents, then spend years building spreadsheets to answer questions the prose already contains.
The shape of a specification here
A specification in Manufacturing PLM is a revision-controlled object holding typed characteristics: a name, a nominal value, upper and lower limits, a unit of measure, a measurement method and a criticality.
It usually also holds prose, because prose carries intent that a number cannot — why a tolerance is what it is, what the failure looks like outside it, what the customer actually asked for. The prose is not the enemy. The problem is prose that is the only representation of something a machine needs to read.
The distinction is concrete. *Operating temperature −20 °C to +60 °C* in a paragraph is a sentence. The same fact as a characteristic — nominal range, unit °C, method chamber soak, criticality major — is a thing that can be compared against a component's rating, rolled up through an assembly, and turned into an inspection plan without anybody retyping it.
What typing makes possible
Five things become available the moment characteristics are typed, and none of them are available while the same content sits in a PDF.
- Comparison across revisions shows that a tolerance tightened, rather than that a document changed. A diff of two PDFs tells you a page differs; a diff of characteristics tells you which limit moved and by how much.
- Rollup through assemblies answers whether a product's specified operating range is actually supported by every component it contains — which is a question nobody asks manually because it takes a day.
- Inspection plan generation turns critical characteristics into an inspection plan without transcription, which is where the transcription errors used to come from.
- Requirement traceability links a customer requirement to the characteristic that satisfies it and the test that verifies it, so an unverified requirement is visible rather than assumed.
- Search by value finds every product specified above a threshold, which is how a regulatory change gets scoped in an afternoon rather than a fortnight.
The failure it prevents
A regulation changes and a class of products must now meet a stricter limit on one characteristic. Somebody has to determine which products are affected.
The specifications are PDFs. The work is a person opening documents, reading them, and building a spreadsheet. It takes three weeks, covers the products somebody remembered, and misses two variants that were specified in a different document because a different engineer wrote them.
The information existed the whole time. It was written down, correctly, in documents that were controlled and current — and it was unreachable, because the only way to read it was for a human to read it. Typed characteristics make that same question a query.
How it meets the rest of the product
Classification supplies the attribute template, so a specification for a power supply starts with the characteristics power supplies have rather than as an empty form. Consistency comes from the template rather than from discipline.
Quality records reference characteristics directly, which means a nonconformance is against a specific limit rather than against a document. That is the difference between a quality history you can analyse and one you can only read.
Change control treats a characteristic edit as what it is. Tightening a limit on a released specification is a change with an impact analysis attached — every product consuming it, every open order, every supplier holding a controlled copy — rather than an edit to a paragraph.
Where-used works on specifications too, which surprises people. Asking which products are governed by a specification is the same structural query as asking which products contain a part, and it is the question that gets asked first whenever a customer or a regulator raises one.
Semantic search reaches both the characteristics and the prose, scoped by permission, so an engineer looking for how a similar problem was specified previously finds the answer rather than rewriting it from scratch — which is where a great deal of quiet duplication comes from.
How it meets your ERP
ERPs generally do not model characteristics, and the ones that do model them for quality inspection rather than for design intent. That is a reason to keep specifications here rather than an argument about capability.
What crosses is narrower: a specification is published as a controlled document reference against the item, so a purchase order can point at the current specification a supplier must meet. The characteristics themselves stay here, because there is no field in an ERP item master that means *upper limit with a measurement method*.
Where your ERP or MES runs inspection, critical characteristics are published as an inspection plan — as data rather than as a document — and results come back as evidence against quality records. That is the one place specification data genuinely needs to leave.
Where the boundary is
Manufacturing PLM does not extract characteristics from your existing PDFs automatically and treat the result as data. Extraction is offered as a proposal an engineer reviews, at Recommend tier, because a mis-read tolerance is a defect that enters the record looking authoritative.
It also does not simulate, calculate margins, or verify that a design meets its specification. It records what was specified, what was measured, and whether the two agree. The engineering judgement between them belongs to an engineer.
Facts
| A characteristic | Name · nominal · limits · unit · method · criticality |
| Prose | Kept — it carries intent a number cannot |
| The problem | Prose as the only representation of something a machine must read |
| Unlocks | Revision diff · rollup · inspection plans · traceability · value search |
| Templates | Supplied by classification, not by discipline |
| A limit change | A change with impact analysis, not a paragraph edit |
| To the ERP | A document reference; inspection plans where the MES runs them |
| Not offered | Automatic PDF extraction as fact · simulation · margin analysis |
Frequently asked
Do we have to stop writing specification documents?
No. Prose stays, because it carries intent that a number cannot — why a tolerance is what it is and what failure looks like outside it. What changes is that prose stops being the only representation of facts a machine needs to read.
What does typing a characteristic actually buy?
Comparison across revisions that names which limit moved, rollup through assemblies, inspection plan generation without transcription, requirement traceability, and search by value. None of those are available while the same content sits inside a PDF, however well written it is.
How does this change a regulatory scoping exercise?
From three weeks of reading documents to a query. The failure mode of the manual version is not that it is slow — it is that it covers the products somebody remembered and misses the variants a different engineer specified in a different document.
Where do the characteristic templates come from?
From classification. A specification for a power supply starts with the characteristics that power supplies have rather than as an empty form, so consistency comes from the template rather than from every engineer independently remembering to record the same set of fields.
Can Manufacturing PLM read our existing PDF specifications?
It can propose characteristics extracted from them, at Recommend tier, for an engineer to review. It does not treat extraction output as fact, because a mis-read tolerance is a defect that enters the record looking every bit as authoritative as a correct one.
Do characteristics go into our ERP?
Generally no — there is no field in an ERP item master meaning upper limit with a measurement method. A specification is published as a controlled document reference against the item, so a purchase order can point at what the supplier must meet.
Does Manufacturing PLM verify a design meets its specification?
No. It records what was specified, what was measured, and whether the two agree with each other. It does not simulate, calculate margins or make an engineering judgement about sufficiency, because that judgement belongs to an engineer and it always will.