Part 3 ended on an asymmetry: capturing reasoning costs minutes at the moment of decision and is impossible afterward. The natural response to that is a process fix. Write a policy. Mandate the templates. Put a gate in the review checklist.
Those are good things to do going forward, and they do nothing about the history. That's worth being precise about, because teams keep buying a tool, mandating a process, and then discovering that the gap they were trying to close is still there.
The reason is structural. What SE produces isn't a document. It's a graph, and graphs have properties that make them expensive to reconstruct.
Traceability is a walk, not a lookup
The questions that matter in systems engineering are almost never single-hop.
"Which tests cover this stakeholder concern?" isn't a lookup. It's a walk: concern → requirement → function → component → test. "If we change this requirement, what breaks?" is the same walk in reverse, with branches: one requirement may allocate to several functions, each realized by several components, each verified by several tests.
Part 2 established that each of those hops is a role handoff. The product manager to the systems engineer. The systems engineer to the component owner. The component owner to the test engineer. So the graph's edges aren't abstractions: each one is a real moment where one person handed something to another person, and recorded what they meant or didn't.
Three properties of this structure matter.
The depth is variable. A requirement decomposes to sub-requirements, which decompose further. You don't know in advance how many hops separate a concern from a test. That's a traversal of unknown depth, not a join across a known number of tables.
The interesting queries are about paths, not nodes. "Show me every requirement with no verification path to a test" is a question about the absence of a path. So is most of what an assessor asks. You can't answer it by looking at any single record.
Some nodes were never documents. This is the one that breaks retrofits. A rejected alternative, the cold plate that lost to passive cooling in Part 1, is a node in the reasoning graph that has no corresponding artifact anywhere in the file system, because it was never built, never drawn, and never specified. You cannot infer it from the artifacts, because its defining property is that it produced none.
What a retrofit can and cannot rebuild
Missing edges between surviving nodes can sometimes be inferred. If the requirement and the test both exist, someone can read both and decide they're related. This is slow and error-prone, and the ASPICE model makes the relevant point directly: the existence of a link doesn't establish that the linked information is consistent. But it's possible, and it's most of what a retrofit project actually delivers.
Missing nodes cannot be inferred at all. No amount of reading the artifacts recovers a decision that produced no artifact. This maps exactly onto the distinction Gotel and Finkelstein drew in 1994 between traceability before the requirements specification exists and traceability after it. It also maps onto their finding that most of the problems attributed to poor traceability come from the missing pre-specification kind [1].
A process fix changes the rate at which new nodes and edges get recorded. It cannot retroactively create nodes.
Time is the second dimension
There's a complication Part 3 introduced that the diagram above doesn't show. Every lap produces new versions of the same things.
The thermal requirement at B-sample isn't the same node as the thermal requirement at C-sample, but it isn't a different requirement either. The component that implemented version 1 may not implement version 2. A test that verified version 1 may now be verifying against a superseded assumption without anyone noticing.
So the real structure needs edges in two directions: across levels, which is traceability as usually drawn, and across versions, which is history. The audit question is almost always a combination of the two: was this design satisfying this requirement at the time it was baselined? That's a path query with a time filter on it.
This is also where change propagation, from Part 3, becomes tractable rather than heroic. Clarkson, Simons and Eckert showed that propagation through a product can be predicted when the connections between components are known [2]. The capability depends entirely on having the connections in a form you can traverse. A team that recorded them is running a query. A team that didn't is running an investigation.
Why the storage shape matters
This is where the argument gets practical for anyone building or buying tooling.
Most requirements tools store artifacts in tables and links as rows in a join table. That works for one hop. For a traversal of unknown depth it means recursive joins, and both the query and the performance get awkward in a way that shows up as "we generate the traceability matrix overnight."
The more current temptation is to point a retrieval-augmented language model at the document corpus and ask it questions. That works better than people expect for single-document lookup, and worse than people expect for anything that requires assembling a chain across documents. The failure mode is specific: vector retrieval returns the passages most similar to the question, and the intermediate steps of a traceability chain are often not textually similar to the question at all. The function sitting between a requirement and a component may share no vocabulary with either.
This is a known limitation, not a vendor talking point. Microsoft Research built GraphRAG because conventional retrieval fails on questions about a corpus as a whole rather than about any one passage, and their fix was to build a graph index over the source material [3]. They evaluated it on summarizing text corpora, not on engineering traceability. But traceability is the same shape of problem: the answer is a structure spanning many documents, not a passage inside a single document.
If your questions are path questions, then store the paths.
Complexity you should actually be wary of
A graph earns its complexity for multi-hop traceability, provenance, and audit queries. It earns nothing for a flat list of requirements that never gets traversed. A team with forty requirements and one subsystem should use a spreadsheet, but still capture the questions, options and criteria behind each decision. The structure can come later, but the reasoning can't.
Version history on a graph is genuinely hard. Getting branching, merging and baselines right on a connected structure is a real engineering problem. It's part of what we're building at SysenAI. If you're building traceability tooling in-house, borrow an established model for history rather than inventing one. If you're buying, ask how the tool baselines the links, not just the documents. Either way, it's a reason to be careful with the structure, not a reason to avoid it.
Where this leaves the series
Four posts in, the diagnosis is complete:
- The work at the top of the V is a graph of decisions and links across role handoffs.
- Rationale is a coproduct of the work, capturable only while it happens.
- Every subsequent lap needs what the previous laps recorded.
- Retrofitting rebuilds edges between surviving artifacts and cannot rebuild nodes that never were artifacts.
Which brings back the question in the title of Part 1. If this is all fairly well understood, and most of it has been in the literature for thirty years or more, why does systems engineering still land at the end of the roadmap?
That's Part 5, and the answer has more to do with how work gets forced onto a roadmap than with anyone failing to understand the V.
Srivardhan Chandrapati is the founder of SysenAI. He spent about twelve years in systems engineering and functional safety across advanced mobility and energy, at Cummins, Rivian, EnerDel, Fisker and BorgWarner, and now builds from Bengaluru.
References
- Gotel, O. C. Z. & Finkelstein, A. C. W. (1994). "An Analysis of the Requirements Traceability Problem." Proceedings of the First IEEE International Conference on Requirements Engineering, Colorado Springs, CO, pp. 94–101. DOI: 10.1109/ICRE.1994.292398
- Clarkson, P. J., Simons, C. & Eckert, C. (2004). "Predicting Change Propagation in Complex Design." Journal of Mechanical Design, 126(5), pp. 788–797. DOI: 10.1115/1.1765117
- Edge, D., Trinh, H., Cheng, N., Bradley, J., Chao, A., Mody, A., Truitt, S. & Larson, J. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130. arxiv.org/abs/2404.16130
The ASPICE point on link consistency is from the Automotive SPICE Process Assessment Model v4.0 (VDA QMC), cited in full in Part 1.