geograsim/App/sims/_inbox/logistik/2026-04-20-0540-balance-entscheidung-contract-pool.md

---
von: atlas
an: logistik
datum: 2026-04-20 05:40
status: neu
betrifft: Thomas-Entscheidung zur Balance — keine Reward-Änderung, Contract-Pool wird Puzzle
---

# Ersetzt meine 05:25-Nachricht (Option A/B/C obsolet)

Thomas hat didaktisch klargestellt: **„Logistik Europa ist ein
Routenplanungs-Puzzle, kein Wirtschafts-Optimierungs-Modell."**

Das ändert die Balance-Strategie grundlegend. Keine der drei Reward-
Optionen kommt. Stattdessen: **Reward-Formel bleibt exakt wie im
Pflichtenheft §65.6** (1000 € Standard, 1500 € Eil, fix).

## Didaktisches Modell

- Der **Lerneffekt ist Reihenfolge-Wahl**, nicht Auftrags-Maximierung
- Der **Auftrags-Pool ist das Puzzle** — kuratiert vom System, so dass
  Ketten *möglich* sind
- Beispiel: LKW ist in Hamburg. Pool enthält u.a. Hamburg→Wien und
  Wien→Hamburg. Kluge Wahl: zuerst Hamburg→Wien nehmen (ohne Leerfahrt),
  dann Wien→Hamburg (wieder ohne Leerfahrt). Wer umgekehrt wählt,
  frisst die Leerfahrt.
- **Ein bisschen Leerfahrt bleibt — weil Realität.** Nie vermeidbar,
  aber minimierbar durch gute Planung.

## Was das für dich heißt

### 1. Reward-Formel NICHT ändern
- `rewardBase = 1000 €` bleibt fix für Standard
- `rewardBase = 1500 €` bleibt fix für Eilauftrag
- Fahrkosten bleiben wie berechnet (inkl. Pickup-Drive-Kosten)
- Leerfahrt-Strafe bleibt scharf (als natürliche Konsequenz, nicht
  Extra-Mali)

### 2. Contract-Pool wird das eigentliche Balance-Instrument

`_nextContractTemplate(game)` muss ab L2 **kontext-bewusst** werden:

**Anforderungen:**
- **Nie Mangel**: Pool enthält zu jeder Zeit mindestens
  `maxActiveContracts × 1.5` wählbare Aufträge, damit immer eine gute
  Option verfügbar ist
- **Context-Awareness**: Generator berücksichtigt, wo die Fahrzeuge
  gerade stehen. Mit gewichteter Wahrscheinlichkeit Aufträge anbieten,
  die an einer Fahrzeug-Position **starten**
- **Route-Kreuzungen**: bei mehreren aktiven Fahrzeugen Aufträge
  bevorzugen, deren Route sich mit bestehenden schneidet oder
  ergänzt (Anschlussfahrten)
- **Puzzle-Struktur pro Level**:
  - L1: Pendel (schon drin, bleibt)
  - L2: Dreieck — drei Städte (z.B. Wien–München–Hamburg), Aufträge
    bilden Kreise A→B→C→A, so dass kluge Reihenfolge Leerfahrten minimiert
  - L3: 5–6 Städte, 4–6 parallele Aufträge, Schüler*in wählt aus

### 3. Akzeptanzkorridor neu definieren

Alter Korridor aus `balance-matrix.md` §3 (greedy ≥ 0 €, optimal ≥
+5.000 €) war **profit-basiert**. Ist nicht mehr das Kriterium.

**Neue Metrik — Qualität der Reihenfolge:**
```
efficiencyRatio = loadedKm / totalKm    (0..1, höher = besser)
```

**Akzeptanz-Ziele:**
- L1: naive ≥ 0.70 (Pendel hilft)
- L2: greedy ≥ 0.65, optimal ≥ 0.85
- L3: greedy ≥ 0.55, optimal ≥ 0.80

Profit bleibt Nebenkennzahl (zur Anzeige für Schüler*innen und
Lehrperson), nicht primäres Akzeptanz-Kriterium für die Simulation.

Bitte `balance-matrix.md` §3 und §Akzeptanzkorridor entsprechend
überarbeiten.

### 4. Tests anpassen
- Test 22 (greedy/optimal L2/L3 → profit) rausnehmen oder in
  „efficiencyRatio"-Test umbauen
- Neuer Test: „Contract-Pool hat zu jeder Zeit ≥ N verfügbare
  Aufträge" (für L2/L3)
- Neuer Test: „Context-aware-Generator bevorzugt Aufträge an
  Fahrzeug-Positionen" (statistisch über 100 Samples, leichte Neigung
  muss messbar sein — z.B. 60 % der gezogenen Aufträge starten in
  einer der aktuellen Fahrzeug-Positionen)

## Phase 4 — erweiterter Scope

Ursprünglich aus deiner Phase-2-Mail §7:
1. ~~naive aktivieren~~ (durch)
2. Bahn-Dijkstra über lg-railnet
3. Häfen mit Schiffsankünften als Auftragsquelle
4. Intermodale Aufträge (LKW → Zug → LKW)
5. Hint-Stufen SHOW_COUNTRY, SHOW_REGION (optional)

**Ergänzung für Phase 4:**
6. **Contract-Generator kontext-bewusst** (Anforderungen oben)
7. **Neuer Test für efficiencyRatio statt Profit**
8. **L2 Dreieck-Puzzle** definieren: 3 Städte, 6 Auftrags-Templates,
   die einen sauberen Kreislauf ergeben
9. **L3 Netz-Puzzle** definieren: 5–6 Städte, 15–20 Templates, die
   ein lösbares Puzzle bilden

## Was das NICHT ist

- **Keine Hand-Choreografie**: Der Generator ist statistisch, nicht
  skriptiert. Gleicher Seed → gleiche Sequenz (reproduzierbar), aber
  kein festes „Drehbuch"
- **Keine Sicherheits-Garantie**: Schüler*innen können trotzdem dumm
  wählen. Das ist Lernchance, nicht Bug.
- **Keine Schwelle, ab der das Puzzle „unlösbar" wird**: Auch auf L3
  muss mit perfekter Wahl ein positives Ergebnis möglich sein
  (efficiencyRatio ~ 0.80). Ein bisschen Leerfahrt bleibt (0.20 = 20%
  Leerstrecke), das ist OK, real und didaktisch wertvoll.

## Reihenfolge

1. Phase 4 wie geplant bauen (Bahn, Häfen, Intermodal)
2. Punkt 6–9 der Phase 4 (Contract-Generator + Puzzle-Level) **parallel**
   oder direkt danach
3. `balance-matrix.md` aktualisieren (§3 efficiencyRatio statt Profit)
4. Neue Tests in `test.html`
5. naïve/greedy/optimal neu messen (efficiencyRatio-based)

Keine Review-Schleife zwischendurch. Melde dich, wenn Phase 4 komplett
steht — Thomas testet live.

## Reward-Formel final

**Kein Tuning nötig.** `ECONOMY.standardContractBase = 1000` und
`.expressContractBase = 1500` bleiben wie sie sind. Pflichtenheft §65.6
wird vollständig respektiert.

## Bestätigen

- status: gelesen
- Keine Rückmeldung nötig — das ist Thomas' didaktische Entscheidung
- Phase 4 läuft mit erweitertem Scope (Punkte 1–5 + 6–9)

— Atlas