A Demonstrator Proves Little
The previous chapters have laid the foundations with a methodology (AIND), language, and runtime for controllable AI processes (APL/PAW). The basic idea is that the AI is embedded in a structured, verifiable process instead of being loosely attached to an application.
This part and the following ones show what emerges from this in practice. A single AI demonstrator is quickly built and may impress at first glance, but it proves little. With every impressive demo, one should check whether it runs only on a narrowly tailored data set, whether one sees only the successful run and not the error cases, whether the prompt is tuned to precisely this one application example, and whether there are experts in the background who make corrections. Anyone who receives no as the answer four times has more than an effect; they have a capability.
That is because it only becomes interesting when the same approach is deployable in very different situations: in dealing with engineering data, in legal or requirements-related documents, in designed presentations, or in extensive product documentation. Then it is no longer about a single demo effect, but about a pattern.
Four Very Different Classes of Task
The traceability assistant shows the described logic in engineering data. Requirements, components, tests, and test results stand in complex relationships with one another. Here it is about finding, assessing, and revealing connections, not merely about a plausible answer: which requirement relates to which test? Which component is affected? Which source supports the statement? How this works in detail is explored in depth by the next part.
Contract and requirements specification analysis moves in a different, similarly demanding world. A document is analyzed along with a framing question or a check catalog, not merely summarized; relevant passages are searched for, assessed, and condensed into a traceable answer. In a further mode, two documents or versions can be compared for correspondences, differences, and conflicts. We look at this case more closely in a part of its own as well.
The presentation generator opens a third dimension. Here AI does not merely produce text, it works on a designed artifact: a presentation. It is about content, structure, layout, slide master, rendering, and correction. The agent can provide support at the content level, make suggestions in the slide editor, and check the visual result.
This demonstrator thus shows that the approach is not limited to analysis but can also generate productive artifacts.
The product documentation assistant stands for a broad everyday class. Users ask questions about extensive technical documentation without having to know its structure. Upstream of this is an import and preparation pipeline that transfers different document types into a shared knowledge base, which supplies the answering process with information: relevant content is searched for, assessed, loaded, and condensed into an answer with reference to the sources used. The plausibility of the language model is delimited by knowledge from prepared data holdings.
These four applications are not a random gallery but deliberately span the hard axes: structured versus unstructured data, analysis versus generation, individual document versus cross-system knowledge base. What works in these extreme corners will, with high probability, also work in between:
| Demonstrator | Task type & data (axis) | Where the AI decides | What remains classical / deterministic |
|---|---|---|---|
| Traceability assistant | Structured engineering data, finding relationships | Assessing relevance, interpreting connections | Search, linking, source-bound recording |
| Contract & requirements specification analysis | Checking & comparing unstructured documents | Selecting passages, answering questions | Criteria run, routing, evidence binding |
| Presentation generator | Generated, designed artifact | Content, structure, phrasing, visual checking | Slide master, layout, rendering |
| Documentation assistant | Broad, mixed knowledge base, answering questions | Assessing relevance, formulating the answer | Import pipeline, search, source binding |
The Common Pattern of All Tasks
As different as these tasks are, they all follow the same basic pattern: the process is not left to the language model but described in such a way that it can be reliably executed and observed. Classical logic is deployed where stability, repeatability, routing, storage, formatting, or rendering count; AI where language, meaning, assessment, selection, phrasing, or visual interpretation are needed. Instead of speculating, the system searches, assesses, and provides evidence in a structured way.
Therein lies the difference between many AI demos: the agent works with the data, tools, and intermediate results of the application, and its actions become part of a controllable procedure.
From Demonstrator to Product Capability
The applications deliberately do not all have the same degree of maturity. Some are demonstrators, some development states, some product building blocks. It is not about showing finished products, but about demonstrating capabilities that are not limited to one domain. That is precisely the argument: if the same structures appear in four very different contexts, what counts is not the individual application but the repeatability; the domain changes, but the pattern remains. And this repeatability paves the way into the product: what counts is not the prettier demo, but the stabilized, integrated, maintainable, and verifiable capability, for which methodology, process language, and runtime are required.
The following parts explore two of these cases in depth: on the one hand traceability, i.e. how an agent finds engineering connections, assesses them, and makes them demonstrable, and on the other hand the analysis of contracts and requirements specifications, i.e. how a language model becomes a traceable checking and comparison assistant. At the end stands the question that is decisive for PROSTEP customers: how do such demonstrators become robust product functions, and how do they feed into the systems with which companies steer their development processes today?
