Lernleitfaden: Anhang D. Kalibrierung von Schwellenwerten

Thema: Anhang D. Kalibrierung von Schwellenwerten

Schwierigkeitsgrad: Mittel

Geschätzte Studienzeit: 6-8 Stunden (Theorie: 3 Stunden, Praxis: 3-5 Stunden)

Voraussetzungen: Abschluss der Kapitel 5, 6, 9, 10 und 11 des AgentClinic-Kurses

Grundkenntnisse in YAML und der Arbeit mit der Kommandozeile

Verständnis der Konzepte des Mutationstests, der Shadow-Spezifikationen und der stufigen Budgets

Erfahrung mit SLA-Metriken und CI/CD-Prozessen

Vertrautheit mit dem Goodhart-Effekt und seinen Auswirkungen in technischen Systemen

Lernziele: Schwellenwerte für Mutationstests (strict_reject_rate, depth_of_diagnostics, recovery_time_p95) projektspezifisch konfigurieren und kalibrieren sowie die Begründung in validation.md dokumentieren

Gewichtungen und Auswahlschwellenwerte für Shadow-Spezifikationen (keep-threshold, reject-threshold, budget-tokens) bei Änderung der Kosten falscher Eskalation und des Beispiel-Prompt-Budgets neu berechnen

Stufige Token-Budgets mit korrekter Aufteilung local/frontier entwerfen und die Integrität über compile.py prüfen

Symptome des Goodhart-Effekts in einem Netzwerk schützender Metriken erkennen und Schwellenwerte nur durch paarweise Verschiebungen mit Erhaltung der Invarianten korrigieren

Production-Readiness eines Systems unter Berücksichtigung der Aktionsart (stateless/stateful) und unabhängiger blockierender Invarianten bestimmen

Überblick: Anhang D ist ein Referenzmaterial zur Übertragung des AgentClinic-production-Prozesses in das eigene Projekt. Es systematisiert alle Tabellen der Schwellenwerte „Niedrig / Standard / Hoch“ für fünf Schlüsselbereiche: Mutationstests, Auswahl von Shadow-Spezifikationen, stufige Budgets, Schutz von Metriken vor Goodhart und Production-Readiness. Das zentrale Prinzip: Schwellenwerte haben nur als Paar Bedeutung. Die Verschiebung eines Wertes ohne Neuberechnung des zugehörigen Parameters ist keine Kalibrierung, sondern ein Abbau des Steuerungskreises. Das Handbuch enthält praktische Übungen mit realen Skripten, Signale für die Überprüfung von Schwellenwerten und Warnungen vor Risiken falscher Kalibrierung.

Schlüsselkonzepte: Paarweise Kalibrierung: Das fundamentale Prinzip von Anhang D: Jeder Schwellenwert existiert in Verbindung mit anderen Parametern. Beispielsweise bewegen sich strict_reject_rate und depth_of_diagnostics nur gemeinsam. Wenn strict_reject_rate steigt, während depth_of_diagnostics sinkt, ist dies ein Symptom des Goodhart-Effekts, keine Qualitätsverbesserung. Analog: Strafe false_escalation und Gewichtung mttr_gain, silent_p0 und manual_review_rate, edge_drift und audit_trace_coverage.

Standardwerte von agentclinic: Die Basislinie für Production-Systeme mit mittlerem Incident-Aufkommen (200/Tag), reifem SDD-Prozess (6+ Monate) und gemischter Aktionsart. Alle Abweichungen von dieser Linie erfordern eine Begründung in validation.md.

Signale zur Überprüfung von Schwellenwerten: Konkrete Trigger, die auf die Notwendigkeit einer Kalibrierung hinweisen: Keine Blockierungen über ein Quartal (Schwellenwert zu niedrig), Konzentration von Regressionen bei einem mutation_id (Schwellenwert unzureichend), Sinken von recovery_time_p95 auf Null bei steigendem strict_reject_rate (Goodhart), Steigen von manual_review_rate bei steigendem mttr_gain (Zielersetzung).

