Files
breakpilot-compliance/backend-compliance/reference_scenarios/customer_mission_4.md
T
Benjamin Admin b71771e52e feat: Customer Mission #4 — a second, different contract target (no tender-special-logic)
One contract example (Mission #3's public tender) is not enough to safely generalise: it risks
baking tender-shaped assumptions into the later Scope→Journey selector. This mission runs TWO
deliberately different contract sub-types against the same company through the IDENTICAL engine:

  - public tender   (procurement: pentest report, references, support SLA, SBOM)  -> delta 4
  - private OEM spec (Lastenheft: CSMS, functional safety, SUMS, ASPICE)            -> delta 3

The two deltas are completely DISJOINT (no shared missing capability), proving the contracts are
genuinely different — yet there is no per-contract code: assess_transition treats each as a plain
Required set, exactly like a regulation or a certification. Evidence-Relevance is target-relative
even between two contracts (TISAX worth more to the automotive OEM than to the generic tender).

Conclusion: "Contract" as a requirement source is now covered by >=2 diverse cases, so the later
selector can treat any contract uniformly. Synthetic company + synthetic contracts (NO real names).
Non-runtime -> no deploy. 5 tests pass.
2026-06-28 09:42:31 +02:00

40 lines
2.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Customer Mission #4 — zwei verschiedene Verträge, eine Engine (kein Contract-Spezialfall)
_Mission #3 zeigte EINEN Vertrag (öffentliche Ausschreibung) durch dieselbe Engine wie Gesetz/Zertifizierung. Ein Beispiel reicht nicht — sonst backen wir Tender-Annahmen in den späteren Selektor. Hier laufen ZWEI bewusst unterschiedliche Vertragsarten gegen dasselbe Unternehmen. Synthetischer Kunde + synthetische Verträge, keine echten Namen._
## Der Kunde (synthetisch) — EIN Profil
> **ISO 9001 · ISO 27001 · ISO 14001 · TISAX · CE-Prozess · PSIRT** · vernetzte Maschinen · Export EU
## 1. Zwei Vertragsarten — dieselbe Engine `Profil Required = Delta`
| Vertrag | Art | geforderte Fähigkeiten | Delta (fehlt) |
|---|---|---|---|
| **Öffentliche Ausschreibung** | public tender | 10 | **4** |
| **OEM-Lastenheft** | private OEM spec | 11 | **3** |
→ Beide Verträge sind nur ein `Required`-Satz; **es gibt keinen Contract-spezifischen Codepfad**`assess_transition` behandelt sie identisch zu Gesetz und Zertifizierung.
## 2. Verschiedene Verträge → verschiedene Deltas (Beweis: keine Tender-Speziallogik nötig)
- **Nur Ausschreibung:** `penetration_test_evidence`, `reference_project_evidence`, `sbom_creation`, `security_sla_and_support_commitment`
- **Nur OEM-Lastenheft:** `aspice_process_capability`, `functional_safety_evidence`, `software_update_management_system`
- **Beiden gemeinsam:** —
→ Die zwei Verträge fordern **strukturell anderes** (Beschaffungsnachweise vs. Automotive-Engineering: CSMS/funktionale Sicherheit/SUMS/ASPICE). Trotzdem **ein** Mechanismus. Genau das brauchten wir vor dem Selektor: zwei diverse Contract-Ziele, kein Sonderpfad.
## 3. Evidence-Relevanz(Vertrag)
| Zertifizierung (Evidence) | → Ausschreibung | → OEM-Lastenheft |
|---|---|---|
| **ISO27001** | hoch (4) | hoch (4) |
| **TISAX** | hoch (4) | hoch (6) |
| **PSIRT** | mittel (1) | mittel (2) |
| **ISO9001** | keine (0) | keine (0) |
| **ISO14001** | keine (0) | keine (0) |
| **CE** | keine (0) | keine (0) |
**TISAX** zählt gegen den **Automotive-OEM** mehr als gegen die generische Ausschreibung (Prototype Protection, CSMS); **ISO 14001** ist gegen beide **keine**. Bestätigt: **Relevanz ist eine Funktion des Ziels** — auch zwischen zwei Verträgen.
## Befund
> **Zwei strukturell verschiedene Verträge, ein Mechanismus, keine Zeile Contract-Spezialcode.** Damit ist „Contract" als Anforderungsquelle abgesichert (≥2 diverse Fälle): der spätere Scope→Journey-Selektor kann **jeden** Vertrag als reinen `Required`-Satz behandeln, ohne Tender-Speziallogik. Nächste sinnvolle Diversität vor dem Selektor: ein Vertrag, der bewusst auf NICHT-Security-Fähigkeiten zielt (z. B. Umwelt-/Materialnachweise), um auch die zielrelative Evidence-Relevanz über Domänen hinweg zu prüfen.