What is a System of Record?

Executive Summary

The phrase “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 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 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, source of truth, single source of truth, system of engagement, system of insight, master 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.

Table of Contents

• Definition
• What is a System of Record?
• Why Systems of Record Matter
• The Enterprise Source of Truth Model
• One Product, Multiple Authoritative Systems
• System of Record vs Single Source of Truth
• System of Record vs System of Engagement
• System of Record vs System of Insight
• Systems of Record Across ERP, PLM, PIM, MDM and MES
• How to Assign Authoritative Ownership by Data Domain
• Systems of Record and Product Data Governance
• Systems of Record and Product Data Stewardship
• Systems of Record and Digital Product Passports
• What Happens When Systems Disagree?
• Practical Example
• Common Mistakes
• Frequently Asked Questions
• Key Takeaways
• Related Articles
• Related Glossary Terms
• References

Definition

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.

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?.

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 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.

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 classifies what kinds of data exist; the Enterprise Product Data Landscape describes what each system does; the Enterprise Integration Model 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.

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?

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.

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.

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 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 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 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.

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.

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?

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? 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 asks.

Data quality depends on all of this. As 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?.

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 such as a 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.

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 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.

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.

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

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. 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)?
• Building an Enterprise Digital Product Passport Architecture
• What is a Golden Record?
• How to Build a Digital Product Passport Implementation Roadmap
• How to Build a Trusted Product Data Foundation
• What is Product Data Governance?
• What is Product Data Stewardship?
• What is Product Master Data?

Related Glossary Terms

• Digital Product Passport
• Product Data
• Product Identifier
• Product Traceability
• Product Lifecycle
• Economic Operator
• Market Surveillance
• Conformity Assessment
• Sustainability Data
• Data Carrier
• QR Code
• GS1
• ESPR

References

• DAMA International, the professional association for data management and publisher of the Data Management Body of Knowledge: https://www.dama.org
• International Organization for Standardization, ISO 8000 series on data quality and master data: 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
• International Organization for Standardization, ISO/IEC 42010 on architecture description: https://www.iso.org/standard/74393.html
• GS1 identification keys, including the GTIN: https://www.gs1.org/standards/id-keys
• GS1, the global standards organisation: 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
• 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
• 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
• EUR-Lex, official portal for European Union law: https://eur-lex.europa.eu

About This Article

Related Docs

• What is Product Master Data?
• ERP vs PIM vs PLM: What’s the Difference?
• How Enterprise Systems Support Digital Product Passports
• What is Product Data Governance?
• What is Product Data Quality?
• What is Product Data Stewardship?
• How to Build a Trusted Product Data Foundation