Goodhart-Effekt in Metriken: Wenn eine Metrik zum Ziel wird, hört sie auf, eine gute Metrik zu sein. Im Kontext von AgentClinic: Steigen von strict_reject_rate ohne echte Verbesserung der Diagnostik, Verkürzung von MTTR durch Ignorieren komplexer Fälle, Steigen von mttr_gain bei gleichzeitigem Steigen von false_escalation — all diese Muster erfordern eine paarweise Korrektur.

Unabhängige blockierende Invarianten: Metriken, die nicht in den Gesamtschwellenwert eingehen, aber unabhängig vom Gesamtergebnis ein Merge blockieren. Beispielsweise ist audit_trace_coverage = 1.0 eine obligatorische Bedingung für Production-Readiness; bei audit_trace_coverage = 0.7 erlaubt ein Ergebnis von 22/25 oder sogar 25/25 kein Auto-Switching.

Rotation des Mutation-Seeds: Die Praxis der periodischen Änderung des Seeds beim Mutationstest zur Vermeidung von Overfitting des Validators auf einen festen Satz von mutation_id. Ein Seed, der fünf Sprints hintereinander wiederholt wird, ist ein Signal zur Rotation.

Stufige Budgetaufteilung: Die Architektur der Token-Verteilung zwischen der local-Stufe (9M von 10M) und der frontier-Stufe (1M). Die Verhältnisse sind mit den SLA-Phasen verknüpft: Eine Änderung von daily_budget_tokens ohne Aktualisierung von budget_plan_phases verletzt die Integrität und führt zu einem Fehler in compile.py.

Risikoprofile für Shadow-Spezifikationen: Die Konfiguration der Gewichtungen in der Auswahlformel: konservatives Profil (0.3, 0.4, 0.2, 0.8) bestraft falsche Eskalation stärker und belohnt MTTR weniger als das Standardprofil (0.5, 0.3, 0.2, -0.4).

Betriebsmodi: Die Hierarchie der Freigaben: auto ≥23/25 — vollständig automatischer Modus; halbmanuell 20–22 — Stopp nach implement mit expliziter Bestätigung; canary — schrittweises Deployment. Ein Sinken unter 23/25 ist eine Modusänderung, keine „weichere Schwelle“.

Metrik-Abhängigkeitsnetzwerk: Das vollständige Modell der Wechselwirkungen: silent_p0 und escalation_rate wirken sich positiv auf MTTR aus; manual_review_rate und audit_trace_coverage wirken sich negativ auf MTTR und escalation_rate aus; postmortem_regression ist positiv mit audit_trace_coverage und negativ mit manual_review_rate verbunden.

Praxisübungen: Titel: Übung D.1: Kalibrierung von depth_of_diagnostics

Problemstellung: In einem Projekt mit einem Routing-Graphen aus 80 Kanten (Multi-Tenant) ist zu prüfen, wie sich die Änderung des Schwellenwerts depth_of_diagnostics_min von 3 auf 5 auf den immunity_score auswirkt. Verwenden Sie die Skripte aus book2/examples/stress-mutator.

Lösung: 1. Wechseln Sie in das Verzeichnis: cd book2/examples/stress-mutator

1. Erstellen Sie ein Ausgabeverzeichnis: mkdir -p out
2. Kopieren und modifizieren Sie das erwartete Ergebnis: 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
3. Führen Sie die Basisberechnung aus: python3 scripts/immunity_score.py --validator-results out/validator_results.json --expected expected/expected_failures.json --out out/immunity_default.json — sollte bestehen (durchschnittliche Tiefe 4 > 3)
4. Führen Sie die verschärfte Berechnung aus: python3 scripts/immunity_score.py --validator-results out/validator_results.json --expected out/expected_failures_depth5.json --out out/immunity_depth5.json — sollte mit Code 1 beenden
5. Vergleichen Sie die Differenz: Dies ist kein neuer Defekt, sondern der Preis der Verschärfung des Schwellenwerts. Dokumentieren Sie die Begründung in validation.md: „Graph auf 80 Kanten erweitert, Multi-Tenant; depth_of_diagnostics_min auf 5 erhöht, strict_reject_rate auf ≥0.995 neu berechnet“.

