Was Sie hier finden — Kurz-Methodik

Dieses Projekt mapped ~200 Forschungsfragen aus dem Forschungskatalog 2025 der Stadt Wien zu Klima-, Energie- und Stadt-Themen. Für jede Frage entsteht ein ~400-Wörter Forschungs-Brief mit Stand der Forschung, Forschungslücken, Trends und KI-Eignungs-Bewertung.

• Wer schreibt. Bernhard Götzendorfer mit KI-Assistenz (Claude Opus 4.7), Single-Editor-Workflow — kein Reviewer-Team, kein anonymer Peer-Review-Pool.
• Wie Quellen gefunden werden. Strikte Suchreihenfolge Wien zuerst → Österreich → EU → Global; pro Brief mindestens 3 Quellen, ≥1 Wien-Anker pro Cluster, ≥1 Quelle ≤3 Jahre alt, peer-reviewed oder institutionell (siehe §2).
• Wie Quellen verifiziert werden. Identifier-Hierarchie DOI → Permalink → institutionelles Registry; Crossref-Triangulation auf Titel und Erst-Autor:in; Wayback-Snapshot-Fallback bei Link-Risiko (siehe §19).
• Wie KI-Eignung bewertet wird. Vier Dimensionen — Datenverfügbarkeit, Aufgabentyp, Methoden-Reife, Ethik & Recht — werden mit 0/1/2/3 Punkten bewertet. Summe ergibt einen Score none / low / medium / high (siehe §12; volle Rubric: docs/ai-suitability-rubric.md).
• Wie Konfidenz markiert wird. Jeder Key-Claim trägt IPCC-Calibrated-Language-Tags (low/medium/high confidence, limited/medium/robust evidence, low/medium/high agreement).
• Was Sie pro Brief sehen. Ein kompakter Brief (~400 Wörter, Rahmen 320–700) über vier Sektionen (Stand · Lücken · Trends · KI-Eignung), jede Aussage an Quelle gebunden, KI-Eignung mit transparenter D1-D4-Aufschlüsselung, Liste der Top-3 Wiener Forschenden zum Thema (via OpenAlex-Mapping, manuell verifiziert).
• Was wir bewusst nicht behaupten. Keine Meta-Analyse, keine systematische Review nach PRISMA, keine ROBINS-I/GRADE-Qualitätsbewertung pro Quelle — siehe §13 Limitations.

Volle Versionierungs-Historie mit allen Methodik-Änderungen ab v1.3 findet sich am Ende dieser Seite unter §Changelog.

---

Recherche-Methodologie — Manual-First Pilot

1. Worum geht's

Dieses Dokument beschreibt den Recherche- und Brief-Workflow für die Phase-1-Pilot-Forschungs-Briefe des Projekts wien-forschungsfragen-klima. Ziel ist, dass jeder Forschungs-Brief — ob von Bernhard direkt im Hauptchat oder von einem Subagent erstellt — denselben methodischen Rahmen verwendet, sodass Quellen-Auswahl, Wortzahlen, Begriffe und KI-Eignungs-Bewertungen über alle Pilot-Outputs hinweg konsistent sind.

Format-Reframe (2026-05-12): Die ~400-Wörter-Dokumente werden customer-sichtbar „Forschungs-Brief" genannt (statt früher „Synthese"). Hintergrund: End2End-Audit gegen PRISMA-ScR / IPCC AR6 / DACH-Benchmark hat den Format-Anspruch-Inkonsistenz-Killer K6 identifiziert — 400 W + 6 Quellen sind im wissenschaftlichen Wortsinn keine Synthese, sondern ein Question-Brief / Forschungs-Brief. Die Umetikettierung macht den Anspruch ehrlich kongruent zur Lieferung. Engineering-Code-Variablen (synthesis_word_count, parseSynthesisBody, Pfade wie syntheses/) bleiben bewusst unverändert — kein Refactor-Risiko, dokumentierte Drift gemäß CLAUDE.md. Siehe docs/prd/2026-05-12-format-reframe-forschungs-brief.md für das vollständige Audit + Strategie-Pfad-Abwägung.

Kontext (Pivot 2026-05-09): Die ursprünglich angedachte programmatische Brief-Pipeline (Anthropic Batch API, apply-synthesis.ts etc.) wird in Phase 1 nicht gebaut — siehe docs/prd/2026-05-09-pilot-workflow-pivot.md §1-2. Stattdessen entstehen die ersten 15 Forschungs-Briefe manuell in Claude-Code Deep-Sessions auf Bernhards Mac mit Opus 4.7 (1M) aus seiner Subscription. Tool-Investments folgen erst, wenn ≥50 manuelle Briefe das Schema kalibriert haben (Pivot-PRD §3, Stufen 4-5).

Pilot-Umfang: 15 Fragen, davon 3 Goldstandards (WFK-2.1.5 als Customer-Sample/Anchor, WFK-1.4.1 als literatur-armer Edge-Case, WFK-6.1.1 als Cross-Discipline-Test) plus 12 Generalisierungs-Fragen aus dem Pilot-Set (Pivot-PRD §3 Stufe 1+2).

Goldstandard-Sequenz: Die 3 Goldstandards werden vor den restlichen 12 erstellt, weil sie das Schema kalibrieren. Erkenntnisse aus den Goldstandards fließen in §7 (Worked Examples) zurück und werden danach in den Pilot-Set-Briefen angewendet, nicht umgekehrt. Diese Sequenz ist die Voraussetzung dafür, dass die spätere Subagent-Parallelisierung (siehe Pivot-PRD §6) auf einem stabilen Schema operiert.

Primärsprache: Deutsch. Quellen dürfen englischsprachig sein (insb. EU-/Global-Layer), die Brief-Texte selbst sind aber DE.

Für Themenpat:innen

Diese Forschungsfragen sind nach 9 Clustern organisiert. Wenn Sie eine bestimmte Themenpatenschaft (z.B. MA 20 Energieplanung, Wien Energie) zugewiesen bekommen haben, finden Sie hier die relevanten Cluster:

1. Cluster 1: Energieversorgung — Briefe ansehen →
2. Cluster 2: Bau & Gebäude — Briefe ansehen →
3. Cluster 3: Kreislaufwirtschaft — Briefe ansehen →
4. Cluster 4: Mobilität — Briefe ansehen →
5. Cluster 5: Naturräume und Stadtökologie — Briefe ansehen →
6. Cluster 6: Klimafitte Grün- und Freiräume — Briefe ansehen →
7. Cluster 7: Klimagerechtigkeit — Briefe ansehen →
8. Cluster 8: Awareness und Teilhabe — Briefe ansehen →
9. Cluster 9: Märkte und Finanzierung — Briefe ansehen →

Für die vollständige Übersicht aller Briefe siehe die Forschungs-Briefe-Liste.

2. Recherche-Workflow pro Frage

Pro Frage gilt ein strikter Time-Box und eine strikt geordnete Quellen-Sequenz. Beides ist nicht-verhandelbar — wer nach 30 Minuten Recherche keine ausreichende Quellenbasis hat, dokumentiert das als Lücke und bricht ab; wer die Quellen-Reihenfolge umdreht, riskiert Wien-Anker zu verlieren.

2.1 Time-Box

| Phase | Dauer | Was passiert | |---|---|---| | Recherche | max. 30 min | Quellen suchen, lesen, exzerpieren, im Frontmatter-Source-Block sammeln | | Brief-Erstellung | max. 30 min | Stand der Forschung / Lücken / Trends / KI-Eignung schreiben, Wortzahlen prüfen |

Insgesamt also ca. 60 min/Frage netto, plus ggf. 10-15 min Quality-Checks. Diese Time-Box gilt für die Pilot-Phase. Sie ist absichtlich straff, um zu verhindern, dass einzelne Fragen disproportionale Tiefe erhalten und damit den Pilot-Schedule (3 Goldstandards à 2-3h Deep-Session, dann 12 weitere in ~6 Sessions) sprengen — siehe Pivot-PRD §3 Stufe 1+2.

2.2 Quellen-Whitelist-Reihenfolge

Quellen werden in dieser Reihenfolge durchgegangen, nicht parallel und nicht „nach Verfügbarkeit":

1. Wien-spezifisch (Primary) — Stadt Wien Klimaberichte, Wien Energie, Wiener Stadtwerke, Urban Innovation Vienna, GeoDatenViewer Wien, MA 22, MA 39. Ziel: mindestens eine Wien-Quelle als Lokalitäts-Anker. Wenn nach 10 min keine direkte Wien-Quelle gefunden wird, eine AT-Quelle mit Wien-Bezug verwenden und das im Frontmatter dokumentieren.
2. Österreich (Secondary) — BMK / BMLFUW, Klima- und Energiefonds, CCCA / APCC, Statistik Austria, Umweltbundesamt, BOKU / TU Wien / IIASA. Ziel: nationaler Kontext, Sektoren-Daten.
3. EU (Tertiary) — EEA, EUROSTAT, Climate-ADAPT, JRC, Open Research Europe, Covenant of Mayors, Cordis. Ziel: Vergleichsrahmen, EU-Politik-Kontext, Best-Practices anderer Städte.
4. Global (Quaternary, EN) — IPCC AR6, IEA, Nature Climate / Energy / Sustainability, arXiv, Google Scholar (DOI-only, ≥2022), C40 Cities, WRI. Ziel: State-of-Science.

Die Reihenfolge ist nicht „erst Wien, dann ignoriere den Rest". Sie heißt: starte bei Wien, höre nicht auf, bis genug abgedeckt ist. Ein guter Pilot-Forschungs-Brief hat typischerweise 1 Wien- + 1-2 AT-/EU- + 1-2 Global-Quellen.

Vollständige Quellen-Tabelle inkl. URLs, Zugang, Suchstrategie: siehe docs/source-catalog.md und Pivot-PRD §4.1-4.5.

2.3 Aufnahme-Kriterien pro Quelle

2.3.1 Identifier-Hierarchie (DOI-First, geordnet)

Die bisherige Disjunktion „DOI oder Permalink" (v1.1) ist aufgehoben. Stattdessen gilt eine strikte Identifier-Hierarchie — die jeweils höchstrangige verfügbare Form MUSS gewählt werden, nicht „die einfachste":

