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.
40 lines
2.8 KiB
Markdown
40 lines
2.8 KiB
Markdown
# 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.
|
||
|