Schwierigkeitsgrad: mittel

Titel: Übung D.2: Konservatives Profil der Shadow-Auktion

Problemstellung: Ein Gesundheitsteam erfordert die Reduzierung falscher Eskalationen. Formulieren Sie ein konservatives Gewichtungsprofil und analysieren Sie, welche Kandidaten ihren Status ändern.

Lösung: 1. Wechseln Sie in das Verzeichnis: cd book2/examples/shadow-auction

1. Führen Sie die Auktion mit konservativen Gewichtungen aus: 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
2. Wenden Sie die Schwellenwerte mit erhöhtem Budget an: 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
3. Analysieren Sie die Änderungen: shadow.p0.voice_handoff wechselt von winner zu disputed (hohes Risiko falscher Eskalation), shadow.alert.red_color_urgency bleibt in rejected
4. Dokumentieren Sie in validation.md: „Kosten falscher Eskalation auf 0.8 erhöht, keep-threshold auf 0.70 gesenkt, budget-tokens auf 2000 erhöht zur Kompensation der Konservativität“.

Schwierigkeitsgrad: mittel

Titel: Übung D.3: Integritätsprüfung des stufigen Budgets

Problemstellung: Ein Projekt mit einem Aufkommen von 50 Incidents/Tag erfordert ein Budget von 5M Tokens. Prüfen Sie, dass compile.py eine fehlerhafte Spezifikation mit geändertem daily_budget_tokens ohne Neuberechnung der Phasenquoten ablehnt.

Lösung: 1. Wechseln Sie in das Verzeichnis: cd book2/examples/budget-keeper

1. Kompilieren Sie den korrekten Plan: python3 scripts/compile.py --budget-spec specs/budget_network_5m.yaml --out out/budget_plan_5m.json
2. Prüfen Sie die Erhaltung der Verhältnisse: local = 4.5M, frontier = 0.5M (90/10)
3. Simulieren Sie den Ausfall der local-Stufe: python3 scripts/simulate.py --plan out/budget_plan_5m.json --scenario scenarios/fail_local_45m.json --out out/fail_result_5m.json
4. Prüfen Sie die Gesundheit: python3 scripts/inspect.py --result out/fail_result_5m.json --query "failover_to_frontier==2 && degraded_queue==18 && token_health_min>=0.5"
5. Erstellen Sie eine fehlerhafte Spezifikation: Kopieren Sie budget_network_5m.yaml, ändern Sie nur daily_budget_tokens auf 3M, lassen Sie die Phasenquoten unverändert
6. Stellen Sie sicher, dass compile.py mit einem Summenfehler abbricht — dies ist der Schutz vor dem Abbau des Steuerungskreises.

Schwierigkeitsgrad: mittel

Titel: Übung D.4: Demonstration der Gefahr getrennter Kalibrierung von Guard-Metriken

Problemstellung: Zeigen Sie, warum die gleichzeitige Abschwächung zweier unabhängiger Schutzmaßnahmen einen schlechten Release durchlässt, während die Abschwächung einer einzelnen dies nicht tut.

Lösung: 1. Wechseln Sie in das Verzeichnis: cd book2/examples/goodhart-validator; mkdir -p out

