# 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.