Four weeks before a new car starts rolling off the line, someone has to change a signal. A camera and a display stop understanding each other after the last software update. The fix is small. The problem is that no one can tell you what else that signal touches, not the lead engineer, not the architect, not the person who owns the change. The car is too big to fit in one head.
Change impact analysis is the work of tracing everything a single change to a signal, requirement, or test can affect, so teams re-check the right things before it ships and nothing critical slips through. In a modern mechatronic system, that map no longer fits in one person's head.
So the organization does the only thing it can. It convenes a task force. A board-level lead pulls in the managers, the managers pull in their people, assistants build lists of who might be affected, and those people are called into rooms where the change is explained one more time so each can go back and check: does this break anything on my side? There's no time to re-test the whole vehicle, which is hundreds of thousands of kilometers the calendar doesn't have. So the company runs a human phone-tree and hopes it reached everyone.
It usually doesn't. I've watched a program discover, far too late, that a part changed for one market was tied to software nobody in the room owned. It was the kind of dependency that lives in one engineer's memory or one line of supplier code, and it surfaces as a recall. The phone-tree isn't stupid; it's the rational response to a system whose connections outran anyone's ability to hold them. That's the real problem worth solving, and most people get the shape of the answer wrong.
Widen the set of "what's affected" and two things move in opposite directions: the size of the list explodes, while its value to a decision peaks in the middle and then collapses.
Direct impact is easy, and that ease is the trap. Ask "if I change this signal, who reads it?" and any competent architecture team can already tell you. They keep sender-receiver lists, the immediate consumers know each other, and the tooling draws that first hop fine. It demos beautifully: point at a requirement, the affected boxes light up, everyone nods. But a team that couldn't answer that couldn't ship a car at all. The direct hop is table stakes: get it wrong and you look foolish, get it right and you've impressed no one. Selling it back to them as a product is selling them their own competence in a nicer wrapper.
The complete answer is useless. If the direct list looks too small, the reflex is to give the whole one, everything the change could conceivably reach. But in a modern vehicle everything reaches everything. Route a signal through the gateway and the gateway touches the whole car, so now the impact set is the vehicle. Technically correct, operationally worthless. A complete list is good for exactly one thing: legal cover. Nobody makes a decision with it.
The middle is the hard part, and the whole game. Between the handful of things that will obviously break and the thousands that theoretically could, there's a much shorter list of things that probably will, the ones a good engineer would want to see, and would feel stupid for having missed. That list is a judgment under uncertainty. It's exactly what the task force was assembling by hand, and exactly what no static diagram or reachability query has ever produced well.
Before any of that, the connections have to exist as data. Not prose in a spec that was last accurate two model years ago, not a diagram in someone's shared drive, but a graph you can walk: this signal is produced by that function, consumed by these modules, carried on that bus, verified by these tests, constrained by that hazard. Traceability isn't a compliance chore here. It's the floor the whole analysis stands on.
And it has to respect direction. Impact flows one way. A change to what software emits forces everyone downstream to reckon with it; a change to what it receives usually doesn't ripple back. Walk the graph without honoring that and you're back to lighting up the whole vehicle.
Why this is the wedge. Most "digital thread" and "semantic layer" views show you that two things are linked, not which way the consequence runs, which is the only thing you needed to know. Undirected, the impact set is the whole graph and every list is noise. Comparing the text of two requirements and calling it impact analysis is the same sleight of hand. Similarity is cheap. Consequence is expensive, and worth paying for.
Here's the claim I'll defend: the middle list is the first version of this problem that a language model, pointed at a real engineering graph, is genuinely good at. Not because it's clever, but because of what the job is. It rewards reading everything, every requirement, every test case, every note, and weighing where a change is likely to bite. Humans are slow and selective at that; a model is fast and tireless. It can search the same idea ten ways, notice that a signal it's about to touch is mentioned constantly around a safety-rated function, and treat that as a reason to look harder.
But breadth only helps if an engineer can trust the output in seconds. The answer can't be a confident essay. It has to be a set of falsifiable claims: this will break that, because the change reaches it along this specific path. Each one carries its own trace. The engineer doesn't have to believe the machine, they follow the path and, at a glance, keep it or kill it.
Here's what one of those fifty actually looks like: a claim, the trace that proves it, and a verdict an engineer reaches in seconds.
Fifty hypotheses, handed to the people who own those parts, come back as "thirteen are real, the rest is noise." That's the phone-tree's job done in an afternoon, and done as evidence rather than rumor. The value isn't that the agent is right. It's that it's checkable.
Honesty matters as much as capability. There are effects the graph can't compute, and pretending otherwise is how you lose an engineer's trust for good. Make a message longer and you might congest a bus; overload a bus and a battery reading arrives late, or a cheap controller falls over, but you won't calculate that from a dependency graph. That needs simulation and a different kind of data. Raise it as a flag to check, never a number you invented. The same discipline binds the model's own instincts: it has absorbed enough engineering to have opinions, useful for deciding where to look and dangerous the moment they're stated as fact about this system. Every claim it makes about what connects to what has to come from the actual graph, with the path attached, not from the fact that wheel-speed signals tend to be well documented. An expert tool is defined by where it admits the map ends.
Put it together and the output isn't a graph at all. It's three lists:
Will change: a checklist. Re-run these tests, re-open these requirements, look at these safety cases first.
Probably changes: ranked hypotheses, each with the path that would prove or disprove it.
Safe to leave alone: quietly the most valuable. The things you've checked and can set aside, with the trail to defend it.
An engineer four weeks from launch doesn't only need to know what to worry about. They need permission to not re-test everything, and the trail to defend that decision when someone asks why.
None of this replaces the expert. It aims the expert. It turns "everything could break, good luck" into "here are the thirteen things worth your afternoon, and here's why each one is on the list." That's a smaller promise than the industry usually makes about AI and engineering data, and I think that's exactly why it's the right one. The teams that win here won't be the ones with the biggest knowledge graph, that's just the prerequisite. They'll be the ones honest enough to say where the analysis stops, and disciplined enough to turn fear into a list a human can actually work through.
This is the discipline behind SPREAD's approach to change impact analysis: a directional, traceable engineering graph that turns fear into a short, checkable list. See how it works in Requirements Manager, or get started with SPREAD.
Change impact analysis is the work of tracing everything a single change to a signal, requirement, or test can affect, so teams re-check the right things before it ships and nothing critical slips through. In a complex system, the useful answer isn't the full list of everything reachable, it's the short, risk-based middle list of what will probably break.
In a modern mechatronic system almost everything reaches everything, so the complete impact set is effectively the whole vehicle. The connections also outgrew what any one engineer can hold in their head, which is why teams fall back on manual task forces and hand-built lists of who might be affected.
A language model pointed at a real engineering graph is well suited to the risk-based middle list, because the job rewards reading everything and weighing where a change is likely to bite. It only works under discipline: every claim has to be a falsifiable hypothesis with its trace attached, and the tool has to admit where the graph ends, flagging effects like bus congestion or timing that need simulation rather than inventing a number.
You need the connections to exist as a directional, walkable graph, not prose in a spec or a diagram on a shared drive. Each signal should trace to the function that produces it, the modules that consume it, the bus that carries it, the tests that verify it, and the hazards that constrain it, and impact has to flow one way so the analysis doesn't light up the whole system.