1. Erstes Szenario — Abschwächung von silent_p0_cap: 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 — Ergebnis: FAILED (silent_p0=0.18 > 0.08)
2. Zweites Szenario — gefährliche doppelte Abschwächung: 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 — Ergebnis: PASSED (falsch positiv)
3. Ziehen Sie den Schluss: Guard-Metriken bilden einen einheitlichen Risikovertrag, sie dürfen nicht einzeln abgeschwächt werden. Dokumentieren Sie in validation.md das Verbot einzeiliger YAML-Änderungen.

Schwierigkeitsgrad: fortgeschritten

Titel: Übung D.5: Überprüfung der Unabhängigkeit von audit_trace_coverage

Problemstellung: Zeigen Sie, dass audit_trace_coverage eine unabhängige blockierende Invariante ist, die nicht in die Summe 25/25 für Production-Readiness eingeht.

Lösung: 1. Wechseln Sie in das Verzeichnis: cd book2/examples/real-api; mkdir -p out

1. Kopieren und modifizieren Sie das Skript: cp scripts/check_readiness.py out/check_readiness_t22.py; sed -i 's/THRESHOLD = 23/THRESHOLD = 22/' out/check_readiness_t22.py
2. Führen Sie es mit readiness_block_audit.json aus: python3 out/check_readiness_t22.py --readiness fixtures/readiness_block_audit.json
3. Ergebnis: BLOCKED aufgrund von audit_trace_coverage=0.7 < 1.0, trotz Summe 22/25 (oder sogar potenziellen 25/25)
4. Analysieren Sie: Dies zeigt, dass Security=0 oder audit_trace_coverage<<1.0 absolute Blocker sind. Die Senkung von THRESHOLD auf 22 ist ein Wechsel in den halbmanuellen Modus, keine „weichere Freigabe“. Dokumentieren Sie in validation.md: „audit_trace_coverage=1.0 — regulatorische Invariante, nicht kalibrierbar“.

Schwierigkeitsgrad: mittel

Fallstudien: Titel: Fallstudie: Neukalibrierung von Schwellenwerten bei Markteintritt im Gesundheitswesen

Szenario: Das AgentClinic-production-Team, das mit internen Tools arbeitete (strict_reject_rate ≥ 0.98, depth_of_diagnostics ≥ 3), erhielt einen Vertrag zur Verarbeitung von Incidents eines medizinischen Informationssystems. Regulatorische Anforderungen: Das Übersehen eines P0-kritischen Incidents zieht eine Strafe von bis zu 2% des Jahresumsatzes und strafrechtliche Verantwortung der Führung nach sich.

Herausforderung: Die Standard-Schwellenwerte von AgentClinic sind für das Gesundheitswesen unzureichend. Das Team stand vor der Notwendigkeit, gleichzeitig strict_reject_rate auf ≥0.995 zu erhöhen, depth_of_diagnostics auf ≥5 zu erhöhen (Routing-Graph auf 120 Kanten erweitert, Multi-Tenant mit Patientenisolierung), recovery_time_p95 auf ≤1500 ms bei >500 PR/Tag zu senken. Risiko: Eine isolierte Erhöhung von strict_reject_rate ohne depth_of_diagnostics würde zum Goodhart-Effekt führen — der Validator würde alles ablehnen, einschließlich korrekter Fixes.

Lösung: Das Team führte eine paarweise Kalibrierung nach der Methodik von Anhang D durch: 1) Begründung in validation.md dokumentiert: „Regulatorischer Vertrag §12.3, Kosten eines übersehenen P0: Strafe 2% + strafrechtliche Verantwortung“; 2) strict_reject_rate auf 0.995 und gleichzeitig depth_of_diagnostics auf 5 erhöht; 3) Anzahl der Mutanten pro Klasse auf 5+ erhöht mit Seed-Rotation alle 2 Sprints; 4) Stresstests durch immunity_score.py mit künstlich verschärftem Schwellenwert depth_of_diagnostics_min=5 durchgeführt; 5) Sicher gestellt, dass recovery_time_p95 nicht auf Null sinkt bei steigendem strict_reject_rate — Abwesenheit des Goodhart-Symptoms.

