Anhang D. Kalibrierung von Schwellenwerten

Dies ist ein Nachschlage-Anhang. Beim ersten Durchgang wird er nicht benötigt: Das Lernminimum jedes Kapitels ist auf die Standard-Schwellenwerte für AgentClinic-production ausgelegt. Diese Datei fasst alle Tabellen „Niedrig / Standard / Hoch“, Übungen zur Verschiebung von Schwellenwerten und Signale zusammen, anhand derer ein Schwellenwert überprüft werden muss. Verwenden Sie ihn bei der Übertragung des Prozesses in Ihr Projekt, wenn die Standardwerte nicht mehr passen.

Das für alle Tabellen geltende Prinzip: Schwellenwerte ergeben nur als Paar Sinn. Eine Verschiebung eines Wertes ohne Neuberechnung des zugehörigen Wertes ist keine Kalibrierung, sondern ein Abbau der Regelschleife. Für jeden Abschnitt sind die Risiken einer solchen Verschiebung explizit aufgeführt.

D.1 Mutationstests (Kapitel 5)

Die Zahlen aus Kapitel 5 sind der Standardwert für AgentClinic-production mit mittlerem Incident-Volumen und einem ausgereiften SDD-Prozess. In Ihrem Projekt hängen die Schwellenwerte vom Preis eines verpassten P0, der Komplexität des Routing-Graphen, dem CI-SLA-Fenster und der Stabilität des eingehenden Volumens ab. Jede Verschiebung einer Zeile muss durch einen Eintrag in validation.md mit Begründung dokumentiert werden.

| Preis eines verpassten P0 | strict_reject_rate ≥ 0,92 | **≥ 0,98** | ≥ 0,995 (Zahlungsverkehr, Gesundheitswesen) | | Komplexität des Routing-Graphen | depth_of_diagnostics ≥ 2 (≤10 Kanten) | **≥ 3** (10–50 Kanten) | ≥ 5 (>100 Kanten, Multi-Tenant) | | CI-SLA-Fenster | recovery_time_p95_ms ≤ 800 | **≤ 1200** | ≤ 1500 (>500 PR/Tag) | | Stabilität des Incident-Volumens | 1 Mutant pro Klasse | 2 Mutanten pro Klasse | 5+ Mutanten pro Klasse + Seed-Rotation |

Übung

cd book2/examples/stress-mutator

mkdir -p out
cp expected/expected_failures.json out/expected_failures_depth5.json
sed -i 's/"depth_of_diagnostics_min": 3/"depth_of_diagnostics_min": 5/' out/expected_failures_depth5.json

python3 scripts/immunity_score.py \
  --validator-results out/validator_results.json \
  --expected expected/expected_failures.json \
  --out out/immunity_default.json

python3 scripts/immunity_score.py \
  --validator-results out/validator_results.json \
  --expected out/expected_failures_depth5.json \
  --out out/immunity_depth5.json

Der erste Lauf sollte erfolgreich sein: Die durchschnittliche Diagnosetiefe beträgt 4 und überschreitet den Schwellenwert 3. Der zweite Lauf sollte mit Exit-Code 1 enden: Derselbe Validator besteht den künstlich verschärften Schwellenwert depth_of_diagnostics_min = 5 nicht mehr. Die Differenz zeigt keinen neuen Defekt in den Mutanten, sondern den Preis einer Verschärfung des Schwellenwerts.

Wann den Schwellenwert überprüfen

• Über ein Quartal wurde kein Merge durch den Schwellenwert blockiert — er ist unnötig niedrig.
• Mehr als 10 Regressionen mit derselben mutation_id in einer Woche — depth_of_diagnostics ist unzureichend, erhöhen.
• recovery_time_p95 fällt gegen null bei steigendem strict_reject_rate — Anzeichen des Goodhart-Effekts.
• Es ist eine neue Klasse von Incidents aufgetreten — alle drei Schwellenwerte neu berechnen.
• Ein Seed (seed) wiederholt denselben Satz von mutation_id fünf Sprints in Folge — Seed-Rotation erforderlich.

Risiko: Wenn strict_reject_rate steigt und gleichzeitig depth_of_diagnostics fällt, ist dies ein Symptom des Goodhart-Effekts. Beide Parameter dürfen nur gemeinsam verschoben werden.

