When we talk about product definition, it is tempting to reduce it to the CAD model or to the item record managed in PLM. Neither one carries the complete definition.
Consider what is actually required to fully define a manufactured product. There is the geometry and the product manufacturing information (PMI) attached to it: features, dimensions, tolerances, datums, surface finish, material callouts, and notes. There is identity and configuration: part number, revision, lifecycle state, effectivity, and the structural relationships to parent assemblies and alternate configurations. Then there is everything required to source, fabricate, inspect, sustain, and support the product: material specifications, approved suppliers, cost, process plans and routings, inspection results and nonconformances, service bulletins, and field history. In a model-based enterprise, the Technical Data Package (TDP) is the formal packaging of the design portion of that information. The rest of it lives well beyond the package.
All of it describes the same physical product. Taken together, it constitutes the authoritative product definition: the governed body of information that defines a product across its lifecycle.
No single enterprise system is authoritative for all of it.
Different Systems Are Authoritative for Different Reasons
That is not, in itself, an architectural failure. In most cases it is the consequence of enterprise systems doing exactly what they were designed and purchased to do.
CAD authoring tools define geometry and the engineering characteristics bound to it: PMI, GD&T, and the semantic annotations that make model-based definition (MBD) consumable downstream. PLM governs part identity, revision and version control, product structure, configuration, effectivity, and lifecycle state, including the change process that moves a definition from one released state to the next. ERP is authoritative for the commercial and resource view of the same part: the item master, sourcing, material, supplier qualification, and cost.
Manufacturing planning and execution systems contribute plant-specific context: the manufacturing BOM, routings, work instructions, and as-built records. Quality systems govern inspection plans, measurement results, nonconformance reports, deviations, and waivers. Service and sustainment systems continue accumulating as-maintained configuration and field performance data long after design release.
The precise boundaries vary by manufacturer. The mBOM may be owned by PLM at one company and by ERP or MES at another; a first-article inspection plan may live in a QMS or be derived directly from the model. The location of any given attribute is not the important distinction. What matters is that each system remains authoritative for the information and processes it governs.
Making one of those systems authoritative for everything would misunderstand why they exist in the first place.
They're Different Dimensions of the Same Product
The interesting architectural problem surfaces when we stop evaluating each system on its own terms and ask what a person or an application actually needs to know about the product.
Take a single part. The part number does not tell you what the part looks like. The geometry does not tell you whether it is the released revision or a working version. The revision does not tell you every assembly, configuration, or effectivity range in which the part is used. The engineering BOM does not tell you how it is routed through a particular plant. And none of that tells you the unit cost, the approved sources, whether a nonconformance was raised against the last lot, or how the part has performed in the field.
Each of those attributes can be authoritative, but each is only one dimension of the product.
The distinction matters more as product definition is consumed outside the systems where each dimension originates. A design engineer needs one composition of that information. A manufacturing engineer authoring a process plan needs another. Quality, service, suppliers, and downstream applications, each need a different, but correctly correlated, view of the same product at the same point in its lifecycle.
The question becomes: how do those authoritative dimensions remain correlated as the product changes?
That's What Makes the Digital Thread Difficult
We usually describe the digital thread in terms of integrating enterprise applications. Integration is necessary, but it is not sufficient. The harder problem is maintaining coherent product context across those systems over time.
An engineering change rolls a revision. The eBOM changes, and the mBOM has to be reconciled with it. A process plan or inspection plan is invalidated and must be re-derived. Sourcing changes when a supplier is added or disqualified. New quality data arrives with every lot. Service history keeps accumulating for decades after the design work is complete.
Throughout all of that, each system keeps doing its job. The challenge is preserving the relationships between the information they govern.
Exports, translations, synchronization jobs, integrations, and derivative representations become the mechanisms by which information moves between environments. A STEP AP242 or JT derivative, a 3D PDF, a QIF inspection plan, and the TDP itself are all derivatives of the authoritative definition. Each is correct at the moment it is produced, and each introduces another place where its relationship to the authoritative source (which revision, which configuration, which effectivity) has to be explicitly carried and maintained. A TDP that cannot be traced back to the released revision it was generated from is a liability, not an asset.
That is why I think the distinction is worth making explicit: the digital thread depends on maintaining product context across authoritative systems, not simply on connecting applications.
An enterprise can be fully integrated at the API level and still fail at product context if users and applications cannot reliably determine how information from those systems relates to the product at a specific revision, configuration, and point in time.
We Don't Need Another "Single Source of Truth"
This is also why “single source of truth” tends to oversimplify the problem. There should absolutely be authoritative sources; the model-based enterprise community’s emphasis on an authoritative source of truth is the right instinct. But there does not need to be one authoritative source for everything about the product.
CAD does not need to become ERP. ERP does not need to become PLM. PLM does not need to become MES. Each system carries a defined responsibility, and there are sound reasons to preserve those boundaries: data model, change control, user base, and regulatory obligations among them.
The architectural objective should not be to consolidate every product attribute into one primary platform. It should be to preserve the authority of each system while maintaining the linkages required to understand and consume the product definition as a whole.
That reframes the conversation. Instead of asking where all of this information should live, we can ask: how do we make the information consumable together without undermining the systems responsible for governing it?
Product Definition Is Inherently Distributed
Modern products are too complex, and the enterprises that produce them too specialized, for a complete product definition to reside in one place.
Geometry and PMI are authoritative in one system. Product structure, configuration, and lifecycle state in another. Manufacturing, commercial, quality, and sustainment context in several more. In large enterprises there are often multiple instances within each of those system categories, which is a complexity worth examining on its own.
The underlying principle holds regardless: product definition is a body of authoritative information distributed across systems, not a single model, file, database record, or data package.
As more teams, suppliers, processes, and applications depend on that information, the ability to maintain its context becomes the limiting factor. That means knowing which revision, configuration, and effectivity a given representation reflects.
The question is not which system should own the entire product definition. It is how the enterprise preserves authoritative product context when no single system does.
I believe the answer starts with a different architectural principle: don’t relocate product definition out of the systems that govern it simply to make it more broadly accessible. Keep those systems authoritative, preserve the relationships between them, and give people and applications access to the product context they need, at the correct revision, configuration, and point in time, without manufacturing another source of truth.
COMMENTS