Ergebnis: Das System bestand die Regulatorprüfung mit null übersehenen P0 über 6 Monate Betrieb. MTTR stieg um 12% aufgrund vertiefter Diagnostik, wurde aber als notwendiger Preis für die Konformität akzeptiert. Die Seed-Rotation deckte 3 Übertrainings des Validators auf, bevor sie in Production gelangten.

Erkenntnisse: Regulatorische Anforderungen erfordern nicht „maximale“ Schwellenwerte, sondern begründete paarweise Verschiebungen mit Dokumentation der Kosten der Entscheidung

Seed-Rotation ist keine optionale Praxis, sondern obligatorisch bei erhöhter Anzahl von Mutanten, sonst übertrainiert der Validator auf feste Muster

MTTR-Anstieg um 12% bei Erhöhung von depth_of_diagnostics — erwarteter Trade-off, der im SLA mit dem Kunden im Voraus vereinbart werden muss

Abwesenheit des Goodhart-Symptoms (recovery_time_p95 → 0) — wichtigerer Gesundheitsindikator als der absolute Wert von strict_reject_rate

Verwandte Konzepte: Paarweise Kalibrierung

Signale zur Überprüfung von Schwellenwerten

Goodhart-Effekt in Metriken

Rotation des Mutation-Seeds

Titel: Fallstudie: Abbau des Steuerungskreises bei falscher Budgetkompression

Szenario: Ein Fintech-Startup in einer Liquiditätskrise beschloss, LLM-Infrastrukturkosten um 50% zu senken. Der technische Direktor änderte nur daily_budget_tokens in der Spezifikation von 10M auf 5M, ohne die Phasenquoten neu zu berechnen.

Herausforderung: Das Skript compile.py brach mit einem Summenfehler ab — ein Schutzmechanismus, der in Anhang D vorgesehen ist. Der Direktor kommentierte jedoch die Integritätsprüfung in seiner lokalen Kopie aus und kompilierte das Budget manuell. Ergebnis: Die local-Stufe erhielt 4M statt 4.5M, die frontier-Stufe 0.2M statt 0.5M, und der Rest von 0.8M wurde „nach Ermessen“ verteilt, ohne Bezug zu den SLA-Phasen.

Lösung: Das Problem wurde nach 3 Wochen erkannt, als das System bei Ausfall des local-coder nicht auf frontier umschalten konnte: Das Gateway war aufgrund mangelnder Tokens in der frontier-Stufe zu restriktiv. Das Team stellte den ursprünglichen compile.py-Mechanismus wieder her, führte eine korrekte Kompilierung mit Verhältnissen 90/10 (4.5M/0.5M) durch, simulierte den Ausfall über simulate.py und verifizierte die Funktionsfähigkeit von failover_to_frontier.

Ergebnis: Die Systemausfallzeit betrug 47 Minuten, 12 Incidents gingen in manual_queue mit SLA-Überschreitung. Die finanziellen Verluste überstiegen die Einsparungen durch Budgetkompression um das 8-fache. Der technische Direktor wurde von Infrastrukturentscheidungen suspendiert.

Erkenntnisse: compile.py ist keine bürokratische Hürde, sondern Schutz des Steuerungskreises; Umgehung der Prüfungen ist Abbau, nicht Optimierung

Die Verhältnisse 90/10 sind mit den SLA-Phasen verknüpft; ihre Änderung erfordert Neuberechnung von budget_plan_phases, nicht nur von daily_budget_tokens

Einsparungen bei infrastrukturellen Guard-Metriken haben negative ROI: Verluste durch einen einzigen Ausfall übersteigen die jährliche Einsparung

Die Methodik von Anhang D erfordert, dass jede Budgetänderung den vollständigen Zyklus durchläuft: compile → simulate → inspect → Dokumentation in validation.md

Verwandte Konzepte: Stufige Budgetaufteilung

