A revised drawing arrives with a familiar question: what else does this change affect? The answer may involve an assembly, a supplier specification, an inspection instruction and equipment already in service. Those references rarely live in one place. Finding the newest file is only the start; the engineering team still has to establish which records describe the same part and which configuration each record applies to.
Connecting that evidence is a practical knowledge problem. The aim is to give the engineer a defensible starting point for an impact review. AI can help retrieve and explain the evidence, but the organization must first make identity, revision and release status explicit. A plausible summary should never silently become approval to implement a change.
Step 1
Define the change before searching for its impact
Begin with one representative change and the decision it will support. Identify the part or document, the previous revision, the proposed revision and the person responsible for approval. Record the authoritative system for each field. A filename containing a later date does not necessarily mean that a drawing has been released. Equally, a released design revision may not describe every installed asset or every supplier order.
Keep separate identifiers for the underlying item and its revisions. Then capture relationships such as belongs to assembly, specified by document and checked by inspection record. Preserve the distinction between a confirmed relationship and a suggested match. Similar names, copied drawings and reused supplier codes make automatic merging risky. Ambiguous matches should remain visible to a reviewer instead of disappearing into an apparently clean register.
Step 2
Build an evidence packet, not an automatic verdict
For each potentially affected record, show why it was retrieved, where the reference appears and whether its status is known. An impact packet might group related drawings, material requirements and inspection instructions. It should also expose missing records and contradictory references. An empty search result means no relevant record was found in the connected sources; it does not establish that no dependency exists anywhere in the enterprise.
The W3C provenance model provides a useful vocabulary for recording where information came from and how it was produced. In a change review, the practical requirement is simple: an engineer must be able to open the source behind a relationship. Preserve the source revision and extraction history so a later update does not silently rewrite the evidence that supported an earlier decision.
Step 3
Test against completed change reviews
Use previously completed reviews as a starting evaluation set, with permission from the record owners. Compare the proposed evidence packet with what experienced engineers actually checked. Separate missed dependencies, incorrect matches and stale revisions. These errors have different causes and should not be hidden inside one overall accuracy score. Include difficult cases, such as renamed parts, duplicate records and changes that apply only to a particular configuration.
Agree on the handoff before introducing the workflow into daily work. The knowledge layer assembles relevant records; the responsible engineer reviews their applicability; the established change process authorizes action. Track the effort needed to verify the packet, not just the time needed to generate it. A faster answer that takes longer to audit is not necessarily an improvement for the people carrying the decision.
How sDEN approaches it
Connected knowledge. Inspectable evidence.
Apply these principles to a defined collection and a practical decision.
Within this scope
Connect existing systems
sDEN Foundation links documents and enterprise records through a governed knowledge graph. Existing repositories remain in place, while common entities provide a path across their boundaries.
Within this scope
Keep evidence attached
Source-linked metadata and relationships make retrieved context inspectable. Human review can be applied to the fields and connections that a critical engineering decision depends on.
Within this scope
Respect the decision owner
Private AI can explain retrieved context with sources. It supports the engineering review; it does not replace the organization's release authority or its configuration management process.
A useful first delivery
What your team should be able to use
Start with one product family and a limited set of known questions. A useful first result is a reviewable packet with clear coverage, visible uncertainty and links to the authoritative records. Expand to additional systems only when reviewers can distinguish what is confirmed, what is suggested and what is still missing. The deliverable is knowledge that can be checked and reused, rather than another folder of generated summaries.
Questions
Manufacturing knowledge, answered.
Does this replace PLM change management?
No. PLM and existing approval workflows remain authoritative. The knowledge graph helps teams gather and connect the evidence that those workflows need, including records held outside PLM.
Can AI decide which components must change?
It can surface candidate dependencies and explain their sources. Applicability, safety and release decisions remain with qualified engineers working through the established change process.
Sources
