Benjamin Admin
b71771e52e
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.
2.8 KiB
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.