D.2 Auswahl von Shadow-Spezifikationen (Kapitel 6)

Die Gewichte 0,5*mttr_gain + 0,3*early_signal + 0,2*coverage - 0,4*false_escalation und die Schwellenwerte keep/reject sind die Standardwerte für AgentClinic-production. In Ihrem Projekt hängen sie vom Preis einer falschen Eskalation, der Bedeutung eines frühen Signals, der Größe der historischen Datenbasis und dem verfügbaren Budget für Few-Shot-Beispiele ab.

Übung

Führen Sie eine Auktion mit einem konservativen Risikoprofil durch (höhere Strafe für falsche Eskalation):

cd book2/examples/shadow-auction
python3 scripts/score.py --candidates candidates/candidates.yaml --incidents data/incidents.jsonl --weights "0.3,0.4,0.2,0.8" --out out/scorebook.json

python3 scripts/decide.py --scorebook out/scorebook.json --budget-tokens 2000 --keep-threshold 0.70 --reject-threshold 0.40 --out-auction out/auction.json --out-quarantine out/quarantine.json

Bei diesem Profil wechselt shadow.p0.voice_handoff von winner zu disputed, während shadow.alert.red_color_urgency in rejected bleibt. Dies zeigt das neue Profil: Das Team belohnt die MTTR-Reduzierung weniger und bestraft falsche Eskalationen stärker.

Wann den Schwellenwert überprüfen

• Über einen Monat hat kein winner einen positiven Effekt in Post-Mortems gezeigt — keep-threshold ist zu niedrig.
• Der Anteil von disputed liegt dauerhaft über 40% — die Formel unterscheidet Fälle nicht.
• In einer Phase werden mehr als 8 Gewinner ausgewählt — budget-tokens wurde ohne Berücksichtigung der Größe von QWEN.md gewählt.
• Es ist eine neue Klasse von Incidents außerhalb der historischen Daten aufgetreten.
• mttr_gain und false_escalation steigen gemeinsam — Symptom des Goodhart-Effekts.

Risiko: Die Strafe false_escalation und das Gewicht mttr_gain dürfen nur gemeinsam verschoben werden. Eine Verschiebung des einen ohne Überprüfung des anderen zerstört das Gleichgewicht „nützliches Signal ↔ falscher Lärm".

D.3 Stufenbudgets (Kapitel 9)

Das Budget von 10 M Tokens mit Aufteilung 9M/1M (local/frontier) ist der Standardwert für AgentClinic-production mit mittlerem Incident-Volumen. In Ihrem Projekt hängen die Budgetgröße und die Anteile vom Incident-Volumen, den durchschnittlichen Kosten pro Phase, dem Anteil strittiger Reviews und der Sensitivität gegenüber dem Ausfall von local-coder ab.

Übung

cd book2/examples/budget-keeper

python3 scripts/compile.py --budget-spec specs/budget_network_5m.yaml --out out/budget_plan_5m.json
python3 scripts/simulate.py --plan out/budget_plan_5m.json --scenario scenarios/fail_local_45m.json --out out/fail_result_5m.json

python3 scripts/inspect.py --result out/fail_result_5m.json --query "failover_to_frontier==2 && degraded_queue==18 && token_health_min>=0.5"

Prüfen Sie, ob token_health_min bei halbiertem Budget über 0,5 gehalten werden konnte. In der vorbereiteten 5M-Variante bleiben die Anteile erhalten: Die local-Stufe erhält 4,5M, die frontier-Stufe 0,5M. Wird nur daily_budget_tokens geändert, aber nicht die Phasenkontingente, muss compile.py mit einer Summenfehler abstürzen.

Wann den Schwellenwert überprüfen

• Über einen Monat gab es keinen degraded_mode-Auslösung — Budget ist entweder überschüssig oder das reale Volumen liegt unter dem Erwartungswert.
• token_health_min fällt öfter als einmal pro Woche unter 0,5 — Die local-Stufe ist unzureichend.
• failover_to_frontier ist bei Ausfällen der local-Stufe dauerhaft 0 — Das Gateway ist zu streng, frontier funktioniert nicht als Absicherung.
• Der Anteil von manual_queue nach manuellem Timeout wächst zwei Monate in Folge — manual_timeout_sec ist zu kurz.
• Pro Tag werden weniger als 60% von daily_budget_tokens verbraucht — Budget sollte verkleinert werden.