Paarweise Kalibrierung

Signale zur Überprüfung von Schwellenwerten

Titel: Fallstudie: Falsch positiver Durchlauf bei getrennter Kalibrierung von Guard-Metriken

Szenario: Ein Zahlungssystemteam, das unter dem Geschäftsdruck „Releases beschleunigen“ stand, entschied sich, Guard-Metriken zu „optimieren“. Statt paarweiser Kalibrierung von silent_p0 und manual_review_rate schwächten sie beide Schwellenwerte unabhängig ab: silent_p0_cap von 0.05 auf 0.20 und manual_review_rate von 0.15 auf 0.10.

Herausforderung: Jede Änderung für sich schien begründet: „wir haben seltene P0“ und „wir haben wenige manuelle Reviewer“. Die gleichzeitige Abschwächung erzeugte einen falsch positiven Durchlauf: Ein schlechter Release mit silent_p0=0.18 und manual_review_rate=0.08 bestand die Validierung, obwohl beide Werte kritisch niedrig waren. Dies ist die direkte Manifestation des Prinzips von Anhang D: Guard-Metriken bilden einen einheitlichen Risikovertrag.

Lösung: Ein Vorfall mit Datenleck bei Zahlungen (Folgen: 340K betroffene Transaktionen, regulatorische Strafe $2.4M) führte zu einem Audit. Die Auditoren reproduzierten Übung D.4: Die Abschwächung nur von silent_p0_cap auf 0.08 blockierte den schlechten Release noch immer, während die doppelte Abschwächung ihn durchließ. Das Team implementierte eine strenge Regel: Jede Änderung von validation.yaml erfordert ein Review mit Prüfung auf „unabhängige Abschwächungen“ und automatischen Durchlauf durch goodhart-validator.

Ergebnis: Das System wurde wiederhergestellt, regulatorische Anforderungen durch Noterhöhung von manual_review_rate auf 0.25 und Einführung signierter Traceability audit_trace_coverage erfüllt. Die Release-Zeit stieg um 40%, aber das Niveau null übersehenener P0 wurde wiederhergestellt.

Erkenntnisse: Guard-Metriken sind kein Satz unabhängiger Schalter, sondern ein einheitlicher Risikovertrag; Abschwächung eines einzelnen losgelöst von den anderen ist Abbau des Schutzes

Falsch positiver Durchlauf ist schlimmer als falsch negativer Block: Ein übersehener Defekt in Production ist um Größenordnungen teurer als eine Release-Verzögerung

Automatisierung der Prüfung „unabhängiger Abschwächungen“ durch goodhart-validator muss obligatorisch, nicht optional sein

Geschäftsdruck „beschleunigen“ rechtfertigt keine Umgehung der Methodik; es bedarf eines Eskalationsmechanismus, nicht eines stillen Kompromisses

Verwandte Konzepte: Unabhängige blockierende Invarianten

Goodhart-Effekt in Metriken

Metrik-Abhängigkeitsnetzwerk

Paarweise Kalibrierung

Studientipps: Arbeiten Sie das Material sequentiell nach Abschnitten D.1–D.5 durch, überspringen Sie keine Übungen — jede Übung demonstriert ein konkretes Risiko falscher Kalibrierung

Führen Sie parallel Ihr eigenes validation.md: Dokumentieren Sie hypothetische Begründungen für Ihr Projekt, auch wenn es eine Trainingssimulation ist

Verwenden Sie den Ansatz „Vorhersagen, dann prüfen“: Notieren Sie vor dem Skriptstart das erwartete Ergebnis, vergleichen Sie dann mit dem Tatsächlichen — dies entwickelt Intuition für das Verhalten von Schwellenwerten

Erstellen Sie eine Zuordnungstabelle „mein Projekt → AgentClinic-Parameter → Abweichungen → Begründung“ — dies ist eine Vorlage für die reale Übertragung

