A manufacturer's knowledge is spread across systems built for different jobs. Product lifecycle management holds parts, structures and drawings. The quality management system holds nonconformances, corrective actions and audits. ERP holds orders, suppliers, lots and inventory. The maintenance system holds equipment, work orders and failures. Around them sit file shares and document repositories with everything that never fit anywhere else.
Each system works for its own purpose. The trouble starts with questions that cross them: which suppliers delivered material for the parts behind this quality issue, which equipment produced the affected lots, which drawings have changed since. Answering means exporting, matching identifiers by hand and asking the people who know how the systems relate.
The usual proposals are a new platform or a large migration. There is another path: connect the systems into one governed knowledge graph that enriches data where it lives. This piece explains how that works and why the graph outlasts any particular model or vendor.
Why not migrate
The systems are not the problem
PLM, QMS, ERP and CMMS are systems of record for good reasons. The gap is between them, not inside them.
Each system of record holds authoritative data, runs its own workflows and enforces its own access controls. Migrating all of that into a new central platform is expensive, risky and usually unnecessary: the workflows still need to run, people still need their tools, and the new platform becomes one more system to keep in sync.
What is missing is a layer that knows how the systems relate. That a part in PLM is the same part on a purchase order in ERP, in a nonconformance in the quality system and in a work order in maintenance. That a drawing in a file share is a released revision of a document managed in PLM. That a supplier name in a contract is the same organization as a supplier code in ERP.
A governed knowledge graph provides that layer without replacing anything. It connects to the systems and repositories where knowledge lives, reads what it needs while honoring existing permissions, and links it into one model of the business. Your repositories, identities, workflows and controls stay in place.
Entity resolution
Deciding what refers to the same thing
The hardest part of connecting systems is not reading them. It is knowing when two records describe the same entity.
Identifiers rarely line up. A part may carry one number in engineering, another in purchasing and only a description in maintenance. Suppliers appear under codes, legal names and abbreviations. Equipment is named differently on drawings, in the maintenance system and in operator reports. Documents in file shares reference all of these in free text.
Entity resolution combines several signals: shared identifiers where they exist, cross-reference tables the business already maintains, attributes such as descriptions, materials and dimensions, and context from documents that mention both forms. Deterministic rules handle the clear cases, models help with ambiguous ones, and matches that matter are reviewed by people who know the data. Each resolved link records how it was established.
Done well, resolution turns separate records into one entity with its history across systems. A part becomes a node linked to its drawings and revisions, its purchase orders and suppliers, its nonconformances and corrective actions, its inspections and the equipment that produces it. Questions that used to require several exports become traversals of the graph.
Governance that travels
Lineage, permissions and a graph that outlives models
A graph that combines data from many systems must be at least as governed as the systems it draws from.
Lineage records, for every entity, attribute and relationship, where it came from, when it was read and how it was produced: copied from a system of record, extracted from a document with its source location, or resolved by a rule or a reviewer. When a value is questioned, its origin is one step away. When a source changes, the graph is refreshed and the affected records are updated.
Permissions follow the data. Access rules from each source system are carried into the graph and applied at query time, so a user, an application or an agent never sees more through the graph than through the original systems. Classifications and retention rules travel with the records as well. This is what makes it safe to put private AI and search on top of combined data.
Because the graph holds the knowledge and connects to systems through their interfaces, it is independent of the models that read it and of the vendors behind each system. Models can be replaced, a system of record can be upgraded or changed, and the graph remains, with its links, lineage and access rules intact. That makes it a durable asset rather than a component of one AI project.
A practical sequence
Start with one cross-system question
Connecting every system at once is a migration project in a different form. A better sequence starts from a question.
Pick a question that crosses systems and matters to the business, such as tracing a quality issue back to the suppliers and production equipment involved, and connect only the sources it needs. The question defines which entities matter, which systems hold them and which documents fill the gaps between them.
The first scope defines the core entities, often parts, suppliers, lots and equipment, and the resolution rules between the systems involved. It establishes lineage and permissions from the start, because retrofitting governance onto a graph that people already use is much harder than building it in.
Each later use case reuses what exists. A maintenance question adds the maintenance system and links work orders to equipment already in the graph; a procurement question adds contracts and certificates linked to suppliers already resolved. The graph grows by connection, not by replacement, and every new link benefits the questions that came before.
How sDEN approaches it
Connect, do not migrate
sDEN Foundation follows a repeatable path from scattered sources to governed knowledge, without replacing repositories or migrating a single folder.
Within this scope
Connect your sources
Foundation connects to PLM, QMS, ERP, CMMS and document repositories, honoring existing permissions and controls.
Within this scope
Extract, classify and resolve
Text, tables and drawings are read into consistent entities and classifications, and entities are resolved across systems with a record of how each link was made.
Within this scope
Link, govern and refresh
Entities are linked with their sources, lineage and access rules, and the graph is monitored and refreshed as documents and systems change.
What good looks like
One model of the business, many uses
The measure of success is that questions crossing systems become ordinary questions.
Engineering, quality, procurement and maintenance teams can follow a part, a supplier or a piece of equipment across every system that knows about it, with the source of each fact visible. Recurring issues can be surfaced across sites, and the impact of a change can be traced through the records it touches.
The same graph serves people, applications, analytics and private AI. Assistants answer with sources and within permissions, dashboards draw on linked data, and systems of record receive enriched data back where it is useful.
The investment also compounds. Each new source or use case extends a shared graph instead of starting another integration project, and the graph remains as models and vendors change.
Questions
Manufacturing knowledge, answered.
Do we need to migrate PLM, QMS or ERP data into a new platform?
No. The knowledge graph connects to the existing systems and repositories and enriches data where it lives. Systems of record remain authoritative and keep running their workflows.
What is entity resolution?
The process of deciding when records in different systems or documents refer to the same real thing, such as a part, a supplier or a piece of equipment, and linking them. It combines identifiers, cross-references, attributes and document context, with human review for the matches that matter.
How do permissions work across combined data?
Access rules from each source system are carried into the graph and applied at query time, so the graph never shows more to a user, an application or an agent than the original systems would.
What happens when a source system changes?
The graph monitors its sources and refreshes the affected records, and lineage shows where each fact came from, so changes can be traced. If a system is replaced, its connection changes while the graph's entities, links and history remain.
Where should we start?
With a priority set of questions that cross systems and the sources they depend on. A focused first scope proves the approach on real data, and further sources and use cases extend the same graph.