Risiko: Die Aufteilung 9M/1M ist mit dem SLA pro Phase verknüpft. Sie darf nicht ohne Aktualisierung von budget_plan_phases in der Spezifikation verschoben werden — sonst kann die frontier-Stufe „strittige" Fälle nicht mehr aufnehmen.

D.4 Schutz von Metriken vor dem Goodhart-Effekt (Kapitel 10)

Die Schwellenwerte silent_p0 ≤ 5%, manual_review_rate ≥ 15%, edge_drift ≤ 0,12, audit_trace_coverage = 1,0 sind die Standardwerte für AgentClinic-production. In Ihrem Projekt hängen sie vom Preis eines verpassten P0, der Verfügbarkeit manueller Reviewer, der Dynamik des eingehenden Volumens und regulatorischen Anforderungen an die Auditierung ab.

Übung

cd book2/examples/goodhart-validator

mkdir -p out

# Spec in lokales out/ kopieren und silent_p0_cap auf 0,08 lockern
cp specs/validation.yaml out/validation_loose.yaml
sed -i 's/threshold: 0.05/threshold: 0.08/' out/validation_loose.yaml

python3 scripts/run_validation.py \
  --validation out/validation_loose.yaml \
  --metrics fixtures/new_metrics_bad.json

# Gefährliche Variante: gleichzeitig zwei unabhängige Schutzmaßnahmen lockern
cp specs/validation.yaml out/validation_unsafe.yaml
sed -i 's/threshold: 0.15/threshold: 0.10/' out/validation_unsafe.yaml
sed -i 's/threshold: 0.05/threshold: 0.20/' out/validation_unsafe.yaml

python3 scripts/run_validation.py \
  --validation out/validation_unsafe.yaml \
  --metrics fixtures/new_metrics_bad.json

Der erste Lauf sollte rot bleiben: Ein schlechtes Release mit silent_p0=0,18 verletzt weiterhin silent_p0_cap. Die zweite, gefährliche Variante besteht nur, weil gleichzeitig zwei unabhängige Schutzmaßnahmen gelockert wurden. Dies zeigt, warum Guard-Metriken nicht Zeile für Zeile in YAML kalibriert werden dürfen.

Wann den Schwellenwert überprüfen

• Über ein Quartal wurde kein Release durch silent_p0_cap blockiert — entweder macht das Team keine riskanten Änderungen, oder der Schwellenwert ist unnötig weich.
• manual_review_rate fällt drei Sprints in Folge bei steigendem mttr_gain — Symptom des Goodhart-Effekts, manuelle Reviewer haben aufgehört, als Absicherung zu fungieren.
• edge_drift schwankt stabil um 0,10–0,11 — Die reale Dynamik des Eingangs liegt nah am Schwellenwert.
• audit_trace_coverage ist in einem einzigen Lauf unter 1,0 gefallen — Verletzung des regulatorischen Invariants, Hot-Fix, keine Kalibrierung.

• Es ist eine neue Klasse von Incidents aufgetreten, die nicht in silent_p0 erfasst wird — Neue Invarianten benötigt, keine Überprüfung alter.

Risiken: silent_p0 und manual_review_rate dürfen nur gemeinsam verschoben werden. edge_drift ergibt nur bei audit_trace_coverage=1,0 Sinn, sonst wird der Drift auf einer Teilstichprobe berechnet. Alle vier Schwellenwerte bilden einen einheitlichen Risikovertrag: Einer in Isolation zu lockern, bedeutet ihn zu zerstören, nicht zu konfigurieren.

Vollständiges Metrikennetzwerk

Im Text des Kapitels wird ein vereinfachtes Mermaid-Diagramm mit drei Metriken und einem Wächter verwendet. Das vollständige Abhängigkeitsnetzwerk sieht so aus:

flowchart LR
    MTTR[MTTR]
    silent_p0[silent_p0]
    manual_review_rate[manual_review_rate]
    escalation_rate[escalation_rate]
    postmortem_regression[postmortem_regression]
    audit_trace_coverage[audit_trace_coverage]
    silent_p0 -->|positive_Wechselwirkung| MTTR
    escalation_rate -->|positive_Wechselwirkung| MTTR
    manual_review_rate -->|negative_Wechselwirkung| MTTR
    manual_review_rate -->|negative_Wechselwirkung| escalation_rate
    audit_trace_coverage -->|negative_Wechselwirkung| escalation_rate

audit_trace_coverage -->|negative_Wechselwirkung| silent_p0
    postmortem_regression -->|positive_Wechselwirkung| audit_trace_coverage
    postmortem_regression -->|negative_Wechselwirkung| manual_review_rate

Die Logik ist dieselbe wie in der vereinfachten Version: Die rote Zone — MTTR und silent_p0; der Weg zu ihrer Abschwächung führt über die Reduzierung manueller Prüfung und den Verlust des Audit-Trails.

D.5 Production-Reife (Kapitel 11)

Der Schwellenwert 23/25 ist der Standardwert für AgentClinic-production mit mittlerer Reife des SDD-Prozesses und gemischtem Aktionstyp. In Ihrem Projekt hängt der Schwellenwert vom Preis eines Cutover-Fehlers, der Reife des Prozesses, der Last manueller Reviews und der Art der Aktionen (stateless / stateful) ab.

| Last manueller Reviews | jeder Pull-Request (~5/Woche) → 21–22 halbautomatisch halten möglich | 20–30% der Pull-Requests → auto 23+ | selten → auto 24/25 | | Aktionstyp | stateless → 22/25 nur canary/halbautomatisch, auto 23+ | gemischt → auto 23+ | stateful → auto 24+ und backup_verified |

Übung

Das Skript check_readiness.py hat THRESHOLD = 23 hardcodiert. Führen Sie es mit einem anderen Wert über eine Kopie aus:

cd book2/examples/real-api && mkdir -p out
cp scripts/check_readiness.py out/check_readiness_t22.py
sed -i 's/THRESHOLD = 23/THRESHOLD = 22/' out/check_readiness_t22.py
python3 out/check_readiness_t22.py --readiness fixtures/readiness_block_audit.json

Bei THRESHOLD = 22 wird readiness_block_audit.json trotzdem blockiert, weil audit_trace_coverage=0,7 < 1,0, obwohl die Summe 22/25 besteht. Dies zeigt, dass audit_trace_coverage ein unabhängiger blockierender Invariant ist, nicht Teil der Summe. Die Übung demonstriert die Sensitivität des Schwellenwerts, nicht eine Empfehlung zur Senkung des Auto-Freigabewerts.

Wann den Schwellenwert überprüfen

• Über ein Quartal wurde keine Reife durch den Schwellenwert blockiert — er ist für die aktuelle Reife des Teams zu niedrig.

• Der Anteil halbautomatischer Incidents wächst drei Sprints in Folge — Der Schwellenwert 23/25 wird wegen einer systematischen Lücke in Verification oder Process nicht erreicht.
• Es ist eine Klasse von Aktionen mit stateful=true aufgetreten — Fordern Sie backup_verified und erhöhen Sie den Schwellenwert für diese Klasse auf 24/25.
• Alle Reife-Ausfälle innerhalb eines Monats liegen auf einer Achse — Das ist eine Lücke in den SDD-Templates; Templates korrigieren, nicht den Schwellenwert verschieben.
• Die Zeit zur Erstellung von Reife-Artefakten überschreitet das SLA für den Cutover — Prüfen Sie, welche Punkte automatisiert werden können, statt den Schwellenwert zu senken.

Risiko: Der Schwellenwert 23/25 ist mit null Punkten in Security bei beliebiger Summe inkompatibel — ein solcher Ausfall blockiert den Merge unabhängig vom Ergebnis. Eine Senkung unter 23/25 ändert den Betriebsmodus: Das ist dann kein Auto-Freigabe mehr, sondern halbautomatischer oder Canary-Modus. Selbst „niedrig" (21/25) bedeutet einen Stopp nach jedem Implement-Schritt und eine explizite Bestätigung durch den Operator, nicht das Recht des Agenten, eine Remediation selbstständig durchzuführen.