The previous part showed the blueprint: search in a targeted and multi-stage way, assess the hits, bind every statement to its source, and steer the procedure algorithmically, while the AI takes over only the cognitive steps. This part starts with the same blueprint and asks what changes when it meets contracts and requirements specifications instead of technical development data. What changes are the form of the data, the core operation, and what is generated in the end. It is precisely in these differences that it shows whether the method is up to the job or was built only for one data set.

From the Graph to Running Text

With the traceability assistant, the data were already available as objects with partly maintained relationships. The art consisted in using existing references and reconstructing missing ones. A contract or a requirements specification is the opposite: a long, linear running text without any machine-readable link. Here there are no relationships to reconstruct, but only relationships to create in the first place.

That is why at the beginning there is a step that did not exist in this form with the graph: the document is first broken down into individual units classified in domain terms. With the contract these are clauses, with the requirements specification, individual requirements. How these units are stored and indexed for an accurate search is described in chapter 2. What is added here is that the generated structure also makes the clean pairwise comparison possible. The form of the data is architecture with running text as well, only it first must be produced before the AI comes into play.

Checking: One Question Against One Document

The first task is checking along a criteria catalog that is adapted according to the type of contract. The analysis runs question by question: find matching clauses, answer the question against them, record the result with a reference to the source clause. The procedure for a single question, from the hybrid search through the evaluation to the source-bound recording, works in the way shown in chapter 2 using the liability example, and is not repeated here.

The only thing that is new is the subject matter: instead of asking which test checks which component, the question is now whether the contract contains a limitation of liability and how it is configured. The checking process is thus closest to the traceability case. The actual extension is brought by the second task.

Comparing: Setting Two Documents Side by Side

Comparing has no counterpart in the traceability case and is the actual innovation. Let us take the question: “Do the liability provisions in the customer contract deviate from our standard terms, and where does a risk arise from this?” What is compared here are not texts, but provisions. For every relevant clause of the one document, the application searches via the same hybrid search for the substantively corresponding clause of the other, even when the two are worded completely differently. For each pair, a narrowly delimited AI step then decides on the relationship between the two provisions: does the one cover the other? Does it tighten it? Does it contradict it? Or is a necessary counter-provision missing on one side?

The findings are ordered by severity, so that the critical conflict does not get lost next to the harmless deviation. In the case of a conflict, the assistant can then go one step further, which does not exist with the traceability assistant, and generate a wording proposal. This is clearly marked as an AI proposal. The assistant does not rewrite the contract but places a checkable variant alongside it. This generating step, too, remains bound to the source clauses and is thereby verifiable.

Requirements Specifications: The Same Mechanism, Different Units

A requirements specification has a different internal structure than a contract. There are must criteria, may criteria, boundary conditions, open points, but it can just as well be divided into nameable units. The same mechanism therefore takes effect, with a different objective.

In preparing a quotation, the question is, for example: “Which must requirements in the requirements specification are not yet sufficiently taken into account in our quotation?” For this, documents are compared against documents, but not for conflict, rather for coverage. The assistant sets every must requirement against its counterpart in the quotation, marks what is open, and orders it by importance. The same way of working, ordered by units, with a different goal.

Where the Responsibility Remains

Because contract and requirements specification analysis is about legal questions and obligations, the limit weighs more heavily than in the engineering case. The assistant is a checking and comparison aid, not legal advice. It structures, accelerates, and substantiates; it finds the relevant clauses, makes deviations and conflicts visible, and proposes wordings. Whether a conflict really is one and how it is resolved is decided by the human.

That is why the seamless source binding is here not only a quality feature, but of central legal significance: it makes it possible to check every finding and every proposal against the original text immediately, instead of trusting it blindly. The assistant takes over the legwork, not the responsibility, a demarcation that is decisive for a legal audience.

The Same Foundation for Two Buildings

The same foundation here carries two completely different buildings: requirements, components, and tests from development on the one side, clauses, deadlines, and liability rules from the contract on the other. Content and specialists could hardly be more different. The following comparison shows what shifts from one case to the other:
 

The last part of this chapter brings the threads together: how do such demonstrators become product functions, and how do they feed into the PROSTEP products and the development processes of our customers?