Impact analysis: what else does this change touch?
Before an ECO is worth approving, somebody has to know what it breaks. Manufacturing PLM answers that by traversing the relationship graph — deterministically, with the path shown — and the AI cites that answer rather than inventing its own.
What it is, and what it is not
Impact analysis is a traversal of typed relationships outward from a set of changed objects, returning everything downstream that a person needs to consider before approving. It is a query and a set of rules. There is no model in this path.
That is a deliberate architectural choice rather than caution about AI. An impact set is the input to an approval decision, and an approval decision has to be reproducible: the same question asked twice must return the same bytes, or the answer cannot be cited, diffed, or defended in an audit.
The Change Agent calls this service. It does not replace it. What the agent adds is framing — which of the forty affected objects actually matter, who should review them, what the draft ECR should say — on top of an impact set that a person can independently re-run.
The mechanism: the path is the point
The traversal starts from the changed objects and walks outward along typed edges: parent assemblies, documents that specify the part, requirements it verifies, approved manufacturer entries, open changes already touching it, and published ERP records.
Each result carries the path by which it was reached, not just the fact that it was reached. “Also affected: 410-0233” is close to useless. “410-0233, because it is a parent of 330-1140 at depth two, and it is released” is something an engineer can agree or disagree with.
Depth is bounded and configurable, and the boundary is shown rather than hidden. An analysis that silently stopped at depth three would report a smaller impact than the truth, which is the one error mode nobody catches until later.
Everything is resolved before it is walked. The traversal runs over the effective structure under stated conditions, so a superseded line does not appear as impact and a line effective only from next quarter is labelled as such.
The failure it prevents
A connector changes. The part is used in four assemblies, two of which are shipping, one of which is in a customer qualification, and one of which is a service kit nobody has thought about in two years.
The engineer knows about the two shipping assemblies. The qualification is remembered by the programme manager, who is not on the review. The service kit is remembered by nobody. The ECO is approved in a week and the service kit is discovered in nine months, by a customer.
Impact analysis does not require anybody to remember. It requires the relationships to have been recorded, which is what the rest of the product is for. And because it is deterministic, the impact set attached to the approved change is evidence of what was known at the time — which is precisely the question asked afterwards.
How it meets the rest of the product
The traversal runs over resolved structures, so where-used, compare and impact all agree by construction rather than by coincidence. Mass change consumes the same impact set, so “change every affected line” operates on exactly the set that was reviewed.
Results are permission-filtered on the way out. An impact set never reveals the existence of a restricted programme through a count, for the same reason search does not.
The Digital Thread Agent uses this service to answer the cross-domain form of the question — “if we do this, what else changes?” — and every element of its answer carries a citation naming the object and the revision it read. Because the underlying query is deterministic, a reviewer can re-run it and get the same set back.
How it meets your ERP
Impact does not stop at the boundary of Manufacturing PLM. Objects already published to the ERP are marked as such in the impact set, because a change to a part that has never left engineering is a very different proposition from a change to one with open purchase orders against it.
The ERP-mastered context that has been read back — on-hand quantity, lead time, open order state — is shown alongside each affected item so the reviewer can see the operational consequence rather than only the engineering one. A cheap change with sixteen weeks of stock on the shelf is not a cheap change.
What Manufacturing PLM does not do is compute the disposition. Use-as-is, rework, scrap and return-to-vendor decisions belong to people, informed by ERP inventory data; the impact set tells them what to decide about.
Where the boundary is
Impact analysis reports what is related. It does not judge severity, and it does not approve anything. Ranking forty affected objects by which three matter is agent work, offered as a recommendation with citations, and it sits on top of the deterministic set rather than replacing it.
It is also bounded by what has been recorded. A relationship that exists only in a drawing note is not in the graph, and no amount of traversal will find it — which is an argument for capturing requirements and specifications as objects, not an argument that the analysis is unreliable.
Facts
| Determinism | Same question twice returns identical bytes |
| AI in this path | None — agents call it, they do not replace it |
| Output | Affected object, relationship path, depth, lifecycle state |
| Traversal | Runs over resolved structures, not stored ones |
| Depth | Bounded and configurable; the boundary is shown |
| Permissions | Filtered on the way out; no existence leak via counts |
| ERP | Published objects flagged, with on-hand and open orders |
| Reuse | Mass change operates on the reviewed set |
Frequently asked
Is impact analysis AI-powered?
No, and deliberately so. It is a query over typed relationships, because an approval decision has to be reproducible. The Change Agent calls this service and adds judgement on top — which of the affected objects matter, who should review — but the underlying set is computed without a model.
How deep does the traversal go?
As deep as you configure, and the boundary is reported rather than hidden. An analysis that quietly stopped at depth three would understate the impact, which is the failure mode nobody notices until the consequences arrive. If the walk was truncated, the result says so.
Does it show why something is affected?
Yes — every result carries the relationship path by which it was reached, its depth, and its lifecycle state. A bare list of part numbers is not reviewable. A path an engineer can read and disagree with is the difference between evidence and a wall of identifiers.
Can it see items already sent to the ERP?
Yes. Objects published to the ERP are flagged in the impact set, along with the context read back from it — on-hand quantity, lead time, open order state. A change to a part with sixteen weeks of stock behind it is a different decision from one that never left engineering.
What about parts affected through documents or requirements?
They are in the graph and they are traversed. Documents that specify a part, requirements it verifies, approved manufacturer entries and open changes already touching it all appear, because the failure this exists to prevent is usually a relationship somebody remembered rather than one the system recorded.
Does the impact set feed mass change?
Yes, and that is the point of computing it once. The bulk operation runs against exactly the set that was reviewed and approved, rather than against a re-query that might return something slightly different because the data moved between the review and the execution.
Can I attach the analysis to the change record?
It is attached automatically. The impact set computed at draft time is stored with the change, so the record shows what was known when the decision was made. Because the query is deterministic, anyone can re-run it later and confirm the stored set was not edited.