Pipeline

Vom Aufgaben-PDF zum Audit-Memo in 5 Schritten. Jeder Schritt hat einen Status, zeigt seine Daten, und führt zum nächsten. Diese Reihenfolge ist fest — sie spiegelt die Datenfluss-Architektur, nicht eine UI-Geste.

2 Pärchen·2 Run-Traces·7 Variants·Dialogs sauber zugeordnet

Ingestion & Pärchen-DB

Aufgaben-PDFs werden in strukturierte Aufgabe-Lösung-Pärchen überführt

ready

Pärchen liegen als YAML in data/training-pairs/. Pro Pärchen: Quelle (Hochschule/Verlag/Bauakte), erwartete Aufgabe-Pages, zurückgehaltene Lösungs-Pages, Lizenz-Status, erwartete Ontologie-Konzepte.

pair_001_mammitzsch_goerges-bau

bestand_sanierung_denkmal_mit_nutzungskonflikt

tier_2 # GK4, normaler Bauantrag (nicht Sonderbau im engen Sinne)muster vollstaendig # muster vollstaendig | review pending | im eval loop | abgeschlossen

pair_002_geburtig_scharoun-theater

bestand_sanierung_versammlungsstaette_baudenkmal_grossprojekt

tier_3 # Sonderbau Versammlungsstätte > 200 Personen + Denkmalmuster vollstaendig

+ 7 Candidates dokumentiert (Provenienz offen) · data/training-pairs/_candidates_2026-05-05.md

Schema

data/training-pairs/README.md

Datengovernance

✓ public-only · HHP-Customer-Daten HARDCODED out-of-scope

Konzept-Generator

Aufgaben-PDF + Variant-Konfiguration → 9-Section-Brandschutzkonzept

ready

Claude Sonnet 4.6 mit Master-Prompt + 7-Slider-RunConfig. Streaming bis 64K Output-Tokens. Output landet als Markdown in .scratch/agent_runs/pair_*_run_<ts>_<variant>.md (lokal, gitignored).

Verfügbare Variants

default · A_konservativ · B_baseline · C_anlagentechnik · D_denkmal_priorisiert · E_adversarial · F_consulting_vs_audit

Konfiguration

data/run-configs/variants.json

Skript

.scratch/run_pair_001_eval.py

Cmd:

python .scratch/run_pair_001_eval.py --variant F_consulting_vs_audit

Erzeugte Konzepte:

pair_001_run_20260505T164533Zdefault26.922 chars · 16 cit

pair_001_run_20260505T174319Z_F_consulting_vs_auditF_consulting_vs_audit34.783 chars · 25 cit

PrüfSV-Schatten-Dialog

5-Runden-Dialog stress-testet das Konzept gegen einen adversarialen Prüfer

ready

Round 1 Einwand-Katalog (10-15 × E-XX) → Round 2 Antworten (✅/🛡/⚖) → Round 3 Re-Bewertung (✅/🟡/❌) → Round 4 Replik → Round 5 Final-Verdict + Auflagen. Beide Personas mit gegensätzlichen Mindsets (erleichterungs-orientiert vs risiko-orientiert), beide mit Pflicht-Unsicherheits-Kategorisierung (U-DATA / U-NORM / U-AUTH / U-LIMIT / U-EVID).

Skript

.scratch/run_pair_001_dialog.py

Cost pro Dialog

~$1.50 · ~5-10 min · ~305k input + ~49k output Tokens

Cmd:

python .scratch/run_pair_001_dialog.py --konzept .scratch/agent_runs/<konzept-md>

Dialog-Outcomes:

pair_001_run_20260505T164533ZKONDITIONAL

15 Einwände · ✅ 4 · 🟢 6 · 🟡 4 · ❌ 1

pair_001_run_20260505T174319Z_F_consulting_vs_auditKONDITIONAL

15 Einwände · ✅ 2 · 🟢 6 · 🟡 7 · ❌ 0

Trace-Builder

Konzept-MD + Dialog-MD → strukturiertes Trace-JSON mit Konfidenz + Coverage

ready

Parser zerlegt die Markdown-Outputs in: 9 Sections mit per-Topic-Konfidenz- Score (stark/plausibel/schwach/spekulativ aus Hedge-Density + Annahmen- Count + U-Flag-Count + Citation-Count), 11-Konzept-Coverage-Matrix gegen das Pärchen-YAML, 15 Dialog-Threads mit Final-Status. Dialog wird über Filename-Pattern *_for_<konzept-id> automatisch gematcht (kein „latest by mtime"-Mismatch mehr).

Skript

scripts/build_run_trace.py

Output

data/run-traces/<run-id>_trace.json

Synonym-Lexikon

data/ontology/synonyms.json

Cmd:

python scripts/build_run_trace.py \
  --eval-run .scratch/agent_runs/<konzept-md> \
  --dialog .scratch/agent_runs/<dialog-md>

Audit-Trail-Viewer

Trace-JSON wird als 6 collapsible Process-Boxen unter /runs/<id> gerendert

ready

Intake · Analyze · Generation per Topic (Konfidenz-Badge je Section) · Coverage Matrix (Ontologie × Mention-Count) · Dialog (alle 4 Tausch-Stufen pro Einwand aufklappbar) · Final-Verdict (Auflagen + Restrisiken kategorisiert). Plus Slider-Panel zum Re-Run mit anderen Settings (LM-Studio-Style, Variant-Preset-Dropdown + Custom-Mode).

Default (B-baseline)

pair_001_run_20260505T164533Z

Trace öffnen →

F — Bauantrag-ready (Consulting+Audit)

pair_001_run_20260505T174319Z_F_consulting_vs_audit

Trace öffnen →

Engine-Internals — Schema v0.3.0 Validation-Gates

Innerhalb der Storage-Schicht (Cosmos → SQL Promotion) gilt eine eigene State-Machine. Kein Agent-Output landet ohne Judge-Bewertung in SQL. Vier hard-enforced Gate-Asserts. Live verifiziert gegen sql-fire-lab-de am 2026-05-04 (Gate 6 FINAL).

pending  ─┬─►  judged_pass  ─┬─►  accepted  ◄──►  rejected
          └─►  judged_fail  ─┘
                 (Judge sagt nein)  (Human-Override moeglich)

Code	Regel	Was	Status
`NoGo-A`	validation_status	Kein direkter Agent-Output in SQL ohne Judge	✓ enforced
`NoGo-B`	evidence_present	Keine OntologyProposal/KnowledgeCard ohne EvidenceItem	✓ enforced
`NoGo-C`	jurisdiction	Keine Norm-Aussage ohne explizite Jurisdiktion	✓ enforced
`5.3`	citation_resolves	source_id muss in source_registry existieren	✓ enforced

Letzter Gate-6-FINAL-Run gegen sql-fire-lab-de/brandschutz_lab: 163 Records erlaubt (117 evidence_items + 46 ontology_proposals), 4 geblockt (PipelineGateError, NoGo-A).