1. DOI — immer wenn verfügbar; Resolve via https://doi.org/<doi> und Crossref-Cache (scripts/check-links.ts).
2. Permalink — web.archive.org-Snapshot mit explizitem Datum (https://web.archive.org/web/<YYYYMMDD>/<url>).
3. Stabile URL — Eigene-Domain mit langem, versionierten Pfad-Pattern (z.B. https://www.wien.gv.at/stadtentwicklung/studien/pdf/b008765.pdf); nur wenn DOI nicht vergeben und kein Wayback-Snapshot praktikabel.
4. Plain URL — Notbehelf; nur zulässig mit gesetztem Pflicht-Feld doi_unavailable_reason: string im Frontmatter (Begründung warum kein DOI verfügbar, z.B. „AT-Behörden-Publikation ohne DOI-Vergabe").

DOI ist Pflicht, sofern verfügbar. Bei Sources ohne DOI MUSS doi_unavailable_reason: string im Frontmatter gesetzt sein (Schema-Pflicht via SQ-04, siehe schemas/source.zod.ts). Begründungen wie „nicht gesucht" oder „kein DOI gefunden" reichen nicht — verlangt ist eine konkrete strukturelle Begründung (z.B. „AT-Behörden-Publikation, keine DOI-Vergabe-Praxis im Herausgeber-Workflow"). Siehe docs/adr/0002-id-schema-frontmatter.md (Amendment 2026-05-09) für den Schema-Vertrag und docs/adr/0004-sidecar-pattern-mutating-metadata.md für archive_url als Sidecar-Feld.

2.3.2 Weitere Kriterien

• Recency: ≥1 Quelle ≤3 Jahre alt
• Peer-Review oder behördliche/institutionelle Herausgeber bevorzugt
• Open Access bevorzugt (ergibt sich aus Wien/AT/EU-Layer meist automatisch)
• Sprache: DE oder EN; andere nur, wenn unverzichtbar und mit DE-Zusammenfassung im Frontmatter

2.4 Source-Quality-Checkliste (pro Quelle)

Vor Aufnahme einer Quelle in das Korpus MUSS diese Checkliste vollständig durchlaufen werden. Sie ergänzt §2.3 um die operativen Verifikations-Schritte (statt nur Kriterien).

• [ ] Pre-Add-Verification (Hard). Vor dem ersten Frontmatter-Eintrag MUSS ein realer HEAD-/GET-Fetch der Ziel-URL und ein Content-Match-Check (≥ 60 % Wort-Overlap auf Titel ODER Erst-Autor:in) erfolgreich gewesen sein. Kein Eintrag „auf Verdacht", keine vermutete URL ohne Verification. Lehre aus SQ-08-A: spekulativ neu-zugewiesene URLs ohne Real-Fetch produzieren erneut broken Links (Re-URL-Versuch der ersten Triage-Welle hatte 0 % Erfolgsquote). Operativ über scripts/add-source.ts (siehe docs/runbook/source-add.md) erzwungen.
• [ ] DOI vorhanden + via Crossref resolved? Falls nein: ist doi_unavailable_reason mit konkreter struktureller Begründung gesetzt (siehe §2.3.1)?
• [ ] Wayback-Snapshot in archive_url vorhanden (Sidecar gemäß ADR-0004)? Mindestens für alle Non-DOI-Sources Pflicht; bei DOI-Sources empfohlen für Defense-in-Depth. Wayback-Fallback nur für aktuell erreichbare URLs: Die Wayback Save API kann nur Snapshots von Live-URLs anlegen. Genuine 404s ohne historischen Snapshot lassen sich nicht via archive_url retten — sie brauchen Source-Replace (siehe §6). Lehre aus SQ-09: 0/9 Wayback-Backfill-Erfolg auf bereits toten AT-Behörden-URLs.
• [ ] Content-Match verified — Title und/oder Erst-Autor:in im Body der Ziel-Seite tatsächlich vorhanden (≥ 60 % Wort-Overlap auf Titel ODER Erst-Autor:in)? Schützt vor HTTP-200-mit-falschem-Inhalt nach CMS-Migrationen.
• [ ] Tier korrekt zugewiesen (Wien / AT / EU / Global) gemäß docs/source-catalog.md Whitelist? Tier sitzt zentralisiert in data/source-catalog.yaml/sources_by_tier, nicht im Source-Frontmatter.
• [ ] OA-Status korrekt (gold / hybrid / green / none) gemäß DOAJ-/Unpaywall-Heuristik?

Quelle: PRD-Amendment 2026-05-09 §6 A-AC7 (Phase A Acceptance-Criterion); Pre-Add-Verification ergänzt durch SQ-08-A-Lessons (W3, 2026-05-10). Operativer Hook: scripts/add-source.ts (Pre-Add-Verification + DOI-Resolve + Wayback-Auto-Snapshot, SQ-11) und pnpm check:links --staged-sources-only (Reachability-Hard-Gate, siehe §5.3) prüfen die ersten vier Punkte automatisiert; Tier + OA bleiben Editorial.

3. Quality-Checklist Pre-Brief

Vor dem Schreibbeginn eines Forschungs-Briefs muss diese Checkliste vollständig abgehakt sein. Fehlende Punkte heißen: zurück in Recherche, nicht „pragmatisch weitermachen".

• [ ] WFK-ID + Frontmatter der Frage geladen, Cluster + Topic verstanden
• [ ] Mindestens 3 Quellen identifiziert
• [ ] Diversität: Quellen aus ≥2 verschiedenen Disziplinen (z.B. Stadtplanung + Energietechnik + Sozialwissenschaft)
• [ ] Autoren-Streuung: ≤30% der Quellen vom selben Autor / derselben Erst-Autorin
• [ ] Institutions-Streuung: ≤50% der Quellen aus derselben Institution
• [ ] Wien-Anker: mindestens 1 Wien-spezifische Quelle (oder dokumentierter AT-Fallback, siehe §2.2)
• [ ] Source-Frische: ≥1 Quelle aus den letzten 3 Jahren
• [ ] DOI / Permalink für jede Quelle vorhanden (Hierarchie gemäß §2.3.1)

Quelle: Pivot-PRD §5.1.

3.1 Diversitäts-Regeln (pro Cluster)

Diese Regeln gelten pro Cluster (nicht pro einzelnem Forschungs-Brief) und werden bei Cluster-Aufnahme in der Closure-Doku (docs/source-coverage-matrix.md, B-AC1) nachgewiesen. Phase A (W1-Draft) dokumentiert die Regeln; Pre-Commit erzwingt sie noch nicht (Phase B, B-AC2 via pnpm check:diversity --cluster=N).

• D1 — Disziplinen-Spread (Soft): ≥ 2 verschiedene Disziplinen pro Cluster. Begründungs-Pflicht in der Cluster-Closure-Doku, falls < 2 (z.B. „Cluster X ist methodisch monodisziplinär, weil …").
• D2 — Autoren-Spread (Soft): ≤ 30 % der Quellen pro Cluster vom selben Erst-Autor / derselben Erst-Autorin. Bei Überschreitung: Begründung dokumentieren (z.B. „Forschungsfeld dominant durch Gruppe X an Institution Y").
• D3 — Wien-Anker (Hard): ≥ 1 Wien-spezifische Quelle pro Cluster. Hard-Rule, dokumentiert in docs/source-catalog.md Whitelist und in der Cluster-Closure-Doku belegt. Fallback nur explizit als „AT-Quelle mit Wien-Bezug" markierbar (siehe §2.2), gilt aber nicht als vollwertiger Wien-Anker.
• D4 — Tier-Mix (Soft): Pro Cluster ≥ 3 der 4 Tiers (Wien / AT / EU / Global) vertreten. Reine Wien-AT-Cluster verarmen am State-of-Science; reine EU/Global-Cluster verlieren den Lokalitäts-Anker. Toleranz für Cluster mit struktureller Schieflage (z.B. Cluster 6 Grünraum: Wien + EU dominant, Global thin) — Begründung in Closure-Doku.
• D5 — Sprach-Mix (Soft): Quellen-Sprachen DE und EN beide vertreten pro Cluster (DE für Wien/AT, EN für EU/Global). Reine DE-Cluster verlieren State-of-Science-Anschluss; reine EN-Cluster verlieren Wien-Behörden-Sprache. Brief-Text bleibt unabhängig davon DE (siehe §1).

Operative Anwendung: Bei Cluster-Recherche in Phase B prüft die Editorial:e die drei Regeln gegen den nach Cluster-Add aktualisierten Korpus. Verletzungen werden in docs/source-coverage-matrix.md mit Begründung dokumentiert (Soft-Rules) bzw. blockieren das Cluster-Closure (Hard-Rule D3).

Quelle: PRD-Amendment 2026-05-09 §5 (Phase B Loop, Step 4) + §6 B-AC2.

4. Quality-Checklist Per-Brief

Während des Schreibens. Per-Sektion-Wortzahlen sind Richtwerte, bei Cross-Discipline- oder Multi-Kompartiment-Fragen ist Überschreitung bis ~+20 % zulässig (Goldstandard-Präzedenz: WFK-6.1.1 Forschungslücken 120 Wörter wegen qual+quant). Harter Stop ist die Brief-Gesamt-Wortzahl 320–700 (interne Code-Variable: synthesis_word_count; schema-seitig erzwungen via schemas/question.zod.ts für Status drafted/reviewed/published).

Wortzahl-Rahmen (Stand 2026-05-18): Das Zielformat bleibt ein kompakter ~400-Wörter-Brief. Der harte Gesamt-Deckel liegt bei 700 Wörtern (vormals 600). Hintergrund: Briefe mit personenbezogenen Daten tragen einen verpflichtenden DSGVO-Art.-35-DPIA-Disclaimer (§15) und — bei KI-Hochrisiko-Anwendungen — einen parallelen EU-AI-Act-Annex-III-Block (§15, Verordnung (EU) 2024/1689). Diese rechtlich gebotenen Bausteine addieren pro betroffenem Brief rund 10–80 Wörter, überwiegend in der KI-Eignungs-Bewertung. Der Deckel wurde angehoben, statt belastbare Compliance-Inhalte zu kürzen; Spec und schema-seitiger Validierungs-Range sind damit deckungsgleich.

• [ ] Stand der Forschung 80–200 Wörter (Richtwert), evidence-based, jede Aussage an mindestens eine Quelle gebunden
• [ ] Forschungslücken 80–150 Wörter (Richtwert), konkret (z.B. „keine Längsschnittstudien Wien-spezifisch ≥5 Jahre", nicht „mehr Forschung nötig")
• [ ] Trends 80–150 Wörter (Richtwert), mit Zeithorizont (z.B. 2025-2030 oder 2030-2040)
• [ ] KI-Eignungs-Score (none / low / medium / high) gesetzt, mit Begründung gemäß Rubric
• [ ] KI-Eignungs-Bewertung 80–180 Wörter (Richtwert; der Korridor liegt über den übrigen Sektionen, weil DPIA-/EU-AI-Act-Compliance-Bausteine hier verortet sind, siehe §15)
• [ ] KI-Use-Cases ≥1 konkret, mit Wien-Kontext (z.B. „Mikroklima-Modellierung MA 22-Geodaten")
• [ ] Brief-Gesamt-Wortzahl 320–700 Wörter (HART; intern: synthesis_word_count)

Quelle: Pivot-PRD §5.2. Detail-Rubric für KI-Score: docs/ai-suitability-rubric.md. Maschinelle Prüfung der Per-Sektion- und Gesamt-Caps: pnpm check:word-counts (Acceptance-Gate, Stage 15).

5. Quality-Checklist Post-Brief

Nach Fertigstellung, vor Status-Transition. Diese Checks sind die Übergabe-Bedingung an den nächsten Quality-Sweep oder direkt an den Customer-Sample-Bündel.

• [ ] pnpm validate läuft grün (Frontmatter-Zod-Schema + Wikilink-Check, siehe scripts/validate/)
• [ ] Alle Sources im Frontmatter mit DOI oder URL eingetragen, keine Plain-Titel ohne Verweis
• [ ] synthesis_word_count im Frontmatter korrekt berechnet (Stand der Forschung + Lücken + Trends; KI-Eignung zählt separat, siehe prompts/synthesis.v1.md) — Feldname bleibt aus Code-Konsistenz-Gründen synthesis_word_count, zählt die Wörter des Forschungs-Briefs
• [ ] ai_potential.rated_by = claude-opus-4-7@prompts/ai-rating.v1 (oder die zur Zeit der Brief-Erstellung aktive Version mit korrektem Pinning)
• [ ] Audit-Trail-Block für KI-Bewertung als ### Audit-Trail Subheading innerhalb von ## KI-Eignungs-Bewertung mit JSON-Block der 4 Dimensions-Werte (D1=X, D2=Y, D3=Z, D4=W, sum=N) — gemäß prompts/ai-rating.v1.md-Output-Vertrag. Format-Beispiel siehe WFK-6.1.1 (### Audit-Trail (Dimensionen-Scoring) mit { ai_score, dimensions: { data, task, maturity, ethics }, sum, override_applied }).
• [ ] status-Transition vollzogen: von not-started (über researching) auf drafted oder — wenn intern reviewed — auf reviewed

Quelle: Pivot-PRD §5.3. Schema-Vertrag: docs/adr/0002-id-schema-frontmatter.md. Status-Werte kanonisch in schemas/workflow.zod.ts (STATUSES-Konstante: not-started → researching → drafted → reviewed → published, plus needs-revision).

5.3 Reachability-Check (Hard-Gate ab Phase A)

Vor jedem Brief-Commit MUSS der Reachability-Check der referenzierten Sources grün laufen. Dies ist ein Hard-Gate, kein Richtwert.

• [ ] pnpm check:links --staged-sources-only läuft grün (HEAD/GET-fallback, DOI-Resolve, Content-Match-Heuristik gemäß SQ-01/SQ-02).
• [ ] Bei Status broken / paywall / content-mismatch / error auf einer der referenzierten Sources: Commit blockiert. Pre-Commit-Hook erzwingt das (siehe SQ-05).
• [ ] Override nur via Sidecar-Feld content_match_override: true (mit Datum + Reviewer-Begründung) gemäß ADR-0004 — nicht durch Hook-Bypass.

Operativer Hook: .husky/pre-commit ruft pnpm check:links --staged-sources-only (SQ-05); CI-Stage link-health ruft pnpm check:links --full (SQ-06). Customer-Versand-Gate (scripts/customer-send-gate.ts, SQ-07) verschärft auf 100 % ok+content-match für die zu sendenden WFK-IDs.

Quelle: PRD-Amendment 2026-05-09 §6 A-AC4 / A-AC5 / A-AC6. Sidecar-Vertrag: docs/adr/0004-sidecar-pattern-mutating-metadata.md. Governance-Rahmen: docs/adr/0005-broken-window-budget-governance.md.

6. Cross-Brief-Sweep (alle 5 Forschungs-Briefe)

Alle 5 fertiggestellten Forschungs-Briefe wird ein Konsistenz-Sweep durchgeführt. Ziel: Drift früh erkennen, bevor er sich in 15 oder 50 Briefen multipliziert. Der Sweep dauert typischerweise 30-45 min und produziert keinen neuen Inhalt — er findet nur Inkonsistenzen.

• [ ] Begriffs-Konsistenz: Wird derselbe Begriff (z.B. „Dekarbonisierung", „Klimaresilienz", „Mitigation/Adaptation") in allen 5 Briefen gleich verwendet? Falls nicht → konsolidieren oder ein Glossar in docs/context/ anlegen.
• [ ] KI-Score-Spread: Sind nicht alle 5 Briefe medium? Eine sinnvolle Spreizung über low / medium / high ist erwartbar; durchgehende Mitte deutet auf zu vorsichtige Bewertung hin. Reverse: 5× high deutet auf Hype-Bias.
• [ ] Quellen-Wiederverwendung: Wenn dieselbe Quelle in mehreren Briefen zitiert wird — ist die abgeleitete Aussage konsistent? Widersprüchliche Lesarten derselben Quelle sind Stop-Bedingung.
• [ ] Cluster-Heterogenität: Decken die 5 Briefe wirklich verschiedene Cluster / Domänen ab, oder hat sich der Sweep auf einen Schwerpunkt verengt? Falls Letzteres → nächste Briefe aktiv aus untervertretenen Clustern wählen.

Quelle: Pivot-PRD §5.4.

7. Worked Examples (3 Goldstandards)

Die drei Goldstandard-Briefe aus Deep-Session 2026-05-09 dienen als kommentierte Anker für alle weiteren 12 Pilot-Briefe. Jeder Walkthrough zeigt die tatsächliche Quellen-Sequenz, die Wortzahl-Verteilung pro Brief-Sektion, die KI-Score-Begründung gemäß Rubric und einen kurzen Lerngewinn für die Pilot-Set-Restarbeit.

Worked Example 1: WFK-2.1.5 — Customer-Sample (KI-explizit, high)

Kontext. Cluster 2 „Bau & Gebäude", Topic 2.1 „Dekarbonisierung des Gebäudebestands". Frage: „Welche KI-Anwendungen können zur Reduktion des Energieverbrauchs von Gebäuden beitragen?" — KI-explizite Frage, fünf Patenschaften (u.a. MD-BD „Raus aus Gas", Wiener Netze, Wiener Stadtwerke, Wien Energie). Ankerbeispiel für customer-fertige Forschungs-Briefe.

Recherche-Walkthrough. Quellensequenz folgte §2.2 strikt: zuerst Wien-Layer (2024-wiener-netze-smart-meter-rollout als Daten-Anker, ~96 % Smart-Meter-Quote Ende 2024), dann AT (2023-ait-maintenance-hvac als nationaler Methoden-Beleg), dann EU (2024-hernandez-european-smart-buildings für EPBD-Recast 2024 + BACS-Pflicht), dann Global (2024-alsayed-rl-hvac-review, 2025-iea-energy-and-ai, 2022-ipcc-ar6-wg3-buildings). Disziplinen-Diversität: Energietechnik, Building Automation, Policy/Regulatorik, KI/RL-Methodik, Klimawissenschaft — fünf Disziplinen über sechs Quellen, Wien-Anker erfüllt. Zeit ~25 min innerhalb Time-Box.

Brief-Highlights. Gesamt-Wortzahl 384 W (Frontmatter synthesis_word_count: 384), innerhalb 320-700 W-Korridor. Verteilung approximativ: ## Stand der Forschung ~155 W, ## Forschungslücken ~95 W, ## Trends & Entwicklungen ~85 W (alle innerhalb der jeweiligen Caps aus §4). ## KI-Eignungs-Bewertung separat ~140 W mit allen vier Aufgabentypen (Prediction, Optimization, Pattern-Recognition, Simulation) belegt und Wien-konkretisiert (WIGEV-Spitäler, MA-34-Verwaltung, Wien-Energie-Fernwärme).

KI-Score-Walkthrough. Score high, Sum 11/12, Dimensionen D1=3 / D2=3 / D3=3 / D4=2. Ausschlaggebend: D1 hoch, weil Wiener-Netze-Smart-Meter (~1,5 Mio Geräte) + Wien-OGD + Copernicus + ab 2024 BACS-Pflichtdaten direkt verfügbar; D2 hoch, weil mehrere Aufgabentypen kombinierbar; D3 hoch, weil RL-HVAC produktiv (24-55 % Einsparung in Feldversuchen) und AIT mAIntenance abgeschlossen 2023; D4 nur 2 wegen GDPR/DPIA-Pflicht auf Haushaltsebene — Aggregation auf Gebäude-/Quartiers-Ebene mitigiert.

Lerngewinn. Wien-Anker war einfach (Smart-Meter-Daten + AIT-Pilot), Disziplinen-Spread ergab sich automatisch durch EPBD-Recast-Quelle. Schwierig: Wortzahl-Diszplin in ## Stand der Forschung (200-W-Cap zwingt zu Verzicht auf Detailerläuterung der RL-Algorithmen). Folgerung für Pilot-Rest: Bei KI-expliziten Fragen mit gutem Wien-Datenanker erreicht man high ohne Methoden-Recherche-Spezialisierung — eine global-EN-Quelle pro Aufgabentyp reicht.

Worked Example 2: WFK-1.4.1 — Edge-Case literatur-arm (medium)

Kontext. Cluster 1 „Energieversorgung", Topic 1.4 „Grüne Gase und chemische Energieträger". Frage: „Welche chemischen Energiespeicher … sind optimal in den urbanen Raum integrierbar? … Rolle von Logistik-Hubs wie Hafen Wien?" — KI nicht explizit erwähnt (mentions_ai_explicit: false), drei Patenschaften (Hafen Wien, Wien Energie, MD-BD). Goldstandard für Halluzinations-Test bei dünner Wien-spezifischer Literatur.

Recherche-Walkthrough. Wien-Layer war die kritische Phase: nur zwei direkte Wien-Quellen verfügbar (2024-wien-energie-h2-simmering für die 3-MW-PEM-Elektrolyse seit April 2024, 2023-h2real-hafen-wien als laufendes Konsortial-Projekt 2023-2026). AT-Layer: 2022-bmk-wasserstoffstrategie-at (1 GW Elektrolyse-Ziel bis 2030). EU/Global: 2024-iea-global-hydrogen-review (Round-Trip-η 30-40 %), 2024-rijksoverheid-mca-h2-carriers (NL-MCA über LH₂/NH₃/Methanol/LOHC), 2024-mdpi-lohc-projects (LOHC-Reife-Stand). Disziplinen-Diversität: Energie-Infrastruktur, Logistik/Hafenbetrieb, Sicherheits-/QRA-Methodik, Energie-Politik. Sechs Quellen erreicht, aber sichtbar dünn auf Wien-Seite — exakt der Edge-Case-Charakter dieses Goldstandards.

Brief-Highlights. Gesamt 383 W (synthesis_word_count: 383). Verteilung: ## Stand der Forschung ~175 W, ## Forschungslücken ~95 W, ## Trends & Entwicklungen ~115 W, ## KI-Eignungs-Bewertung ~110 W. Halluzinations-Disziplin: Forschungslücken-Sektion benennt konkret, was fehlt („Live-Betriebsmessungen ≥1 Jahreszyklus Simmering", „keine veröffentlichte QRA für NH₃-/Methanol-Bunkering Lobau", „BMK-Strategie carrier-neutral, keine Wien-Priorisierung") statt Allgemeinplätze à la „mehr Forschung nötig". Zahlenangaben sind quellengebunden (1.300 kg/Tag, 1 GW, 30-40 %), keine erfundenen Kennzahlen.

KI-Score-Walkthrough. Score medium, Sum 9/12, D1=2 / D2=3 / D3=2 / D4=2. Ausschlaggebend für medium statt high: D1 nur 2, weil Wien-Energie-Sensordaten der Simmering-Anlage öffentlich dünn dokumentiert sind (Auslegungs-Daten statt Live-Telemetrie); D3 nur 2, weil sektorale H₂-Demand-Kopplungs-Modelle noch in Forschung — Routing/Forecasting zwar produktiv, aber QRA via HyRam und H₂-spezifische Last-Modelle hybrid.

Lerngewinn. Schwierig: Versuchung, mit Globaldaten Wien-Lücken zu kaschieren. Disziplin-Test bestanden, weil jede Aussage zu Wien-Spezifika an 2024-wien-energie-h2-simmering oder 2023-h2real-hafen-wien gebunden ist; globale Aussagen (IEA/MCA) bleiben explizit als globaler Vergleichsrahmen markiert. Folgerung für Pilot-Rest: Bei literatur-armen Fragen ist die ## Forschungslücken-Sektion das wichtigste Qualitätssignal — wer dort konkret bleibt, halluziniert auch im Stand der Forschung nicht.

Worked Example 3: WFK-6.1.1 — Cross-Discipline qual+quant (low)

Kontext. Cluster 6 „Klimafitte Grün- und Freiräume", Topic 6.1 „Aufenthaltsqualität öffentlicher Räume". Frage: „Wie muss der öffentliche Raum gestaltet sein, damit Menschen, die in besonderer Weise auf konsumfreie öffentliche Orte angewiesen sind, Erholung erfahren können?" — normativ-gestalterisch, acht Patenschaften aus vier Magistratsabteilungen (MA 18/19/22/42/50) plus FSW und Sucht- und Drogenkoordination. Goldstandard für qualitative + quantitative Quellen-Integration über mehrere Disziplinen.

Recherche-Walkthrough. Wien-Layer: 2020-team-focus-mariahilfer-strasse-public-space (FSW-Sozialraumanalyse, qualitativ-ethnographisch), 2025-stadt-wien-coole-zonen-public-space (Policy/Programm, quantitative Maßnahmen-Liste), 2023-univie-mapping-exclusion-public-space-vienna (empirische Hostile-Architecture-Kartierung in 5 Bezirken). EU/Global: 2025-leijssen-green-blue-spaces-vulnerable-scoping-review (PRISMA-ScR, 28 peer-reviewte Studien, methodisch quantitativ-systematisch), 2024-kidd-homelessness-extreme-temperatures-public-space (epidemiologisch-quantitativ, 3-10× Hitze-Mortalitätsrisiko), 2018-gehl-inclusive-healthy-places-public-space (Public-Life-Toolkit, methodisch). Disziplinen-Diversität: Stadtsoziologie, Stadtplanung, Public-Health, Sozialpolitik, Stadt-/Architekturgestaltung, Klimaanpassung — sechs Disziplinen über sechs Quellen, höchste Spreizung der drei Goldstandards.

Brief-Highlights. Gesamt 487 W (synthesis_word_count: 487), nahe oberer 600-W-Cap-Grenze. Verteilung: ## Stand der Forschung ~195 W, ## Forschungslücken ~120 W (knapp am 100-W-Cap, gerechtfertigt durch Cross-Discipline-Lücken-Befund über vier Institutionen), ## Trends & Entwicklungen ~95 W, ## KI-Eignungs-Bewertung ~140 W. Zusätzlich: WFK-6.1.1 ist der einzige der drei Goldstandards mit explizitem ### Audit-Trail (Dimensionen-Scoring)-JSON-Block im Brief-Body — dient als Format-Referenz für die Audit-Trail-Bullet in §5.

KI-Score-Walkthrough. Score low, Sum 6/12, D1=2 / D2=1 / D3=2 / D4=1. Ausschlaggebend: D2=1, weil die Frage primär normativ-gestalterisch ist — Erholung für vulnerable Gruppen ist eine Sozialarbeits-/Planungs-/Beteiligungs-Frage, kein Algorithmus-Problem. D4=1 wegen DPIA-Pflicht und AI-Act-Sensitivität bei Verhaltens-Tracking marginalisierter Gruppen (Wohnungslose, Suchtkranke). KI bleibt explizit unterstützend (Pattern-Recognition auf Luftbildern, Public-Life-Datenauswertung), nicht entscheidend.

Lerngewinn. Einfach: Quellenspread war organisch — die Frage zwingt zu Cross-Discipline, weil keine einzelne Disziplin sie beantwortet. Schwierig: Wortzahl-Disziplin in ## Stand der Forschung (195 W, knapp am Cap) — Versuchung, jede der sechs Disziplinen zu erwähnen. Lösung: Wien-Quellen ausführlich, globale als Belege für Verallgemeinerung. Folgerung für Pilot-Rest: Bei normativ-gestalterischen Fragen ist low der ehrliche Score, auch wenn Patenschaften KI-affin sind — die Rubric darf nicht durch Stakeholder-Erwartungen verzerrt werden. Audit-Trail-Block sollte für alle künftigen Forschungs-Briefe Standard sein (siehe §5-Bullet).

8. Source-Repair-Workflow

Wenn die Link-Health-Pipeline (pnpm check:links, CI-Stage link-health, oder Customer-Send-Gate) eine Source als broken / content-mismatch / paywall / error markiert, gilt dieser geordnete Repair-Workflow. Lehren aus W3 (SQ-08-A/B Triage, SQ-09 Wayback-Backfill): wirf nichts vorschnell weg, aber spekulier auch nichts neu zu — verifizier jeden Schritt.

1. Verify-Real-Fetch. Manueller Browser-Aufruf der gemeldeten URL plus zweiter Aufruf via curl -I mit aktuellem UA. False-Positive-Rate des automatischen Checks ist nicht 0 % (CDN-Geo-Blocks, Bot-Detection, transient 5xx). Wenn URL doch erreichbar: Override via Sidecar content_match_override: true mit Datum + Begründung (siehe §5.3 / ADR-0004).
2. Wayback-Search. Wenn URL real tot: prüfe ob historischer Snapshot in web.archive.org existiert (https://web.archive.org/web/*/<url>). Wenn ja: setze archive_url im Sidecar und nimm Wayback-URL als Permalink-Promote (siehe §2.3.1 Hierarchie). Nicht Wayback Save API gegen tote URL aufrufen — das funktioniert nicht (SQ-09-Lehre: 0/9 Erfolg).
3. New-URL-Recherche. Wenn kein Snapshot existiert: gezielte Recherche nach Ersatz-URL (CMS-Migrations-Pfad, neue Domain, Repository-Mirror). Vor Eintrag MUSS Pre-Add-Verification (§2.4) durchlaufen — Real-Fetch + Content-Match. Lehre aus SQ-08-A: spekulative Re-URLs ohne Content-Match-Verification produzieren erneut broken Links.
4. Content-Match-Override. Wenn URL erreichbar, aber Content-Match-Heuristik False-Negative produziert (z.B. Title-Variante nach Site-Redesign, valider Content): Sidecar content_match_override: true + override_reason: <text> + override_date: <ISO> + override_reviewer: <handle>. Pflicht-Begründung; Bypass via Hook-Skip ist verboten (ADR-0004).
5. Source-Replace (Last Resort). Wenn weder Wayback-Snapshot noch Ersatz-URL noch Content-Match-Override greift: Source ersetzen durch andere Quelle gleicher Tier-/Disziplinen-Kategorie, die dieselbe Aussage stützt. Ersetzung im betroffenen Brief-Frontmatter (linked_sources) + data/source-catalog.yaml aktualisieren.
6. Phase-B-Defer. Wenn die Reparatur in der laufenden Session nicht lösbar ist (z.B. Recherche-Aufwand > Time-Box, oder strukturelle Lücke betrifft mehrere Sources): Issue im SQ-Block mit ADR-0005-Budget-Notation öffnen; aktuelle Session committet nicht, bis Customer-Send-Gate für die zu sendenden WFK-IDs trotzdem 100 % erreicht (z.B. via partielle Source-Replace) oder Customer-Sample explizit verschoben wird.

Cross-Referenzen: konkrete Triage-Daten der Phase 1.5 in docs/source-broken-triage-2026-05-09-A.md (initiale 28-Broken-Forensik) und docs/source-broken-triage-2026-05-09-B.md (W3-Repair-Pass mit 14 erfolgreichen Fixes); Governance-Rahmen ADR-0005; Sidecar-Vertrag ADR-0004.

9. Realistische Defect-Rate-Erwartung

AT-Behörden-Domains rotten kontinuierlich (CMS-Migrations-Kadenz ~3-6 Monate, siehe Source-Quality-Hardening-PRD §7 R1). Die folgende Erwartungs-Kurve ist empirisch aus Phase 1.5 und gilt als Basis für künftige Korpus-Health-Audits.

| Korpus-Stand | Defect-Rate | Erklärung | |---|---|---| | Initial Pilot-Korpus 2026-05-09 (62 Sources) | ~ 60 % | Bulk-Add ohne Reachability-Gate, keine Pre-Add-Verification, DOI-Coverage 16 % (siehe PRD-Amendment §2 RC1-RC4) | | Post Triage Phase-1.5 W3 (62 Sources) | ~ 42.6 % | 14 Fixes durch SQ-08-B; Re-URL-Versuche der ersten Welle (SQ-08-A) hatten 0 % Erfolg, Wayback-Backfill (SQ-09) hatte 0/9 Erfolg auf bereits toten URLs | | Phase-A-Gate Ziel | ≤ 5 % | Erreichbar nur mit systematischer Re-URL-Recherche + Source-Replace für Unrettbares (Phase B) — nicht durch Wayback allein |

Operative Empfehlungen für Korpus-Stabilität:

• Strikter Source-Add-Workflow. Jede neue Source MUSS über scripts/add-source.ts (siehe docs/runbook/source-add.md) — das Skript erzwingt Pre-Add-Verification, DOI-Resolve, Wayback-Auto-Snapshot, Sidecar-Konsistenz. Direkter Frontmatter-Eintrag „von Hand" ohne Helper umgeht die Gates und ist verboten.
• 6-monatlicher Wayback-Backfill-Cron. Spezifikation in docs/architecture/wayback-cron-spec.md. Snapshotted alle aktuell erreichbaren AT-Behörden-Sources präventiv, bevor sie rotten — lange bevor Wayback Save API auf tote URLs scheitern würde. Subset-Run (~25 AT-Behörden-Sources) in <5 min bei 8s-Throttle.
• CI-Stage link-health als Hard-Gate. Defect-Rate > 5 % blockt Merge (siehe §5.3 / SQ-06). Der Gate verhindert, dass neue Sources das Korpus verschmutzen — aber er macht bestehende Drift sichtbar, statt sie zu beheben (deshalb Cron + manuelle Triage-Sessions zusätzlich).
• Erwartungsmanagement Customer. „Verifiziert am YYYY-MM-DD" pro Source im Dashboard (PRD-Amendment §4 G6) — kommuniziert ehrlich, dass Link-Health ein laufender Prozess ist, kein einmaliger Zustand.

10. Cross-Referenzen

• docs/source-catalog.md — kuratierte Quellen-Whitelist mit Per-Source-Workflow (Suchstrategie, Zitations-Format, Verified-Status, Lizenz, Refresh-Frequenz)
• docs/ai-suitability-rubric.md — Rubric für die KI-Eignungs-Bewertung (none / low / medium / high) inkl. Kriterien und Beispielen
• prompts/synthesis.v1.md — der versionierte Prompt für Stand-der-Forschung / Lücken / Trends / KI-Eignung inkl. Wortzahl-Vorgaben (Dateiname behält „synthesis"-Stamm aus Code-Konsistenz-Gründen)
• prompts/ai-rating.v1.md — der versionierte Prompt für die KI-Eignungs-Bewertung (verwendet in ai_potential.rated_by-Pinning)
• docs/prd/2026-05-09-pilot-workflow-pivot.md — die Amendment-PRD, aus der diese Methodologie abgeleitet ist (insb. §4 Source-Whitelist, §5 Quality-Checklisten, §6 Subagent-Parallelisierung)
• docs/prd/2026-05-09-source-quality-hardening.md — Phase-1.5-PRD-Amendment, aus der die v1.2-Änderungen (DOI-Hierarchie, Reachability-Check, Diversitäts-Regeln) abgeleitet sind
• docs/prd/2026-05-12-format-reframe-forschungs-brief.md — Phase-1.5-PRD-Amendment, aus dem die v1.3-Änderungen (Begriffs-Reframe + §§11/12/13 für Methods/Confidence/Limitations) abgeleitet sind
• docs/adr/0001-filesystem-first-markdown.md — SSOT-Entscheidung, warum keine DB / kein Tool jetzt
• docs/adr/0002-id-schema-frontmatter.md — der Frontmatter-Vertrag, gegen den pnpm validate prüft (inkl. Amendment 2026-05-09 für doi_unavailable_reason und Sidecar-Felder)
• docs/adr/0004-sidecar-pattern-mutating-metadata.md — Sidecar-Pattern für archive_url, content_match_override etc.
• docs/adr/0005-broken-window-budget-governance.md — Closure-Disziplin: visible-broken muss budgetiert werden

11.0 Topic-Lead-Konvention (optional, brief-typ-abhängig)

Vor der ersten H2 (## Methodische Grundlagen) KANN ein Topic-Lead-Block stehen — 1–2 Sätze (≤ 60 W), customer-visible, ohne eigene H2-Überschrift, direkt nach Frontmatter-Closing. Funktion: Setzt das thematische Lese-Frame bevor der Customer durch die 7 PRISMA-ScR-Light-Felder (§11.1) muss.

Default-Spec: kein Topic-Lead (= direct-h2-Pattern). Begründung: 3/3 Goldstandards (WFK-2.1.5 / 1.4.1 / 6.1.1) und 14/15 Pilot-Briefe sind ohne Topic-Lead konsistent kalibriert; ## Stand der Forschung übernimmt die orientierungs-stiftende Funktion ab Sektion 2.

Topic-Lead-erlaubt bei (≥ 1 Trigger):

• HYBRID-Brief mit gemischten ACTIVE+PASSIVE-Achsen (§14-PASSIVE-Pattern bzw. impact-PASSIVE-Caveat-Brief), wo der Lese-Frame die Achsen-Mechanik vor-aufzieht. Vorbild: WFK-8.1.1 (segment-ACTIVE + impact-PASSIVE-Caveat).
• DPIA-Disclaimer-Brief (§15) mit Re-ID-Risiken, wo der Customer den privacy-by-design-Frame vor Methods sehen sollte.
• Edge-Case literatur-arm (z.B. Goldstandard WFK-1.4.1 als Negativ- Beispiel — könnte einen 1-Satz „literatur-arm" Hinweis tragen, hat es aber faktisch in §Methodische Einschränkungen Baustein 5).

Topic-Lead-Wortlaut: deklarativ (keine Cliffhanger / Werbe-Sprache), ohne Wikilink-Zitationen (Citations starten erst in §Stand der Forschung), ohne IPCC-Confidence-Tags (diese gehören zu Key-Claims in §Stand).

Section-Count-Effekt: Topic-Lead zählt NICHT als Sektion für die "6 H2-Sektionen"-Invariante; synthesis_word_count-Total ist Topic-Lead-Wörter

• 6-H2-Body-Wörter (siehe check-word-counts.ts Per-Sektion-Caps — Topic-Lead-Wörter werden unter §0 erfasst, Cap ≤ 60 W).

11. PRISMA-ScR-Light — Methodische Grundlagen pro Forschungs-Brief

Jeder Forschungs-Brief MUSS eine ## Methodische Grundlagen-Section enthalten, die die Recherche-Spur transparent macht. Hintergrund: End2End-Audit 2026-05-12 hat K1 (fehlende Methods-Section) als ersten PhD-Reviewer-Killer identifiziert (docs/prd/2026-05-12-format-reframe-forschungs-brief.md §2.1). Maßstab ist die PRISMA-ScR Extension (Tricco et al. 2018, Annals of Internal Medicine, Items 6-9) und das JBI Manual for Scoping Reviews — aber in einer „Light"-Variante, die zum 400-Wörter-Format eines Forschungs-Briefs passt (nicht ein 5.000-Wörter-Review-Protokoll). Pflicht-Felder sind so kalibriert, dass eine reviewende PhD in 30 Sekunden verstehen kann, was wir wo gesucht und wie gefiltert haben.

Pflicht-Felder pro Brief (Body-Markdown im Pilot WFK-2.1.5, Frontmatter-Schema-Extension folgt via F-36):

• databases — Tatsächlich genutzte Suchquellen, in Reihenfolge der Wien-Whitelist-Hierarchie aus §2.2. Beispiele: Wien-OGD (data.wien.gv.at), Stadt-Wien-Publikationen-Server, Scopus, Google Scholar, Crossref, arXiv, IEA-Library, EEA-Datenbank, IPCC-AR6-Reports. Mindestens 3 Datenbanken nennen; keine Phantom-Datenbanken („wir haben es nur in Google Scholar gesucht? Dann nur Google Scholar nennen", siehe R2 in Reframe-PRD).
• search_strings — Verbatim die genutzten Suchabfragen, inklusive Boolean-Operatoren und Trunkierungen. Beispiel: "RL-HVAC" AND ("energy saving" OR "consumption reduction") AND building. Mindestens 2 Strings dokumentieren.
• date_range — Publikationsfenster der eingeschlossenen Literatur (z.B. 2020-01-01 / 2026-05-09). Default: ≥2020, ältere Quellen nur als methodologische Anker (z.B. Gehl 2018 für Public-Life-Toolkit).
• last_run — Datum (YYYY-MM-DD) des letzten realen Suchlaufs. Bei Updates: das spätere Datum überschreibt — vorherige Stände in der Sidecar-History (ADR-0004), nicht im Hauptfeld.
• inclusion_criteria — Geordnete Liste der Aufnahme-Bedingungen. Mindestens: Wien-Bezug ODER AT-Bezug ODER methodisch übertragbarer EU/Global-Anker; Publikationsdatum ≥2020; peer-reviewed oder behördlich/institutionell herausgegeben (siehe §2.3.2); DE oder EN.
• exclusion_criteria — Geordnete Liste der Ausschluss-Bedingungen. Beispiele: Conference-Abstracts ohne Proceedings; Pressemeldungen ohne Primärquellen-Verweis; Non-EU/Non-DACH-Studien ohne Wien-Übertragbarkeit (außer als globaler Benchmark explizit markiert); Sprachen außer DE/EN ohne DE-Abstract.
• records_screened — Anzahl der gesichteten Treffer (Titel/Abstract-Ebene). Realistische Bandbreite Pilot: 20-80 pro Brief. Wird ehrlich angegeben, auch wenn klein.
• records_included — Anzahl der in das Brief-Frontmatter aufgenommenen Quellen (typisch 4-6). Die Differenz zu records_screened ist erwartet, nicht verdächtig.

Operative Disziplin. Methodische-Grundlagen werden nicht post-hoc fabriziert (R2 in Reframe-PRD). Wer den Brief schon geschrieben hat und die Suchstrings nicht mehr rekonstruieren kann, dokumentiert das ehrlich: „Recherche-Spur post-hoc rekonstruiert; primäre Quellen reproduzierbar, Suchstrings approximativ." Das ist eine kleinere Verletzung als Erfinden von 8 Datenbanken, die nie konsultiert wurden. Quelle der Disziplin: PRISMA-ScR Item 9 (Search), JBI Manual Stage 3, sowie die Cochrane-Rapid-Reviews-Praxis der ehrlichen Restricted-Methods-Deklaration (Garritty et al. 2024).

12. IPCC-Calibrated-Language — Confidence-Tags pro Key-Claim

Jeder Forschungs-Brief MUSS mindestens 3 Key-Claims mit IPCC-Calibrated-Language-Tags markieren. Hintergrund: End2End-Audit 2026-05-12 hat K2 (fehlende Confidence-Calibration) als zweiten PhD-Reviewer-Killer identifiziert — Aussagen unterschiedlicher Beleg-Stärke wurden in v1.2 gleichwertig dargestellt (z.B. „24-55 % Einsparung in Feldversuchen" neben „300 TWh global einsparbar"). Maßstab ist die IPCC AR6 Uncertainty Guidance Note (Mastrandrea et al. 2010, fortgeführt in AR5/AR6), nationale Präzedenz ist APCC AAR2 (CCCA, 2024 SPM-DE), die die Calibrated-Language explizit für den österreichischen Klima-Kontext anwendet.

Tag-Format (inline, customer-lesbar). Im Fließtext direkt nach dem Key-Claim, kursiv mit Klammern und Semikolon-Separation:

RL-basierte HVAC-Steuerung erreicht 24-55 % Energieeinsparung in Feldversuchen (medium confidence; medium evidence, high agreement).

Confidence-Achse (5 Stufen, Aggregat-Urteil). Die Confidence wird nicht numerisch, sondern qualitativ aus der Evidence-Agreement-Matrix abgeleitet. Vermeidet falsche Präzision.

| Confidence-Level | Trigger (typisch) | |---|---| | very low | limited evidence, low agreement — Hypothese, anekdotisch | | low | limited evidence × medium agreement ODER medium evidence × low agreement | | medium | medium evidence × medium-high agreement ODER robust × low agreement | | high | robust evidence × high agreement, multiple Studien konvergieren | | very high | robust × high mit großer Studien-Anzahl + methodischer Triangulation |

Evidence-Achse (3 Stufen, Beleg-Tiefe).

• limited — Einzelstudie, kleines N, Modell-/Simulations-Daten ohne Feld-Validierung. Beispiel: Eine Wien-Energie-Pressemeldung mit Auslegungs-Daten, keine Telemetrie.
• medium — Mehrere Studien, gemischte Methodik (Modell + Feld), N moderat. Beispiel: 3-5 peer-reviewte HVAC-RL-Feldversuche europaweit.
• robust — Systematic Reviews / Meta-Analysen / IPCC-AR-Aggregate / großflächige Real-World-Deployments. Beispiel: IPCC AR6 WG3 Buildings-Kapitel mit hunderten Primärstudien.

Agreement-Achse (3 Stufen, Konvergenz der Quellen).

• low — Quellen widersprechen sich substantiell, oder es gibt eine prominente kritische Gegen-Stimme. Beispiel: Mulayim et al. 2025 (MPC schlägt RL unter Comfort-Normalisierung) widerspricht Alsayed-Review-Tenor.
• medium — Quellen konvergieren in der Richtung, divergieren in der Effekt-Größe (z.B. 24-55 % statt klarer Punktschätzung).
• high — Quellen konvergieren in Richtung und Größenordnung; keine substantielle Gegen-Stimme aufgetaucht in der Recherche.

Beispiel pro Achse (kalibriert am WFK-2.1.5-Pilot, F-33-Roll-Out folgt):

• (high confidence; robust evidence, high agreement) — „Smart-Meter-Rollout in Wien erreicht Ende 2024 ~96 % Quote" (Wiener-Netze-Primärquelle + EU-Aggregate konvergieren).
• (medium confidence; medium evidence, medium agreement) — „RL-HVAC erreicht 24-55 % Einsparung in Feldversuchen" (gestützte Bandbreite, aber Mulayim-2025-Kritik an Comfort-Normalisierung dokumentiert).
• (low confidence; limited evidence, medium agreement) — „Wien-spezifische Wärmenetz-RL-Optimierung amortisiert in 3-5 Jahren" (modellbasiert, keine veröffentlichte Wien-Feld-Validierung).

Operative Disziplin. Max. 5 Confidence-Tags pro Brief, um Tag-Inflation zu vermeiden (R3 in Reframe-PRD). Tags werden nur auf Key-Claims vergeben — nicht auf jeden Nebensatz. Wer unsicher ist, ob ein Claim ein Key-Claim ist, fragt: „Würde dieser Satz in einer Executive-Summary für Stadt-Wien-Verwaltung auftauchen? Wenn ja → taggen. Wenn nein → kein Tag." Quellen: IPCC AR6 Uncertainty Guidance Note (Mastrandrea et al. 2010), APCC AAR2 SPM-DE 2024, GRADE Working Group als Vergleichs-Framework.

13. Limitations-Boilerplate — Methodische Einschränkungen pro Forschungs-Brief

Jeder Forschungs-Brief MUSS eine ## Methodische Einschränkungen-Section am Ende (nach dem Audit-Trail-JSON-Block, der innerhalb ## KI-Eignungs-Bewertung als inline-Block geführt wird — vgl. prompts/ai-rating.v1.md Output-Vertrag) enthalten. Hintergrund: End2End-Audit 2026-05-12 hat K3 (Sample-Bias bei n=6) und K6 (Format-Anspruch-Inkonsistenz) als kombinierten PhD-Reviewer-Risiko-Vektor identifiziert. Die Limitations-Section macht die strukturellen Restriktionen unseres Manual-First-Pilot-Workflows transparent, statt sie als Bug zu verstecken. Maßstab ist die Cochrane-Rapid-Reviews-Methodik (Garritty et al. 2024, Journal of Clinical Epidemiology), die explizit „transparency about restricted methods" als Qualitäts-Indikator führt — nicht trotz, sondern wegen der reduzierten Tiefe gegenüber einem Full Systematic Review.

4 Standard-Bausteine (Boilerplate-Wortlaut, Brief-spezifisch leicht adaptierbar):

1. Single-Screener-Recherche. „Diese Recherche wurde von einer Person durchgeführt (Bernhard Götzendorfer mit Claude Opus 4.7 als KI-Assistenz). Es gab kein Dual-Screening durch eine unabhängige zweite Reviewer:in — die in PRISMA-ScR/JBI-konformen Reviews üblich ist. Mitigation: Suchstrings und Auswahl-Entscheidungen sind in §11 transparent dokumentiert und damit reproduzierbar; Cochrane-Rapid-Reviews akzeptieren Single-Screening explizit, sofern Transparenz gegeben ist (Garritty et al. 2024)."
2. Suchsprache DE/EN. „Die Recherche erfolgte in deutscher und englischer Sprache. Literatur in französischer, italienischer, niederländischer oder skandinavischer Sprache ist möglicherweise unterrepräsentiert, auch wenn sie methodisch relevant wäre (z.B. niederländische Wasserstoff-Logistik-Studien für WFK-1.4.1). Mitigation: EU-Layer-Quellen sind häufig EN-übersetzt verfügbar; Wien-Kontext priorisiert DE."
3. Stand der Recherche. „Stand der Recherche: <YYYY-MM-DD> (entspricht search_strategy.last_run in §11). Spätere Updates der Quellen-Basis werden in separaten Brief-Versionen dokumentiert, nicht durch Überschreiben dieses Briefs (ADR-0002 Frontmatter-Immutability, ADR-0004 Sidecar-Pattern). Bei zeitkritischen Themen (z.B. EU-Regulatorik, AI-Act-Sekundärrechtsakte): Halbjährliches Re-Screening empfohlen."
4. Keine formale Critical Appraisal pro Quelle. „Es wurde keine formale Critical Appraisal nach GRADE, ROBINS-I oder vergleichbaren Risk-of-Bias-Frameworks durchgeführt. Quellen-Qualität wird stattdessen über die Whitelist-Tier-Zuordnung (Wien/AT/EU/Global, siehe §2.2) und Peer-Review-Status (siehe §2.3.2) heuristisch eingeschätzt. IPCC-Calibrated-Language-Tags (§12) machen die resultierende Confidence pro Key-Claim transparent. Eine GRADE-Anwendung wäre für ein 400-Wörter-Brief-Format methodisch overengineered."

Operative Disziplin. Bausteine 1, 2 und 4 sind wortgleich über alle 15 Pilot-Briefe verwendbar (echte Boilerplate). Baustein 3 wird pro Brief mit dem konkreten last_run-Datum gefüllt. Bei Briefen mit besonders dünner Wien-spezifischer Literatur (z.B. WFK-1.4.1 Edge-Case) wird ein 5. Brief-spezifischer Baustein ergänzt, der die spezifische Lücke benennt — z.B.: „Wien-Layer-Quellenbasis dünn (n=2 direkte Wien-Quellen); globale Vergleichs-Quellen dominieren den Stand der Forschung." Damit ist die Sektion skalierbar auf 15-30 Briefe ohne Wortlaut-Drift. Quelle: Cochrane Rapid Reviews Garritty et al. 2024 (PubMed 38320771); analoge Praxis in WHO-Rapid-Evidence-Briefs.

14. PASSIVE-Brief-Pattern — normativ-juristische und qualitativ-gestaltende Fragen

Nicht jede Forschungsfrage des Wiener Katalogs ist primär algorithmisch lösbar. Für normativ-juristische Fragen (z.B. Reform der Bauordnung, Anwendung des CPR-Recast, Auslegung des AWG §3 Ende-der-Abfall-Eigenschaft) und für qualitativ-gestaltende Fragen (z.B. Aufenthaltsqualität für vulnerable Gruppen, partizipative Klimagerechtigkeit) ist KI legitim, aber nicht primär-treibend. Diese Briefe heißen PASSIVE-Briefe — die KI-Rolle ist analytisch-unterstützend, nicht Lösungs-Treiber. Das Muster ist die Folge von K3-Sample-Bias-Mitigation (Decision-Doc K3-Skalierung 2026-05-12, docs/decisions/2026-05-12-k3-active-scaling.md §10): wer die Frage ehrlich beantwortet, kommt bei manchen Themen auf low oder none — eine künstliche Hebung auf medium durch KI-Use-Case-Forcierung verzerrt die Bewertung und untergräbt die Glaubwürdigkeit über das Gesamtset.

Task-Charakteristik (Pre-Condition für PASSIVE). Die Frage ist kein quantitatives Algorithmen-Fahrzeug:

• Normativ-juristisch: Reform/Regelungs-Frage, bei der Gesetzgebung, Höchstgerichts-Rechtsprechung, Verwaltungs-Auslegung oder rechtsförmliche Konsultation den Lösungsraum strukturiert. KI-Anwendungen sind preparatory (Legal-NLP-Konsistenz-Checks zwischen Rechtskorpora, Pattern-Recognition für Bestands-Material-Datenlücken pre-2000, etc.) — sie ersetzen keine juristische Hermeneutik.
• Qualitativ-gestaltend: Sozialarbeits-, Planungs-, Beteiligungs-Frage, bei der menschliche Bewertung, partizipative Aushandlung und disziplinäre Praxis (Stadtsoziologie, Public-Health, Sozialpolitik) den Kern bilden. KI-Anwendungen sind unterstützend (Mapping, Auswertung, Pattern-Recognition auf Luftbildern, Public-Life-Daten) — sie entscheiden nicht über Gestaltungs-Normen.

Required content pro PASSIVE-Brief.

• KI-Rolle: preparatory. Im ## KI-Eignungs-Bewertung-Body explizit benennen, was KI nicht entscheidet (Reform, Normen, Aushandlungen) und was sie kann (Konsistenz-Checks, Datenlücken-Synthese, Visualisierung). Wording-Anker (WFK-6.1.1): „KI bleibt explizit unterstützend (Pattern-Recognition auf Luftbildern, Public-Life-Datenauswertung), nicht entscheidend."

• AI-Score low oder none. D2 ≤ 1 (Task ist nicht in mehrere KI-Aufgabentypen kombinierbar; entweder ein einzelner preparatory Use-Case oder keiner). Sum 6/12 (low) bzw. ≤4 (none) gemäß docs/ai-suitability-rubric.md. Keine künstliche D2-Hebung: wer schreibt „RL für Reform-Konsistenz" und keine Quelle stützt das, hat einen Hype-Use-Case und verstößt gegen die Rubric.

• Quellen-Mix: Mehrheitlich autoritative Quellen (Tier-1-Legal-Government, Tier-1-Institutional) ergänzt durch ≥1 K3-Critical-Gegenposition. Tier-1-Legal-Quellen (Gesetzestexte, EU-Verordnungen, amtliche Kommentare, Höchstgerichts-Urteile, siehe §16) bilden bei normativen Briefen den Kern; bei qualitativen Briefen treten institutionelle Sozialberichte (FSW, Sucht- und Drogenkoordination, Statistik Austria mikro-Daten) hinzu. Die K3-Critical-Gegenposition (z.B. Friesenecker für Wien-Gentrification, Li für Cooling-Inequity, Krayenhoff für Pedestrian-Cooling-Mapping) ist Pflicht — siehe sources/_critical-perspectives/README.md Curation-Index. Worked-Example WFK-3.1.1 erreicht 4/9 = 44% Tier-1-Legal/Government + 2 K3-Critical (Costa 2025, Sivers-Fivet 2025) — Pattern erfüllt.

• Limitations-Boilerplate-Erweiterung (Baustein 5, Brief-spezifisch). Über die §13-Standard-Bausteine 1-4 hinaus MUSS ein expliziter PASSIVE-Caveat ergänzt werden. Vorschlag-Wortlaut (anpassbar an Brief-Topik):

  „Diese Frage ist primär normativ-juristisch [bzw. qualitativ-gestaltend]. KI-Anwendungen bleiben analytisch-unterstützend und ersetzen weder juristische Hermeneutik [bzw. partizipative Aushandlung] noch Höchstgerichts-Rechtsprechung [bzw. disziplinäre Praxis in Sozialarbeit/Planung/Politik]. Legal-NLP- und Pattern-Recognition-Verfahren haben dokumentierte Grenzen bei der Auslegung offener Rechtsbegriffe und kontextueller Normen — eine vollautomatisierte Lösung wäre methodisch unzulässig und ethisch nicht verantwortbar."

• IPCC-Confidence-Mapping mit anderer Semantik als bei ACTIVE-Briefen. Die §12-Achsen (Confidence × Evidence × Agreement) bleiben formal gleich, ihre Trigger sind aber für PASSIVE neu interpretiert, weil rechtliche/qualitative Evidenz anders strukturiert ist als naturwissenschaftliche:

  | Confidence-Level | Trigger für PASSIVE-Briefe | |---|---| | high | Mehrere unabhängige rechtliche Quellen (z.B. EU-Verordnung + AT-Bundesgesetz + amtlicher Kommentar) plus Höchstgerichts-Urteil(e) konvergieren in der Auslegung. | | medium | Unterschiedliche Interpretations-Richtungen in Schrifttum oder Verwaltungspraxis ODER einzelne Implementierungs-Beispiele (z.B. ein laufender Wiener Roadmap-Entwurf ohne Vergleichsfälle). | | low | Juristische Auslegung offen, Regelwerk noch nicht in Kraft, keine Höchstgerichts-Rechtsprechung verfügbar, oder qualitative Empirie auf Einzelfall-Niveau. |

  very high und very low werden für PASSIVE-Briefe selten vergeben — rechtliche Auslegung ist selten unanfechtbar konvergent, qualitative Gestaltung selten anekdotisch-zerstreut.

Worked Example als Vorbild — WFK-6.1.1 (qualitativ-gestaltend, AI-Score low). Cluster 6 „Klimafitte Grün- und Freiräume", Aufenthaltsqualität für vulnerable Gruppen. Score low (Sum 6/12, D1=2 / D2=1 / D3=2 / D4=1), Begründung gemäß §7 Worked Example 3. KI-Rolle: preparatory (Mikroklima- und Hostile-Architecture-Overlay-Mapping auf Stadt-Wien-OGD-Luftbildern, Public-Life-Datenauswertung) — KI entscheidet nicht über Sozialarbeits-Normen, partizipative Gestaltung oder politische Priorisierung. Quellen-Mix: FSW-Sozialraumanalyse + Stadt-Wien-Coole-Zonen + UniWien-Hostile-Architecture-Empirie + K3-Critical-Voices (Friesenecker Wien-Green-Gentrification, Li Cooling-Inequity, Krayenhoff Pedestrian-Cooling-Mapping). WFK-6.1.1 hat de facto bereits PASSIVE-Charakter — §14 macht das Muster explizit und benennbar.

Reference forward — WFK-3.1.1 (normativ-juristisch, K3-PASSIVE). Cluster 3 „Kreislaufwirtschaft im Bauwesen", Reform der Bauordnungs- und Abfallrechts-Schnittstelle. Per K3-Wave-2-Pre-Vet (_research/k3-wave-2-prevet-2026-05-13.md) ist WFK-3.1.1 als erster expliziter PASSIVE-Brief designiert (Wave 3-B, nach den Tech-Briefs WFK-1.1.1 / 4.1.2 / 4.2.1). Pre-Vet-Begründung: „D2=1 Killer — task ist normativ-juristisch, nicht algorithmisch. KI-Anwendungen sind rein preparatory (Konsistenz-Checks, Datenlücken-Synthesis). Reform-Wirkung kommt von Gesetzgebung (CPR-Recast, AWG-Novelle), KI is pre-gaming input." Quellen-Anker: EU-CPR-Recast 2024 (Tier-1-Legal, §16), AWG 2002 §3 (Tier-1-Legal, §16), MD-BD-Ressourcenschonung-Roadmap, BOKU-Material-Fluss, plus K3-Critical (z.B. Friesenecker für Wien-spezifischen Reform-Diskurs). Das Pre-Vet erwähnt explizit „WFK-6.1.1 Vorbild" — §14 kodifiziert diese Lesart als skalierbares Muster.

15. DPIA-Disclaimer-Pattern — Briefe mit personenbezogenen / personen-rekonstruierbaren Daten

Forschungsfragen, deren KI-Use-Cases auf personenbezogene oder personen-rekonstruierbare Daten angewiesen sind (Bewegungsdaten, Smart-Meter-Telemetrie, Gesundheits-Daten, Telco-Aggregate, App-Logger), brauchen eine eigene Disclaimer-Sektion im Forschungs-Brief. Hintergrund: D4-Dimensionen-Bewertung in docs/ai-suitability-rubric.md zwingt ohnehin zur DPIA-Sensibilitäts-Prüfung, aber der customer-sichtbare Brief muss die rechtliche Hürde explizit benennen — sonst wirkt ein medium/high-Score wie ein Freibrief, was er nicht ist. Der Anker im Wiener Kontext ist die Mehrfach-Geltung von DSGVO + DSG (Datenschutzgesetz AT) + WIWG (Wiener Informationsweiterverwendungsgesetz) plus AI-Act-Anhang-III-Sensitivität bei kritischer Infrastruktur und vulnerablen Gruppen.

Required content pro DPIA-Brief.

• DSGVO Art. 35 explizit zitieren. Verordnung (EU) 2016/679 Art. 35 (Datenschutz-Folgenabschätzung) MUSS namentlich genannt sein, nicht paraphrasiert. Wording-Anker: „Eine Datenschutz-Folgenabschätzung gemäß DSGVO Art. 35 ist verpflichtend, sobald [Datentyp] auf Haushalts-/Personen-Ebene verarbeitet wird; Aggregation auf Quartiers-Ebene mitigiert, ersetzt sie aber nicht."

• EU AI Act Annex III (parallel zu DSGVO Art. 35 bei KI-Systemen). Forschungsfragen, die KI-Klassifikatoren, Empfehlungs-, Predictive- oder Risiko-Scoring-Systeme im öffentlichen Sektor oder mit signifikantem Bürger-Impact behandeln (z.B. Predictive-Allocation, Vulnerabilitäts-Scoring, automatisierte Förderzuteilung, Trip-Reconstruction-Pipelines), MÜSSEN in §Methodische Einschränkungen explizit auf eine Annex-III-Hochrisiko-Klassifikation hinweisen — auch dann, wenn DSGVO Art. 35 bereits adressiert ist. Die Regimes laufen parallel, nicht alternativ: DSGVO regelt die Datenverarbeitung, der AI-Act die System-Entwicklung und das System-Inverkehrbringen. Pflicht-Checkpunkte: (a) Annex-III-Screening — fällt das KI-System unter eine Hochrisiko-Kategorie (Annex III Punkt 5 „Zugang zu wesentlichen privaten/öffentlichen Diensten und Leistungen", Punkt 8 „Rechtspflege/demokratische Prozesse", Punkt 2 „Kritische Infrastruktur" oder Punkt 1 „Biometrie"); (b) Konformitätsbewertung vor Deployment (Art. 43 AI Act) — Konformitätsbewertungsverfahren mit interner oder Drittstellen-Kontrolle, CE-Kennzeichnung, EU-Datenbank-Registrierung (Art. 49); (c) Fundamental-Rights-Impact-Assessment (Art. 27 AI Act) — für öffentliche Stellen und Privatakteure mit öffentlichem Auftrag verpflichtend, ergänzt die DSGVO-DPIA um Grundrechte-Dimensionen (Diskriminierungsschutz, Versammlungs-/Meinungsfreiheit, Recht auf wirksamen Rechtsbehelf); (d) Risikomanagement-System (Art. 9 AI Act) — kontinuierlicher Lebenszyklus-Prozess statt punktueller Bewertung. Wording-Anker: „Das System fällt voraussichtlich unter EU AI Act Annex III Punkt [X] (Hochrisiko); vor Deployment ist eine Konformitätsbewertung nach Art. 43 sowie ein Fundamental-Rights-Impact-Assessment nach Art. 27 erforderlich — diese laufen parallel zur DSGVO-DPIA gemäß Art. 35, ersetzen sie aber nicht." Cross-Refs: Verordnung (EU) 2024/1689 (KI-Verordnung) Anhang III, Art. 9, Art. 27, Art. 43, Art. 49. Anwendung erprobt in WFK-4.2.1 (Trip-Reconstruction, biometrische Kategorisierung möglich), WFK-9.1.1 (Predictive Markets, Annex III Punkt 5 / 8), WFK-7.1.1 (Klimagerechtigkeit-Bias, Annex III Punkt 5).

• Re-Identifikations-Risiko-Floor. Bei Bewegungs-/Trajektorien-Daten MUSS der empirische Befund von de Montjoye et al. 2013 (Scientific Reports 3:1376, „Unique in the Crowd") zitiert sein: vier spatio-temporale Punkte reichen, um 95 % der Personen in einem Mobilfunk-Datensatz eindeutig zu re-identifizieren. Wording-Anker: „Mobilitäts-Datensätze sind auch nach Pseudonymisierung re-identifizierbar — vier spatio-temporale Punkte genügen für 95 % eindeutige Re-Identifikation (de Montjoye et al. 2013). Privacy-by-Design-Maßnahmen sind nicht optional."

• Privacy-by-Design-Pattern (mindestens eines explizit benannt).

  • Aggregation mit k-anonymity ≥20 (Quartiers- statt Adress-Ebene; in WIWG-konformer Praxis der Stadt Wien etabliert).
  • Differential Privacy (kalibrierter Noise-Floor auf Aggregat-Statistiken; in EU-Mobility-Data-Space-Roadmap als Standard vorgesehen).
  • Synthetische Ersatzdaten (Diffusion/GAN-erzeugte Trajektorien mit erhaltener Verteilungs-Statistik, aber ohne reale Personen-Spuren; Forschungsstand 2024-2026, Pilot-Reife).

• NGO-Critical-Voice-Anker. Mindestens eine zivilgesellschaftliche / NGO-Stimme aus dem DACH-Datenschutz-Raum MUSS als kritische Gegenposition zitiert sein. Akzeptable Anker: epicenter.works (AT, Bürgerrechte digital), noyb (EU, Max Schrems / DSGVO-Durchsetzung), AKVorrat (AT/DE, Vorratsdatenspeicherung-Kritik), Bundesdatenschutzbeauftragte (DE: BfDI; AT: Datenschutzbehörde). Disziplin: Die NGO-Position wird als wissenschaftlicher Skeptizismus gerahmt (z.B. „epicenter.works dokumentiert systematische Re-Identifikations-Risiken bei aggregierten Mobilitäts-Daten"), nicht als NGO-Advocacy-Endorsement. Wer den Brief als Lobby-Plattform liest, hat das Pattern falsch angewendet.

• Sample-Bias-Hierarchie (Garber et al. 2022). Bei Selection-Bias-Risiken in den verwendeten Datensätzen (z.B. GVS-Mobilitätssurvey unterrepräsentiert Personen ohne Festnetz-Anschluss): Within-Group-Bias > Between-Group-Bias in der Größenordnung — d.h. Heterogenität innerhalb einer Untergruppe (z.B. einkommensschwache Haushalte) ist die größere Verzerrungs-Quelle als Unterschiede zwischen Gruppen. Garber et al. 2022 (Epidemiology, „Selection Bias Hierarchies") ist der methodische Anker; im Brief wird das als Caveat in ## Methodische Einschränkungen Baustein 5 ergänzt.

• Placement im Brief: drei zulässige Optionen. Entscheidung pro Brief im Pre-Vet (W3-A):

  1. Als eigene Sub-Sektion ### Datenschutz & Re-Identifikations-Risiken in ## KI-Eignungs-Bewertung, direkt nach der D4-Rationale.
  2. Als eigene Sub-Sektion ### DPIA-Constraint zwischen ## Methodische Grundlagen (§11) und ## Methodische Einschränkungen (§13).
  3. Als Brief-spezifischer Baustein 5 in ## Methodische Einschränkungen (§13), wenn die DPIA-Sensitivität ein Caveat über den Ergebnissen ist (z.B. „Pilot auf 1.500 Personen GPS-Sample begrenzt, weil Telco-Aggregate DPIA-pflichtig").

  W3-A entscheidet pro Brief; die drei Optionen sind funktional gleichwertig — Wahl folgt der inhaltlichen Schwerpunktsetzung (D4-Dimensions-Erläuterung vs. Methods-Constraint vs. Limitations-Caveat).

Worked Example als Sub-Variante — WFK-1.2.1a (Smart-Meter, DPIA-Caveat bereits implizit). Demand-Response / Smart-Meter / VPP. D4=2 (statt 3) wegen DSGVO/DPIA-Pflicht auf Haushalts-Ebene; Aggregation auf Quartiers-/Gebäude-Ebene mitigiert (Wording aus dem existierenden WFK-1.2.1a Rationale, vgl. §7 Worked Example 1). Re-Identifikations-Risiko bei viertelstündlichen Smart-Meter-Profilen ist hoch (Lastprofile sind Verhaltens-Signaturen). WFK-1.2.1a hat das im Rationale dokumentiert, aber nicht als eigene Disclaimer-Sub-Sektion ausgewiesen — §15 macht das Muster explizit und prescriptiv für künftige Briefe gleicher Datentyp-Klasse.

Reference forward — WFK-4.2.1 (Trip-Reconstruction, K3-ACTIVE-WITH-CAVEATS, erster expliziter DPIA-Brief). Cluster 4 „Mobilität, neue Erhebungsmethoden". Per K3-Wave-2-Pre-Vet (_research/k3-wave-2-prevet-2026-05-13.md) ist WFK-4.2.1 als erster expliziter DPIA-Brief designiert (Wave 3-A, nach Tech-Briefs 1+2). Pre-Vet-Begründung: „D4=1 (DSGVO-Kern-Sensibilität) erzwingt explizite Datenschutz-Gating: (a) DPIA-Phase vor any Telco-Sensor-Integration, (b) k-anonymity-Schwellwerte mit DSA/AGSM verhandelt, (c) Differential-Privacy-Layer mandatory." Quellen-Anker werden u.a. epicenter.works (AT-NGO-Kritik), noyb (DSGVO-Enforcement), de Montjoye et al. 2013 (Re-ID-Floor), Garber et al. 2022 (Sample-Bias-Hierarchie) sein.

16. Tier-1-Legal-Government — Source-Acceptance für normative Quellen

§16 erweitert docs/source-catalog.md Tier-Strategy (Wien-Primary / AT-Secondary / EU-Tertiary / Global-Quaternary) um eine fünfte Quellen-Kategorie: Tier-1-Legal. Diese Kategorie umfasst Gesetzestexte, EU-Verordnungen, amtliche Kommentare und Höchstgerichts-Urteile und ist die authoritative Primärquelle für normative Fragen (PASSIVE-Briefe gemäß §14). Sie sitzt funktional vor den anderen Tiers, wenn die Frage rechtlich strukturiert ist — bei tech-getriebenen Fragen bleibt Wien-Primary der Pflicht-Anker.

Legitimization. Tier-1-Legal-Quellen sind nicht akademisch-peer-reviewed. Sie sind aber rechtsförmlich verbindlich: EU-Verordnungen gelten unmittelbar in allen Mitgliedsstaaten (TFEU Art. 288); AT-Bundesgesetze sind im RIS (Rechtsinformationssystem des Bundes) authentisch und kanonisch zitierfähig; Wiener Landesgesetze sind im Wiener Landesgesetzblatt amtlich; Höchstgerichts-Urteile (EuGH, VfGH, OGH) bilden Auslegungs-Präjudiz. Für normative Forschungsfragen (Reform, Compliance, Implementierungsspielraum) ist eine Tier-1-Legal-Quelle methodisch stärker als ein peer-reviewter Reform-Vorschlag im akademischen Schrifttum — sie ist der operative Bezugspunkt, gegen den der Reform-Vorschlag selbst sich messen muss.

Examples (im Korpus etabliert oder als nächstes vorgesehen):

• EU-CPR-Recast 2024 — Verordnung (EU) 2024/3110 zur Festlegung harmonisierter Bedingungen für die Vermarktung von Bauprodukten (Bauproduktenverordnung-Neufassung). Direkt relevant für WFK-3.1.1 (Kreislaufwirtschaft im Bauwesen): Art. 11 Wiederverwendete Bauprodukte, Art. 22 Sekundär-Rohstoff-Anteile, Anhang III Umweltleistungs-Erklärung. Authentisch via EUR-Lex (https://eur-lex.europa.eu/eli/reg/2024/3110/oj). Im Korpus als sources/2024-eu-cpr-recast-secondary-materials.md.
• AT-AWG 2002 — Bundesgesetz über eine nachhaltige Abfallwirtschaft (Abfallwirtschaftsgesetz 2002), aktuelle Fassung. §3 AWG 2002 definiert die Ende-der-Abfall-Eigenschaft, die juristische Hürde für die Wiederverwendbarkeit von Baumaterialien. Authentisch via RIS. Im Korpus als sources/2002-at-awg-abfallwirtschaft-ende-abfall.md.
• AT-ABGB §§922-933b — Allgemeines bürgerliches Gesetzbuch, Gewährleistungs-Recht. Relevant für Briefe, in denen Sekundärbauteile-Wiederverwendung an zivilrechtliche Mängel-Haftung anschließt (Compliance-Schnittstelle CPR-Recast ↔ ABGB). Authentisch via RIS.
• Wiener Bauordnung (Novelle) — Landesgesetz, BO für Wien. Relevant für alle Cluster-3-/Cluster-2-Fragen mit baurechtlicher Operationalisierungs-Ebene (Konformitätsnachweise wiederverwendeter Bauteile, energetische Sanierungspflichten). Authentisch via RIS Landesrecht Wien.

Diese Liste ist nicht abschließend — weitere Tier-1-Legal-Quellen (z.B. DSGVO, AI-Act, EU-Mobility-Data-Space-Rechtsakte, AT-DSG, WIWG, EU-EPBD-Recast) treten je nach Brief-Topik hinzu.

Frontmatter-Type-Pattern (Schema-Vertrag). Das schemas/source.zod.ts SourceTypeSchema-Enum kennt seit Deep #20 (F-82, ADR-0002 A7): paper | report | webpage | dataset | standard | book | legal-text. Tier-1-Legal-Quellen MÜSSEN type: legal-text und legal_jurisdiction setzen (Enum: EU | AT-Bund | AT-Land-Wien | Höchstgericht). Das Schema enforct dies hart via .refine() in schemas/source.zod.ts: jede legal-text-Source ohne legal_jurisdiction bricht die Validate-Stufe. Beispiele aus dem Korpus: sources/2024-eu-cpr-recast-secondary-materials.md (type: legal-text, legal_jurisdiction: EU); sources/2002-at-awg-abfallwirtschaft-ende-abfall.md (type: legal-text, legal_jurisdiction: AT-Bund). Cross-Ref: ADR-0002 Amendment A7 (Deep #20).

Citation-Discipline (Pflicht für Tier-1-Legal). Bei Tier-1-Legal-Quellen MUSS die Article-/Paragraph-Nummer im Wikilink-Anchor stehen, sodass der konkrete Rechtsnorm-Verweis verifizierbar ist. Format: [<source-id>](/sources/%3Csource-id%3E)§<Norm-Anchor> bzw. mit explizitem Article-Verweis. Beispiele:

• [2024-eu-cpr-recast-secondary-materials](/sources/2024-eu-cpr-recast-secondary-materials)§Art.11 (Wiederverwendete Bauprodukte)
• [2024-eu-cpr-recast-secondary-materials](/sources/2024-eu-cpr-recast-secondary-materials)§Art.22 (Sekundär-Rohstoff-Anteile)
• [2002-at-awg-abfallwirtschaft-ende-abfall](/sources/2002-at-awg-abfallwirtschaft-ende-abfall)§3 (Ende-der-Abfall-Eigenschaft)
• [2024-wiener-bauordnung-novelle](/sources/2024-wiener-bauordnung-novelle)§118 (Konformitätsnachweise) — falls/sobald im Korpus

Begründung: anders als ein DOI-Aufruf, der direkt zum Volltext führt, sind Rechtstexte umfangreich (das AWG 2002 hat dutzende Paragraphen). Ohne Norm-Anchor ist der Verweis im Brief nicht reproduzierbar — die reviewende PhD muss raten, welcher Paragraph gemeint war. Die Citation-Discipline schließt diese Lücke.

Operative Disziplin. Tier-1-Legal-Quellen werden nicht statt, sondern zusätzlich zu Wien-Primary-Quellen geführt — der Lokalitäts-Anker (D3 in §3.1) bleibt erhalten. Bei reinen Reform-Briefen (WFK-3.1.1-Klasse) kann der Tier-1-Legal-Anteil dominieren (CPR-Recast + AWG + ABGB + Wiener BO summieren auf 4 Quellen), aber mindestens eine Wien-spezifische Quelle (MD-BD-Roadmap, MA 22-Bericht, etc.) MUSS auch in PASSIVE-Briefen vorhanden sein. Die D3-Wien-Anker (Hard)-Regel aus §3.1 gilt uneingeschränkt — Tier-1-Legal ist eine Quellen-Erweiterung, kein Wien-Anker-Ersatz.

Quelle: Decision-Doc K3-Skalierung 2026-05-12 (docs/decisions/2026-05-12-k3-active-scaling.md §10 PASSIVE-Sequenz); K3-Wave-2-Pre-Vet 2026-05-13 (_research/k3-wave-2-prevet-2026-05-13.md WFK-3.1.1-Befund); existierende Tier-1-Legal-Quellen im Korpus (sources/2024-eu-cpr-recast-secondary-materials.md, sources/2002-at-awg-abfallwirtschaft-ende-abfall.md).

17. PhD-Reviewer-Pass-Pattern — institutionalisierter Qualitäts-Gate vor Abschluss

Nach jedem K3-Brief-Drafting-Wave (W2 ACTIVE + W3 HYBRID/PASSIVE) läuft ein institutionalisierter PhD-Reviewer-Pass als Inter-Wave-Gate vor W4-Quality. Brutal-honest peer-review by simulated discipline-specialist panel. Ziel: Findings adressieren, bevor acceptance + boilerplate-check + session-reviewer die Brief-Qualität als „read-only" stempeln.

17.1 Trigger

≥1 K3-active Brief gedrafted im laufenden Wave. Bei Multi-Brief-Waves: ein gemeinsamer Panel-Lauf statt Pass pro Brief (Panel-Cross-Cutting-Consistency-Vorteil).

17.2 Panel-Zusammensetzung (≥3 Disziplinen)

• Reviewer A: Disziplin-spezifisch für Cluster-Topic. Beispiele: Hydrologie für Cluster 5, Stadtklima für Cluster 6, Labour-Econ / Politikevaluation für Cluster 9, Sozial-Klima / Klimagerechtigkeit für Cluster 7, Climate-Communication / Behavioral-Science für Cluster 8.
• Reviewer B + C: weitere Disziplinen entsprechend dem Brief-Mix (cross-Disziplin Quervalidierung).
• Panel-Chair: cross-cutting Consistency, Hub-Source-Reach, Goldstandard-Comparison (Vergleich gegen WFK-2.1.5 / 1.4.1 / 6.1.1 Goldstandards).

17.3 Review-Kriterien (Layer-3-Discipline)

1. Wissenschaftliche Integrität — Claims-vs-Sources (jede Behauptung im Brief muss durch eine zitierte Quelle gedeckt sein), IPCC-Tag-Discipline (robust evidence benötigt ≥2 unabhängige Sources im Citation-Context), Cherry-Picking-Check (gegensätzliche Evidence nicht ignoriert).
2. Quellen-Qualität & Source-Tier — Source-Whitelist-Reihenfolge §2.2 eingehalten, Tier-Mix balanced, D1-D3 §3.1 erfüllt.
3. Wien-Anwendbarkeit — D3-Wien-Anker (Hard) §3.1, MD-BD/MA-22/Wien-Energie-Bezug.
4. Methods — §11 PRISMA-ScR-Light 7 Pflicht-Felder (databases, search_strings, date_range, last_run, inclusion/exclusion_criteria, records_screened/included).
5. KI-Eignungs-Bewertung — D1-D4 §3.1 nachvollziehbar, Audit-Trail-JSON-Block sauber.
6. Section-Balance + Paragraph-Struktur — §Stand der Forschung ≤3 Absätze, Body 320-700W, Sektionen-Caps (Stand ≤200W, KI-Eignungs-Bewertung ≤180W inkl. DPIA-/AI-Act-Block, Einschränkungen ≤120W).
7. PASSIVE-Pattern compliance (§14) — wenn Brief PASSIVE: AI-Score low/none, KI-Rolle preparatory, K3-Critical-Gegenposition, Limitations-Erweiterung Baustein 5.
8. HYBRID-Boundary clean — wenn Brief HYBRID: ACTIVE-Components und PASSIVE-Caveats sind segregiert (z.B. WFK-8.1.1 NLP-Message-Testing ACTIVE + impact-messbar PASSIVE).
9. Skeptiker-Check — explizite Frage „Was würde ein PhD-Reviewer ablehnen?" mit ≥1 nicht-trivialen Schwachstelle pro Brief.

17.4 Output

Markdown-Report mit folgender Struktur pro Brief:

• Per-Reviewer Strong-Points (≥2 pro Reviewer)
• Per-Reviewer Weaknesses (≥1 pro Reviewer, severity-tagged Critical/High/Medium/Low)
• Suggested-Edits (konkrete Diff-Vorschläge, nicht vague „verbessern")
• Verdict (eines von):
  • SHIP — direkt zu W4-Quality, keine Edits nötig
  • SHIP-WITH-TWEAKS — Edits in coord-direct oder W3-C Polish-Iteration vor W4
  • RESHAPE — Brief braucht substanzielle Überarbeitung (Body-Rewrite, Source-Substitution); nicht ready für W4

17.5 Template

Kanonische Vorlage: prompts/phd-reviewer-pass.v1.md (versioniert per CLAUDE.md G5 AI-Prompt-Discipline). Bei Major-Revision: v2.md, CHANGELOG ergänzen, v1 für Reproduzierbarkeit behalten.

17.6 Findings-Loop

Findings werden gemäß Severity verteilt:

• Critical — coord-direct gefixt VOR W4 (Beispiel: linked_sources-Schema-Drift WFK-8.1.1, Deep #18 W3-Inter-Gate Pass v2).
• High — coord-direct ODER W3-C Polish-Iteration vor W4 (je nach Aufwand).
• Medium — W4-Quality-Tasks oder W5-A-Fixes nach acceptance/boilerplate.
• Low / Med-LongTerm — F-Issue defer.

17.7 Effektivität-Metriken (institutionalisiert tracked)

Pro Pass dokumentiert in HANDOFF.md Wave-Summary:

• Pre-Vet-Compliance ≥80% — Brief enthält ≥80% der Pre-Vet § Verified Sources als Wikilinks (Anti-Hallucinations-Anchor).
• Confidence-Tag-Inflation reduziert — Pattern: high confidence; robust evidence benötigt ≥2 unabhängige Sources im Citation-Context (sonst Downgrade auf medium confidence; medium evidence).
• Schema-Field-Alignment — mentions_ai_explicit muss zu question_text_de AI-keywords passen (Korrelations-Check).

17.8 Historie (erste 2 Anwendungen)

• Erster Lauf: 3 Briefe reviewt (WFK-5.1.1, WFK-6.3.1, WFK-9.1.1) — 3× SHIP-WITH-TWEAKS, Findings vor Abschluss adressiert. Panel: Hydrologie + Stadtklima + Labour-Econ + Chair.
• Zweiter Lauf: 2 Briefe reviewt (WFK-7.1.1, WFK-8.1.1) — 2× SHIP-WITH-TWEAKS, davon 1 kritischer Blocker (linked_sources-Schema-Drift auf WFK-8.1.1), sofort vor Abschluss gefixt. Panel: Sozial-Klima + Climate-Communication + Chair.

Quelle: prompts/phd-reviewer-pass.v1.md Template; interne Wave-Notizen.

18. Source-Integrity-Audit (post-F-121)

Status: verbindlich ab 2026-05-15 (F-121). Methode-Spezifikation: docs/runbook/source-audit.md (Master-Runbook für retrospektive Audits). Der Audit deckt den gesamten Quellen-Korpus ab; jede Quelle trägt einen dokumentierten Verifikations-Befund mit Einzelsignalen und Begründung (Audit-Methode Version 2).

18.1 Anlass und Zielsetzung

Vor der Auslieferung der Pilot-Briefe wurde der gesamte Quellen-Korpus einem systematischen Vollkorpus-Audit auf Quellen-Integrität unterzogen — Crossref-Triangulation der DOIs samt Titel-/Autoren-Abgleich, kombiniert mit Wayback-Snapshot-Verifikation der zitierten URLs, gemäß ADR-0006 (Source-Integrity-Policy). Ziel dieses Audits ist eine belastbare Garantie: Jede tragende Quellenangabe in den ausgelieferten Forschungs-Briefen verweist auf eine real existierende, unabhängig triangulierte Publikation. Quellen, deren Existenz oder bibliografische Angaben sich nicht eindeutig bestätigen lassen, werden in Quarantäne gestellt und aus den Briefen entfernt, nicht ausgeliefert.

Dieser Audit ist kein einmaliger Vorgang, sondern ein stehendes Qualitäts-Gate: Er wird vor jeder Auslieferung erneut durchlaufen, und jede neu aufgenommene Quelle muss den Provenance-Nachweis aus §19 erbringen, bevor sie Teil eines Briefs werden darf.

18.2 Methode (Kurzform — Vollspec im Runbook)

Pro Quelle läuft ein achtstufiges Verifikations-Protokoll (docs/runbook/source-audit.md §2): DOI-Resolve und Crossref-Metadaten-Abgleich (Titel + Erst-Autor:in), URL-Erreichbarkeit mit Content-Match, Wayback-Snapshot-Prüfung zum Recherche-Zeitpunkt sowie eine Titel- und Autor:innen-Suche in den großen Indexen. Die Einzelsignale werden zu einem von drei Befunden aggregiert:

| Befund | Definition (Kurzform) | |---|---| | bestätigt | mindestens eine starke Verifikation greift — z.B. auflösender DOI mit Crossref-Titel-Match, erreichbare URL mit Inhalts-Treffer plus Index-Fund, oder ein vor dem Recherche-Datum liegender Wayback-Snapshot; bei Behörden-Primärquellen genügt erreichbare URL bzw. Wayback-Beleg | | nicht eindeutig | technische Signale reichen für eine belastbare Bestätigung nicht aus → verpflichtende manuelle Einzelprüfung (manual_review) | | nicht bestätigbar | mehrere starke Negativsignale zugleich (z.B. nicht auflösender DOI und kein Index-Treffer für den exakten Titel) → Quarantäne, kein Einsatz in ausgelieferten Briefen |

Die Rubrik ist bewusst konservativ: Im Zweifel wird eine Quelle als „nicht eindeutig" eingestuft und manuell geprüft, statt sie vorschnell zu verwerfen (vgl. Anti-Pattern in docs/runbook/source-audit.md).

18.3 Ergebnis und Konsequenz

Der Vollkorpus-Audit wurde gegen alle Quellen des Korpus durchgeführt. Quellen mit dem Befund nicht bestätigbar wurden in Quarantäne gestellt — der Eintrag bleibt mit vollständigem Audit-Trail erhalten, wird aber aus den Forschungs-Briefen entfernt und nicht ausgeliefert. Quellen mit dem Befund nicht eindeutig durchliefen eine manuelle Einzelprüfung; verbleibende Restzweifel führten ebenfalls zum Ausschluss aus den ausgelieferten Briefen.

Das Ergebnis für die ausgelieferten Pilot-Briefe: Jede tragende Quellenangabe verweist auf eine real existierende, unabhängig triangulierte Publikation (auflösender DOI mit Crossref-Match, Wayback-Beleg vor dem Recherche-Datum oder Eintrag in einer autoritativen institutionellen Registry). Quellen, deren Existenz oder bibliografische Angaben sich nicht eindeutig bestätigen ließen, sind nicht Teil der ausgelieferten Briefe.

18.4 Konsequenzen (going-forward)

1. Stehendes Auslieferungs-Gate — der Audit wird vor jeder Auslieferung erneut durchlaufen; ausgeliefert werden nur Briefe, deren tragende Quellen den Befund „bestätigt" tragen (bzw. eine manuelle Einzelprüfung ohne Restzweifel bestanden haben).
2. Provenance-Pflicht (§19) ist ein Hard-Gate für jede neu aufgenommene Quelle.
3. Diagnostisches Vokabular (§20) strukturiert künftige Audit-Berichte und automatisierte Verifikations-Läufe.
4. Laufende Nach-Recherche ersetzt schrittweise die ausgeschlossenen durch verifizierte Quellen, wo dieselbe Aussage belastbar belegbar ist.

Cross-Refs: ADR-0006 (Source-Integrity-Policy), docs/decisions/2026-05-15-source-hallucination-audit.md. Die internen Audit-Roh-Befunde werden im nicht-öffentlichen Runbook geführt (docs/runbook/source-audit.md).

19. Source-Provenance-Pflicht (going-forward policy)

Status: verbindlich ab 2026-05-15 für jede neu hinzugefügte Source in sources/*.md. Enforcement: ADR-0006 + scripts/audit-source.ts als CI-Pre-Add-Gate (acceptance.sh source-audit-Gate, Stage 11). Das verified_by-Frontmatter-Feld ist strukturiertes Objekt (kanonisch via schemas/source.zod.ts).

19.1 Regel

Jede neu hinzugefügte Source MUSS mindestens eine der folgenden drei Provenance-Optionen vorweisen — andernfalls darf der Source-Add-Commit nicht stattfinden.

| Option | Anforderung | Verifikations-Schritt | |---|---|---| | (a) DOI-Crossref-Match | doi-Feld gesetzt + Crossref-Resolve mit Title+Author exact-match (Fuzzy ≥ 0.8 auf Title; mindestens ein Frontmatter-Author in Crossref-Author-Liste) | Step 2 des 8-Step-Protokolls (docs/runbook/source-audit.md §2) | | (b) Wayback-Pre-Retrieved-Snapshot | Wayback-Snapshot mit Timestamp ≥ 1 Jahr vor retrieved-Datum, der URL als real-existent zum Recherche-Zeitpunkt belegt | Step 4 des 8-Step-Protokolls (Wayback Availability API) | | (c) Institutional-Registry-Eintrag | Eintrag in einer authoritativen Institutional-Registry (WHO Library, IPCC Publications Catalog, IEA Data Portal, EEA Reports, OECD iLibrary, Statistik Austria, Stadt Wien Open Data, RIS, EUR-Lex) — mit URL/ID zum Registry-Eintrag im Audit-Trail | Step 5/6/7 Triangulation gegen Registry-Site |

19.2 Anti-Patterns (untersagt)

• „URL ist live + Title plausibel" als alleinige Provenance — reicht NICHT (vgl. Hallucinations-Subtyp §20.1 Real-Institution-Fake-Title).
• „DOI ist syntaktisch valide" als alleinige Provenance — reicht NICHT (vgl. §20.2 DOI-Resolves-To-Wrong-Paper, §20.5 Wrong-DOI-Assignment).
• „WebSearch fand 1 Treffer" als alleinige Provenance — reicht NICHT, wenn Treffer das eigene Repo / Self-Reference ist.

19.3 Audit-Trail

Pro Source-Add wird die gewählte Provenance-Option + Verifikations-Evidenz im Frontmatter-Feld verified_by dokumentiert. Das Feld ist ein strukturiertes Objekt (kanonisch, schema-enforced via schemas/source.zod.ts; ersetzt den früheren flat-string Format-Vorschlag aus v1.9 — diese Darstellung ist die verbindliche Repräsentation):

# Option (a) — DOI-Crossref-Match
verified_by:
  method: crossref-doi
  evidence: "Crossref-Match: Title-Fuzzy 0.92, Author Müller bestätigt"
  checked_at: "2026-05-15"

# Option (b) — Wayback-Snapshot ≥ 1 Jahr vor retrieved
verified_by:
  method: wayback-snapshot
  evidence: "20230614000000"   # Wayback-Timestamp des ältesten validen Snapshots
  checked_at: "2026-05-15"

# Option (c) — Institutional-Registry-Eintrag
verified_by:
  method: institutional-registry
  evidence: "eur-lex/32024R1781"   # Registry-Permalink oder Registry-ID
  checked_at: "2026-05-15"

Die drei method-Werte bilden die §19.1-Optionen ab: crossref-doi = Option (a), wayback-snapshot = Option (b), institutional-registry = Option (c). evidence trägt den unveränderlichen forensischen Detail (Wayback-Timestamp, Registry-Permalink, Crossref-Match-Notiz); checked_at das ISO-Datum des Audits.

19.4 Tier-1-Legal-Government Sonderfall

type: legal-text-Sources (vgl. §16) erfüllen Option (c) per Definition via RIS (AT-Bund/Land) oder EUR-Lex (EU) oder VfGH/OGH-Datenbank (Höchstgericht) — der jeweilige Registry-Permalink wird als url im Frontmatter geführt. verified_by-Format:

verified_by:
  method: institutional-registry
  evidence: "eur-lex/32024R1781"   # oder ris.bka.gv.at/... / VfGH-GZ etc.
  checked_at: "2026-05-15"

legal_jurisdiction (ADR-0002 A7) bleibt unverändert Pflicht.

20. Hallucinations-Subtypen (5 Patterns aus method-v1)

Status: diagnostisches Vokabular ab 2026-05-15 für Audit-Berichte und automatisierte Verifikations-Läufe. Quelle der Subtypen: empirische Auswertung der im Vollkorpus-Audit als nicht bestätigbar eingestuften Quellen (§18). Sie beschreiben, welche Fehlersignaturen das Verifikations-Protokoll erkennt — und damit gegen welche Defekte die ausgelieferten Briefe abgesichert sind.

Subtypen sind nicht-exklusiv — eine Quelle kann mehrere Pattern gleichzeitig zeigen. Im Audit-JSON wird der dominante Subtyp im evidence-String genannt.

20.1 Real-Institution-Fake-Title

Pattern: Plausibler Titel + reale Institution als Author + plausibler URL-Slug auf Institution-Domain → 404 oder PDF-Slug existiert nicht; Institution-Library kennt das Werk nicht; keine Wayback-Snapshots; WebSearch liefert ähnliches reales Werk (anderer Titel/Scope) derselben Institution.

Beispiel: 2024-un-habitat-climate-justice-cities (cited in WFK-7.1.1) — UN-Habitat ist real, aber kein Compendium dieses Titels auf unhabitat.org / UNEP / UN Digital Library auffindbar; verwandt: reales „World Cities Report 2024: Cities and Climate Action" (anderer Titel, anderer Scope).

Verifikations-Signal: TITLE-FAIL + URL-FAIL + WAYBACK-NONE + AUTHOR-PASS (Institution real, aber Werk nicht).

20.2 DOI-Resolves-To-Wrong-Paper

Pattern: doi-Feld gesetzt, DOI ist syntaktisch valide und Crossref-resolved, aber das aufgelöste Paper hat einen anderen Titel und/oder andere Autoren als das Source-Frontmatter behauptet.

Verifikations-Signal: DOI-MISMATCH (Step 2, Fuzzy < 0.8 zwischen Frontmatter-Title und Crossref-Title) — oft kombiniert mit DOI-AUTHOR-MISMATCH.

20.3 Real-Paper-Fake-Authors

Pattern: Title und Venue sind real (WebSearch-Treffer auf Publisher / Repository), aber die Frontmatter-Autoren-Liste enthält Personen, die im realen Werk nicht als Autoren geführt sind — typisch: KI hat plausibel klingende Wissenschaftler:innen aus dem Themenfeld dazu-erfunden.

Verifikations-Signal: TITLE-PASS + AUTHOR-FAIL (Step 6 Author-Search liefert keine Co-Authorship-Belege; Crossref-Author-Liste enthält keinen Frontmatter-Author).

20.4 Real-Paper-Paraphrased-Title

Pattern: Es existiert ein reales Paper mit ähnlichem Inhalt + überlappenden Autoren, aber der Frontmatter-Titel ist eine KI-paraphrasierte Variante (z.B. „Heat Vulnerability in Urban Microclimates" statt original „Microclimate Heat Vulnerability in Cities"). Auf den ersten Blick scheint die Source real, beim exact-title-WebSearch (Step 5) gibt es aber 0 Treffer.

Verifikations-Signal: TITLE-FAIL bei exakter Suche, aber TITLE-PASS bei fuzzy/keyword-Suche + AUTHOR-PASS — Audit muss aufmerksam zwischen „nicht-existent" und „paraphrasiert" unterscheiden.

20.5 Wrong-DOI-Assignment

Pattern: Frontmatter-Title + Authors + Year matchen ein reales Werk, aber das doi-Feld zeigt auf ein anderes reales Werk (KI hat zufällig einen valide aussehenden DOI aus dem Trainings-Korpus assoziiert). Im Unterschied zu §20.2 ist das Frontmatter selbst real-zuordenbar, nur die DOI-Zuordnung ist falsch.

Verifikations-Signal: DOI-PASS (Crossref resolved + Title-Match auf den DOI-Target), aber Frontmatter-Title + Authors matchen das DOI-Target NICHT, sondern ein anderes reales Werk in der WebSearch (Step 5).

20.6 Anwendung im Audit-Report

In _research/source-audit-<date>.md (Tracking-Sheet pro Audit-Lauf) wird in der notes-Spalte der dominante Subtyp benannt (z.B. „§20.1 Real-Institution-Fake-Title" oder „§20.2 DOI-Resolves-To-Wrong-Paper"). Damit ist für Folge-Audits / Verifier-Agents / Customer-Trust-Audits die Halluzinations-Klasse maschinen-lesbar nachvollziehbar.

21. Forschende-Discovery-Methodology (Wiener Researchers via OpenAlex)

Status: v1.10-additiv ab 2026-05-15 (Deep #24). Customer-driven Scope-Erweiterung aus der Mail Katharina Meißner-Schöller 2026-05-13: „inwiefern zu den jeweiligen Fragen Forschungsexpertise in Wien besteht und, falls ja, welche (etwa 1–3) Forschenden …". Vollspec: docs/prd/2026-05-15-forschende-mapping.md. Empirisches Briefing aller hier referenzierten API-Annahmen: _research/openalex-recon-2026-05-15.md (~25 min Spike, 13 ROR-Lookups, 3 Pilot-WFK-Topic-Discoveries, Rate-Limit-Verifikation).

21.1 Ziel

Pro WFK-Forschungsfrage werden 1–3 in Wien aktive Forschende (an Wien-Hochschulen oder Wien-relevanten außeruniversitären Forschungseinrichtungen) als zusätzliche Dimension im Forschungs-Brief gepflegt. Discovery ist voll-automatisch (OpenAlex-API + LLM-Translate + LLM-Re-Rank), aber nicht voll-autonom: jeder Output durchläuft ein Admin-Review-Gate (§21.5) bevor er customer-sichtbar wird. Ergebnis-Felder: openalex_id, display_name, institution, optional orcid / public_profile_url + Provenance-Felder. Customer-Render: Detail-Page-Block „Wiener Forschende", Card-Badge, Brief-Body-Sektion, PDF- und CSV-Export.

21.2 Pipeline-Schritte (6 enforced steps)

Die Reihenfolge ist nicht-verhandelbar (siehe PRD §4 Architecture und empirisches Briefing §6). Jeder Schritt schreibt sein Zwischen-Ergebnis ins Provenance-Sidecar data/researcher-provenance/<wfk-id>.json (Audit-Trail-Pflicht analog §19.3).

1. LLM-Translate (DE→EN). WFK-Frage (DE) → Anthropic Haiku-4-5 mit versioniertem Prompt prompts/forschende-translate.v1.md → 3–5 EN-Keywords + 1 kondensierter Topic-Query. Begründung: DE-Suche auf OpenAlex ist empirisch tot (Recon §3: /topics?search=KI Energieverbrauch Gebäude = 0 Treffer; EN-Äquivalent „building energy efficiency" = 5 Topics). Output landet in provenance.translate_output.

2. Topic-Discovery. EN-Keywords → GET /topics?search=<en-keywords> → Top-3 Topic-IDs + scores. Wenn best_topic.score ≥ 0.6: Topic-Pfad (Step 3). Topic-IDs werden NIE hardcoded — sie sind nicht stabil über Briefings hinweg (Recon §5 Edge-Case 6). Output: provenance.topic_discovery.

3. Authors by Topic+Institution. Topic-ID + Wien-ROR-Liste (§21.3) → GET /authors?filter=last_known_institutions.ror:<wien-list>,topics.id:<T>&sort=works_count:desc&per_page=25. Output: provenance.authors_raw (Top-25 Wien-Authors im Topic).

4. Works-Fallback (Trigger: topic_score < 0.6 ODER n_authors < 10). Bei schwachem Topic-Match Keyword-Search auf /works?search=<keywords>&filter=authorships.institutions.ror:<wien-list>&per_page=50 mit anschließendem Author-Rollup (Distinct-Author-Count gewichtet nach works_count). Begründung: Topics sind ein vorgefertigtes 4-Level-Cluster, nicht eine offene Tag-Wolke; Themen wie „Klimagerechtigkeit / Verwaltung & Klima" haben kein dediziertes Topic (Recon §3, §5 Edge-Case 3). Output: provenance.works_fallback.

5. Frische-Filter (Hard-Gate). Für jeden Author: prüfe affiliations[].years; behalte nur Authors mit ≥ 1 Wien-ROR-Affiliation in [today − 3y, today]. Begründung: last_known_institutions allein produziert „Retired-Researcher"-Hits; affiliations[] liefert Jahres-granulare Inst-Historie (Recon §4: Probe Lukas Kranzl years: [2026, 2025, 2024, 2023, 2022]). Output: provenance.fresh_filtered.

6. LLM-Re-Rank (optional, Feature-Flag). Top-10 Authors + Frage-Beschreibung → Anthropic Haiku-4-5 mit versioniertem Prompt prompts/forschende-rerank.v1.md → Re-Rank nach Topic-Fit (statt roher works_count-Sortierung). Adressiert den „Senior-General-vs-Topic-Fit"-Bias (Recon §5 Edge-Case 7: works_count-Sort privilegiert Senior-Autoren über Themen-Breite). Final Top-3. Output: provenance.final (+ optional Frontmatter-Write via --auto-write-frontmatter).

21.3 Wien-Institutions-Definition

12 Institutionen mit eindeutiger ROR + OpenAlex-ID, gepflegt in data/wien-institutions.yaml (Registry). Empirisch verifiziert in Recon §2:

| # | Institution | ROR | OpenAlex | |---|---|---|---| | 1 | University of Vienna | 03prydq77 | I129774422 | | 2 | TU Wien | 04d836q62 | I145847075 | | 3 | Medical University of Vienna | 05n3x4p02 | I76134821 | | 4 | BOKU University | 057ff4y42 | I92869138 | | 5 | Vienna University of Economics (WU) | 03yn8s215 | I102248843 | | 6 | University of Veterinary Medicine Vienna | 01w6qp003 | I150540706 | | 7 | IIASA (Laxenburg) | 02wfhk785 | I1317774081 | | 8 | AIT (Austrian Institute of Technology) | 04knbh022 | I132118926 | | 9 | GeoSphere Austria (ex-ZAMG) | 048dqgk17 | I2799949648 | | 10 | WIFO | 0515pjs57 | I1315541505 | | 11 | IHS (Institut für Höhere Studien) | 05ag62t55 | I4210156362 | | 12 | Akademie der bildenden Künste Wien | 029djt864 | I5075986 |

CCCA-Aggregation (Sonderfall): Das Climate Change Centre Austria hat keinen eigenen ROR und keinen OpenAlex-Record (Recon §2). CCCA wird als virtuelle Aggregation über Member-Institutionen behandelt — alle CCCA-affiliierten Forschenden werden über ihre primäre Member-Inst (Uni Wien, BOKU, TU Wien, …) erfasst, die ohnehin in der 12er-Liste stehen. data/wien-institutions.yaml enthält dazu einen expliziten ccca_member_aggregation-Block mit Doku-Hinweis. Folge: kein ror:CCCA-Filter, kein „13. Institution"; Pipeline-Doku und Brief-Methodology-Sektion erklären die Aggregation, um Customer-Verwirrung („Wieso ist CCCA nicht in der Liste?") vorzubeugen.

21.4 Provenance-Pflicht (analog ADR-0006)

ADR-0006 (Source-Integrity-Policy) hat die F-121-Lehre — „kein customer-sichtbares Datum ohne nachvollziehbare Provenance" — für Quellen kodifiziert (§19). §21.4 zieht dieselbe Disziplin für Researcher-Records:

Hard-Requirements pro Researcher-Record (im Question-Frontmatter wiener_researchers[]):

• openalex_id (Pattern ^A\d+$) — Stable-ID, primärer Anker. NIEMALS NULL bei einem aktiven Record. Ohne openalex_id kein Eintrag — freihändiges Hinzufügen „bekannter Wien-Forschender" ohne OpenAlex-Anchor ist explizit verboten (öffnet Halluzinations-Surface analog F-121).
• discovered_at (ISO-Datetime) — Wann der Pipeline-Lauf den Record produziert hat.
• verified_by (string) — auto (Auto-Discovery, kein Admin-Touch) | bernhard (Phase-1-Admin) | künftig user-ids bei Multi-Admin-Erweiterung.

Manual-Edit-Path: Sobald ein Admin im Dashboard-Edit-UI (siehe ADR-0007) einen Record ändert (reject / accept / pin neuer Researcher / Inst-Korrektur), gilt:

• manually_edited: true wird gesetzt.
• Im Sidecar data/researcher-provenance/<wfk-id>.json wird edit_history[] um ein Append-only-Entry { ts, user, action, before, after } erweitert. Sidecar-Pattern analog ADR-0004 (mutating metadata).
• Sidecar-Files sind gecommittet (Audit-Trail-Pflicht), keine Gitignore-Ausnahme.

Audit-Trail-Format (analog §19.3, verified_by-String-Variante für Researcher):

verified_by: "forschende-pipeline-2026-05-15:auto"        # auto-discovered, no admin touch
verified_by: "forschende-pipeline-2026-05-15:bernhard"    # admin-reviewed/edited

Rationale: Der Quellen-Integritäts-Audit (§18) hat gezeigt, dass auto-generierte Daten ohne expliziten Provenance-Trail nicht vertrauenswürdig genug für die Auslieferung sind — deshalb der verpflichtende Verifikations-Nachweis vor jeder Aufnahme. Researcher-Records sind ähnlich exponiert: Eine Kund:in kann zu jedem Researcher fragen „Wo kommt der her?", und die Antwort muss in unter 30 Sekunden aus dem Sidecar reproduzierbar sein (PRD AC-10).

21.5 Admin-Review-Gate

Pipeline-Output ist NIEMALS automatisch customer-sichtbar. Zwischen Auto-Discovery (Step 6) und Brief-Render gibt es einen explizit verpflichtenden Admin-Review-Gate:

1. Pipeline schreibt provenance.final ins Sidecar — Frontmatter-Feld wiener_researchers bleibt zunächst leer (oder mit status: pending-review-Marker im Sidecar, je nach Implementation-Detail-W3).
2. Admin (in Phase 1: Bernhard, via Admin-UI /admin/researchers/[wfk-id]) prüft das Auto-Ergebnis: accept / reject / edit / add-pinned. Optionaler Feedback-Eintrag (§21.6).
3. Nach explizitem „Save"-Action wird das Frontmatter geschrieben (questions/<wfk-id>.md Frontmatter-Update + Git-Commit via Pre-Commit-Hook). Erst jetzt ist der Record für Detail-Page / Card-Badge / PDF / CSV sichtbar.

Begründung (Lehre aus dem Quellen-Audit): Der Vollkorpus-Audit (§18) hat gezeigt, dass ohne expliziten Verifikations-Gate Quellen nicht-bestätigbarer Provenienz ins Korpus wandern können — die Konsequenz war die Quarantäne und der Ausschluss der betroffenen Einträge vor Auslieferung. §17 PhD-Reviewer-Pass und §18 Audit-Methode sind die strukturellen Antworten für Briefe und Quellen; §21.5 ist das Äquivalent für Researcher-Records: ein Mensch entscheidet, was kund:innen-sichtbar wird. Cross-Refs: §17 (PhD-Reviewer-Pass-Pattern), §18 (Source-Integrity-Audit-Methode), ADR-0006 (Source-Provenance-Policy).

21.6 Feedback-Loop

Auto-Discovery ist iterativ. Admin-Feedback wird strukturiert erfasst und in nachfolgende Pipeline-Läufe re-injiziert:

• Erfassung im Admin-UI: Freitext-Feld („Was sollte die Pipeline anders machen?") + Structured-Tags (wrong-institution, not-active-anymore, wrong-topic-fit, missing-known-expert).
• Persistenz: data/researcher-feedback/<wfk-id>.json (gecommittet).
• Re-Run-Mechanik: Bei pnpm tsx scripts/discover-researchers.ts <wfk-id> --consider-feedback:
  • bestehende Feedback-Items werden als Negativ-Beispiele in den LLM-Re-Rank-Prompt (Step 6) eingespeist;
  • manuell-akzeptierte Researcher werden als pinned beibehalten (überleben Re-Discovery);
  • das resultierende Provenance-Sidecar dokumentiert die Feedback-Berücksichtigung explizit (PRD AC-7).

Disziplin: Feedback ist kein Edit-Ersatz — wenn Bernhard einen Researcher rejected, wird das primär als edit_history-Eintrag im Provenance-Sidecar (§21.4) erfasst, das researcher-feedback/-File nimmt die Begründung auf für die nächste LLM-Iteration. Beides koexistiert.

21.7 Risks

Paraphrasiert aus PRD §5 (Risk-Table). Mitigations sind in der jeweiligen Pipeline-Stufe verankert; diese Sektion dient als methodische Sichtbarmachung für Folge-Audits.

1. CCCA-No-Record. Das Climate Change Centre Austria hat keinen eigenen ROR/OpenAlex-Record — ein direkter ror:CCCA-Filter ist unmöglich. Mitigation: virtuelle Aggregation über Member-Inst (§21.3); Pipeline-Doku + Brief-Methodology-Sektion erklären den Workaround.
2. DE-Search-Tot. OpenAlex-Suche in DE liefert empirisch 0 Treffer für nicht-trivial-anglophone Begriffe (Recon §3). Mitigation: LLM-Translate-Step (Step 1) ist Pflicht, nicht Optimierung; Output-Validation auf Keywords-Format.
3. Topic-Coverage-Skew. Topics sind ein vorgefertigtes 4-Level-Cluster — Themen wie „Klimagerechtigkeit / Verwaltung & Klima" haben kein dediziertes Topic, Topic-Match schwankt stark über Cluster (Recon §3, §5). Mitigation: Works-Fallback (Step 4) bei score < 0.6 oder n_authors < 10; LLM-Re-Rank (Step 6) für Topic-Fit über bloße works_count-Sortierung.
4. OpenAlex-Display-Name-Stale. Display-Namen können veraltet sein (Recon §2: GeoSphere Austria heißt im OpenAlex-Record noch „Central Institution for Meteorology and Geodynamics"). ROR-ID bleibt aber stabil. Mitigation: Wir filtern auf ROR, nicht auf Display-Name; Wien-Inst-Registry data/wien-institutions.yaml pflegt den korrekten Display-Namen für Customer-Render.
5. Works-Count-Bias. sort=works_count:desc (Step 3) privilegiert Senior-Autoren mit hoher Gesamt-Output — die haben aber nicht zwingend den höchsten Topic-Fit (Recon §5 Edge-Case 7: Kranzl 196 works über alle Themen, davon Anteil im Topic-Cluster ggf. klein). Mitigation: LLM-Re-Rank (Step 6); zusätzlich Erfassung works_count_in_topic als Sekundärsignal in der Researcher-Record-Struktur.

21.8 Cross-Refs

• PRD docs/prd/2026-05-15-forschende-mapping.md — Vollspec, AC-1…AC-10, Out-of-Scope-Begründungen, Risk-Table mit Probability + Mitigation-Spalten.
• ADR-0007 (NEU) docs/adr/0007-application-level-auth-rbac.md — Application-Level Auth-Schicht für das Admin-Edit-UI (kontrollierte Erweiterung von ADR-0001 Markdown-SSOT um Session-State).
• Runbook docs/runbook/forschende-discovery.md — Operative Anleitung (Re-Run, Rate-Limit-Handling, Feedback-Re-Inject-Flow), Output von Sub-Issue W2-E.
• Registry data/wien-institutions.yaml — 12 ROR-IDs + CCCA-Aggregation-Block (siehe §21.3).
• ADR-0006 docs/adr/0006-source-integrity-policy.md — Vorbild für §21.4 (Provenance-Pflicht, analog für Quellen).
• ADR-0004 docs/adr/0004-sidecar-pattern-mutating-metadata.md — Vorbild für das Provenance-Sidecar-Pattern.
• §17 (PhD-Reviewer-Pass) + §18 (Audit-Method-v2) — Methodische Vorbilder für den Admin-Review-Gate (§21.5).

21.9 PhD-Coordinator-Pattern (Anthropic-API-Bypass)

Status: Empirisch erprobt 2026-05-16 (Deep #28). 45 Wiener Forschende (3 pro WFK, 15 Pilot-Fragen) zero-cost via Coordinator-Subagents persistiert und verifiziert. Pattern ist Bernhard-supervised — nicht voll-autonom.

21.9.1 Motivation

Die Standard-Discovery-Pipeline (§21.2) nutzt zwei Anthropic-API-Subschritte: LLM-Translate (Step 1, Haiku-4-5) und LLM-Re-Rank (Step 6, Haiku-4-5). Für kleinere Runs (≤ ~50 WFK) existiert eine alternative Ausführungsform, bei der ein Claude Code Coordinator (Opus 4.7 oder Sonnet, innerhalb einer laufenden Deep-Session) diese beiden LLM-Subschritte als Subagent-Calls direkt erledigt — ohne separaten Anthropic-API-Schlüssel, ohne Haiku-Kosten, ohne scripts/discover-researchers.ts-Orchestrierung.

Dieses Verfahren ist zweckmäßig wenn:

• Das Pilot-Set klein ist (≤ 15–50 WFK), sodass das Coordinator-Token-Budget der laufenden Session die Arbeit aufnehmen kann.
• Kosten-Sensitivität hoch ist (kein Anthropic-API-Guthaben, Staging-Phase, Prototyp-Validierung).
• Der Bernhard-Admin-Review-Gate (§21.5) ohnehin unmittelbar folgt — d.h. das Ergebnis muss sowieso vor Customer-Sichtbarkeit manuell geprüft werden.

Wann NICHT verwenden: Bei mehr als ~50 WFK in einem einzelnen Run, oder wenn Reproduzierbarkeit ohne aktive Session Pflicht ist → dann ist der API-Pfad (scripts/discover-researchers.ts + Haiku-4-5) ökonomisch und technisch sinnvoller. Kostenvergleich: siehe §21.9.5.

21.9.2 Architektur

Der Coordinator-Pattern ersetzt Step 1 (LLM-Translate) und Step 6 (LLM-Re-Rank) durch direkte Subagent-Calls innerhalb der Deep-Session. Die verbleibenden Steps 2–5 (OpenAlex-REST, Frische-Filter) bleiben identisch und werden vom Coordinator direkt via curl/Bash-Tool gegen die OpenAlex polite-pool-API ausgeführt (mit mailto-Parameter gemäß API-Etiquette).

Ablauf im Deep #28-Precedent:

1. Translate (Coordinator-intern): Der Coordinator übersetzt die DE-Frage direkt in 3–5 EN-Keywords + Topic-Query. Kein API-Call, keine Latenz — Sprachkompetenz ist im Modell vorhanden. Output landet als Inline-Reasoning im Sidecar-JSON (coordinator_reasoning-Feld).

2. OpenAlex-REST (direkt): GET /topics?search=<en-keywords> + GET /authors?filter=last_known_institutions.ror:<wien-list>,topics.id:<T>&sort=works_count:desc&per_page=25. Polite-Pool mit mailto=office@gotzendorfer.at. Raw-Response wird im Provenance-Sidecar als raw_openalex_response abgelegt (ADR-0006-Provenance-Pflicht; analog §21.4).

3. Frische-Filter (Hard-Gate): Identisch zu §21.2 Step 5 — affiliations[].years ≥ today − 3y für mindestens eine Wien-ROR-Affiliation. Dieser Gate ist nicht-verhandelbar; auch im Coordinator-Pattern gilt: kein Author ohne aktuelle Wien-Affiliation.

4. Re-Rank (Coordinator-intern): Der Coordinator rankt die Top-10 gefilterten Authors nach Topic-Fit semantisch neu (analog Haiku-Re-Rank-Prompt prompts/forschende-rerank.v1.md). Reasoning explizit dokumentiert im Sidecar (coordinator_reasoning-Feld, Freitext).

5. Parallelisierung: Im Deep-#28-Lauf wurden 3 Discovery-Subagents parallel geschickt, je Batch von 5 WFK. Damit war das gesamte Pilot-Set (15 WFK × 3 Authors) in ~30 Minuten abgearbeitet. Für einen Full-Run (204 WFK) wären entsprechend ~4 Batches à 50 WFK möglich — aber ab dieser Größe lohnt der API-Pfad (§21.9.5).

Wien-ROR-Registry: Identisch zu §21.3. Coordinator liest data/wien-institutions.yaml (12 Institutionen + CCCA-Aggregation). Kein Handcoding von ROR-IDs in den Subagent-Prompts — immer aus der Registry laden.

21.9.3 Editor ≠ Verifier-Pass

Gemäß Memory-Pattern feedback-walkthrough-prevet-then-decision (Editor ≠ Verifier on source-integration) wird jeder Author-Block von einem zweiten, unabhängigen Coordinator-Subagent gegen den primären OpenAlex-Record verifiziert, bevor der Record ins Frontmatter geschrieben wird.

Verifikations-Checklist pro Author-Record:

• openalex_id auflösbar? (GET /authors/<A-id> → HTTP 200)
• display_name im OpenAlex-Record identisch zum persistierten Namen?
• Mindestens 1 Wien-ROR-Affiliation im affiliations[].institution.ror-Feld mit years-Eintrag ≥ heute − 3 Jahre?
• works_count ≥ 3 (Minimal-Output-Schwelle, verhindert Ghost-Autoren)?
• Kein explizit falscher Topic-Fit (Verifier-Agent gibt Freitext-Begründung)?

Wenn mindestens eine Bedingung nicht erfüllt ist → Record wird verworfen, Coordinator-Note im Sidecar, nächster Author aus dem Top-10-Pool wird geprüft. Das Ergebnis des Verifier-Passes ist im Sidecar-Feld verified_by: "phd-curator-YYYY-MM-DD" festgehalten (analog §21.4-Provenance-Pflicht; Cross-Ref ADR-0006).

21.9.4 Provenance-Sidecar

Pflichtige Sidecar-Files unter _research/forschende-pilot-smoke-2026-05-15-sidecars/<WFK-id>.json. Mindest-Schema:

{
  "wfk_id": "WFK-2.1.5",
  "run_date": "2026-05-16T10:00:00Z",
  "pattern": "phd-coordinator",
  "coordinator_model": "claude-opus-4-7",
  "translate_output": {
    "en_keywords": ["building energy efficiency", "smart buildings", "heat pump"],
    "topic_query": "energy efficient buildings Vienna"
  },
  "raw_openalex_response": { "...": "truncated or full response" },
  "coordinator_reasoning": "Ranked Kranzl above Mahdavi because works_count_in_topic is higher despite lower overall works_count. Haas excluded: last Wien-affiliation 2019 (< today−3y).",
  "fresh_filter_cutoff": "2023-05-16",
  "final_top3": [
    { "openalex_id": "A2143292867", "display_name": "Lukas Kranzl", "verified": true },
    { "openalex_id": "A2023456789", "display_name": "Ardeshir Mahdavi", "verified": true },
    { "openalex_id": "A1987654321", "display_name": "Ulla Unger", "verified": true }
  ],
  "verified_by": "phd-curator-2026-05-16"
}

Sidecar-Files sind gecommittet (Audit-Trail-Pflicht, analog ADR-0004). Sie sind nicht gitignored. Das verified_by-Suffix phd-curator-YYYY-MM-DD signalisiert, dass ein Coordinator-Agent (nicht auto-Pipeline, nicht direkter Bernhard-Edit) den Record verifiziert hat — Cross-Ref §21.4.

21.9.5 Cost-Comparison: API-Pfad vs. PhD-Coordinator-Pattern

| Dimension | API-Pfad (scripts/discover-researchers.ts + Haiku-4-5) | PhD-Coordinator-Pattern | |---|---|---| | Translate-Kosten | ~$0.001 pro WFK (Haiku Input/Output tokens, DE→EN 50 tokens in / 80 out) | 0 — Session-Token-Budget | | Re-Rank-Kosten | ~$0.003 pro WFK (Haiku, Top-10 Authors × 200 tokens + Frage) | 0 — Session-Token-Budget | | Full-Run 204 WFK | ~$0.82 total (604 Translate + 604 Re-Rank calls) | Session-Token-Budget-Druck — bei 204 WFK substanziell | | Pilot-Set 15 WFK | ~$0.06 total | 0 Kosten, ~30 min Coordinator-Zeit | | Reproduzierbarkeit | Skript-Run deterministisch, CI-kompatibel | Nur mit aktiver Session reproduzierbar | | Autonomie | Voll-automatisch (mit --auto-write-frontmatter) | Bernhard-supervised (§21.5 Admin-Gate bleibt Pflicht) | | Break-Even | Bei ≥ ~50 WFK lohnt API-Pfad | Optimal ≤ 50 WFK, Prototyp-Validierung, Staging |

Faustformel: Pilot-Set (≤ 15–20 WFK) → PhD-Coordinator-Pattern. Rollout (> 50 WFK) → API-Pfad. Dazwischen (20–50 WFK) → situative Entscheidung je nach Session-Token-Budget und Zeitdruck.

21.9.6 Cross-Refs

• §17 (PhD-Reviewer-Pass-Pattern) — Analoges Subagent-Delegation-Prinzip für Brief-Quality-Review; PhD-Coordinator-Pattern überträgt dieselbe Idee auf Discovery.
• §18 (Source-Integrity-Audit, Audit-Method-v2) — F-121-Lehre: Auto-generierte Daten ohne Verifikation sind nicht customer-trust-fähig. PhD-Coordinator-Pattern antwortet darauf mit explizitem Editor≠Verifier-Pass (§21.9.3).
• §21.2 (Pipeline-Schritte) — Coordinator-Pattern ersetzt Step 1 + Step 6; Steps 2–5 sind identisch.
• §21.4 (Provenance-Pflicht) — verified_by: "phd-curator-YYYY-MM-DD" ist eine explizit definierte Variante im Provenance-Audit-Trail.
• §21.5 (Admin-Review-Gate) — Auch beim Coordinator-Pattern ist der Admin-Gate Pflicht vor Customer-Sichtbarkeit. Der Coordinator-Verifier-Pass (§21.9.3) ersetzt nicht den Admin-Gate — er ist ein zusätzlicher Pre-Gate.
• ADR-0006 (docs/adr/0006-source-integrity-policy.md) — Provenance-Pflicht, auf Researcher-Records übertragen via §21.4; Sidecar-Pflicht analog ADR-0004.
• Memory feedback-walkthrough-prevet-then-decision — Editor≠Verifier-Prinzip, das §21.9.3 strukturell umsetzt.

22. Multi-Reviewer-Peer-Review-Layer (R-Block Phase 1.5, ab 2026-05-17)

22.1 Übersicht

Ergänzung zum LLM-basierten PhD-Reviewer-Pass (§17) um eine menschliche Peer-Review-Schicht: 3 externe Wiener Forschende reviewen jeden Forschungs-Brief nach drafted-Status. 2-of-3 approve triggert automatische Transition zu reviewed. Nach 7-Tage-Veto-Window (admin-vetobar): automatische Promotion zu published.

Diese Schicht ist customer-facing und signalisiert externe Validierung: „Peer-reviewed by 3 Wiener Forschende" auf reviewten und publizierten Briefen.

22.2 Abgrenzung zum §17 PhD-Reviewer-Pass

• §17 PhD-Reviewer-Pass (LLM-Layer, während Drafting-Wave) — automatisiert, Subagent-Personas (Architekt:in, Security-Expert:in, QA-Strateg:in, etc.), 9 Review-Kriterien, Verdict SHIP/SHIP-WITH-TWEAKS/RESHAPE. Verhindert Methodik-Mängel vor Abschluss des Brief-Drafts.
• §22 Multi-Reviewer-Layer (Mensch-Layer, nach Brief-Draft) — strukturierte Peer-Review durch 3 externe Wiener Forschende aus relevanten Disziplinen, Verdict approve/request-changes/decline mit Kommentar. Validiert Customer-Reife vor Publikation.

Beide Layer sind komplementär: §17 sichert Drafting-Qualität früh, §22 sichert finales Produkt vor Customer-Versand.

22.3 Quorum-Engine und Workflow-State-Machine

Spezifikation: ADR-0008 (SQLite-Workflow-Layer) + PRD docs/prd/2026-05-17-reviewer-workflow.md §4.

State-Übergänge:

• drafted → reviewed: 2-of-3 Reviewer approve (Quorum erreicht), keine request-changes/decline ausstehend
• drafted → needs-revision: ≥1 Reviewer setzt request-changes ODER decline
• needs-revision → drafted: Admin reset nach Revision (alte Reviews werden superseded, neue Runde startet)
• reviewed → published: Auto-Promotion nach 7 Tagen (ohne Admin-Veto) ODER manueller Admin-Push
• reviewed → needs-revision: Admin-Veto + Rückkehr zur Review
• published → needs-revision: Admin-Override bei Post-Publish-Finding

22.4 Customer-facing Signal

Forschungs-Briefe mit Status reviewed oder published tragen das Qualitäts-Signal:

„Peer-reviewed by 3 Wiener Forschende"

Dieses Signal erhöht den Customer-Wert — die Briefe sind nicht nur LLM-rationalisiert (§17), sondern auch durch externe Fachpersonen human-validated. Die Reviewer-Identitäten werden nicht namentlich customer-facing veröffentlicht (DSGVO + Anonymitätsschutz), nur das Aggregate-Statement.

22.5 Reviewer-Anforderungen und Pool

Fachliche Anforderungen pro Reviewer:

• Forschungs-Aktivität in relevanter Disziplin (Klima, Stadt, Energie, Mobilität, Umwelt, Sozialwissenschaften, etc.)
• Wien-Bezug: institutionelle Affiliation (Universität Wien, TU Wien, BOKU, AIT, WIFO, etc.) ODER thematische Expertise mit Wien-Fokus
• Zeitkapazität: ~10–15 Min pro Brief × 200 Briefe = ~50 Stunden für kompletten Roll-Out
• Verfügbarkeit: mindestens 3 aktive Reviewer, plus ≥1 Backup für Vacancy-Szenarien

Pool-Größe: 3 aktive + 1 Backup (= 4 Konten). Bei Erweiterung auf >50 Briefe eventuell 5–6 Reviewer für höhere Parallelisierung.

22.6 Open-Review-Prinzip und Anchoring-Bias-Mitigation

Reviewer sehen alle bisherigen Reviews auf einem Brief (open-review, kein blind-review).

Vorteile: Diskussions- und Lerneffekt, Konsens erleichtert, falsche Standalone-Annahmen einzelner Reviewer werden durch andere Perspektiven korrigiert.

Nachteil: Anchoring-Bias — der erste Reviewer beeinflusst die nachfolgenden.

Mitigation: Diese Methodik-Sektion dokumentiert das Trade-off transparent. Customer-Statement erwähnt „peer-reviewed" explizit ohne blind-review-Claim. Open-Review ist akzeptiert als Phase-1.5-Design-Entscheidung (siehe PRD 2026-05-17-reviewer-workflow.md §8 R7) und wird ggf. in Phase 2 revisited, wenn Reviewer-Feedback Anonymisierung erzwingt.

22.7 Versionierung und Audit-Trail

Jede Status-Transition wird in SQLite-Workflow-Tabelle persistiert mit:

• Auslöser (triggered_by): username des handelnden Users
• Zeitstempel (created_at): ISO-Datetime
• Grund (trigger_reason): manual / quorum-met / auto-promotion-7d / reviewer-revision-request / admin-override / admin-reset-after-revision / admin-veto-extend

Volle Reproduzierbarkeit für Customer-Anfragen und Operational-Audits. Audit-Log abrufbar via /admin/audit-log (R-Block AC-12), Per-User-Activity-Feed via /admin/users/[username]/activity (R-Block AC-13).

22.8 Methodologische Konsequenzen

Bei zukünftigen Audits und Studien zu diesem Forschungs-Brief-Projekt:

• Status ist nicht statisch. Ein Brief kann nach published zurückrollen zu needs-revision bei Post-Publish-Finding oder Admin-Override (Policy, nicht Fehler). Versions-Historie via Git-Commits nachvollziehbar.
• Last-Updated-Datum ist relevant. Customer (Stadt Wien) sieht aktuelle Brief-Version + last_updated-Timestamp. Bei substanziellen Updates nach Publikation: Mail-Benachrichtigung an Stakeholder (Bernhard-Action, entkoppelt von R-Block-Engine).
• Review-Status ist transparent. Jeder Brief trägt ein Status-Badge (drafted / reviewed / published / needs-revision); die Quorum-Zusammensetzung (z.B. „2/3 approve, 1/3 pending") ist in Admin-UI sichtbar, nicht customer-facing.

22.9 Risks und Mitigationen

Siehe PRD 2026-05-17-reviewer-workflow.md §7 Risk-Table. Wichtigste technische + personelle Risks:

• R3 Quorum-Stall: Nur 2 Reviewer verfügbar (Urlaub/Krankheit) — Mitigation: Pool ≥3 + Admin-Override-Fallback.
• R6 Reviewer-Burnout: 200 Briefe × 3 Forscher = ~600 Reviews — Mitigation: Schmale Verdict+Comment-Form (~10 Min pro Review), Bulk-View, Section-Tag optional.
• R7 Anchoring-Bias: Open-Review beeinflusst spätere Reviewer — Mitigation: dokumentiert (diese Sektion), akzeptiert als Trade-off.

22.10 Cross-Refs

• ADR-0008 docs/adr/0008-workflow-state-sqlite.md — SQLite-Workflow-Layer-Spezifikation
• PRD docs/prd/2026-05-17-reviewer-workflow.md — Vollständige R-Block-PRD (Workflow-State-Machine, UI-Spec, AC, Risks)
• §17 (PhD-Reviewer-Pass-Pattern) — Komplementäre LLM-basierte Quality-Gate vor Drafting
• §18 (Source-Integrity-Audit) — Vertrauens-Governance für Input-Daten (Quellen)
• §21 (Forschende-Discovery-Methodology) — Mapping von 3 Wiener Forschenden pro Brief (Input für Reviewer-Pool-Auswahl)
• Runbook docs/runbook/reviewer-onboarding.md (geplant, R-18) — Admin-Provisioning, Reviewer-FAQ
• Runbook docs/runbook/pii-anonymization.md (erweitert, R-17) — DSGVO-Compliance für Reviewer-PII und Review-Comments

Changelog

• 2026-05-08: Skeleton angelegt (Phase-0-Wrap-Up-Session, #13 prep).
• 2026-05-09: v1 — Vollinhalt nach Pivot-PRD 2026-05-09 (§4 Source-Whitelist-Reihenfolge, §5 Quality-Checklisten Pre/Per/Post/Cross, §6 Subagent-Disziplin). Worked-Examples-Sektion als Platzhalter angelegt, Befüllung in Wave 3 der Deep-Session 2026-05-09 (Issue #143).
• 2026-05-09 (W3-3E): v1.1 — §7 Worked Examples mit drei Goldstandard-Walkthroughs (WFK-2.1.5, WFK-1.4.1, WFK-6.1.1) befüllt. §5 Post-Synthese: Status-Werte auf schema-konform korrigiert (draft → drafted, review-ready → reviewed, gemäß schemas/workflow.zod.ts STATUSES) und Audit-Trail-Block-Bullet ergänzt (Output-Vertrag aus prompts/ai-rating.v1.md).
• 2026-05-09 (Phase-1.5 W1, SQ-10): v1.2 — Draft, finalisiert in Phase A W4.
  • DOI-Hierarchie kodifiziert (§2.3.1) — war: disjunktiv „DOI oder Permalink"; jetzt: ordered list DOI > Permalink (Wayback) > Stabile URL > Plain URL.
  • doi_unavailable_reason als Pflicht-Feld bei Non-DOI-Sources dokumentiert (§2.3.1, verweist auf ADR-0002-Amendment 2026-05-09).
  • Source-Quality-Checkliste neu (§2.4, 5-Punkt-Liste: DOI-Resolve / Wayback-Snapshot / Content-Match / Tier / OA-Status).
  • Diversitäts-Regeln neu (§3.1, 3 Rules: D1 Disziplinen-Spread Soft, D2 Autoren-Spread Soft, D3 Wien-Anker Hard).
  • Reachability-Check Pflicht (§5.3, Hard-Gate via Pre-Commit gemäß SQ-05; Override nur via Sidecar content_match_override).
  • Cross-Referenzen ergänzt um ADR-0004, ADR-0005 und PRD-Amendment 2026-05-09-source-quality-hardening.
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md — Synthesis-Prompts bleiben unberührt; v1.2 betrifft nur den Source-Aufnahme-Workflow und Quality-Gates, nicht die Synthese-Wortzahl-Vorgaben oder den Synthesis-Prompt-Vertrag.
  • Finalize-Pass: in Phase A W4, nach Vorliegen der SQ-08-28-Broken-Triage-Daten (kann z.B. die DOI-Coverage-Realitäts-Korridor-Aussage in §2.4 schärfen).
• 2026-05-12 (Phase-1.5, F-31a): v1.3 — Reframe + 3 neue §§ (Methods/Confidence/Limitations). Abgeleitet aus PRD-Amendment docs/prd/2026-05-12-format-reframe-forschungs-brief.md (Pfad-β-Entscheidung End2End-Format-Audit 2026-05-12).
  • Begriffs-Reframe „Synthese" → „Forschungs-Brief" in allen customer-sichtbaren Stellen (§§1-10 plus neue §§11-13). Engineering-Code-Variablen (synthesis_word_count, parseSynthesisBody, syntheses/-Pfade, prompts/synthesis.v1.md) bleiben unverändert — dokumentierte Drift gemäß CLAUDE.md.
  • §11 PRISMA-ScR-Light neu — Pflicht-Felder pro Brief (databases, search_strings, date_range, last_run, inclusion/exclusion_criteria, records_screened/included). Quelle: PRISMA-ScR Extension Tricco et al. 2018, JBI Manual, Cochrane Rapid Reviews Garritty et al. 2024.
  • §12 IPCC-Calibrated-Language neu — Rubric (confidence × evidence × agreement) für mindestens 3 Key-Claims pro Brief mit Beispielen pro Achse. Quelle: IPCC AR6 Uncertainty Guidance (Mastrandrea et al. 2010), APCC AAR2 SPM-DE als nationale Präzedenz.
  • §13 Limitations-Boilerplate neu — 4 Standard-Bausteine (Single-Screener / Suchsprache DE-EN / Stand der Recherche / keine formale Critical Appraisal). Quelle: Cochrane Rapid Reviews Garritty et al. 2024.
  • Cross-Referenzen ergänzt um docs/prd/2026-05-12-format-reframe-forschungs-brief.md.
• v1.4 (2026-05-13, W2-D Deep #16) — §13 Reihenfolgen-Hinweis präzisiert: Audit-Trail-JSON ist inline in ## KI-Eignungs-Bewertung-Sektion, Limitations folgt danach am Body-Ende. Entscheidungsdokument: docs/decisions/2026-05-12-audit-trail-limitations-order.md (Reihenfolge A approved 2026-05-13).
• v1.5 (2026-05-13, W2-F Deep #17) — Drei additive Sektionen für die K3-Wave-2/3-Skalierung. Abgeleitet aus K3-Wave-2-Pre-Vet (_research/k3-wave-2-prevet-2026-05-13.md, WFK-3.1.1 K3-PASSIVE-Verdict + WFK-4.2.1 DPIA-WITH-CAVEATS) und Decision-Doc K3-Skalierung (docs/decisions/2026-05-12-k3-active-scaling.md).
  • §14 PASSIVE-Brief-Pattern neu — Muster für normativ-juristische und qualitativ-gestaltende Fragen (AI-Score low/none, D2 ≤ 1, KI-Rolle preparatory, mehrheitlich autoritative Quellen (Tier-1-Legal-Government, Tier-1-Institutional) + ≥1 K3-Critical-Gegenposition, Limitations-Boilerplate-Erweiterung Baustein 5, IPCC-Confidence-Mapping mit anderer Semantik). Vorbild: WFK-6.1.1; erster expliziter PASSIVE-Brief: WFK-3.1.1 (Wave 3-B; 4/9 = 44% Tier-1-Legal/Government — Pattern erfüllt per Worked-Example-Note).
  • §15 DPIA-Disclaimer-Pattern neu — Muster für Briefe mit personenbezogenen / personen-rekonstruierbaren Daten (DSGVO Art. 35 explizit, Re-Identifikations-Risiko-Floor de Montjoye et al. 2013, Privacy-by-Design k-anonymity ≥20 / Differential Privacy / synthetische Ersatzdaten, NGO-Critical-Voice als wissenschaftlicher Skeptizismus, Sample-Bias-Hierarchie Garber et al. 2022, drei zulässige Placement-Optionen). Sub-Variante: WFK-1.2.1a; erster expliziter DPIA-Brief: WFK-4.2.1 (Wave 3-A).
  • §16 Tier-1-Legal-Government Source-Acceptance neu — Erweiterung der Source-Whitelist (docs/source-catalog.md Tier-Strategy) um Tier-1-Legal: Gesetzestexte, EU-Verordnungen, amtliche Kommentare, Höchstgerichts-Urteile als authoritative Primärquelle für normative Fragen. Examples: EU-CPR-Recast 2024, AT-AWG 2002 §3, AT-ABGB §§922-933b, Wiener BO. Frontmatter-Type-Fallback type: standard bis Schema-Extension (F-Issue für legal-text to SourceTypeSchema enum, filed in Deep #17 W5 ISSUES-sync). Citation-Discipline: Article-/Paragraph-Nummer Pflicht im Wikilink-Anchor.
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md oder schemas/source.zod.ts. v1.5 ist rein doku-additiv; die Schema-Extension für legal-text ist explizit als Folge-Issue ausgelagert (Anti-PSA-Disziplin: erst zweiter realer Konsument rechtfertigt Enum-Erweiterung).
• v1.6 (2026-05-14, Deep #18 W5) — Eine additive Sektion für die K3-Wave-3-Roll-Out-Erkenntnisse. Abgeleitet aus den zwei erprobten PhD-Reviewer-Passes in Deep #18 W2-Inter-Gate (3 Briefe, 3× SHIP-WITH-TWEAKS) + W3-Inter-Gate (2 Briefe, 2× SHIP-WITH-TWEAKS inkl. 1 CRITICAL-Blocker vor W4 gefixt).
  • §17 PhD-Reviewer-Pass-Pattern neu — institutionalisierter Inter-Wave-Gate nach K3-Brief-Drafting-Waves. Trigger ≥1 K3-active Brief gedrafted, Panel ≥3 Disziplinen + Chair, 9 Review-Kriterien (Layer-3-Discipline), Output Markdown-Report mit Per-Reviewer Strong-Points + Weaknesses + Suggested-Edits + Verdict (SHIP/SHIP-WITH-TWEAKS/RESHAPE), Findings-Loop Severity-getaggt (Critical → coord-direct vor W4, High → W3-C, Medium → W4-Q, Low → F-Issue defer). Template prompts/phd-reviewer-pass.v1.md (versioniert per G5 AI-Prompt-Discipline). Layer-1-Bundle-B-Decision per feedback walkthrough-prevet-then-decision.
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md oder Schemas. v1.6 ist rein prozess-additiv (Inter-Wave-Gate-Spec); kein Refactor an existierenden §§1-16. prompts/phd-reviewer-pass.v1.md ist NEW prompt — Convention G5 (Modell-Pinning + Prompt-Version in rated_by Audit-Trail) gilt analog.
• v1.7 (2026-05-14, Deep #19 W2-T12) — Eine additive Sub-Sektion zur Resolution der F-100-Spec-Inkonsistenz Topic-Lead vs. direct-h2. Abgeleitet aus dem F-100-Audit (_research/k3-f100-topic-lead-audit-2026-05-14.md, 15/15 K3-active Briefe geprüft: 14 direct-h2 / 1 topic-lead WFK-8.1.1) und der Decision Option C in Deep #19 W1-Gate (docs/decisions/2026-05-14-topic-lead-spec.md, status decided).
  • §11.0 Topic-Lead-Konvention neu — Topic-Lead ist optional, brief-typ-abhängig; Default direct-h2. Erlaubt bei HYBRID-Briefen (Vorbild WFK-8.1.1), DPIA-Disclaimer-Briefen (§15) und Edge-Cases mit ungewöhnlicher Methodik-Asymmetrie. Wortlaut-Spec: 1–2 Sätze, ≤ 60 W, deklarativ, keine Wikilink-Citations, keine IPCC-Confidence-Tags, kein H2-Header. Zählt nicht als Sektion für die "6 H2-Sektionen"-Invariante; synthesis_word_count-Total = Topic-Lead-Wörter + 6-H2-Body-Wörter.
  • Brief-Alignment-Impact: Null. 14/15 Briefe (direct-h2) und WFK-8.1.1 (topic-lead, HYBRID-Pattern-konform) sind bereits compliant.
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md, prompts/phd-reviewer-pass.v1.md oder Schemas. v1.7 ist rein doku-additiv (Topic-Lead-Konvention). Cross-Ref _research/k3-goldstandard-verification-2026-05-14.md §Wave-3-Drafting-Specification §1 ("Pre-H2 Topic-Lead" als NON-NEGOTIABLE) wird auf §11.0-Optional-Spec geupdatet; PhD-Reviewer-Pass-Kriterium 6 (Section-Balance) verweist optional auf §11.0 für Topic-Lead-Check.
• v1.8 (2026-05-14, Housekeeping F-88) — F-88: §15 EU AI-Act Annex III bullet added. §15 DPIA-Disclaimer-Pattern um einen kompakten Pflicht-Bullet zur EU-AI-Act-Annex-III-Hochrisiko-Klassifikation erweitert (parallel zur DSGVO-Art.-35-DPIA, nicht alternativ). Pflicht-Checkpunkte: Annex-III-Screening (Punkt 1/2/5/8), Konformitätsbewertung vor Deployment (Art. 43), Fundamental-Rights-Impact-Assessment (Art. 27), Risikomanagement-System (Art. 9). Cross-Refs: Verordnung (EU) 2024/1689 (KI-Verordnung). Anwendung erprobt in WFK-4.2.1 / WFK-9.1.1 / WFK-7.1.1. Abgeleitet aus Deep #17 W4-B-Finding M-4 (DSGVO-Tiefe ohne parallelen AI-Act-Pfad).
• v1.8-update (2026-05-14, Deep #20 F-105) — §16 Stale-Fix: „type: standard Fallback"-Wording entfernt; canonical type: legal-text + Pflicht-legal_jurisdiction (Enum EU | AT-Bund | AT-Land-Wien | Höchstgericht) als Schema-Vertrag dokumentiert. Cross-Ref ADR-0002 Amendment A7 (F-82 Schema-Extension closed in Deep #20). Folge-Issue-Verweis aus v1.5 §16 obsolet — entfernt. Kein Major-Version-Bump (rein doku-erfüllend, kein neuer Pattern).
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md, prompts/phd-reviewer-pass.v1.md oder Schemas. v1.8 ist rein doku-additiv (ein Bullet in §15). Footer-String Methodik v1.7 in apps/dashboard/app/layout.tsx:50 ist out-of-scope dieser Housekeeping-Task (File-Lock auf docs/methodology.md) und bleibt als Follow-up offen — Bump auf v1.8 erfolgt in nächster Dashboard-Session.
• v1.9 (2026-05-15, F-121) — Drei additive Sektionen aus dem Quellen-Integritäts-Audit. Abgeleitet aus dem Vollkorpus-Audit (audit_method_version 2, gesamter Korpus geprüft) + docs/runbook/source-audit.md (8-Step-Protokoll) + ADR-0006 (Source-Integrity-Policy). Die internen Audit-Roh-Befunde werden im nicht-öffentlichen Runbook geführt.
  • §18 Source-Integrity-Audit (post-F-121) neu — Anlass, Methode (Verweis auf Runbook-Vollspec), Ergebnis/Konsequenz (Quarantäne nicht-bestätigbarer Quellen, ausgelieferte Briefe zitieren ausschließlich triangulierte Quellen), stehendes Auslieferungs-Gate + Provenance-Pflicht.
  • §19 Source-Provenance-Pflicht (going-forward policy) neu — Drei Provenance-Optionen pro neuer Source: (a) DOI-Crossref-Match (Title+Author exact-match), (b) Wayback-Snapshot ≥ 1 Jahr vor retrieved, (c) Institutional-Registry-Eintrag (WHO/IPCC/IEA/EEA/OECD/Statistik Austria/Stadt Wien Open Data/RIS/EUR-Lex). Enforcement-Pfad: ADR-0006 + scripts/audit-source.ts CI-Pre-Add-Gate (F-121-Sub-MethodV2). verified_by-Audit-Trail-Format spezifiziert. Tier-1-Legal-Government-Sonderfall (Option (c) per Definition via Registry-Permalink, legal_jurisdiction bleibt Pflicht).
  • §20 Verifikations-Subtypen (5 Patterns) neu — Diagnostisches Vokabular für Audit-Berichte + automatisierte Verifikations-Läufe: §20.1 Real-Institution-Fake-Title, §20.2 DOI-Resolves-To-Wrong-Paper, §20.3 Real-Paper-Fake-Authors, §20.4 Real-Paper-Paraphrased-Title, §20.5 Wrong-DOI-Assignment. Subtypen nicht-exklusiv; dominanter Subtyp im evidence-String + Tracking-Sheet-notes-Spalte.
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md, prompts/phd-reviewer-pass.v1.md. ADR-0006 hängt mit §19 verbindlich zusammen (Schema-Refinement: schemas/source.zod.ts ggf. um verified_by-Feld in W4-A — out-of-scope dieses Files). Footer-String Methodik v1.7 in apps/dashboard/app/layout.tsx:50 bleibt weiterhin out-of-scope (Drift-Sentinel-Test wäre Follow-up).
• v1.10 (2026-05-15, Deep #24, Forschende-Mapping-Initiative #222) — Add §21 Forschende-Discovery-Methodology (Wiener Researchers via OpenAlex). Eine additive Sektion mit 8 Subsektionen (Ziel · Pipeline-Schritte · Wien-Institutions-Definition · Provenance-Pflicht · Admin-Review-Gate · Feedback-Loop · Risks · Cross-Refs). Abgeleitet aus PRD docs/prd/2026-05-15-forschende-mapping.md und Recon-Briefing _research/openalex-recon-2026-05-15.md (~25 min Spike, 13 ROR-Lookups, 3 Pilot-WFK-Topic-Discoveries, Rate-Limit-Verifikation). Provenance-Disziplin (§21.4) ist die ADR-0006-Übertragung auf Researcher-Records; Admin-Review-Gate (§21.5) ist die strukturelle F-121-Lehre für customer-sichtbare Auto-Discovery-Outputs. Footer-String Methodik v1.9 in apps/dashboard/app/layout.tsx:50 wird synchron auf v1.10 gebumpt (F-106/F-107 Drift-Pattern, jetzt in-task gefixt statt deferred). Cross-Refs: ADR-0007 (NEU, Auth-Gate), docs/runbook/forschende-discovery.md (W2-E Runbook), data/wien-institutions.yaml (Registry).
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md, prompts/phd-reviewer-pass.v1.md. NEW prompts prompts/forschende-translate.v1.md und prompts/forschende-rerank.v1.md folgen Convention G5 (Modell-Pinning + Prompt-Version in Audit-Trail) analog. Schema-Refinement (schemas/researcher.zod.ts, schemas/question.zod.ts-Extension um wiener_researchers) erfolgt in der Foundation-Wave separat — out-of-scope dieses Files.
• v1.11 (2026-05-15, Deep #25) — Add §22 Für Themenpat:innen — Navigations-Abschnitt mit Cluster-Direkt-Links für Magistrats-Abteilungen und Wien-Energie-Mitarbeitende (AC-7, Issue #226). Rein doku-additiv, keine Schema- oder Prompt-Drift.
• v1.12 (2026-05-15, Deep #28, Issue #196) — §19.3 verified_by als strukturiertes Objekt schema-enforced (method + evidence + checked_at statt flat-string aus v1.9). Drei Provenance-Optionen (a/b/c) unverändert, nur ihre Repräsentation ist jetzt schema-seitig erzwungen via schemas/source.zod.ts. Drift-Annotation: ADR-0006 wurde entsprechend amendiert; existierende Sources werden im Migration-Lauf von audit-source.ts automatisch in das strukturierte Format überführt.
• v1.13 (2026-05-16, /test-Audit Customer-UX-Sweep) — Reframe ohne neue Methodik-Sektion: TLDR-Kurz-Methodik-Box am Anfang des Dokuments (vor §1) eingefügt, Versionierungs-Übersichts-Block aus dem Header an das §Changelog am Ende konsolidiert (war redundant). Keine inhaltliche §§-Änderung, kein neuer Pattern. Hintergrund: End-zu-End-UX-Audit hat den Engineering-Changelog-am-Anfang als customer-facing Friction-Punkt identifiziert (Wall-of-Text, keine Einstiegshilfe für Außenstehende). Parallele UI-Änderungen: veralteter Audit-Status-Banner aus Landing + Methodology-Page entfernt (faktisch überholte Snapshot-Zahlen), Brief-Detail bekommt SectionCard-Pattern + At-a-Glance-Header + Wikilink-Tier-Pills statt Source-Type-Badges, Quelldatei-GitLab-Link entfernt (Customer hat keinen Repo-Access), ResearchersCollapsible bekommt OpenAlex-Topic-Suche-Footer-Link für Customer-Erweiterungspfad jenseits der Top-3. Drift-Annotation: Keine erwartete Drift mit prompts/* oder Schemas. Footer-String Methodik v1.12 in apps/dashboard/app/layout.tsx wird synchron auf v1.13 gebumpt.
• v1.14 (2026-05-16, Deep #29 Wave 2 IC-4) — §21.9 PhD-Coordinator-Pattern (Anthropic-API-Bypass) neu. Dokumentiert den in Deep #28 empirisch erprobten alternativen Ausführungspfad für Forschende-Discovery, bei dem ein Claude Code Coordinator (Opus 4.7 / Sonnet) die LLM-Translate- (§21.2 Step 1) und LLM-Re-Rank-Subschritte (Step 6) ohne separaten Anthropic-API-Key durch Subagent-Calls ersetzt. Kernelemente: Motivation + Break-Even-Faustformel (≤ 50 WFK Coordinator, > 50 WFK API-Pfad), Architektur-Übersicht (5 Schritte, Parallelisierungs-Pattern 3 Subagents × 5 WFK = ~30 min Pilot), Editor≠Verifier-Pass (§21.9.3, 5-Punkt-Checklist, phd-curator-verified_by-Suffix), Provenance-Sidecar-Schema (_research/forschende-pilot-smoke-2026-05-15-sidecars/<WFK-id>.json), Cost-Comparison-Tabelle (API-Pfad ~$0.82 / 204 WFK vs. 0 Kosten Pilot-Set), Cross-Refs §17/§18/§21.2/§21.4/§21.5/ADR-0006. Drift-Annotation: Keine erwartete Drift mit prompts/* oder Schemas. Footer-String Methodik v1.13 in apps/dashboard/app/layout.tsx bleibt out-of-scope dieses Wave-Agents — Bump auf v1.14 erfolgt in W5-F2 (SSOT-Sync).
• v2.0 (2026-05-17, R-Block Wave 5 R-20) — Add §22 Multi-Reviewer-Peer-Review-Layer neu. Dokumentiert die menschliche Peer-Review-Schicht als Komplementum zum §17 PhD-Reviewer-Pass (LLM-Layer pre-draft). 10 Subsektionen (Übersicht · Abgrenzung zu §17 · Quorum-Engine · Customer-Signal · Reviewer-Pool · Open-Review-Bias · Audit-Trail · Konsequenzen · Risks · Cross-Refs). Quellen: ADR-0008 (SQLite-Workflow-Layer), PRD 2026-05-17-reviewer-workflow.md (vollständige R-Block-Spezifikation), Runbooks R-17/R-18 (geplant). Major-Version-Bump (1.14 → 2.0) rechtfertigt sich durch methodische Upgrade: Phase 1 (Single-Editor + Auto-LLM-Pass) → Phase 1.5 (Multi-Reviewer-Workflow aktiviert). Customer-facing Signal „Peer-reviewed by 3 Wiener Forschende" ist explizit neue Qualitäts-Claim. Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md, prompts/phd-reviewer-pass.v1.md oder Schemas. Footer-String Methodik v1.14 in apps/dashboard/app/layout.tsx:60 wird synchron auf v2.0 gebumpt (F-107 Drift-Sentinel-Test).