> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://tieback.io/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server. # What is a System of Record? > A vendor neutral explanation of systems of record: what makes a system authoritative, why one product can have several authoritative systems, how systems of record differ from systems of engagement and systems of insight, and why a Digital Product Passport consumes authoritative information rather than replacing it. ## Executive Summary The phrase "[system of record](/docs/knowledge-base/glossary/system-of-record)" is used constantly in product data programmes and understood precisely almost nowhere. Two misreadings do most of the damage. The first is the belief that an organisation needs one application holding every piece of product information, which leads to consolidation projects that run for years and rarely finish. The second is the belief that a [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) should become the new system of record, which quietly moves authority for engineering, commercial and manufacturing data into a publication layer that was never designed to hold it. Both misreadings share a root cause: treating "system of record" as a property of an application rather than a property of a data domain. A system is not authoritative in general. It is authoritative for something specific, and the same product will normally have several authoritative systems at once. Engineering specifications are authoritative in the design environment. Commercial records are authoritative in the planning environment. Enriched channel descriptions are authoritative in the product information environment. Manufacturing execution data is authoritative where production is actually recorded. None of these is wrong, and none of them needs to absorb the others. This article sets out **The Enterprise [Source of Truth](/docs/knowledge-base/glossary/source-of-truth) Model**, a four role structure that separates **authoritative sources**, **data domain ownership**, **integration and governance**, and **information use**. The model is deliberately drawn as parallel sources feeding a shared governance layer, not as a single consolidated store, because the parallelism is the point. It also separates terms that are routinely used as synonyms and are not: system of record, [authoritative source](/docs/knowledge-base/glossary/authoritative-source), source of truth, single source of truth, system of engagement, system of insight, [master data](/docs/knowledge-base/glossary/product-data) and Digital Product Passport. The central principle is short enough to carry into an architecture review. There does not need to be one system of record for the entire product. There needs to be an identifiable authoritative source for each governed data domain, a named owner for that decision, and a defined behaviour for what happens when two systems disagree. Nothing here is a regulatory requirement. European product legislation, including the Ecodesign for Sustainable Products Regulation, sets obligations about what information must be available, accurate and accessible. It does not prescribe which internal application should hold that information. That is an enterprise architecture decision, and this article keeps the two firmly apart. Framework TBF-027 The Enterprise Source of Truth Model Separates authoritative sources, data domain ownership, integration and governance, and information use, so multiple authoritative systems can coexist with one defined source of truth per governed element. ## Table of Contents * [Definition](#definition) * [What is a System of Record?](#what-is-a-system-of-record) * [Why Systems of Record Matter](#why-systems-of-record-matter) * [The Enterprise Source of Truth Model](#the-enterprise-source-of-truth-model) * [One Product, Multiple Authoritative Systems](#one-product-multiple-authoritative-systems) * [System of Record vs Single Source of Truth](#system-of-record-vs-single-source-of-truth) * [System of Record vs System of Engagement](#system-of-record-vs-system-of-engagement) * [System of Record vs System of Insight](#system-of-record-vs-system-of-insight) * [Systems of Record Across ERP, PLM, PIM, MDM and MES](#systems-of-record-across-erp-plm-pim-mdm-and-mes) * [How to Assign Authoritative Ownership by Data Domain](#how-to-assign-authoritative-ownership-by-data-domain) * [Systems of Record and Product Data Governance](#systems-of-record-and-product-data-governance) * [Systems of Record and Product Data Stewardship](#systems-of-record-and-product-data-stewardship) * [Systems of Record and Digital Product Passports](#systems-of-record-and-digital-product-passports) * [What Happens When Systems Disagree?](#what-happens-when-systems-disagree) * [Practical Example](#practical-example) * [Common Mistakes](#common-mistakes) * [Frequently Asked Questions](#frequently-asked-questions) * [Key Takeaways](#key-takeaways) * [Related Articles](#related-articles) * [Related Glossary Terms](#related-glossary-terms) * [References](#references) ## Definition A system of record is the system that holds the authoritative version of a defined set of data. It is the system the organisation has formally designated as the place where those data elements are created or maintained, where their current correct value is determined, and against which all other copies are reconciled. Authority is scoped to a data domain rather than to a product, so an organisation normally operates several systems of record, each authoritative for different information about the same product. Three parts of that definition carry the weight. **Designated.** A system of record is the result of a decision, not of technical accident. If no one decided, the organisation does not have a system of record for that domain; it has a habit, and habits fail silently the moment a second system starts holding the same attribute. **Scoped.** Authority attaches to a data domain, such as engineering specifications, supplier declarations or commercial attributes. It does not attach to a whole product record. The question is never "what is our system of record?" but "what is our system of record for this?" **Reconciled against.** The practical test of authority is what happens during a disagreement. If a value in system A and a value in system B conflict and the organisation knows without discussion which one wins and which one has to change, A is a system of record. If the answer is a meeting, it is not. ## What is a System of Record? A system of record performs four functions for the data it is authoritative for. **It is the point of creation or authoritative maintenance.** New values enter there, or are formally accepted there when they originate outside the organisation. Values that appear first elsewhere and are back-filled later are a strong signal that the designation is nominal. **It determines the current correct value.** When the value changes, the system of record's version is what changed. Other systems reflect the change; they do not compete with it. **It carries the record's history and context.** Effective dates, versions, approval state and the identity of whoever made the change. Authority without history is unverifiable, and unverifiable authority is not usable as evidence. **It is the reference point for reconciliation.** Downstream copies are compared to it, and differences are treated as defects in the copy rather than as alternative opinions. A system can be a system of record for one domain and a subordinate consumer for another. A planning system may be authoritative for commercial product records while holding an engineering attribute it merely receives. This is normal and healthy. Problems begin when the distinction is undocumented, because a received value and an authoritative value look identical on screen. > **Tip** > > A quick diagnostic: pick five attributes that appear on your product label or public listing and > ask five different people which system is authoritative for each. If the answers diverge, you have > found the real state of your architecture, and it is not a technology problem. ## Why Systems of Record Matter Designating authority is not administrative tidiness. It is what makes several other capabilities possible at all. **Conflict resolution becomes deterministic.** Without designated authority, every disagreement between systems becomes a negotiation, and negotiations are slow, inconsistent and unrecorded. With it, the resolution rule is known in advance and can be automated. **Evidence becomes defensible.** A published claim is only as strong as the chain from the claim back to the record that supports it. That chain has to terminate somewhere specific. "It came from the spreadsheet the team maintains" is not a terminus. **Change propagates predictably.** When authority is clear, a change in one place has a known set of downstream effects. When it is not, changes are applied in several places at different times, and the systems drift apart between updates. **Integration stops being bidirectional by default.** Two systems that are both allowed to update the same attribute will eventually overwrite each other, and the winner will depend on timing rather than on correctness. Designating one as authoritative turns a fragile two way sync into a directional flow. **Accountability attaches to something.** A named owner can be accountable for an attribute domain only if there is a defined place where that domain lives. Ownership of a value that exists in six systems with no primary is ownership in name only, a point developed further in [What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship). **Regulatory response becomes possible under time pressure.** When a market surveillance authority asks where a published value came from, the useful answer names a system, a record, a version and a date. Assembling that answer during the request rather than before it is how deadlines are missed. #### The cost of an undesignated attribute A consumer goods manufacturer publishes a recycled content percentage. The value exists in the supplier portal, in the design environment, in the commercial record and in the marketing catalogue. All four are slightly different because they were updated at different times against different supplier declarations. Nobody is wrong; nobody is authoritative. When the figure is challenged, the organisation cannot say which number it stands behind, and the investigation takes three weeks. The defect was not data quality. It was the absence of a designation. ## The Enterprise Source of Truth Model The Enterprise Source of Truth Model separates four distinct information roles. It is drawn as a set of parallel authoritative sources feeding a shared ownership and governance layer, which in turn serves several kinds of consumption. The parallelism is deliberate: at no point does the model require product information to be consolidated into a single application. Framework The Enterprise Source of Truth Model Multiple authoritative systems coexist. Each governed data element has one defined source of truth, resolved by ownership rather than by consolidation. 01 Authoritative Sources Parallel, not consolidated * PLM Design and specification * ERP Commercial and operational * PIM Channel facing content * MDM Identity and reference * MES Manufacturing execution * Supplier systems Declarations and evidence * Other governed sources Quality, logistics, laboratory ↓ each governed element is assigned to exactly one source 02 Data Domain Ownership The resolving layer Which system is authoritative for which attribute or data domain? * One authoritative source per governed element, recorded and visible * A named owner accountable for the designation, not just for the value * Precedence rules where more than one system legitimately holds the element * An explicit decision, reviewed when systems or processes change ↓ authoritative values pass through controls before use 03 Integration & Governance Where authority is enforced * Validation * Transformation * Access * Lineage * Policy * Stewardship ↓ governed information is used without transferring authority 04 Information Use Consumers, never sources * Systems of Engagement Interaction with people and partners * Systems of Insight Analysis, reporting, modelling * Digital Product Passport Published external representation * External Services Recyclers, authorities, marketplaces One product can have multiple authoritative systems. Each governed data element should have one clearly defined source of truth. **Role one, authoritative sources.** The systems where governed information legitimately originates or is formally accepted. They operate in parallel and are expected to remain distinct. Their boundaries follow the work the organisation actually does: design happens in one environment, commercial administration in another, production in a third, and supplier declarations arrive from outside altogether. **Role two, data domain ownership.** The layer that answers the only question that matters when two systems hold the same element: which one is authoritative? This is a governance artefact, not a piece of software. It can live in a data catalogue, a governance register or an architecture decision record, but it has to be written down and it has to be visible where the data is maintained. **Role three, integration and governance.** Where designated authority becomes operative. Validation enforces the definition, transformation makes the value usable elsewhere without changing its meaning, access control determines who may see or change it, lineage records where it came from, policy sets what may be published, and stewardship supplies the human judgement the other five cannot. **Role four, information use.** Everything that consumes governed information: interfaces for people and partners, analytical environments, published passports, and external services. Consumption never confers authority. A system that displays a value, caches it, translates it or publishes it has not become the system of record for it. The model deliberately extends rather than replaces existing tieback frameworks. The [Product Data Foundation Model](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data) classifies what kinds of data exist; the [Enterprise Product Data Landscape](/docs/knowledge-base/enterprise-systems-and-data-architecture/erp-vs-pim-vs-plm) describes what each system does; the [Enterprise Integration Model](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-enterprise-systems-support-digital-product-passports) describes how information moves. This model addresses the question those three leave open: when several of those systems hold the same element, which one is right? ## One Product, Multiple Authoritative Systems The instinct to consolidate is understandable. One system means one value, and one value means no conflict. In practice, consolidation of all product information into one application is rare, expensive and usually incomplete, because the systems in question exist for different reasons and serve different operational disciplines. A design environment exists to manage change control over engineering intent. A planning system exists to run commercial and operational processes with financial controls attached. A product information environment exists to enrich and syndicate content for channels. A manufacturing execution environment exists to record what actually happened on a line. Merging them does not produce one better system; it produces one system doing four jobs badly, with four groups of users fighting over the change roadmap. The alternative is not chaos. It is federation with designation. Multiple authoritative systems coexist, and every governed element is assigned to exactly one of them. Conflict is prevented by the assignment rather than by consolidation. #### Federate the systems, centralise the designation Keep authoritative systems where the work happens, and centralise only the register of which system is authoritative for what. The register is small, cheap to maintain and the single most useful artefact in a product data programme. The consolidation project it replaces is neither. There is one important caveat. Federation only works when the assignment is genuinely exclusive per element. "PLM and ERP both own materials" is not federation; it is an unresolved conflict written down in a nicer font. If two systems must both hold an element, one is authoritative and the other holds a copy, and the copy must be identifiable as one. ## System of Record vs Single Source of Truth These two phrases are used interchangeably more often than any other pair in this field, and the difference between them explains a great deal of confusion. A **system of record** is a designation of authority for a data domain. It is scoped, plural and architectural: an organisation has many. A **source of truth** is a looser term for wherever the correct value is obtained for a particular purpose. It is usually the system of record, and sometimes a governed projection of it. A **single source of truth** is often intended to mean "one agreed answer per data element", which is a governance statement and a reasonable goal. It is frequently heard as "one system holding everything", which is an architectural statement and usually neither achievable nor desirable. The same three words carry both meanings, and the ambiguity is not harmless: programmes have been scoped, budgeted and staffed on the second reading when only the first was intended. An **authoritative source** is the most precise of the four. It names the system that is authoritative for a specific element, and it invites the natural follow up question: authoritative for what? | Term | What it actually designates | Scope | How many | | ---------------------- | ------------------------------------------------------------ | ---------------- | ------------------------------ | | System of record | The system formally designated as authoritative for a domain | A data domain | Several per organisation | | Authoritative source | The system authoritative for a specific element | A single element | One per governed element | | Source of truth | Where the correct value is obtained for a purpose | Contextual | One per purpose, ideally | | Single source of truth | Informal: one agreed answer, or one system holding all data | Ambiguous by use | Depends which meaning is meant | #### Treating 'single source of truth' as an architecture When the phrase appears in a programme charter, ask which meaning is intended. If it means one agreed answer per element, it is a governance objective and it is achievable. If it means one system holding all product data, it is a consolidation programme and it needs to be costed, justified and approved as one, not smuggled in as a data quality initiative. ## System of Record vs System of Engagement The distinction between systems of record and systems of engagement predates Digital Product Passports by well over a decade and remains the most useful two way split in enterprise architecture. A **system of record** holds authoritative data. It optimises for correctness, control, history and auditability. Change is deliberate and traceable. Users are relatively few and usually trained. A **system of engagement** supports interaction. It optimises for usability, responsiveness and reach. It presents information, collects input and drives a process, and it is typically where the largest number of people meet product data. Storefronts, portals, mobile applications, service desks and partner interfaces are systems of engagement. The failure mode is predictable. A system of engagement is easier to change than a system of record, so when a value is wrong the pragmatic fix is applied where the fix is easy. The engagement layer now holds a value the record layer does not, no one records that this happened, and the next synchronisation either overwrites the correction or preserves the divergence. Either way the organisation has acquired a second, unmanaged source. #### Correcting data in the engagement layer A wrong value visible to a customer is an emergency, and the fastest fix is nearly always in the channel. Make the fast fix if you must, then raise the correction against the authoritative source the same day. A correction that never travels upstream is not a correction; it is a divergence with good intentions. ## System of Record vs System of Insight A **system of insight** analyses. Data warehouses, lakehouses, reporting environments, sustainability calculation engines and analytical models all sit here. They combine data from many sources, derive new values, and present aggregates, trends and scores. Systems of insight are consumers, and derived values are not authoritative by virtue of being calculated. A carbon figure computed in an analytical environment from inputs held elsewhere is a derivation. If it is going to be published, the organisation has to decide deliberately whether the derivation itself becomes a governed element with its own authoritative source, method version and approval, or whether it remains an internal analysis that is not published. This decision is frequently skipped, and skipping it is how a number from an exploratory model ends up on a public passport. The rule is simple: anything published must have an authoritative source, and "a report" is not one unless the organisation has deliberately made that reporting environment authoritative for that derived element, with the governance that implies. | Property | System of record | System of engagement | System of insight | | ----------------- | ---------------------------- | ------------------------- | ------------------------------------------ | | Primary purpose | Hold authoritative data | Enable interaction | Analyse and derive | | Optimised for | Correctness and control | Usability and reach | Aggregation and modelling | | Data origin | Created or formally accepted | Received, plus user input | Copied and combined | | Change discipline | Controlled and versioned | Frequent and iterative | Recalculated | | Authoritative? | Yes, for its domain | No | Only for deliberately governed derivations | | Typical failure | Becomes a bottleneck | Becomes a shadow source | Publishes an ungoverned derivation | ## Systems of Record Across ERP, PLM, PIM, MDM and MES The following divisions are common patterns, not prescriptions. Every organisation's allocation depends on its operating model, its sector and the systems it actually runs. [ERP vs PIM vs PLM](/docs/knowledge-base/enterprise-systems-and-data-architecture/erp-vs-pim-vs-plm) covers what each system does in more depth; this section addresses only what each tends to be authoritative for. **PLM, product lifecycle management.** Commonly authoritative for engineering specifications, bills of materials, design revisions, material composition as designed, and engineering change state. Its natural strength is controlled change over engineering intent. **ERP, enterprise resource planning.** Commonly authoritative for the commercial product record, procurement and supplier commercial relationships, units of measure for transactions, operational status, and the financial view of the product. Its natural strength is transactional integrity. **PIM, product information management.** Commonly authoritative for enriched descriptions, marketing attributes, channel specific content, digital assets and localised content. Its natural strength is enrichment and syndication. It is rarely the right authority for engineering or regulatory facts, though it frequently displays them. **MDM, master data management.** Commonly authoritative for identity and reference data: product identifiers, classification, hierarchies, controlled vocabularies and cross system matching. In some architectures MDM is authoritative for a [golden record](/docs/knowledge-base/glossary/golden-record) spanning several domains; in others it governs identity and defers to domain systems for everything else. Both are legitimate, and the choice should be explicit rather than emergent. **MES, manufacturing execution.** Commonly authoritative for what actually happened in production: batch and lot records, production events, equipment and process parameters, and as built configuration. Its natural strength is the factual record of execution, which is precisely what [product traceability](/docs/knowledge-base/glossary/product-traceability) depends on. **Supplier systems and portals.** Suppliers are authoritative for what they declare about their own goods. The receiving organisation is authoritative for the decision to accept a declaration, and remains accountable for anything it publishes on that basis. This split matters: accepting a supplier value is a governed act with a date, an approver and an evidence reference, not a data transfer. **Quality, laboratory and compliance systems.** Frequently authoritative for test results, certificates, conformity assessment outcomes and the documentary evidence behind regulatory claims, depending on how the organisation has divided its quality landscape. > **Tip** > > A useful sanity check on any allocation: does the designated system own the process that changes > the value? Authority follows the work. A system that receives an attribute but cannot change it > through its own process should not be authoritative for it, however convenient the integration. ## How to Assign Authoritative Ownership by Data Domain The table below shows example product data domains with plausible authoritative sources. Every row carries the same caveat: the authoritative system is an organisational architecture decision unless a specific requirement prescribes otherwise, and few requirements do. | Data domain | Typical authoritative source | Common secondary holders | Notes | | -------------------------- | ---------------------------------------------------------------------------- | --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Product identity | MDM, or ERP where no MDM exists | PLM, PIM, passport layer | Identifier issuance and structure follow the relevant identification standard; the choice of holding system remains an architecture decision. | | Engineering specifications | PLM | ERP, PIM | Frequently displayed downstream in simplified form; the simplification is a projection, not a second source. | | Materials and composition | PLM for as designed, MES for as built | ERP, sustainability tools | The two are different elements and should be designated separately. | | Supplier declarations | Supplier system, accepted in a governed system of the receiving organisation | Quality, procurement tools | The supplier owns the declaration; the receiving organisation owns the acceptance. | | Commercial attributes | ERP | PIM, channel systems | Pricing and terms are usually the least contested designation. | | Manufacturing data | MES | ERP, quality systems | Batch and lot level facts, not product level generalisations. | | Compliance evidence | Quality or compliance system | PLM, document management | Certificates need expiry and version handling wherever they live. | | Sustainability attributes | Varies widely; often a dedicated calculation or sustainability environment | PLM, ERP, PIM | Derived figures need an explicit decision about whether the derivation is governed. | | Repair information | PLM or service documentation system | PIM, service portals | Often authored late and inherited from documentation processes rather than data processes. | | Lifecycle events | The operational system that records the event | Analytics, traceability platforms | Events are usually authoritative where they are captured, not where they are aggregated. | A workable assignment process has five steps. **Inventory the governed elements.** Start with what is published or externally relied upon rather than with everything. The set of elements that appear on a passport, a label or a regulatory submission is a natural starting scope. **Identify every system that currently holds each element.** Including the spreadsheets. Especially the spreadsheets, since an undocumented spreadsheet acting as a de facto system of record is one of the most common findings in a first inventory. **Designate one authoritative source per element.** Prefer the system that owns the process that changes the value. Where two candidates are equally plausible, prefer the one closest to the point of creation and the one with the stronger change control. **Record the designation where practitioners will see it.** A register that only exists in a governance repository will be consulted during audits and ignored during work. **Define the behaviour for the other holders.** For each non authoritative copy: is it read only, is it refreshed on a schedule, is divergence detected, and what happens when it is found? #### Designate at element level, not system level Statements like "PLM is our system of record" are too coarse to resolve any real conflict. Statements like "PLM is authoritative for material composition as designed; MES is authoritative for material composition as built" resolve conflicts before they occur, which is the entire point. ## Systems of Record and Product Data Governance Designating a system of record is a governance act, and it inherits everything governance provides. [What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance) sets out the wider framework; three connections matter most here. **Ownership.** A designation without a named owner decays. Systems change, processes move, and someone has to be accountable for revisiting the assignment when they do. The owner of the designation is normally the owner of the data domain, not the owner of the application. **Policy.** Which elements may be published, to whom, in what form and with what approval. Policy operates on governed elements, and governed elements are the ones with an authoritative source, so the register of designations is effectively the input to publication policy. **Lineage.** The record of where a value came from, what happened to it in transit, and which version of which record it reflects. Lineage is what turns a designation from an intention into something provable, and it is the mechanism that makes a published claim defensible when [market surveillance](/docs/knowledge-base/glossary/market-surveillance) asks. Data quality depends on all of this. As [What is Product Data Quality?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-quality) sets out, consistency cannot be assessed without knowing which value should have been consistent with which, and that is a designation question before it is a measurement question. ## Systems of Record and Product Data Stewardship Systems hold data; people are responsible for it. A designation tells you where the authoritative value lives. It does not tell you who accepts a supplier declaration, who approves a correction, or who decides that a conflict between two systems has been resolved. Those are stewardship responsibilities, described in detail in [What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship). The two work as a pair. The data owner decides which system is authoritative for the domain and what standard values must meet. The data steward operates inside that decision: maintaining values, accepting or rejecting incoming declarations, and escalating conflicts the designation does not resolve. The data custodian keeps the designated system available, protected and faithful in transport, without acquiring any right to determine what the value should be. A designation with no steward produces an authoritative system full of stale values, which is worse than no designation at all because it carries unearned credibility. ## Systems of Record and Digital Product Passports A Digital Product Passport should not automatically be treated as the enterprise system of record. It is, in the normal case, a consumer: it takes selected governed information from several authoritative systems and presents it externally in the form a regulation, a standard or a commercial arrangement requires. The publication layer will commonly hold copies, projections, caches or published representations of information. None of that makes it authoritative for the underlying business data. A published representation is a statement about what the authoritative record said at a point in time, which is a different thing from being the record. The distinction is easiest to hold onto as a sequence. **Source.** The authoritative system where the element is created or formally accepted. **Governance.** Ownership, definition, quality standard, evidence requirement and publication policy applied to that element. **Integration.** Retrieval, validation, transformation and lineage capture as the value moves. **Publication.** Assembly of the passport representation, including any snapshot or version taken at the moment of publication. **Consumption.** Scanning, retrieval and use by consumers, repairers, recyclers, authorities and partners, typically reached through a [data carrier](/docs/knowledge-base/glossary/data-carrier) such as a [QR code](/docs/knowledge-base/glossary/qr-code). This is one valid architecture, not the only one. Some organisations publish directly from an integration layer; others assemble a governed publication store first; others operate a hybrid where regulated elements follow one path and commercial content another. What matters is that each published element can be traced back to a designated authoritative source, and that the passport layer does not silently become the place where values are edited. #### Editing values in the passport layer Passport publication surfaces usually allow editing, because someone has to fix a bad publication quickly. The moment corrections are routinely made there and not upstream, the publication layer has become an undeclared system of record for the corrected elements, with no change control, no lineage into the enterprise, and no owner. This is one of the most common architectural drifts in passport programmes, and it happens gradually enough to go unnoticed. There is a legitimate exception worth naming. Some information genuinely originates in the passport context and exists nowhere upstream: the publication record itself, the identifier binding for a specific item, the version history of what was published and when, and in some designs the [product identifier](/docs/knowledge-base/glossary/product-identifier) allocation for serialised items. For those elements the passport platform may reasonably be the authoritative source, because it owns the process that creates them. That is a narrow and explicit designation, not a general promotion. > **Regulation and architecture** > > European product legislation, including the Ecodesign for Sustainable Products Regulation and the > Batteries Regulation, sets requirements about the information that must be available, its > accuracy, its accessibility and in some cases its persistence. It does not designate an internal > system of record. Requirements about information are not requirements about architecture, and > conflating the two produces designs justified by regulations that say no such thing. ## What Happens When Systems Disagree? Disagreement between systems is normal. It is not a sign of failure; it is the expected consequence of information being captured in different places at different times by different processes. What distinguishes a mature architecture is that disagreement is detected, resolved by rule and recorded, rather than discovered by a customer. **Ownership rules resolve most conflicts without judgement.** If the designation is clear, the authoritative value wins and the divergent copy is corrected. No meeting, no escalation. This is why designation is worth the effort: it converts a large class of recurring disputes into mechanical corrections. **Stewardship handles what rules cannot.** Some conflicts are genuine: the authoritative system is wrong and the copy is right, or two systems reflect different but legitimate states, such as as designed against as built. A steward decides, within the standard the data owner set, and the decision is recorded rather than applied silently. **Validation catches conflicts early.** Cross system comparison at the integration boundary is cheaper than downstream discovery. Values that fail comparison should be quarantined rather than published, and quarantine should be visible to the steward rather than logged and forgotten. **Lineage makes resolution possible.** Deciding which value is correct requires knowing where each came from, when, and on what evidence. Without lineage, conflict resolution is a matter of seniority rather than fact, and the same conflict recurs at the next refresh. **Reconciliation should be routine, not incident driven.** Scheduled comparison between the authoritative source and its known copies turns divergence into a measured, trending number instead of a series of surprises. The trend is a genuinely useful health indicator for a data programme. **Exception management is a process, not a spreadsheet.** Unresolved conflicts need an owner, a state, an age and a resolution target. Anything unresolved beyond its target on a published element should block or flag publication rather than being carried indefinitely. **Approval separates correction from alteration.** Changing an authoritative value should carry an approval appropriate to the element's consequence. A marketing description and a regulatory declaration do not warrant the same ceremony, and applying one standard to both guarantees the wrong outcome for at least one of them. **Auditability closes the loop.** Every resolution should leave a record: what conflicted, what was decided, who decided, on what evidence and when. This is the material that answers a challenge months later, and it costs almost nothing to capture at the moment of decision. #### A conflict resolved by designation A recycled content figure differs between the design environment and the sustainability calculation environment. The register says the design environment is authoritative for material composition as designed, and that the sustainability figure is a governed derivation with its own method version. The comparison is therefore invalid: the two values are different elements, not the same element in conflict. The correct action is to check that the derivation used the current design value, not to argue about which number is right. Half of all product data conflicts dissolve this way once elements are defined precisely. ## Practical Example Consider a manufactured appliance produced in Europe and sold across several markets. Its information is distributed as follows. The allocation below is illustrative; another organisation making the same appliance could reasonably allocate differently. **PLM** is authoritative for engineering specifications, the bill of materials, material composition as designed, design revisions and the engineering change record. When a component is substituted, the change originates here and is approved here. **ERP** is authoritative for the commercial product record, procurement information, supplier commercial terms, transactional units of measure and operational status. When the appliance is discontinued in a market, that fact originates here. **PIM** is authoritative for enriched product descriptions, localised marketing content, channel specific attributes and digital assets. It displays engineering and compliance facts sourced from elsewhere, and it is authoritative for none of them. **MES** is authoritative for manufacturing execution: batch records, production events, process parameters and the as built configuration of each unit produced. When a specific unit differs from the designed configuration, this is where that fact lives. **Supplier systems** are the origin of supplier declarations, including material declarations and component level certificates. The manufacturer's quality system is authoritative for the acceptance decision, recording who accepted the declaration, when, and against what evidence. **The quality and compliance environment** is authoritative for test results, conformity assessment outcomes and certificates, including validity periods. **The Digital Product Passport** consumes selected governed elements from all of the above and publishes what the applicable requirements and the organisation's own policy permit. It is authoritative for the publication record itself: which version was published, when, against which identifier, and what it contained. It is authoritative for nothing else on the list. Now trace one element. A regulator asks how the recycled content figure on the passport was derived. The answer runs backwards through the model: the passport publication record shows the value and the publication date; lineage shows it came from the sustainability derivation, method version 2.1; that derivation used material composition from PLM at revision D and supplier declarations accepted in the quality system on specific dates; each supplier declaration references a document with an issue date and an accepting steward. Every step names a system, a record, a version and a person. That chain is the deliverable, and it exists only because each element had a designated authoritative source before the question was asked. ## Common Mistakes #### Assuming one system must hold everything The most expensive misreading of the term. Consolidation programmes justified as "establishing a system of record" typically deliver a partial migration, a long dependency freeze and the original problem intact. Designation is cheaper, faster and solves the actual conflict. #### Making the passport the enterprise system of record Convenient at first, because the passport layer is new, flexible and already holds a curated view. Within a year, engineering, commercial and compliance values are being edited in a publication tool with no engineering change control, no financial controls and no quality management integration. #### Designating at system level and stopping there "ERP is our system of record" resolves nothing, because the conflicts that matter are about specific attributes that several systems hold. Designation only becomes useful at element or domain level. #### Allowing bidirectional updates on the same element Two systems both permitted to update the same attribute will overwrite each other, and the surviving value will depend on synchronisation timing. This produces intermittent, irreproducible defects that are extraordinarily hard to diagnose after the fact. #### Treating derived values as authoritative because they were calculated A number produced by a model is an output, not a record, until the organisation deliberately governs the derivation. Publishing an ungoverned derivation is one of the more serious risks in sustainability reporting. #### Leaving spreadsheets undocumented Spreadsheets frequently are systems of record in practice. The problem is not that they exist; it is that they are authoritative without being designated, which means no access control, no history and no continuity when the owner leaves. #### Designating once and never revisiting Systems get replaced, processes move between functions, and new regulatory elements appear. A register that is not reviewed becomes a description of an architecture the organisation no longer operates, which is more dangerous than having none. ## Frequently Asked Questions **Can an organisation have more than one system of record?**\ Yes, and nearly all do. Authority is scoped to data domains, so several systems are authoritative for different information about the same product. What an organisation should not have is more than one authoritative source for the same governed element. **Is a Digital Product Passport a system of record?**\ Generally not for the underlying business data. It is a consumer and publisher of governed information. It may reasonably be authoritative for elements that originate in the passport process itself, such as the publication record and, in some designs, identifier binding for serialised items. **Is a data warehouse a system of record?**\ Not by default. It is a system of insight holding copies. It can be authoritative for deliberately governed derived values, but that requires an explicit decision, a versioned method and an owner, not just the fact that the calculation runs there. **What is the difference between a system of record and a golden record?**\ A system of record is a system. A golden record is a consolidated, reconciled view of an entity, often assembled by an MDM platform from several sources. A golden record can be authoritative if the organisation designates it so, and in that case the MDM platform is the system of record for the elements it consolidates. **Does master data management make one system authoritative for everything?**\ No. MDM approaches vary: some designate a golden record as authoritative across domains, others govern identity and reference data while deferring to domain systems for the rest. Both are valid patterns and the choice should be documented rather than assumed. **Do regulations require a specific system of record?**\ Product regulations set requirements about information: what must be available, how accurate, how accessible and for how long. They do not generally prescribe internal architecture. Always separate what the requirement actually says from how the organisation chooses to satisfy it. **Where should the register of authoritative sources live?**\ Wherever practitioners will encounter it while working: a data catalogue, a governance register, or attribute level documentation surfaced in the systems themselves. A register no one reads during normal work only functions during audits. **What if two systems genuinely need to update the same attribute?**\ Then it is usually two different elements that have been given one name, such as as designed and as built values, or a planned and an actual date. Splitting them resolves the conflict properly. Where they are truly the same element, one system must be authoritative and the other must hold a copy that cannot be edited independently. **How does this relate to supply chain data exchange?**\ Every organisation in a chain has its own systems of record, and information crossing a boundary becomes a received declaration rather than an authoritative record for the recipient, as described in [How Product Data Moves Through the Supply Chain](/docs/knowledge-base/standards-and-technology/how-product-data-moves-through-the-supply-chain). Accepting it is a governed act. **Where should an organisation start?**\ With the elements it already publishes or is about to publish. Inventory those, find every system holding them, designate one authoritative source for each, and write it down. That exercise usually takes weeks and reveals more about a product data estate than a year of tooling work. ## Key Takeaways ## Related Articles * [What is Master Data Management (MDM)?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-master-data-management) * [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture) * [What is a Golden Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-golden-record) * [How to Build a Digital Product Passport Implementation Roadmap](/docs/knowledge-base/implementation/how-to-build-a-digital-product-passport-implementation-roadmap) * [How to Build a Trusted Product Data Foundation](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-to-build-a-trusted-product-data-foundation) * [What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance) * [What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship) * [What is Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data) ## Related Glossary Terms * [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) * [Product Data](/docs/knowledge-base/glossary/product-data) * [Product Identifier](/docs/knowledge-base/glossary/product-identifier) * [Product Traceability](/docs/knowledge-base/glossary/product-traceability) * [Product Lifecycle](/docs/knowledge-base/glossary/product-lifecycle) * [Economic Operator](/docs/knowledge-base/glossary/economic-operator) * [Market Surveillance](/docs/knowledge-base/glossary/market-surveillance) * [Conformity Assessment](/docs/knowledge-base/glossary/conformity-assessment) * [Sustainability Data](/docs/knowledge-base/glossary/sustainability-data) * [Data Carrier](/docs/knowledge-base/glossary/data-carrier) * [QR Code](/docs/knowledge-base/glossary/qr-code) * [GS1](/docs/knowledge-base/glossary/gs1) * [ESPR](/docs/knowledge-base/glossary/espr) ## References * DAMA International, the professional association for data management and publisher of the Data Management Body of Knowledge: [https://www.dama.org](https://www.dama.org) * International Organization for Standardization, ISO 8000 series on data quality and master data: [https://www.iso.org/standard/81745.html](https://www.iso.org/standard/81745.html) * International Organization for Standardization, ISO/IEC 38505 on governance of data: [https://www.iso.org/standard/56639.html](https://www.iso.org/standard/56639.html) * International Organization for Standardization, ISO/IEC 42010 on architecture description: [https://www.iso.org/standard/74393.html](https://www.iso.org/standard/74393.html) * GS1 identification keys, including the GTIN: [https://www.gs1.org/standards/id-keys](https://www.gs1.org/standards/id-keys) * GS1, the global standards organisation: [https://www.gs1.org](https://www.gs1.org) * Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for sustainable products, including Digital Product Passport provisions, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2024/1781/oj](https://eur-lex.europa.eu/eli/reg/2024/1781/oj) * Regulation (EU) 2023/1542 concerning batteries and waste batteries, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2023/1542/oj](https://eur-lex.europa.eu/eli/reg/2023/1542/oj) * European Commission, Ecodesign for Sustainable Products Regulation: [https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation\_en](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en) * EUR-Lex, official portal for European Union law: [https://eur-lex.europa.eu](https://eur-lex.europa.eu) ## About This Article About This Article
Last Reviewed
2026-08-08
Next Scheduled Review
2027-08-08
Article Version
1.0
tieback Knowledge is a continuously maintained reference library covering Digital Product Passports, product traceability, product compliance and related regulations. Articles are reviewed regularly as legislation, standards and implementation guidance evolve. ## Related Docs * [What is Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data) * [ERP vs PIM vs PLM: What's the Difference?](/docs/knowledge-base/enterprise-systems-and-data-architecture/erp-vs-pim-vs-plm) * [How Enterprise Systems Support Digital Product Passports](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-enterprise-systems-support-digital-product-passports) * [What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance) * [What is Product Data Quality?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-quality) * [What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship) * [How to Build a Trusted Product Data Foundation](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-to-build-a-trusted-product-data-foundation)