source of record

Core meaning

A **source of record** is the formally designated system, application, or repository that holds the authoritative version of a specific data set or data element. It is the place an organization agrees to treat as the final, controlling reference when there are discrepancies between systems.

In industrial and manufacturing environments, a source of record is usually defined for key operational, quality, and business data so that everyone knows which system’s values must be used and maintained as correct.

How it is used in manufacturing and industrial systems

Organizations commonly assign a source of record for:

– **Master data** – e.g., product definitions, bills of material, recipes, routing (often in ERP or PLM).
– **Manufacturing execution data** – e.g., work order execution status, equipment states, material genealogy (often in MES or specialized OT systems).
– **Quality data** – e.g., test results, batch dispositions, nonconformance records (often in LIMS, QMS, or MES).
– **Asset and maintenance data** – e.g., equipment master, maintenance history (often in EAM/CMMS systems).
– **Regulatory-relevant records** – e.g., electronic batch records, electronic device history records (often in MES, EBR systems, or document control systems).

In day-to-day workflows, a source of record:

– Defines **where data must be corrected** if errors are found, so downstream systems can be updated via integration or refresh.
– Guides **integration design**, because interfaces should consume data from the agreed source of record and treat other instances as copies.
– Acts as the **reference in reconciliations**, audits, and investigations when numbers do not match across systems.

Boundaries and what it is not

A source of record:

– **Is about authority, not physical origin.** The data may have been first generated elsewhere (e.g., a sensor), but a different system may be chosen as the authoritative source of record after validation or enrichment.
– **Is not necessarily the only place the data lives.** The same data may be replicated into data warehouses, reporting tools, or other applications, which are then treated as secondary copies.
– **Is not automatically a regulatory record.** Some sources of record are regulatory-relevant, others are purely operational or commercial; this depends on the data type and applicable regulations.

Relation to data trust and KPI reporting (site context)

When organizations build KPI reporting for manufacturing or quality, they typically:

– Designate a **source of record** for each data element used in the KPI (e.g., production quantity, scrap quantity, equipment state, batch release status).
– Ensure that KPI calculations consistently pull from that source of record, or from controlled derivatives of it (e.g., a governed analytics layer fed from the source of record).
– Use the source of record as the **reference point for data lineage and reconciliation**, particularly when there are discrepancies between MES, ERP, historians, or reporting tools.

Without a clearly defined source of record, different reports can compute the same KPI from different systems, leading to conflicting numbers and reduced confidence in MES and enterprise reporting.

Common confusion and related terms

– **Source of truth**: Often used interchangeably with source of record. In many organizations, “system of record” or “source of record” is the more specific term for the particular system that holds authoritative data for a defined domain.
– **Data origin**: The system or device where data is first generated (e.g., a PLC or sensor). The source of record may be different if the organization designates a higher-level system (such as MES or historian) as the authoritative holder after validation, aggregation, or contextualization.
– **Reporting or analytics layer**: Dashboards and data warehouses often consume data from the source of record but are not always designated as the source of record themselves, unless the organization explicitly defines them as such for certain derived metrics.

Clear terminology and governance typically require explicitly naming the **system of record** for each data domain, documenting how other systems depend on it, and distinguishing it from both raw data origins and downstream reporting copies.