feat: Customer Mission #3 — one profile, three target TYPES (Requirements Verification proof)

Proves the next thing after Mission #2: the pipeline is target-type-agnostic. One company
profile runs against THREE deliberately different target types through the identical engine
(assess_transition):
  - CRA          (Regulation)  -> delta 8
  - TISAX        (Certification) -> delta 3
  - public tender (Contract, synthetic) -> delta 4

A regulation, a certification and a contract all reduce to required capabilities; Profile −
Required = Delta does not care which. That is the Requirements Verification Platform: the
requirement SOURCE is swappable, the pipeline stays.

Makes Evidence-Relevance(Target) concrete: the same evidence is worth a different amount per
target. PSIRT = hoch(CRA)/keine(TISAX)/mittel(tender); ISO 14001 = keine against all three
security targets but would be hoch against an environmental target. Relevance is a function
of the target, not an attribute of the evidence.

Also: cross-target-TYPE convergence (8 capabilities satisfy >=2 of the 3 target types) — the
leverage one level above law-convergence.

Synthetic company + synthetic tender (NO real names). Non-runtime -> no deploy. 5 tests pass.

backend-compliance/reference_scenarios/customer_mission_3.md

@@ -0,0 +1,40 @@
+# Customer Mission #3 — EIN Profil, DREI Zieltypen (der Requirements-Verification-Beweis)
+
+_Mission #2 bewies: der Start ist ein Company Capability Profile, kein Zertifikat. Mission #3 beweist das Nächste: dieselbe Pipeline ist ZIELTYP-AGNOSTISCH. Ein Gesetz, eine Zertifizierung und ein Vertrag reduzieren sich alle auf geforderte Fähigkeiten. Synthetischer Kunde + synthetische Ausschreibung, keine echten Namen._
+
+## Der Kunde (synthetisch) — EIN Profil
+> **ISO 9001 · ISO 27001 · ISO 14001 · TISAX · CE-Prozess · PSIRT** · vernetzte Maschinen · Export EU
+
+## 1. Drei Zieltypen — dieselbe Engine `Profil − Required = Delta`
+
+| Ziel | Zieltyp | geforderte Fähigkeiten | Delta (fehlt) |
+|---|---|---|---|
+| **CRA** | Regulation | 17 | **8** |
+| **TISAX** | Certification | 13 | **3** |
+| **Öffentliche Ausschreibung** | Contract | 11 | **4** |
+
+→ Drei **völlig unterschiedliche Zielarten** (Gesetz · Zertifizierung · Vertrag) liefen durch **eine** Engine ohne Sonderfall. Der Vertrag (Ausschreibung) ist nur ein weiterer `Required`-Satz — genau das ist die **Requirements Verification Platform** ([[strategy-requirements-intelligence]]): die Anforderungs-QUELLE ist austauschbar, die Pipeline bleibt.
+
+## 2. Konvergenz über Zieltypen hinweg
+- **8 Fähigkeiten erfüllen ≥2 der drei Zielarten gleichzeitig** — eine Maßnahme zahlt auf Gesetz UND Zertifizierung UND/ODER Vertrag ein.
+- Beispiele (Fähigkeit → Ziele): `incident_management`→{CRA,TISAX,Öffentliche Ausschreibung}; `technical_vulnerability_management`→{CRA,Öffentliche Ausschreibung}; `access_control_and_authentication`→{CRA,TISAX,Öffentliche Ausschreibung}; `sbom_creation`→{CRA,Öffentliche Ausschreibung}
+- Das ist der Hebel *eine Ebene höher* als Mission #1: dort konvergierten **Gesetze** (CRA+MaschinenVO), hier konvergieren **ZielTYPEN**.
+
+## 3. Evidence-Relevanz(Ziel) — dieselbe Zertifizierung, anderer Wert je Ziel
+> Nicht „Evidence vorhanden", sondern **Evidence-Relevanz(Ziel)**: jede Zertifizierung wird **relativ zum Ziel** bewertet. Das erklärt, warum dieselbe Capability in zwei Beratungen unterschiedlich priorisiert wird.
+
+| Zertifizierung (Evidence) | → CRA | → TISAX | → Ausschreibung |
+|---|---|---|---|
+| **ISO27001** | hoch (5) | hoch (5) | hoch (4) |
+| **TISAX** | mittel (2) | hoch (8) | hoch (5) |
+| **PSIRT** | hoch (3) | keine (0) | mittel (1) |
+| **ISO9001** | mittel (1) | keine (0) | keine (0) |
+| **ISO14001** | keine (0) | keine (0) | keine (0) |
+| **CE** | mittel (1) | keine (0) | keine (0) |
+
+→ **PSIRT** ist gegen die **CRA hoch**, gegen **TISAX keine**, gegen die **Ausschreibung mittel** — dieselbe Evidence, drei verschiedene Werte. **ISO 14001** ist gegen alle drei (Security/Qualität) **keine** — *aber* gegen ein **Umwelt-Ziel** (Batterieverordnung/Umweltauflagen) wäre sie **hoch**. Genau deshalb gilt: **Relevanz ist eine Funktion des Ziels, kein Attribut der Evidence.**
+
+## Befund
+
+> **Dieselbe Pipeline trägt Gesetz, Zertifizierung UND Vertrag.** Damit ist bewiesen, dass die Architektur nicht „Compliance" macht, sondern **Anforderungen verifiziert** — die Quelle (Regulation/Certification/Contract) ist nur ein `Required`-Satz, der Rest ist `Profil − Required = Delta`. Zwei durable Folgerungen: (1) **Evidence-Relevanz ist zielrelativ** (gehört künftig als `relevance(evidence, target)` modelliert, nicht als „vorhanden/fehlt"); (2) Konvergenz existiert nicht nur zwischen Gesetzen, sondern zwischen **Zielarten** — der höchste Hebel überhaupt.
+