The Lastenheft and Pflichtenheft are the backbone of German project contracting: the client writes down what they need, the contractor writes down how they will deliver it, and acceptance happens against the second document. The model works because classic software is deterministic, given input X, the spec can demand output Y, always. AI systems refuse that deal. A model that is right 94% of the time is a success or a lawsuit depending entirely on how the spec was written. This article explains both documents briefly, shows exactly where probabilistic behavior breaks the classic logic, and gives spec patterns that keep the documents' function, clear accountability, without pretending the system is deterministic.
The two documents, briefly explained
For readers outside German-style contracting: the pair splits requirements into a client-owned and a contractor-owned document, and that split is what makes it powerful, when it works.
| Lastenheft (requirements specification) | Pflichtenheft (functional specification) | |
|---|---|---|
| Owner | Client | Contractor (approved by the client) |
| Question answered | What is needed, and why | How it will be delivered, concretely |
| Level of detail | Goals, requirements, constraints | Solution design, features, technical detail |
| Legal role | Basis of the tender / contract scope | Baseline for acceptance (Abnahme) and warranty claims |
| Classic assumption | Requirements are fully knowable up front | Behavior can be specified exactly and verified case by case |
Where probabilistic systems break the classic spec logic
Every one of these breakpoints has produced real project disputes across the industry. They are worth reading as a checklist against your current draft.
- 1No per-case guarantees: "for input X the system returns Y" is unwritable when the same input can legitimately yield different, or occasionally wrong, outputs. Only aggregate statements over defined test sets are honest.
- 2Acceptance becomes measurement: Abnahme against an AI spec is an evaluation run, which means the test data, metrics and procedure must themselves be specified, versioned and agreed, or acceptance is arbitrary.
- 3Requirements shift with the data: what is achievable depends on data quality discovered during the project, so a spec frozen before data exploration is fiction with signatures on it.
- 4Behavior drifts after acceptance: models degrade as the world changes, so a spec that ends at acceptance ignores the phase where most AI risk lives; monitoring and retraining duties belong in the Pflichtenheft.
- 5"Error" needs a definition: a wrong classification within the agreed error rate is not a defect (Mangel) in the warranty sense, and the documents must say so explicitly, or every miss becomes a claim.
Writing acceptance criteria for model behavior
The pattern: deterministic clauses for boundaries, statistical clauses for quality, and a specified evaluation procedure that makes the statistical clauses testable. The table shows classic clauses next to their AI-ready rewrites.
| Classic clause (breaks with AI) | AI-ready clause |
|---|---|
| "The system correctly classifies incoming documents" | "Macro-F1 >= 0.90 on the frozen test set TS-v1.2 (5,000 documents, stratified, jointly approved); evaluation script and seed versioned in the repo" |
| "The chatbot answers customer questions correctly" | "On the agreed 300-question eval set, >= 92% of answers rated correct by the defined rubric and two independent raters; zero answers violating the blocked-topics list (hard criterion)" |
| "The system responds within 2 seconds" | Keep it classic: latency, availability and cost-per-request stay deterministic clauses, p95 latency <= 2s under defined load" |
| "Defects will be remedied within warranty" | "A quality drop below threshold on the agreed monitoring metric for 7 consecutive days triggers the remediation process in section X; misclassifications within the agreed error rate are not defects" |
Iterative spec patterns that keep the documents useful
The goal is not to abandon the Lastenheft/Pflichtenheft discipline but to phase it. These patterns are contract-compatible and used across the industry in various forms.
- 1Two-stage Pflichtenheft: a binding version after the data-exploration phase, not before; the pre-exploration contract covers only the exploration itself, with defined deliverables (data report, feasibility assessment, target metrics proposal).
- 2Corridor targets instead of point targets: the Lastenheft states a minimum acceptable and a target quality level; landing between them triggers a pre-agreed price/scope adjustment instead of a dispute.
- 3Frozen eval sets as contract annexes: test data, metric definitions and evaluation scripts are versioned annexes; changing them requires a change request like any other contract change.
- 4Staged acceptance gates: separate partial acceptance for data pipeline, offline model quality, pilot-phase behavior, and production stability after N weeks, each with its own criteria and its own sign-off.
- 5Living-document clause: a defined cadence (for example quarterly) where both sides review monitoring results against the spec and formally update thresholds, with a named owner on each side.
A filled-in miniature example
An illustrative excerpt from an AI-adapted requirements pair for a fictional invoice-processing project, showing how classic and statistical clauses sit side by side.
| Document | Clause (condensed) | Type |
|---|---|---|
| Lastenheft | Manual invoice data entry (currently about 3 FTE, fictional figure) shall be reduced by at least 60% without increasing posting error rates | Business goal |
| Lastenheft | Invoices that the system cannot process confidently must route to a human queue, never to auto-posting | Hard boundary |
| Pflichtenheft | Field-level extraction accuracy >= 97% on frozen test set TS-A (2,000 invoices, jointly sampled); confidence threshold tuned so that auto-posted invoices reach >= 99.5% field accuracy | Statistical |
| Pflichtenheft | Documents with confidence below threshold are flagged and queued within 5 seconds; no document is auto-posted without passing validation rules V1-V14 | Deterministic |
| Pflichtenheft | Weekly monitoring report on extraction accuracy against a rolling labeled sample; two consecutive weeks below 95% triggers the remediation process | Post-acceptance |
Common mistakes in AI specs
- 1Signing a fixed-price, fixed-spec contract before anyone has looked at the data: the single most common root cause of AI project disputes.
- 2Writing quality targets without specifying the test set and procedure, which makes acceptance a negotiation instead of a measurement.
- 3Putting safety boundaries into the statistical part: what the system must never do belongs in deterministic clauses with zero-tolerance testing.
- 4Ending the Pflichtenheft at acceptance: no monitoring metrics, no drift thresholds, no named operator, the riskiest phase is left unspecified.
- 5Letting the contractor own the test data unilaterally: eval sets must be jointly approved and frozen, or the spec can be gamed from either side.
