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. 320–600 Wörter ü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 (abgestimmt mit prompts/synthesis.v1.md 80–150 Wörter), 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 bleibt die Brief-Gesamt-Wortzahl 320–600 (interne Code-Variable: synthesis_word_count).

• [ ] 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-Use-Cases ≥1 konkret, mit Wien-Kontext (z.B. „Mikroklima-Modellierung MA 22-Geodaten")
• [ ] Brief-Gesamt-Wortzahl 320–600 Wörter (HART, laut prompts/synthesis.v1.md; intern: synthesis_word_count)

Quelle: Pivot-PRD §5.2. Detail-Rubric für KI-Score: docs/ai-suitability-rubric.md.

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-600 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 Inter-Wave-Gate (v1.6, Deep #18 Institutionalisierung)

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-600W, Sektionen-Caps (Stand ≤200W, 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 (Deep #18, erste 2 Anwendungen)

• v1 (Deep #18 W2-Inter-Gate): 3 W2-Briefe reviewt (WFK-5.1.1, WFK-6.3.1, WFK-9.1.1) — 3 Verdikte (SHIP-WITH-TWEAKS), Findings adressiert in coord-direct + W3-C Polish-Iteration. Panel: Hydrologie + Stadtklima + Labour-Econ + Chair.
• v2 (Deep #18 W3-Inter-Gate): 2 W3-Briefe reviewt (WFK-7.1.1, WFK-8.1.1) — 2 Verdikte (SHIP-WITH-TWEAKS, davon 1 CRITICAL-Blocker: linked_sources-Schema-Drift auf WFK-8.1.1). CRITICAL-Finding sofort vor W4 gefixt. Panel: Sozial-Klima + Climate-Communication + Chair.

Quelle: Layer-1-Bundle-B-Decision Deep #18 (feedback walkthrough-prevet-then-decision); HANDOFF.md 2026-05-14 Deep #18 W2/W3-Inter-Gate-Notes; prompts/phd-reviewer-pass.v1.md Template.

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

Status: verbindlich ab 2026-05-15 (Deep #22, F-121). Methode-Spec: docs/runbook/source-audit.md (Master-Runbook für retrospektive Audits). Evidence-Pointer: .orchestrator/notes/w3-audit-master.json (audit_method_version: 2, alle 137 Korpus-Quellen mit Per-Source-Verdict + Signals + Evidence-String).

18.1 Auslöser

In Deep #22 W1-C (Stichproben-Sichtung des K3-Korpus durch Bernhard) fielen 5 Quellen mit plausiblem Titel + plausiblen Autoren + nicht-auflösbaren DOIs / 404-URLs / 0 Wayback-Snapshots auf — klassische Halluzinations-Signaturen. Hypothese: parallele Synthese-Agents in den K3-Roll-Out-Wellen (Deep #16/#17/#18) hatten gelegentlich Frontmatter generiert, ohne dass die zugrundeliegende Publikation real existiert. Auslöser für den Vollkorpus-Audit: Customer-Send #151 war kurz vor Versand — fabricated citations in einem Customer-Brief sind Pilot-Killer.

18.2 Methode (Kurzform — Vollspec im Runbook)

Pro Source läuft ein 8-Step-Protokoll (docs/runbook/source-audit.md §2). Signale werden zu einem Verdict aggregiert:

| Verdict | Definition | |---|---| | REAL | DOI-PASS ODER (URL-PASS + (TITLE-PASS ODER WAYBACK-PASS)) ODER (WAYBACK-PASS pre-retrieved + TITLE-PASS) ODER Tier-1-Behörde + URL/WAYBACK-PASS | | LIKELY-HALLUCINATED | DOI-FAIL + TITLE-FAIL ODER TITLE-FAIL + AUTHOR-FAIL + WAYBACK-NONE ODER DOI-MISMATCH + URL-MISMATCH ODER DOI-absent + URL-FAIL + WAYBACK-NONE + TITLE-FAIL | | AMBIGUOUS | Alles dazwischen — manual_review Pflicht |

Die Verdict-Rubrik ist konservativ (vgl. Anti-Pattern „LIKELY-HALLUCINATED bei niedrig-Konfidenz-Signal" in docs/runbook/source-audit.md).

18.3 Ergebnis (Deep #22, 137 Sources auditiert)

| Verdict | Count | Anteil | |---|---:|---:| | REAL | 85 | 62.0 % | | LIKELY-HALLUCINATED | 34 | 24.8 % | | AMBIGUOUS | 18 | 13.1 % |

Quelle: .orchestrator/notes/w3-audit-master.json §verdict_summary. Affected Briefs (14/15): WFK-1.1.1 / 1.2.1a / 2.1.4 / 2.1.5 / 2.2.1 / 3.1.1 / 4.1.2 / 4.2.1 / 5.1.1 / 6.1.1 / 6.3.1 / 7.1.1 / 8.1.1 / 9.1.1.

18.4 Konsequenzen

1. Customer-Send #151 bleibt blocked bis alle LIKELY-HALLUCINATED-Quellen quarantäniert + alle betroffenen Briefe remediated sind (Workflow: docs/runbook/source-audit.md §6).
2. Provenance-Pflicht going-forward (§19) wird zum Hard-Gate für jede neue Source-Aufnahme.
3. 5 Hallucinations-Subtypen (§20) sind das diagnostische Vokabular für künftige Audit-Reports + Verifier-Agent-Outputs.
4. Re-Research-Campaign für die LIKELY-HALLUCINATED-Kohorte ist eine Multi-Session-Arbeit (siehe F-121-Sub-Issues in docs/prd/ISSUES.md).

Cross-Refs: ADR-0006 (Source-Integrity-Policy), docs/decisions/2026-05-15-source-hallucination-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-Reports + Verifier-Agent-Outputs. Quelle der Subtypen: empirische Auswertung der 34 LIKELY-HALLUCINATED-Befunde aus dem Deep-#22-Audit (.orchestrator/notes/w3-audit-master.json).

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: F-121 hat empirisch gezeigt, dass auto-generierte Daten ohne expliziten Provenance-Trail nicht customer-trust-fähig sind (137 Sources → 34 LIKELY-HALLUCINATED, §18). Researcher-Records sind ähnlich exponiert: Customer 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 F-121): Im Deep-#22-Source-Audit wurden 34 / 137 Sources (~24,8 %) als LIKELY-HALLUCINATED klassifiziert — das war die Folge davon, dass die Originale ohne expliziten Verifikations-Gate ins Korpus gewandert sind. §17 PhD-Reviewer-Pass und §18 Audit-Method-v2 sind die strukturellen Antworten für Briefe und Quellen; §21.5 ist das Äquivalent für Researcher-Records: ein Mensch entscheidet, was customer-sichtbar wird. Cross-Refs: §17 (PhD-Reviewer-Pass-Pattern für K3-Brief-Drafting-Waves), §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, Deep #22 W4-E, F-121) — Drei additive Sektionen aus dem F-121-Source-Hallucination-Audit. Abgeleitet aus .orchestrator/notes/w3-audit-master.json (audit_method_version 2, 137/137 Sources, 34 LIKELY-HALLUCINATED / 18 AMBIGUOUS / 85 REAL = 24.8 % / 13.1 % / 62.0 %) + docs/runbook/source-audit.md (8-Step-Protokoll) + ADR-0006 (Source-Integrity-Policy).
  • §18 Source-Integrity-Audit (post-F-121) neu — Auslöser (W1-C-Stichprobe), Methode (Verweis auf Runbook-Vollspec), Ergebnis-Tabelle (Verdict-Counts + Anteile + Affected-Briefs), Konsequenzen (#151-Block, Provenance-Pflicht, Subtypen-Vokabular, Re-Research-Campaign).
  • §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 + (geplant) 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 Hallucinations-Subtypen (5 Patterns aus method-v1) neu — Diagnostisches Vokabular für Audit-Reports + Verifier-Agent-Outputs: §20.1 Real-Institution-Fake-Title (Beispiel 2024-un-habitat-climate-justice-cities WFK-7.1.1), §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: F-121-Banner aus Landing + Methodology-Page entfernt (faktisch veraltete Snapshot-Zahlen 85/34/18 aus Deep #22), 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).