# Brandschutz-Workspace — Plattform-Übersicht

Stand: 2026-05-06. Alle 12 Sektionen mit gemessenen Zahlen aus dem Bootstrap-Sprint 2026-05-04 bis 2026-05-06 gefüllt. Diese Doku ist Single-Source für (a) internes Team-Onboarding und (b) externe Sales-Pitch-Vorbereitung. Wo eine Aussage nicht durch Code oder Run-Daten belegbar ist, ist das explizit als Hinweis kenntlich gemacht. Diszipliner Anker: Memory feedback_no_lipservice_in_commits.md.

# TL;DR

Eine Compliance-Audit-Plattform für Brandschutz-Konzepte, die jede Aussage bis zur Quelle nachverfolgen lässt — mit messbarem Konfidenz-Score, simuliertem Prüfingenieur-Stress-Test und gerichts- festem Argument-Trail.

(„Erstmalige Marktposition" ist Positionierungs-Behauptung des Bauherrn, nicht engineering-bewiesen. In Sales-Pitch ist die Aussage gestützt durch das Fehlen vergleichbarer öffentlicher Produkte — wird aber nicht in der Doku als Fact gesetzt.)

Konkret heute messbar:

1213-Knoten-Wissensgraph mit 166 echten Rechtsquellen + 65% Coverage der Baunetz- Brandschutz-Sitemap
7 parametrische Slider zur Argumentations-Steuerung (default + 6 Lab-Variants A-F)
5-Runden-PrüfSV-Schatten-Dialog mit U-DATA/U-NORM/U-AUTH/ U-LIMIT/U-EVID-Unsicherheits-Kategorisierung und vier Final-Verdict- Stufen
Vollständig nachverfolgbarer Audit-Trail-Viewer pro Run unter /runs/<id> mit 6 collapsible Process-Boxen
Datengovernance HARDCODED — Public-only-Trainingsdaten, jede Quelle mit Provenance-Trail

# 1. Was die Plattform macht

Eingabe: Aufgabenpaket eines Bauherrn als PDF — Objektbeschreibung, Geometrie, Bestandsdaten, Schutzziele. Beispiel pair_001: die ersten 11 Seiten einer TU-Dresden-Diplomarbeit (Görges-Bau, Architektur, Mammitzsch 2024) ohne den Lösungs-Teil ab Seite 51.

Output: Vollständiges Brandschutzkonzept im Bauantrags-Stil mit 9 strukturierten Sections (Klassifizierung baurechtlich → Schutzziele → Schlüssel-Strategie → Bauliche Maßnahmen → Anlagentechnik → Organisatorisches → Rettungswege → Abweichungen+Kompensationen → Restrisiko+Annahmen). Plus Audit-Trail der jede Aussage zur Quelle und zum Konfidenz-Niveau nachvollziehen lässt.

Walkthrough am Demo-Fall pair_001 Mammitzsch Görges-Bau:

Eingangs-PDF wird über das Pärchen-YAML (data/training-pairs/pair_001_mammitzsch_goerges-bau.yaml) auf die Aufgabe-Seiten reduziert (Pages 9-12 + 26-32). Die Lösungs- Seiten 51-98 werden bewusst zurückgehalten — sie sind die Ground- Truth für späteren Vergleich.
Der Konzept-Generator (Claude Sonnet 4.6, max_tokens 64.000, streaming) produziert in ~30-60 Sekunden ein 9-Section-Konzept. Default-Variant erzeugt ~27.000 Zeichen, Variant F „Bauantrag- ready" erzeugt ~35.000 Zeichen mit deutlich erhöhter Citation- Dichte (Section 5 Anlagentechnik: 2 → 7 Citations, Section 6 Organisatorisch: 1 → 4 Citations).
Der PrüfSV-Schatten startet einen 5-Runden-Dialog gegen das Konzept (~$1.50, ~5-10 min Walltime). Round 1: Einwand-Katalog mit 10-15 spezifischen Einwänden, jeweils mit Schwere (KRITISCH/ AUFLAGE/HINWEIS), Schutzziel-Bezug und §-Verweis. Round 2: Fachplaner-Antworten (akzeptiert/verteidigt/widersprochen). Round 3: Prüfer-Reaktion (konsensual/strittig/Nachbesserung). Round 4: Fachplaner-Replik. Round 5: Final-Verdict mit Audit-Memo.
Der Trace-Builder (scripts/build_run_trace.py) parst beide Markdown-Outputs zu strukturiertem JSON mit per-Topic-Konfidenz- Score (stark/plausibel/schwach/spekulativ) und Coverage-Matrix gegen die im Pärchen erwarteten Ontologie-Konzepte.
Der Audit-Trail-Viewer unter /runs/<id> rendert alles als collapsible Process-Boxen — pro Topic Konfidenz-Badge mit Indikatoren (Annahmen-Count, Hedge-Density, U-Flag-Count, Citation-Count), pro Dialog-Thread alle 4 Tausch-Stufen einzeln aufklappbar mit Final-Status-Color-Code.

# 2. Architektur

5-Layer-Pipeline:

Eingangs-PDF                Pair-YAML-Schema
     │                            │
     └──────────┬─────────────────┘
                ▼
   ┌─────────────────────────────────────┐
   │ 1. INGESTION & PÄRCHEN-DB           │
   │   data/training-pairs/*.yaml        │
   │   PDF lokal (.scratch/ oder public/)│
   │   Aufgabe- ⊂ Lösungs-Page-Trennung  │
   └─────────────────────────────────────┘
                ▼
   ┌─────────────────────────────────────┐
   │ 2. KONZEPT-GENERATOR                │
   │   .scratch/run_pair_001_eval.py     │
   │   Claude Sonnet 4.6 + 7 Slider      │
   │   data/run-configs/variants.json    │
   └─────────────────────────────────────┘
                │
                ▼ Konzept-MD
   ┌─────────────────────────────────────┐
   │ 3. PRÜFSV-SCHATTEN-DIALOG           │
   │   .scratch/run_pair_001_dialog.py   │
   │   Claude Sonnet 4.6 × 5 Rounds      │
   │   Beide Personas adversarial        │
   └─────────────────────────────────────┘
                │
                ▼ Dialog-MD
   ┌─────────────────────────────────────┐
   │ 4. TRACE-BUILDER                    │
   │   scripts/build_run_trace.py        │
   │   Konfidenz-Score + Coverage        │
   └─────────────────────────────────────┘
                │
                ▼ data/run-traces/*.json
   ┌─────────────────────────────────────┐
   │ 5. AUDIT-TRAIL-VIEWER               │
   │   web/app/runs/[id]/page.tsx        │
   │   6 collapsible Process-Boxen       │
   └─────────────────────────────────────┘

Stack:

Backend: Python 3.12, anthropic SDK, pypdf, azure-identity
- azure-keyvault-secrets für API-Key-Pull, pyyaml für Pärchen- Schema. Tests pytest 238/238 grün (Stand 2026-05-04), ruff format/lint sauber, pyright basic-mode 0 errors.
Frontend: Next.js 15 App Router, React 19, vanilla CSS-Variables für Theme-System (light/dark + Teams ?theme=-URL-Param), native <details>-Tags für Collapsibility (kein React-State-Management für UI-Boxen nötig). 16 Routes prerendered (Stand 2026-05-06): Dashboard, Upload, Schwarm, Wissensgraph, Agents, Lab, Pipeline, Portale, Avatar plus dynamische /runs/[id] (SSG).
Cloud-Hosting: Azure Container Apps app-fire für Orchestrator, app-bot-fire für Teams-Bot, app-personal-fire für Workspace. Cosmos DB + Azure SQL + Cognee Knowledge Graph als Triple-Storage. Auth via User-Assigned Managed Identity mi-fire (kein Bot- Password). CI über GitHub Actions mit OIDC Federated Credentials (kein Static Client Secret).
Discovery: SerpAPI für Schwarm-Discovery. Aktuelle Skripte: scripts/sustainable_swarm.py (production-grade mit Atomic-Write, Resume, 36 Provenance-Pattern, Anti-Dup gegen vorherige Runs); Schwarm #1 hat 1002 URLs in 70 Sekunden indiziert.

Multi-Truth-Architektur (gilt seit 2026-05-01, Memory feedback_three_truths_green.md HARDCODED): Vor jedem Phasenwechsel müssen alle drei Wahrheiten grün sein:

Lokal: pytest + ruff + pyright + az bicep build
GitHub: alle Workflow-Runs grün (gh run list --limit 5)
Azure: az deployment group list -g rg-fire zeigt alle Sub- Module succeeded — nicht nur der GitHub-Workflow-Status

Lesson aus 14 Failed-Deploys vor 2026-04-29: GitHub-Action-Status zeigt nur Pass/Fail des gesamten Workflows; welches Sub-Bicep-Module gefailt ist, steht ausschließlich in der Azure-Deployment-History (Memory reference_deploy_lessons.md).

# 3. Konzept-Generator mit 7 Slidern

Der Generator lässt sich parametrisch steuern über 7 Slider, die nicht was der Agent argumentiert, sondern wie hart er argumentiert beeinflussen. Hohe Slider-Werte produzieren keine norm-widrigeren Ergebnisse — sie produzieren defensiv-härtere Konzepte mit pre-emptiver Argumentation gegen jeden potentiellen Prüfer-Einwand.

Die 7 Slider (Vollständige Spec in data/run-configs/schema.md):

Slider	Pol 0	Pol 100
Argumentations-Schärfe	minimalistisch	maximaldefensiv
Kompensations-Stil	bauliche Trennung	anlagentechn. Vollschutz
Denkmal-Strenge	brandschutz-priorisiert	substanz-priorisiert
Nachweis-Tiefe	Vorkonzept	ausführungsreif
Risiko-Akzeptanz	konservativ-eliminieren	bewusst-akzeptiert
Counter-Example-Pressure	aus	devil's advocate
Precedent-Anchoring	optional	gerichtsfest

7 Variant-Presets (entsprechen den Lab-Variants A-F im v0.3.0-Schema, Memory project_session_state_2026-05-04.md):

Variant	Charakter	Use-Case
`default` / `B_baseline`	Standard-Fachplaner, alle Slider 50	erster Wurf
`A_konservativ`	Norm-strikt, bauliche Lösung bevorzugt	Bauanträge ohne Sonderfall
`C_anlagentechnik`	BMA Kat 1 als universal-Kompensator	Geburtig-Modus, Bestand
`D_denkmal_priorisiert`	Substanz-Erhaltung als Leit-Schutzziel	Baudenkmal-Sanierung
`E_adversarial`	Sucht aktiv eigene Schwächen	Pre-Audit, Compliance
`F_consulting_vs_audit`	Voller Argument-Trail, Bauantrag-direkt-einreichen	Sales-Demo, finale Konzepte

Beispiel-Wirkung Default vs Variant F (gemessen 2026-05-05 am pair_001 Mammitzsch Görges-Bau):

Indicator	Default	Variant F	Delta
Body chars total	26.922	34.783	+29%
Citations Section 5 (Anlagentechnik)	2	7	+250%
Citations Section 6 (Organisatorisch)	1	4	+300%
Citations Section 4 (Bauliches)	1	3	+200%
Citations Section 1 (Klassifikation)	4	5	+25%
Annahmen explizit benannt	12	8	-33% (mehr aus Daten verifiziert)

Der Slider-Effekt ist im Dialog-Outcome ebenfalls sichtbar: Default hatte 1 ungeklärten Punkt (E-07 Hörsaal-2.RW); Variant F hatte 0 ungeklärt, dafür mehr „nachzuweisen" (7 vs 4) — der Variant-F- Agent hat den ungeklärten Punkt pre-emptive im Konzept adressiert und stattdessen mehr Detail-Tiefe gefordert. Beide Verdicts: KONDITIONAL (Bauantrag bei Vorlage der Nachweise genehmigungsfähig).

# 4. PrüfSV-Schatten-Dialog

Der Konzept-Generator allein ist eine LLM-Stimme. Für Vertrauen brauchen wir sichtbar-kontroverse Diskussion vor der Lieferung. Der PrüfSV-Schatten ist ein zweiter Agent mit gegenteiligem Mindset, der das Konzept stress-testet. Patterns analog zu echten Ingenieurbüros: Senior + Junior, einer advokat einer challenger, Entscheidung emergiert aus dem Dialog.

Persona-Konfiguration:

	Fachplaner-Agent	PrüfSV-Schatten
Mindset	erleichterungs-orientiert	risiko-orientiert
Hebel	SächsBO § 67 + Schutzziel-Äquivalenz	§ 14 MBO + Norm-Konformität
Bauherr-Beziehung	bezahlt durch Bauherr	unbeteiligungs-pflichtig
Letztwort	nein	ja (Bescheinigung muss vor Gericht halten)

5-Runden-Struktur (.scratch/run_pair_001_dialog.py):

Round	Akteur	Aufgabe	Format
R1	PrüfSV	Einwand-Katalog	10-15 × `E-XX`-Punkte mit Schwere (KRITISCH/AUFLAGE/HINWEIS) + Schutzziel-Bezug + §-Verweis
R2	Fachplaner	Antwort pro Einwand	`A-XX` mit Reaktions-Tag (✅ akzeptiert / 🛡 verteidigt / ⚖ widersprochen) + Konzept-Konsequenz
R3	PrüfSV	Re-Bewertung	`Re-XX` mit Status (✅ konsensual / 🟡 strittig-weiter / ❌ Nachbesserung) + ggf. Verschärfung
R4	Fachplaner	Replik nur auf 🟡/❌	`A2-XX` mit Konzept-Modifikation oder finalem Argument oder Eskalation
R5	PrüfSV	Final-Verdict + Audit-Memo	Tabelle aller `E-XX` mit Status + Auflagen-Liste + Verbleibende Risiken + Audit-Trail-Zusammenfassung

Final-Verdict-Stufen:

ZUSTIMMEND — sofort genehmigungsfähig
ZUSTIMMEND-MIT-AUFLAGEN — genehmigungsfähig bei Erfüllung formaler Auflagen
KONDITIONAL — bei Vorlage genannter Nachweise (Fachgutachten, Bestandspläne) genehmigungsfähig
NACHBESSERUNG-ERFORDERLICH — Konzept ist substanziell zu überarbeiten

Unsicherheits-Kategorisierung — Pflicht statt „unklar"- Schreibweise:

Beide Personas müssen, wenn sie einen Punkt nicht abschließend bewerten können, eine von fünf Kategorien explizit benennen:

U-DATA — Aufgaben-Daten unvollständig (was genau fehlt?)
U-NORM — Norm-Anwendbarkeit unklar (welche § konkurrieren?)
U-AUTH — Außerhalb der Kompetenz, Bauaufsicht/LfD entscheidet
U-LIMIT — Außerhalb der Vorplanungs-Ebene, gehört in LP 5
U-EVID — Evidenz im Konzept fehlt, Fachplaner muss nachweisen

Diese Kategorisierung wandert direkt in den Audit-Trail (U-AUTH/U-EVID/Restrisiko-Sektion des Final-Verdicts) und in die Konfidenz-Score-Berechnung pro Topic.

Beispiel pair_001 Mammitzsch Görges-Bau, Default-Run (Stand 2026-05-05):

Total Einwände:                15
✅ Konsensual:                   4
🟢 Zustimmend mit Auflage:       6
🟡 Nachzuweisen:                 4
❌ Ungeklärt:                    1   (E-07 Zweiter Rettungsweg
                                    Hörsaal 226 — ohne Grundrissplan
                                    nicht bewertbar)
─────────────────────────────────
Final-Verdict:                 KONDITIONAL
Auflagen:                      20  (formale Bauantrags-Auflagen)
Verbleibende Risiken:          5 U-AUTH + 3 U-EVID + 2 Restrisiken

Token-Verbrauch: ~305.000 input + ~49.000 output → ~$1.64 pro vollständigem 5-Round-Dialog (Sonnet-4.6-Pricing).

# 5. Audit-Trail-Viewer (`/runs/`)

Jeder Konzept-Run wird im Trace-Builder zu einer JSON-Datei verarbeitet (data/run-traces/<run-id>_trace.json) und unter /runs/<id> gerendert. Layout-Anker: LM-Studio-Model-Parameters- Panel adoptiert auf unsere Domain — collapsible <details>-Boxen, Konfidenz-Badges, Slider-Panel.

6 Process-Boxen (jede aufklappbar):

Box	Inhalt	Default
📥 Intake	Pair-ID + PDF-Pfad + Lizenz + welche Pages reingingen + welche Lösungs-Pages bewusst zurückgehalten	zu
🔍 Analyze	Vollständige Vorbemerkung des Konzepts + Annahmen-Count A1-A12 (was hat der Agent vorab vom PDF verstanden?)	zu
🛠 Generation per Topic	9 Sections, jede mit Konfidenz-Badge + per-Section-Indikatoren + Volltext zum Aufklappen	offen
📊 Coverage Matrix	11 erwartete Ontologie-Konzepte × Mention-Count + Status (vollständig/angeschnitten/fehlt) mit Farbleiste	offen
💬 Dialog (5 Rounds)	15 Einwände-Threads E-01 bis E-15, jeder mit Final-Status-Color (✅/🟢/🟡/❌), alle 4 Tausch-Stufen aufklappbar	zu
🎯 Final-Verdict	Verdict + Begründung + vollständiger Round-5-Block (alle Auflagen + Restrisiken + Audit-Trail-Zusammenfassung)	offen

Plus ein Slider-Panel unten (web/app/runs/[id]/slider-panel.tsx) mit Variant-Preset-Dropdown, 7 Slidern (Range + Number-Input pro Slider, Endpunkt-Beschriftung „minimal" → „maximaldefensiv" etc.) und Run-Command-Preview unten — kopierbar, „Custom"-Marker bei Slider-Abweichung vom Preset.

Konfidenz-Score-Algorithmus (scripts/build_run_trace.py):

score = 100
       - 8 × annahmen_count       (explizite "Annahme A1:" Markers)
       - 3 × hedge_count           (vermutlich, ggf., ca., wahrscheinlich)
       - 5 × u_flag_count          (U-DATA / U-NORM / U-AUTH / U-LIMIT / U-EVID)
       + 2 × min(citations, 10)    (§-Verweise, DIN-Refs, etc.)

Mapping zu Label + Farbe:
  ≥ 80 → stark      (grün, var(--good))
  ≥ 60 → plausibel  (blau, var(--info))
  ≥ 40 → schwach    (gelb, var(--warning))
  <  40 → spekulativ (rot,  var(--bad))

Dieser Score ist absichtlich grob (Heuristik basierend auf Hedge- Density + Annahmen-Count + U-Flag-Count + Citation-Boost). In den gemessenen Runs am pair_001 ergaben alle 9 Sections Score ≥ 85 (Label „stark") — das Konzept ist gut strukturiert und Annahmen sind konsequent in der Vorbemerkung gebündelt statt in den Sections verstreut. Ein „spekulativ"-Score würde ein massiv über-extrapoliertes Konzept anzeigen, was ein Warnsignal für den Reviewer wäre.

Coverage-Matrix-Algorithmus:

Pro im Pärchen-YAML erwartetem Ontologie-Konzept (z.B. „Schutzziel", „Gebäudeklasse", „Versammlungsraum / Versammlungsstätte", „Brandabschnitt") wird das gesamte Konzept-Markdown mit Synonym- Expansion durchsucht. Synonym-Lexikon:

BMA ↔ Brandmeldeanlage
RWA ↔ Rauchableitung ↔ Rauchabzug
GKL ↔ Gebäudeklasse ↔ GK 1...GK 5
versammlungsraum ↔ versammlungsstätte ↔ vstättvo ↔ nvstättvo ↔ sächsvstättvo
(vollständige Liste in scripts/build_run_trace.py:SYNONYME, Backlog-Item B29 schiebt das in eine eigene data/ontology/synonyms.json)

Status-Mapping:

≥ 3 Mentions → ✅ vollständig (grün)
1-2 Mentions → ⚠ angeschnitten (gelb)
0 Mentions → ❌ fehlt (rot)

Im pair_001 Default-Run sind alle 11 erwarteten Konzepte vollständig abgedeckt. Bei einem schlecht abdeckenden Konzept würde diese Matrix zeigen, welche Themen fehlen — direkter Hinweis-Geber für den Reviewer.

# 6. Wissensgraph

Der Cognee Knowledge Graph ist der Wissens-Backbone der Plattform. Stand 2026-05-17: 1213 Nodes / 8578 Edges, gewachsen aus drei abgeschlossenen Sprints (1 + 2 + 2.6) plus 73 emergente Patterns aus 14 NotebookLM-Phasen.

Coverage:

Brandschutz-Sitemap-Coverage: 65% (527 von 813 Baunetz- Brandschutz-URLs mit BFS-Crawl bis Fixpunkt indiziert, 2026-05-04)
166 echte Rechtsquellen + 2 Praxis-Leitfäden als Wurzel-Nodes mit Volltext-Preview
- Cross-Edges (9 Familien — siehe Tabelle unten)
73 emergente Argumentations-Patterns aus NotebookLM-Material, geparsed in data/notebooklm/emergent_patterns.jsonl

KB Sprint 1 (abgeschlossen 2026-05-05, 102 Cross-Edges, 770 Seiten Volltext-Korpus):

Quellengruppe	Items	Volumen	Cross-Edges	Commit
vfdb-Leitfaden TB 04-01 (Ingenieurmethoden)	9 Kapitel-Nodes	494 Seiten / ~1 MB	50	`4f563b3`
8 Mustervorschriften (MBO/MPPVO/MVStätt/MVKVO/MGarVO/MHHR/MIndBauRL/MSchulb)	8 enriched	265 Seiten / 685k Zeichen	30	`056d4a1`
6 Anbieter-Curricula (EIPOS/TÜV-Rh/TÜV-Nord/BZB/FeuerTrutz/IQ-Zert)	8 Curriculum-Pages	~3 MB HTML	22	`e8c1cc7`

KB Sprint 2 (abgeschlossen 2026-05-16, +97 Nodes inkl. 73 Patterns, +260 Edges):

Quellengruppe	Items	Commit
Bundesrecht (BauGB, BauNVO, GEG, ROG, BNatSchG)	5/5	`c7551d7`
16 Landesbauordnungen (LBOs)	16/16	`c7551d7`
MVV TB Bund + 16 VV TB Länder	17/17	`c7551d7`
Vergabeverordnung (VgV)	1/1	`c7551d7`
Fachrecht (DSchG + WG + StrG + LPlG × 16 Länder)	58/64	`c7551d7`
Cleanup-Mirror-Retries (5 Failures nachgezogen)	+5	`81bcf96`

KB Sprint 2.6 (abgeschlossen 2026-05-17, +21 Nodes, +40 Edges): ausgelöst durch Lücken-Analyse anhand BauR-Archiv-Benchmark (Sungwoo Kim, Vercel-App, Stefan-Truthän-Input).

Quellengruppe	Items	Detail
Brandschutz-Bundesverordnungen	11/11	ArbSchG, ArbStättV, GefStoffV, BetrSichV, BImSchG + 1./4./12. BImSchV, WHG, AwSV, SchfHwG
FeuVO Länder (Feuerungsverordnungen)	10/14	BW, BB, MV, NRW, RP, SL, SN, ST, SH, TH (BE+HB aufgehoben, 4 als B60-Backlog)

Master-Quellenregister: data/notebooklm/master_quellenregister.jsonl konsolidiert 238 Records (166 ingestiert + 58 backlog mit Trigger). Single source of truth für „was haben wir / was fehlt".

Visualisierung:

/graph-Tab: zwei Views nebeneinander — „Fest" (konzentrische Ringe) und „Dynamisch" (Force-Directed via react-force-graph-2d)
Filter-Pillen pro Konzept-Typ (Bootstrap, Rolle, Spezialisierung, Zertifikat, Anbieter, Norm, Verordnung, Richtlinie, Baunetz, Stub, ResearchOutput, Quelle)
Freeze-Toggle für Inspect-Mode, Labels-Toggle für dichte Views

Verwendung im Konzept-Generator:

Der Wissensgraph dient als Retrieval-Quelle für den Slider precedent_anchoring. Bei Wert ≥ 67 fordert der System-Prompt: "Pro Section MINDESTENS 2 Citations zu §, DIN, Richtlinien. Wenn historische Präzedenz-Bauten bekannt sind, explizit zitieren (Format: 'in N ähnlichen Bauten genehmigt nach Bauaufsicht X'). Ziel: gerichtsfeste Begründung." Der Live-Lookup gegen den KG ist Backlog-Item B25 (Live-Konfidenz-Indikator) — aktuell zieht der Generator aus dem System-Prompt-Kontext + Trainings-Wissen.

# 7. Datengovernance

Dies ist der wichtigste Abschnitt für Sales-Vertrauen. Die Plattform ist explizit darauf ausgelegt, dass jede Datenquelle in einer Compliance-Audit nachweisbar wird.

HARDCODED-Regel: HHP-Customer-Daten gehen niemals in Trainings-, Eval- oder Discovery-Pipelines. User-Quote 2026-05-05:

„Momentan will ich noch vermeiden dass die HHP in mein Trainingsmodell läuft. Bisher habe ich nichts was nicht auch online verfügbar wäre."

(Memory feedback_hhp_data_out_of_trainingsmodel.md HARDCODED.)

Konsequenzen heute:

public/*.pdf (auch HHP-BSNs aus E2E-Smoke-Tests) liegen lokal, gitignored, werden NICHT für Agent-Eval verwendet
Trainings-Pärchen kommen ausschließlich aus Public Sources (Hochschul-Repositorien, Bauleitplanungs-Auslegungen, Verbands-Beispielsammlungen, FeuerTrutz-Open-Releases)
Wissensgraph + Run-History dürfen nur public-Material enthalten — niemals HHP-Customer-Identifikatoren in committed JSON
private/ ist root-gitignored, leer, reserviert für rein lokale Customer-Materials wenn jemals nötig

Pärchen-Anonymisierung (Memory feedback_data_ethics_pruefer_identitaet.md): Privat-Bauherren- Namen werden vor Pipeline-Use geschwärzt. Bei pair-Candidate #4 „Demenzpflege Niedertraubling" ist das Pflicht (Privatperson Andreas Frieser als Bauherr); bei pair-Candidate #5 „MIN-Forum Hamburg" ist es nicht nötig (HmbTG-Akte = explizit öffentliches Material).

Provenance-Trail: Jede Datenquelle bekommt im Pärchen-YAML einen lizenz_status-Eintrag. Der Sustainable-Schwarm (scripts/sustainable_swarm.py) klassifiziert URLs automatisch nach 36 Domain-Pattern in folgende Klassen:

public_hmbtg — Hamburgisches Transparenzgesetz, Confidence 1.0
public_iberg — Berliner Informationsfreiheitsgesetz, Confidence 1.0
public_baugb — BauGB-Bürgerbeteiligung kommunal/Land, Confidence 0.85-0.95
public_dnb — Deutsche Nationalbibliothek, Confidence 1.0
public_uni — Hochschul-Repository, Confidence 0.85-0.95
public_bund — Bundesamt für Bauwesen / BBSR / DIBt, Confidence 0.9
public_kammer — Architekten-/Ingenieurkammer, Confidence 0.7
editorial — redaktionelle Artikel (Baunetz, Detail), Confidence 0.5
commercial — Verlag/lizenzpflichtig (FeuerTrutz), Confidence 0.4
tbd_check — unbekannte Domain, Pflicht-Prüfung vor Pipeline-Use

Compliance-Story für den Pitch: „Jede Quelle in unserem Trainings-Datensatz hat einen Provenance- Trail mit License-Claim und Confidence. Wir können auf Verlangen für jede Aussage des Agents die Datenherkunft nachweisen — von der Bauleitplanungs-Auslegung kommunaler Beteiligungsportale bis zur publizierten Diplomarbeit einer Hochschule mit DOI."

# 8. Methodische Säulen (ADR-0018)

Die Plattform erreicht Research-Grade-Niveau durch vier methodische Säulen, gemeinsam dokumentiert in ADR-0018 (2026-05-03).

Säule 1: Citation-Trail-Determinismus

Jede Aussage im Konzept hat eine zurückverfolgbare Quelle. Im Trace- Builder zählen wir Citations pro Section explizit (§-Verweise, DIN- Refs, VdL-Arbeitsblätter, MLAR, IndustrieBauRL etc.) und integrieren sie in den Konfidenz-Score. Der Slider precedent_anchoring zwingt bei hohem Wert zwei Citations pro Section. Ziel: in einer Audit kann jede Aussage rückverfolgt werden — keine „weil das LLM es gesagt hat"-Lücken.

Säule 2: 4-Stufen-Konfidenz-Pyramide

stark / plausibel / schwach / spekulativ. Sichtbar pro Section im Audit-Trail-Viewer. Eine Aussage mit Score < 60 wird visuell anders dargestellt (gelb/rot-Badge) — der Reviewer sieht sofort, wo das Konzept Schwächen hat. Diese Pyramide ist auch das Pricing-Hebel: ein Konzept mit ausschließlich „stark"-Sections kann teurer angeboten werden als eines mit „schwach"-Sections.

Säule 3: Multi-Layer-Triangulation

Drei Korpus-Schichten triangulieren jede Empfehlung:

Normativ (LBOs, Sonderbau-VOs, MBO, MVStättVO, MIndBauRL etc.)
Praxis (Mustervorschriften, vfdb-Leitfäden, FeuerTrutz-Beispiele, Architektenkammer-Best-Practices)
Curriculum (EIPOS / TÜV / BZB / FeuerTrutz / IQ-Zert Zertifizierungs-Curricula — was muss ein Fachplaner können)

Eine Empfehlung gilt als „stark" wenn sie aus mindestens zwei dieser drei Schichten belegt ist. Layer 1 + 2 ist heute aktiv im KG; Layer 3 (Curriculum-Tiefenextraktion) ist Backlog (Memory project_layer3_curriculum_pending.md).

Säule 4: Falsifizierbarkeit via A/B-Tests im Lab

Jede Architektur-Entscheidung kann gegen Lab-Variants A-F gemessen werden. Variants A-F sind ceteris paribus — gleicher Input, gleiches Pärchen, nur die Slider-Konfiguration ändert sich. Der LabTestRun-Container (Cosmos lab_test_runs) speichert pro Variant die Outputs, der validation_gate.py mit State-Machine + 4 NoGo- Asserts setzt Schreibschutz wenn ein Variant offensichtlich manipuliert wäre.

Der erste geplante A/B-Test (Memory project_cognee_a_b_test_lab.md): Cognee Structured-First vs Raw-First über denselben 3-Layer-Korpus. Konsequenz: jede Architektur-Entscheidung muss gegen die 4 Säulen geprüft werden, jeder A/B-Test wird mit Falsifikator + Mess-Metriken vorab dokumentiert.

# 9. Trainings-Pärchen-Datensatz

ID	Quelle	Schlüssel-Strategie	Status
`pair_001_mammitzsch_goerges-bau`	TU Dresden Diplomarbeit 2024	Re-Klassifizierung Flur → Versammlungsraum	muster_vollstaendig
`pair_002_geburtig_scharoun-theater`	FeuerTrutz Dossier 2020 (Branchenpreis 2018)	Anlagentechn. Kompensation BMA Kat. 1 als universal pattern	muster_vollstaendig
`_candidates_2026-05-05.md`	7 weitere PDFs vom User gedroppt	Provenienz-Klärung offen	candidate
Sustainable-Schwarm-Iteration #3 (`scripts/sustainable_swarm.py`)	41 Slices Welle 1 über 5 Quellen-Klassen	divers — pro Quelle eigene Strategie	bereit, ungeladen

Strategien-Diversifikation (das Killer-Asset des Datensatzes): Die ersten beiden vollständigen Pärchen zeigen unterschiedliche Schlüssel-Strategien für vergleichbare Bestand+Denkmal+Versammlungs- Konflikte:

Re-Klassifizierung (Mammitzsch): Flur als Versammlungsraum neu definieren → erleichternde Anforderungen statt strenger Flur- Regeln
Anlagentechnische Kompensation (Geburtig): BMA Kat. 1 Vollschutz nach DIN 14675 als universal-Kompensator für 5 verschiedene Erleichterungen tabellarisch
Bauliche Trennung (Claude-generated, default-Variant gegen pair_001): Lichthof als eigenständiger Brandabschnitt mit EI 30- Glasverglasung + Sprinkler-Kompensation nach SächsBO § 67

Das Eval testet, ob unser Agent diese Diversität erkennt und situations-abhängig auswählt — nicht nur eine Strategie reflexhaft anwendet. Variant-D (Denkmal-priorisiert) sollte Mammitzsch-Pattern bevorzugen; Variant-C (Anlagentechnik) sollte Geburtig-Pattern bevorzugen.

# 10. Sales-Story (3 Kernpunkte)

Kernpunkt 1 — Audit-Trail-Determinismus:

"Unser Agent generiert ein Brandschutzkonzept aus dem Eingangs- Aufgabenpaket, lässt es durch einen simulierten Prüfingenieur stress-testen, und liefert dir das Audit-Memo dazu — alles transparent nachvollziehbar."

Demo-Skript (3-5 Minuten in einem Pitch):

Öffne /runs/pair_001_run_20260505T164533Z (Default-Run)
Zeige Box „Generation per Topic" — 9 Sections mit Konfidenz- Badges (alle ≥ 85 / „stark")
Klicke Box „Coverage Matrix" — alle 11 Ontologie-Konzepte ✅ vollständig
Klicke Box „Dialog (5 Rounds)" — zeige einen Thread (z.B. E-05 Sprinkler-Äquivalenz) komplett aufgeklappt mit allen 4 Tausch- Stufen
Klicke Box „Final-Verdict" — KONDITIONAL mit 20 Auflagen + 5 Restrisiken explizit kategorisiert (U-AUTH/U-EVID/Restrisiko)

Kernpunkt 2 — Parametrische Härte-Steuerung:

"Du steuerst über 7 Slider die Argumentations-Härte: konservativ- norm-strikt bis bauantrag-ready-mit-vollem-Argument-Trail. Hohe Werte produzieren keine norm-widrigeren Ergebnisse — sie produzieren defensiv-härtere Konzepte mit pre-emptiver Argumentation gegen jeden potentiellen Prüfer-Einwand."

Demo-Skript:

Im selben Run-Page: scrolle zu Box „Steuerung & Re-Run"
Wähle Variant-Preset „F — Bauantrag-ready (Consulting+Audit)" — alle 7 Slider verschieben sich
Zeige den Run-Command unten — kopierbar für lokale Re-Runs
Wechsle zu /runs/pair_001_run_20260505T174319Z_F_consulting_vs_audit
Vergleichs-Tabelle (Default vs Variant F): +29% Body, +250% Citations Section 5, 0 ungeklärte Punkte statt 1

Kernpunkt 3 — Compliance-fähig durch Provenance-Trail:

"Jede Quelle in unserem Trainings-Datensatz hat einen Provenance- Trail mit License-Claim und Confidence. Wir können auf Verlangen für jede Aussage des Agents die Datenherkunft nachweisen."

Demo-Skript:

Öffne data/training-pairs/pair_002_geburtig_scharoun-theater.yaml
Zeige quelle.lizenz_status: lizenzpflichtig_feuertrutz_verlag plus Provenance-Pfad (lokal_pfad, lizenz_hinweis)
Erkläre Sustainable-Schwarm: 36 Domain-Pattern, Confidence-Score pro URL
Zeige Memory feedback_hhp_data_out_of_trainingsmodel.md — HARDCODED-Regel als gesperrte Disziplin

# 11. Roadmap (transparent — nicht versteckt)

Backlog B22-B33 in CLAUDE.md ist Teil der Doku, nicht Anhang. Prospect sieht organisierte Roadmap statt versteckter Lücken (Disziplin-Memory feedback_no_lipservice_in_commits.md HARDCODED).

Item	Was	Aufwand	Status
B22	Variant-F-Dialog	30 min	(b) ✅ 2026-05-05 / (a) ⏳
B23	Sampling-Sektion „Output-Disziplin"	2h	⏳
B24	Save-Preset-As für Custom-Variants	1.5h	⏳
B25	Live-Konfidenz-Indikator	2h	⏳
B26	Reviewer-Notes / Conversation-Notes-Input	1h	⏳
B27	„Enable PrüfSV-Schatten"-Toggle	1h	⏳
B28	Re-Submit-Pattern bei ❌-Punkten	2h	⏳
B29	Synonym-Lexikon Single-Source	1h	⏳
B30	Phase 2B: Web-trigger Re-Run-Button	2-3h	⏳
B31	Phase 3: Vergleichs-Ansicht 2 Runs	3h	⏳
B32	Disziplin-Regel HARDCODED	0	✅ Memory
B33	Dialog-Skript nach scripts/ promoten mit generischer pair-ID	30 min	⏳

Plus Vision-Item ohne B-Nummer noch (siehe Memory project_virtuelle_fachplaner_firma.md): Virtuelle Fachplaner-Firma mit benannten Agent-Identitäten + Multi-Agent-Diskussion. User erklärt Implementations-Strategie.

# 12. Was die Plattform NICHT kann (heute)

(Disziplin: keine versteckten Lücken — diese Liste ist Sales-Asset, nicht Schwäche-Eingeständnis.)

Keine Webhook-Triggered-Runs aus dem UI — aktuell Command-kopieren-und-lokal-ausführen-Workflow (B30 Roadmap).
Keine Side-by-Side-Variant-Vergleichs-View — Vergleich aktuell durch Aufrufen von zwei Run-URLs in zwei Tabs (B31 Roadmap).
Keine Brandschutzatlas-Lehrbuch-Integration — Lizenz-Klärung vorausgesetzt, dann via private/ebooks/ gemäß Memory project_ebook_ingest_pipeline.md (lokal-only, Output nur Cite/Paraphrase).
Keine Schwarm-Discovery für 500+ Konzepte — Skript bereit (scripts/sustainable_swarm.py, 41 Slices Welle 1, dry-run grün), Welle 1 wartet auf Go-Entscheidung.
Keine Multi-Agent-Diskussion zwischen mehreren spezialisierten Fachplaner-Agenten — heutiger Dialog ist 1 Fachplaner ↔ 1 PrüfSV. Multi-Agent-Engine ist eigener Workstream (Memory project_virtuelle_fachplaner_firma.md).
Keine HHP-Mandanten-Daten in der Pipeline — HARDCODED out-of-scope. Falls jemals benötigt: separater Storage-Container mit Access-Audit + Customer-Consent-Form pro Projekt + Anonymisierungs- Pipeline.

# Sektionen-Vollständigkeit

#	Sektion	Status
1	Was die Plattform macht	✅ Inhalt vollständig
2	Architektur	✅ Inhalt vollständig
3	7-Slider	✅ Inhalt vollständig
4	PrüfSV-Dialog	✅ Inhalt vollständig
5	Audit-Trail-Viewer	✅ Inhalt vollständig
6	Wissensgraph	✅ Inhalt vollständig
7	Datengovernance	✅ Inhalt vollständig
8	Methodische Säulen	✅ Inhalt vollständig
9	Pärchen-Datensatz	✅ Inhalt vollständig
10	Sales-Story	✅ Inhalt vollständig
11	Roadmap	✅ Inhalt vollständig
12	Was NICHT geht	✅ Inhalt vollständig

Pflege-Hinweis: Diese Doku altert mit jedem Commit. Vor jedem Sales-Pitch:

git log --since="2 days ago" — was hat sich geändert?
Sektionen mit konkreten Zahlen (3, 6, 9, 11) prüfen ob die Zahlen noch stimmen
Roadmap-Status (Sektion 11) auf den aktuellen B-Backlog-Stand bringen

Bei Major-Änderung (z.B. neue Sektion oder Architektur-Layer): hier verzeichnen, Commit-Hash dranschreiben.