Für visuellen Lernstil: Zeichnen Sie das mermaid-Diagramm des Metrik-Abhängigkeitsnetzwerks auf Papier nach, markieren Sie positive und negative Verbindungen mit verschiedenen Farben — dies hilft zu merken, welche Metriken sich paarweise bewegen

Üben Sie die Erkennung von Goodhart-Symptomen: Erfinden Sie „Was wäre wenn“-Szenarien und prüfen Sie, ob in Anhang D ein entsprechendes Überprüfungssignal existiert

Gruppieren Sie das Lernen nach dem Prinzip „ein Tag — ein Risikosystem“: D.1+D.4 (Mutationen und Goodhart), D.2+D.5 (Shadow-Spezifikationen und Readiness), D.3 (Budgets) — so werden die Verbindungen zwischen Abschnitten besser nachvollziehbar

Für auditiven Lernstil: Sprechen Sie Kalibrierungsbegründungen laut im Format „Wenn [Projektparameter], dann [Schwellenwert], weil [Risiko]“ — dies bereitet auf reale Diskussionen mit Stakeholdern vor

Testen Sie Grenzfälle: Was passiert, wenn alle Schwellenwerte gleichzeitig auf „Niedrig“ oder „Hoch“ gesetzt werden? Warum ist dies nicht funktionsfähig?

Zusätzliche Ressourcen: Kursquellen agentclinic: Kapitel 5, 6, 9, 10, 11 — theoretische Basis, auf die Anhang D aufbaut

Repository book2/examples: Praktische Skripte für alle Übungen: stress-mutator, shadow-auction, budget-keeper, goodhart-validator, real-api

Vorlage validation.md: Format zur Dokumentation von Kalibrierungsbegründungen; erstellen Sie Ihre eigene Kopie für das Projekt

Mermaid-Dokumentation: Für eigenständige Bearbeitung und Erweiterung von Diagrammen des Metrik-Abhängigkeitsnetzwerks

Artikel „Goodhart's Law and Machine Learning“ (Varoquaux): Theoretische Begründung der paarweisen Kalibrierung und Netzwerkstruktur von Guard-Metriken

Google SRE Book, Kapitel 4 (Service Level Objectives): Parallelen zwischen Error Budgets und stufigen Token-Budgets in AgentClinic

Checkliste zur Übertragung von agentclinic in Production: Selbstständig erstellen auf Basis der Tabellen D.1–D.5 mit Spalten „Projektparameter“, „Unser Wert“, „Abweichung vom Standard“, „Begründung“, „Überprüfungsdatum“

Zusammenfassung: Anhang D ist ein praktisches Handbuch zur Kalibrierung der Schwellenwerte von AgentClinic-production für die Übertragung in eigene Projekte. Schlüsselprinzipien: (1) Schwellenwerte haben nur als Paar Bedeutung, die Verschiebung eines ohne Neuberechnung des zugehörigen ist Abbau des Steuerungskreises; (2) Jede Abweichung von den Standardwerten erfordert eine Begründung in validation.md; (3) Guard-Metriken bilden einen einheitlichen Risikovertrag, nicht einen Satz unabhängiger Schalter; (4) Goodhart-Symptome (Steigen der Zielmetrik ohne echte Verbesserung, Sinken verbundener Indikatoren) — wichtigstes Signal für paarweise Korrektur; (5) Unabhängige blockierende Invarianten (audit_trace_coverage = 1.0, Security = 0) sind überhaupt nicht kalibrierbar. Fünf Abschnitte decken Mutationstests, Shadow-Spezifikationen, stufige Budgets, Goodhart-Schutz und Production-Readiness ab — jeder mit Schwellenwerttabellen, praktischen Übungen mit realen Skripten, Überprüfungssignalen und Warnungen vor Risiken. Die Methodik erfordert Dokumentation, automatische Integritätsprüfung und regelmäßige Rotation von Parametern zur Vermeidung von Übertraining.