Of the four demonstrators presented, this part takes a closer look at one of them: the assistant for traceability, which enables traceability across requirements, components, tests, and test results. Using a concrete case, it shows how a question in natural language becomes a demonstrable answer, and in doing so it describes at the same time the methodological core on which the further applications of this chapter build.
The Question and the Data Situation
A public data set from the development of the Mars rover serves as an example, a vehicle with many subsystems and documented requirements, components, tests, and test results. An engineer asks: “The rover reported a fault in locomotion during a trial run. What was the cause, and which subsystems bear the responsibility?” The question sounds simple, but the data situation is not. The answer is not contained in any single document but must be gathered from several sources.
What takes a long time by hand becomes a guided, repeatable search process, not because the assistant was cleverer, but because it works more systematically. The procedure has three phases: planning, executing, answering.
Phase 1: Planning the Right Sequence
The first step is expressly not to generate an answer. The assistant first looks at the relationship model of the data basis, which at its core is a graph of typed objects and links: which kinds of information are there, e.g. requirements, components, tests, test results, and which links are there between them - in the sense of checks, belongs to, or has failed at? From this a search plan emerges that specifies which data must be drawn on in which order to be able to answer the question demonstrably later.
The remarkable thing about this is that none of it is the answer. The assistant does not yet have any knowledge about the actual fault, but only a plan for how it would find it. And this plan can be inspected before a single system is queried, a property that only the firmly described procedure makes possible. This means that, before the first search, it is clear which trail the assistant will follow in its work.
Phase 2: Executing the Combined Search
Where the data already contains fixed links, as with a requirement that is directly connected with a test, the assistant follows these references. Such direct references do exist in industrial IT systems, but they are rarely complete.
The real value arises where they are missing. Then, from the respective plan step, the model forms several targeted search queries with a different emphasis of terms. These run through the same hybrid search of word-based and meaning-based paths with a consolidated ranking, as described in chapter 2. If the hit list remains too fuzzy, a further, narrowly delimited AI step checks it against the original question and sorts out what does not fit.
What remains decisive is the division of roles: the model answers nothing. It formulates search queries, assesses relevance, and selects. Every sub-task remains small and verifiable, and the repetition, too, remains part of the described procedure: whether the search continues follows from the checked intermediate results and not from a free decision of the language model.
Phase 3: Preparing the Chain of Evidence
Before the actual answer comes a last, inconspicuous but central step: the preparation of the material. It would be an obvious move, and a wrong one, to hand the raw hit list to the language model, because then it would have to reconstruct the connections in the text itself: which component belongs to which requirement, which test checks which component, and so on. That is the kind of task in which language models make inconspicuous errors.
Instead, the hit set is first brought into a clear structure: requirements are at the top, the associated components below them, and below those the matching tests and test results. The structure of the presentation thereby already shows the domain connection, so that the model does not have to guess it.
In addition, every finding carries a reference to its source in the original system. These references appear unchanged in the finished answer, so that the engineers can jump back from every single statement to the data source. Only on this ordered basis does the model formulate the answer, by casting the findings into a readable explanation without adding new content. The answer is thereby not only readable, but at any time verifiable.
The Honest Limit
Nevertheless, an honest look at the limits is worthwhile, and the first one is a strength. Where fixed links at database level are missing, the assistant does not give up. Precisely there, the content-based search establishes the connection, not with the certainty of a maintained reference, but with relatively high reliability and with a corresponding marking: the connection was not present as a fixed one but was reconstructed. The engineers thereby not only see that a gap exists but get a substantiated proposal for how to close it. That is significantly more valuable than merely showing that something is missing. This reconstruction of missing relationships via the graph is the actual strength of the traceability assistant, a capability that only takes effect where a relationship structure of objects and references exists at all.
The actual limit lies behind that: where the data yield nothing related in terms of content, the assistant invents nothing but reports the gap. Reconstructed connections remain proposals, marked as such, and are no substitute for a checked reference before a human confirms them. The assistant therefore does not heal the data in secret, but closes gaps visibly, with evidence, and at the same time makes the quality of the existing technical data undeniably visible. Typical AI errors such as incorrect linking via similar identifiers or lost sources are thereby not made impossible but systematically made harder: every statement must be carried by structure and source.
With this, the shared methodological core is described: planning, combined search, and source-bound preparation, with a clear division of roles between the fixed procedure and the selectively deployed AI. The next part of this chapter transfers it into a quite different area, the analysis of contracts and requirements specifications. It is precisely the contrast that is the strongest evidence that the method can be generalized.
