Dieses Projekt mapped 204 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 (aktuelle Frontmatter-Pin: claude-opus-4-8@prompts/synthesis.v2.md), Single-Editor-Workflow — kein Reviewer-Team, kein anonymer Peer-Review-Pool.
• Wie Quellen gefunden werden. Strikte Suchreihenfolge Wien zuerst → Österreich → EU → Global; pro Brief mindestens 3 Quellen, ≥1 Wien-Anker pro Cluster, ≥1 Quelle ≤3 Jahre alt, peer-reviewed oder institutionell (siehe §2).
• Wie Quellen verifiziert werden. Identifier-Hierarchie DOI → Permalink → institutionelles Registry; Crossref-Triangulation auf Titel und Erst-Autor:in; Wayback-Snapshot-Fallback bei Link-Risiko (siehe §19).
• Wie KI-Eignung bewertet wird. Vier Dimensionen — Datenverfügbarkeit, Aufgabentyp, Methoden-Reife, Ethik & Recht — werden mit 0/1/2/3 Punkten bewertet. Summe ergibt einen Score none / low / medium / high (siehe §12; volle Rubric: docs/ai-suitability-rubric.md).
• Wie Konfidenz markiert wird. Jeder Key-Claim trägt IPCC-Calibrated-Language-Tags (low/medium/high confidence, limited/medium/robust evidence, low/medium/high agreement).
• Was Sie pro Brief sehen. Ein kompakter Brief (~400 Wörter, Rahmen 320–700) über vier Sektionen (Stand · Lücken · Trends · KI-Eignung), jede Aussage an Quelle gebunden, KI-Eignung mit transparenter D1-D4-Aufschlüsselung, Liste der Top-3 Wiener Forschenden zum Thema (via OpenAlex-Mapping, LLM-gestützt kuratiert; Expert:innen-Stichprobenprüfung steht aus, siehe §21.11).
• Woher die Anstellungsangabe der Forschenden kommt. Wo eine ORCID hinterlegt ist, gleichen wir die Anstellung gegen das ORCID-Register ab und schreiben Herkunft und Stand sichtbar dazu — „ORCID-Eintrag (Selbstauskunft): Anstellung ‹Organisation› · Registry-Stand ‹MM.YYYY› · abgerufen ‹TT.MM.YYYY›". Das ist die Selbstauskunft der Person, keine Prüfung durch uns oder durch die Einrichtung: 668 der 746 abgerufenen Anstellungs-Einträge hat die Person selbst gesetzt, und 45 % der laufenden Einträge wurden zuletzt vor 2023 geändert (siehe §21.11).
• Was menschlich geprüft ist. Bei den Forschenden-Zuordnungen: nichts — 0 von 177 gelisteten Personen tragen ein dokumentiertes menschliches Urteil (Stand 13.08.2026). Die Werkzeuge dafür stehen bereit (Reviewer-Rolle, Urteils-Feld, Stichproben-Report), die Durchführung steht aus (§21.11, Issue #336).
• Woher die Förderprojekt-Daten kommen. Ergänzend zum Literatur-Korpus zeigen die Themengebiete öffentlich geförderte Projekte aus drei amtlichen Registern: FFG-Projektdatenbank (307 Records), EU-Register CORDIS (4.124 Records, HORIZON/H2020/FP7) und FWF Open API (51 Records, davon 29 mit Themengebiet und damit sichtbar). Zugeordnet wird auf Themengebiets-Ebene, nie auf einzelne Fragen; jede Zeile trägt einen Registry-Deep-Link. FFG und CORDIS sind personenfrei; FWF ist die dokumentierte Ausnahme — dort wird Name und ORCID der Projektleitung übernommen, Kontaktdaten nie (siehe §24, Begründung in §24.6).
• Was wir bewusst nicht behaupten. Keine Meta-Analyse, keine systematische Review nach PRISMA, keine ROBINS-I/GRADE-Qualitätsbewertung pro Quelle — siehe §13 Limitations.

Aktueller Status (20.07.2026). Das öffentliche Korpus umfasst 204 Forschungs-Briefe im Single-Editor-Workflow. §22 bleibt als Workflow-Spezifikation erhalten; die darin beschriebene externe Review-Schicht ist aktuell nicht als Validierung des öffentlichen Korpus aktiv. Kein öffentlicher Forschungs-Brief darf derzeit den Anspruch „Peer-reviewed by 3 Wiener Forschende“ oder eine gleichbedeutende externe Peer-Review-Aussage tragen.

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

Recherche-Methodologie — Manual-First-Workflow

Dieses Dokument beschreibt den Recherche- und Brief-Workflow 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 das gesamte Korpus 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.

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

Historischer Pilot-Umfang (2026-05-09): 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). Dieser historische Umfang ist nicht der aktuelle Korpusstand; das Korpus umfasst heute 204 Fragen.

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 historische Sequenz war 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.

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.

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 galt für die historische Pilot-Phase. Sie war absichtlich straff, um zu verhindern, dass einzelne Fragen disproportionale Tiefe erhalten und damit den damaligen 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.

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.

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

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

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

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

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-8@prompts/synthesis.v2.md (aktuelle Frontmatter-Pin; bei historischen Briefen gilt 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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

• 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 historische Goldstandard-Briefe (WFK-2.1.5 / 1.4.1 / 6.1.1) und 14/15 historische 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).

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).

Struktur-Gate (#273, seit 2026-06-25). Die Pflicht-Sektionen ## Methodische Grundlagen (§11) und ## Methodische Einschränkungen (§13) sowie ≥1 badge-fähiger IPCC-Confidence-Tag (§12) werden ab sofort maschinell erzwungen: pnpm validate (Check 9 synthesis-sections, scripts/validate/synthesis-sections.ts) failt jeden Brief mit status ∈ {drafted, reviewed, published}, dem eines der drei Elemente fehlt. Der IPCC-Parser des Gates spiegelt renderer-treu den Dashboard-Badge (apps/dashboard/lib/markdown/render.tsx) — ein Tag im falschen Format zählt nicht. Hintergrund: der Bake-off 2026-06-22 zeigte, dass frische Briefe den Gold-Vergleich rein auf FORMAT (fehlende §11/§13/IPCC) verloren; das Gate macht dieses Vergessen strukturell unmöglich.

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 .

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.

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-8 als KI-Assistenz; aktuelle Frontmatter-Pin: claude-opus-4-8@prompts/synthesis.v2.md). 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 waren wortgleich über die 15 historischen 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 auf größere Korpora skalierbar, ohne Wortlaut-Drift. Quelle: Cochrane Rapid Reviews Garritty et al. 2024 (PubMed 38320771); analoge Praxis in WHO-Rapid-Evidence-Briefs.

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.

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 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).

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

17.1 Trigger

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

17.2 Panel-Zusammensetzung (≥3 Disziplinen)

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

17.3 Review-Kriterien (Layer-3-Discipline)

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

17.4 Output

Markdown-Report mit folgender Struktur pro Brief:

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

17.5 Template

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

17.6 Findings-Loop

Findings werden gemäß Severity verteilt:

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

17.7 Effektivität-Metriken (institutionalisiert tracked)

Pro Pass dokumentiert in HANDOFF.md Wave-Summary:

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

17.8 Historie (erste 2 Anwendungen)

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

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

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

18.1 Anlass und Zielsetzung

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

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

18.2 Methode (Kurzform — Vollspec im Runbook)

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

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

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

18.3 Ergebnis und Konsequenz

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

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

18.4 Konsequenzen (going-forward)

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

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

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.

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

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

20.1 Real-Institution-Fake-Title

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

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

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

20.2 DOI-Resolves-To-Wrong-Paper

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

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

20.3 Real-Paper-Fake-Authors

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

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

20.4 Real-Paper-Paraphrased-Title

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

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

20.5 Wrong-DOI-Assignment

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

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

20.6 Anwendung im Audit-Report

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

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).

Ist-Stand (2026-08-13): Das Admin-Review-Gate (§21.5) ist als Spezifikation definiert und das Review-Tooling existiert (Admin-Edit-UI unter /admin/researchers, Reviewer-Rolle, dokumentiertes Urteil je Person, Stichproben-Report scripts/report-researcher-review.ts); ein verpflichtendes Gate vor Customer-Sichtbarkeit ist weiterhin nicht implementiert. Gemessen am 13.08.2026: von 456 publizierten Einträgen (177 distinct Personen) sind 0 menschlich verifiziert, 278 (61,0 %) tragen ein maschinelles Verifikations-Label und 178 (39,0 %) gar keines; dokumentierte menschliche Urteile: 0 von 177 Personen. Publizierte Einträge sind damit automatisiert ermittelt und LLM-kuratiert; die Expert:innen-Stichprobenprüfung steht aus (Issue #336).

Ergebnis-Felder: openalex_id, display_name, institution, optional orcid / public_profile_url + Provenance-Felder. orcid ist seit 2026-08-13 kein reines Ergebnis-Feld mehr: Wo eine ORCID vorliegt, wird die Anstellungsangabe gegen das ORCID-Register abgeglichen und mit Herkunft, Registry-Stand und Abrufdatum ausgewiesen — als Selbstauskunft der Person, nicht als Prüfung durch uns (Verfahren, Zahlen und Grenzen: §21.11). Customer-Render: Detail-Page-Block „Wiener Forschende", Card-Badge, Brief-Body-Sektion, PDF- und CSV-Export.

21.2 Pipeline-Schritte (6 enforced steps)

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

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

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

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

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

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

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

21.3 Wien-Institutions-Definition

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

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

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

21.4 Provenance-Pflicht (analog ADR-0006)

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

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

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

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

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

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

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

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

21.5 Admin-Review-Gate

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

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

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

21.6 Feedback-Loop

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

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

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

21.7 Risks

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

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

21.8 Cross-Refs

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

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

Historischer Pilotstatus (2026-05-16, Deep #28): 45 Wiener Forschende (3 pro WFK, 15 Pilot-Fragen) wurden zero-cost via Coordinator-Subagents persistiert und verifiziert. Pattern war 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). Im historischen Pilotpfad für kleinere Runs (≤ ~50 WFK) erledigte ein Claude Code Coordinator (Opus 4.7 oder Sonnet, innerhalb einer laufenden Deep-Session) diese beiden LLM-Subschritte als Subagent-Calls direkt — 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.

21.10 Geo-Diversität der Forschenden (opt-in GEO_DIVERSITY_V1, #279)

Status: Flag-gated opt-in (Default OFF), customer-gated bis zur Recall-Regressions-A/B. Eingeführt 2026-06-19 (#279).

Der Standard-Discovery-Pfad fordert eine aktuelle Wien-ROR-Affiliation (Frische-Filter §21.2 Step 5) — der Forschenden-Pool ist damit by-design 100 % Wien, und die Geo-Buckets at / eu / global bleiben strukturell leer. Die optionale Geo-Diversitäts-Fähigkeit (GEO_DIVERSITY_V1=1) lockert ausschließlich diesen Gate-3-Schritt: statt nur aktuell-Wien-affiliierter werden jemals-Wien-affiliierte, inzwischen im Ausland tätige Forschende gesourct (über die unveränderte deriveGeoBucket-Logik, die bei fehlender aktueller Wien-Affiliation automatisch at / eu / global liefert). Diese Forschenden werden mit ihrer aktuellen Nicht-Wien-Institution + Land dargestellt. Die Geo-Kandidat:innen laufen über den echten LLM-Rerank (RETRIEVAL_V2-Topic-Grounding) — daher die harte Abhängigkeit GEO_DIVERSITY_V1 ⇒ RETRIEVAL_V2=1; ohne echtes Rerank-Signal kollabierte das Ranking auf Zitationen × Recency = Senior-Generalisten-Bias (Lehre aus #264). Default OFF ist byte-identisch zur Baseline.

Recall-Regressions-Gate (Pflicht vor Default-Flip): Die Lockerung darf den Recall nicht verschlechtern. Validiert über eine LIVE-A/B (Set bakeoff-set-30, EU-gemma $0): final-recall darf nicht fallen (B ≥ A), pool-recall innerhalb von 2 pp; zusätzlich Geo-Fill-Erfolg ≥ 60 % der Fragen mit ≥ 1 at|eu|global-Eintrag und Median Nicht-Wien/Frage ≥ 1. Hält der Recall nicht, bleibt das Flag aus und das Ergebnis wird in #279 dokumentiert. Konsument der Geo-Buckets ist die bestehende DETAIL_UX_V2-Geo-UI (#271/#274, vier Buckets bereits gerendert) — kein UI-Change nötig. Seam-Begründung + Anti-PSA: ADR-0003-Amendment (2026-06-19). Operative Lauf-Anleitung: docs/runbook/forschende-full-run.md §5.7.

#279-Fix (deep-2 2026-06-20): Ein Defekt in scripts/discover-researchers.ts leerte final[] (kuratierten Top-3-Block) wenn GEO_DIVERSITY_V1=1 aktiv war: ever-Wien-abroad-Kandidat:innen füllten den Rerank-Shortlist vollständig, ohne dass aktuelle Wien-Forschende im Kandidaten-Pool verblieben, was zu ranked: [] ohne Fallback führte. Fix (pool-decoupling): Kurationspfad (applyFrischeFilter, aktuell-Wien) und Geo-Anreicherungspfad (applyEverWienFilter, ever-Wien) werden getrennt ausgeführt und erst danach zusammengeführt — ever-Wien-abroad-Kandidat:innen füllen Geo-Buckets, verdrängen aber nie mehr aktuelle Wien-Forschende aus dem Rerank-Pool. Flag-gated; GEO_DIVERSITY_V1=0-Baseline bleibt byte-identisch. Recall-Regressions-A/B (W3, bakeoff-set-30, EU gemma $0) PASSED: final-recall 5,1 % == Baseline ✅, geo-fill 96,7 % ✅, Wien-Forscher 975 == 975 ✅ — der final[]-Flip-Blocker aus deep-2 (2026-06-19) ist damit behoben.

Neuer Default-Flip-Blocker (#269, deep-2 2026-06-20): Die A/B offenbarte, dass works_count in der Geo-Bucket-Aggregation global misst (nicht Wien-spezifisch). Senior-Generalisten mit breitem Publikationsvolumen dominieren at/eu/global-Leaderboards — dieselbe #264-Klasse, nur im Geo-Bucket. Default bleibt OFF bis #269 (Wien-Topic-gewichteter Score in Geo-Buckets) gelöst und ein erneuter bakeoff-30 passiert. Kein Default-Flip vor #269-Behebung.

#269-Fix (2026-06-21 deep-1): Das works_count-Rauschen in den Geo-Buckets wird durch eine zweigliedrige Topic-Rerank-Schicht in buildEnrichedResearchers (scripts/discover-researchers.ts) behoben, gated hinter GEO_DIVERSITY_V1=1 (Baseline byte-identisch):

1. Binärer Floor (topicGroundedIds) — Autoren, deren OpenAlex-Kurz-ID in der topic-geerdeten Kandidatenmenge liegt (aus dem RETRIEVAL_V2-Grounding-Pfad), erhalten den Signal-Flag has_topic_signal=true. Autoren ohne Topic-Erdung werden aus nicht-Wien-Buckets herausgefiltert, wenn der Bucket noch kein GEO_TOPIC_FLOOR_MIN_RELEVANT (Konstante 1) topic-geerdetes Mitglied aufweist.
2. Gradiertes bge-Relevanz-Signal (RERANKER_V2) — Ist zusätzlich RERANKER_V2=1 aktiv, liefert das neue Modul scripts/lib/reranker-prefilter.ts einen Cross-Encoder-Score vom EU-Endpoint (bge-reranker-v2-m3, Cohere-style /rerank, EU_LLM_*). Autoren, die den bge-Prefilter überleben, erhalten topicRelevance = TOPIC_GROUNDED_FLOOR_RELEVANCE (Konstante 0.66) statt neutral 0,5 — unterhalb des Wien-Rerank-Bands, aber klar über dem ungeerdeten Generalisten-Score.

Autoren, die weder topic-geerdet noch bge-Survivor sind, bleiben im Pool nur wenn ihr Bucket ≥ GEO_TOPIC_FLOOR_MIN_RELEVANT topic-Anker enthält — andernfalls werden sie als Generalisten-Noise herausgefiltert. Default (GEO_DIVERSITY_V1=0) bleibt byte-identisch. Recall-Regressions-A/B-Gate (bakeoff-set-30, EU gemma $0) PASSED (2026-06-21 deep-1): geo-fill 100 % (4/4 Fragen), final-recall 5,1 % == Baseline ✅, pool-recall 23,1 % == Baseline ✅, 0 Crashes. GEO_DIVERSITY_V1-Default-Flip ist damit kein quality-Blocker mehr — bleibt #224-gated (via RETRIEVAL_V2 hard-dep). Runbook: docs/runbook/source-enrichment-regen.md §5.5 (GEO-on Regen, transient-empty-Guard, Cross-Ref zu #269 + bge-Prefilter-Modul).

21.11 ORCID-Registry-Abgleich der Anstellungsangaben (#335)

Status: Produktiv seit 2026-08-13. Datenbasis: 144 Sidecars data/orcid-employments/<wfk-id>.json mit 363 Personen-Zeilen (168 distinct Personen) und 746 Anstellungs-Einträgen, abgerufen über die öffentliche ORCID-API v3.0 (/employments, Pipeline-Pin fetch-orcid-employments@orcid-pub-v3.0). Schema-Vertrag: schemas/orcid-employments.zod.ts.

Anlass. Bis dahin stand die ORCID-Nummer unter dem Namen der Person, ohne dass an ihr irgendetwas geprüft war — eine Kennung direkt neben einer Institution liest sich wie ein Beleg für diese Institution. §21.11 schließt genau diese Lücke: Wir holen die Anstellungen, die die Person in ihrem eigenen ORCID-Record führt, und schreiben Herkunft und Stand sichtbar dazu.

Was angezeigt wird — wörtlich gleich im Forschungs-Brief, im Themen-Leaderboard und im PDF-Export:

ORCID-Eintrag (Selbstauskunft): Anstellung ‹Organisation› · Registry-Stand ‹MM.YYYY› · abgerufen ‹TT.MM.YYYY›

Bewusst nicht formuliert wird „Affiliation bestätigt am ‹Datum›". Das wäre in zwei Punkten falsch: Bestätigt hat die Angabe niemand — sie ist eine Selbstauskunft der Person, keine Prüfung durch uns oder durch die genannte Einrichtung. Und unser Abrufdatum sagt nichts über das Alter der Angabe aus, sondern nur darüber, wann wir sie gelesen haben. Deshalb stehen zwei getrennte Daten in der Zeile: der Registry-Stand (wann die Person ihren Eintrag zuletzt geändert hat, monatsgenau — ein Tagesdatum suggerierte eine Präzision, die die Quelle nicht hat) und das Abrufdatum.

Vier unterscheidbare Abruf-Zustände (363 Personen-Zeilen, Stand 13.08.2026):

| Zustand | n | Was die Anzeige sagt | |---|---|---| | ok | 287 | Anstellung(en) mit Organisation, Registry-Stand und Abrufdatum | | no-employments | 46 | „ORCID-Registry abgefragt am ‹Datum› — keine Anstellung hinterlegt" | | not-checked | 30 | „ORCID-Registry nicht abgefragt — Anstellung ungeprüft" | | error | 0 | „Abruf fehlgeschlagen — Anstellung ungeprüft" |

„Abgefragt, nichts hinterlegt" ist ausdrücklich nicht dasselbe wie „nicht abgefragt" — im ersten Fall ist die Leere ein Befund, im zweiten fehlt uns schlicht die Grundlage. Das ORCID-Signal an der Person erscheint deshalb nur bei echter Registry-Deckung (ok oder no-employments); not-checked gilt nicht als geprüft. Fehlt ein Sidecar oder ist es unlesbar, entfällt die Herkunftszeile ersatzlos — es wird nie eine Deckung behauptet, die nicht vorliegt.

Qualitätsvorbehalt, in Zahlen. 668 der 746 Anstellungs-Einträge (89,5 %) sind self-asserted, also von der Person selbst eingetragen; 78 stammen aus dem System einer Einrichtung. Von den 393 laufenden Anstellungen wurden 176 (45 %) zuletzt vor 2023 geändert. Ein ORCID-Eintrag belegt damit, was eine Person über sich angegeben hat und wann zuletzt — nicht, dass die Angabe heute noch zutrifft.

Organisations-Auflösung (ROR). Die genannte Organisation wird, wo möglich, auf eine ROR-ID aufgelöst: 663 von 746 Einträgen (88,9 %) in drei Stufen — ORCID liefert bereits eine ROR-Quelle (202), Offline-Abgleich gegen die 12 kuratierten Wien-Institutionen aus data/wien-institutions.yaml (58), Online-Auflösung über api.ror.org/v2 (403). 83 Einträge (11,1 %) bleiben ohne ROR. Rohbezeichner anderer Register (RINGGOLD, GRID, FUNDREF) werden nie als ROR-ID ausgegeben — nur 202 der Einträge tragen überhaupt eine ROR-Rohquelle, wer den Rohwert blind übernähme, publizierte eine GRID-ID als ROR-ID.

Konflikte werden ausgewiesen, nicht still korrigiert. Der Validator scripts/validate/orcid-employments.ts meldet eine WARNung, wenn keine laufende ORCID-Anstellung zu der Institution passt, die der Brief für die Person führt. Erstmals belastbar gemessen (13.08.2026): 28 Konflikte bei 121 prüfbaren von 182 Institutions-Behauptungen; die übrigen 61 haben keine ORCID-Datengrundlage und werden weder als bestätigt noch als widerlegt gezählt. Ein Konflikt ist kein Fehler-Beweis (Personen wechseln, ORCID-Records veralten, Instituts-Namen weichen ab) — er ist ein Fall für die fachliche Prüfung. Automatisch korrigiert wird nichts.

Was offen bleibt. Der Abgleich prüft die Anstellung, nicht die thematische Zuordnung der Person zur Forschungsfrage — dafür gibt es weiterhin kein maschinelles Signal und bis heute (siehe §21.1) kein einziges dokumentiertes menschliches Urteil. Die 28 Konflikte und die Stichproben-Prüfung der Zuordnungen laufen zusammen in Issue #336.

Cross-Refs: §21.1 (Ist-Stand Verifikation) · §21.4 (Provenance-Pflicht) · §21.5 (Admin-Review-Gate) · ADR-0004 (Sidecar-Pattern) · ADR-0006 (kein customer-sichtbares Datum ohne Provenance) · schemas/orcid-employments.zod.ts · scripts/fetch-orcid-employments.ts · scripts/validate/orcid-employments.ts · Issues #335, #336.

22.1 Übersicht

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

Die Spezifikation sieht ein customer-facinges Signal für externe Validierung vor: „Peer-reviewed by 3 Wiener Forschende" auf reviewten und publizierten Briefen. Dieses Signal ist im aktuellen öffentlichen Korpus nicht aktiv.

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

Gemäß Workflow-Spezifikation sollen Forschungs-Briefe mit Status reviewed oder published das Qualitäts-Signal tragen; im aktuellen öffentlichen Korpus wird es nicht verwendet:

„Peer-reviewed by 3 Wiener Forschende"

In der Spezifikation erhöht dieses Signal den Customer-Wert — die Briefe wären dann 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 × 204 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

Vier additive Methodik-Bausteine aus dem Kundengespräch Stadt Wien Juni 2026, alle flag-gated (Default OFF → Prod byte-identisch). Sie verfeinern, wie Quellen und Forschende dem Kunden gegenüber transparent gemacht werden — sie ändern nicht, wie Briefe geschrieben oder bewertet werden. Tooling-Details: docs/runbook/source-cluster-enrichment.md.

23.1 SJR-Quartil + Source-Metriken (#280)

Pro Journal-Quelle wird — wo verfügbar — das SCImago Journal Rank (SJR) Quartil (Q1–Q4) sowie OpenAlex-Source-Metriken (is_core, is_in_doaj, 2-Jahres-Mittel-Zitiertheit) als Zusatzsignal geführt (data/source-rankings.json, ADR-0004). SCImago hat kein freies API (out-of-scope bis Juni 2026, vgl. §2-Whitelist) → die CSV wird einmal jährlich manuell bezogen (scimagojr.com/journalrank.php?year=YYYY&out=xls). Fehlt das Ranking (~Non-Journal-Lücke), zeigt die UI „kein Ranking verfügbar" — NIE „schlechte Quelle". SJR ist kein Aufnahme-Gate (§2.3) und ändert die Evidenz-Stufe NICHT.

23.2 Source-Provenance (Herkunfts-Transparenz) (#280)

Jede Quelle trägt optional ein neutrales Herkunfts-Label source_provenance (city-of-vienna / public-authority / academic / ngo-industry, immutables Frontmatter- Feld, ADR-0002-Amendment A8). Zweck: dem Kunden die Zusammensetzung des Korpus transparent machen (Wie viel kommt von der Stadt selbst? Wie viel ist peer-reviewed?). Das Label ist orthogonal zur Qualität — es ändert die Evidenz-Stufe nicht und ist „neutral, nicht rot".

23.3 Doppel-Bewertung (wissenschaftlich vs. alle Quellen) (#280)

Pro Forschungs-Brief werden zwei Quellen-Kennzahlen abgeleitet angezeigt: nur peer-reviewed/akademische Literatur vs. alle herangezogenen Quellen. Es gilt invariant wissenschaftlich ≤ alle. Das ist eine Filter-Sicht zur Konsumzeit, KEINE zweite Datenhaltung (Anti-PSA) — sie macht transparent, wie tragfähig die wissenschaftliche Basis gegenüber der breiteren (behördlichen/grauen) Quellenlage ist.

23.4 Cluster-Themengebiet-Auswertung (Quantität ≠ Qualität) (#282)

Pro Themen-Cluster (1–9) entsteht eine Auswertung der Wiener Forschungslandschaft: eine Rangliste der Top-Wiener-Hochschulen im Cluster-Thema + ein Forschenden-Leaderboard (data/cluster-enrichment/<N>.json). Methodische Kern-Disziplin (direkte Fortsetzung der §21-Anti-Generalisten-Logik): Quantität (Werk-Anzahl im Thema) und Qualität (h-Index, Zitationen, i10) werden GETRENNT ausgewiesen — KEIN Misch-Score. h-Index dient nur als Tiebreak (vgl. §21).

• Cluster→Topic-Pinning gegen den Generalisten-Bias: Reines mean-score-Auto-Grounding ist auf Cluster-Ebene nicht robust — bei dicht beieinanderliegenden Topic-Scores (Cluster 3: T10435 „Environmental Impact" 0,988 vs. T11988 „Sustainable Building Design" 0,984) kippt eine 0,4-%-Differenz das gesamte Leaderboard von lokalen Bau-Spezialisten zu globalen IAM- Generalisten (IIASA/van Vuuren/Riahi — exakt der #264-Bias, eine Ebene höher). Deshalb wird ein kuratiertes Pinning data/cluster-topics.yaml geführt (Cluster 3 → T11988, LIVE-verifiziert).
• Offene Härtung: Die Geo-Bucket-Zuordnung des Pilot-Sidecars folgt aktuell einer „jemals-Wien"-Semantik (historische Affiliation), nicht „aktuell-Wien" → Re-Validierung offen (siehe docs/prd/ISSUES.md #282). Die kundengerichtete Aussage „Geo-Diversität pro Cluster" wird erst nach diesem Fix freigegeben.

23.5 Quellen-Geo-Übertragbarkeit (GRADE-Indirectness) (#281)

Pro Quelle wird ein Geltungsbereich (wien → at → eu → global, „any-Wien gewinnt") aus den OpenAlex-Autorenschafts-Ländern abgeleitet (data/geo-provenance.json). Das ist die Übertragbarkeits-Dimension — methodisch verwandt mit GRADE-Indirectness (wie direkt ist die Evidenz auf den Wiener Kontext übertragbar?). Geo = Übertragbarkeit ≠ Qualität: globale Quellen werden in der UI priorisiert, NIE ausgeblendet (eine globale Top-Quelle bleibt eine Top-Quelle). IIASA zählt für Quellen als at (Laxenburg/NÖ, nicht Stadt Wien) — eine bewusste Abgrenzung gegenüber der Forschenden-Geo-Semantik (§21). Die Auto-Ableitung ist ein Vorschlag mit manuellem Override (Divergenz-WARN, nie Voll-Auto).

23.6 Plain-Language-Management-Summary (#283)

Die „Auf einen Blick"-Management-Summary (§-Komplement zum 400-Wörter-Brief) erhält einen versionierten Plain-Language-Prompt v2 (prompts/management-summary.v2.md, Leitplanke ≤ Schulstufe 10, aktiv > passiv). Lesbarkeit wird per Wiener Sachtextformel / LIX gemessen, aber nur als WARN (kein Gate — Fachbegriffe sind legitim, Werte nicht persistiert). Prompt-v1 bleibt für die G5-Reproduktion alter Outputs erhalten (vgl. CLAUDE.md AI-Prompt-Disziplin). Der Full-204-Lauf ist an #224 gekoppelt.

23.7 Wissenschaftlich begutachtete Quellen — Peer-Review-Signal + kein Google Scholar (Kundenwunsch W3, #298)

Die Stadt Wien wünscht eine stärkere Fokussierung auf wissenschaftlich begutachtete (peer-reviewte) Quellen. So wird dieses Signal erhoben — und so ehrlich bleibt es:

• Woher das Peer-Review-Signal kommt. Für jede Quelle mit DOI wird bei OpenAIRE (der offenen EU-Forschungsinfrastruktur) abgefragt, ob das Werk in einem begutachteten Rahmen erschienen ist. Ist die Antwort eindeutig „begutachtet", wird die Quelle als peer-reviewed markiert. OpenAIRE ist damit die maßgebliche Peer-Review-Wahrheit — nicht eine Volltext-Suchmaschine.
• Wie die Evidenz-Stufe daraus folgt. Jede Quelle trägt eine von zwei Stufen: „gewertet" (peer-reviewed laut OpenAIRE oder von einer Behörde/Institution verifiziert und nicht beanstandet) oder „Kontext" (alles Übrige — weiterhin angeführt, aber ohne Peer-Review-Anspruch).
• DOAJ ist ein Bonus, kein Filter. Ist ein Journal zusätzlich im Directory of Open Access Journals gelistet, wird das als Gold-Open-Access-Zusatzsignal angezeigt. Fehlt es, ist das nie ein Ausschluss — viele hochwertige, begutachtete Journals (etwa Nature oder Elsevier-Titel) sind dort legitim nicht enthalten.
• Was wir nicht behaupten. Liefert OpenAIRE kein eindeutiges Signal, wird die Quelle nicht als peer-reviewed ausgewiesen, sondern konservativ als „Kontext" geführt. Es wird also nie ein unbestätigter Peer-Review-Status behauptet.

Warum kein Google Scholar (obwohl im Wunsch genannt)? „Google Scholar" steht im Kundenwunsch stellvertretend für „die wissenschaftliche Suchbreite". Eine direkte Anbindung ist aber weder nötig noch vertretbar: Google bietet keine offizielle Scholar-Schnittstelle; ein eigener Abruf verstieße gegen die Nutzungsbedingungen, und kommerzielle Umwege über US-Dienstleister wären ein datenschutzrechtlicher Drittlandtransfer — für ein Projekt der Stadt Wien nicht angemessen. Dieselbe begutachtete Breite inklusive Zitationssignalen liefert stattdessen OpenAlex (offen lizenziert, Nachfolger des Microsoft Academic Graph), kombiniert mit dem OpenAIRE-Peer-Review-Signal — rechtssicher und EU-souverän. Die vollständige Abwägung inklusive geprüfter Alternativen steht in docs/decisions/2026-07-15-google-scholar-openalex-openaire.md.

23.8 Cross-Refs

• ADR-0002-Amendment A8 (source_provenance als immutables Frontmatter) · ADR-0003-Amendment 2026-06-19 (Seam-Entscheidungen #280–#283) · ADR-0004-Amendment 2026-06-19 (neue Sidecars + cluster-topics.yaml)
• Runbook docs/runbook/source-cluster-enrichment.md — Tooling (Lauf, Flags, SJR-CSV-Download)
• Runbook docs/runbook/source-enrichment-regen.md — Operator-Regen-Guide (Jahres-Zyklus, SJR-CSV-Bezug, Geo-Pilot-Limit-Gotcha, Cluster-Pinning-Protokoll)
• §2 (Quellen-Whitelist + Aufnahme) · §19 (Source-Provenance-Pflicht) · §21 (Forschende-Discovery, Anti-Generalisten-Logik) · docs/ai-suitability-rubric.md
• .orchestrator/audits/w1-schema-lock.md (Schema-Lock) · .orchestrator/audits/w4-qa.md (#282-Semantik-Gate) · Issues #280–#283

Ergänzend zum Literatur-Korpus zeigt das Dashboard pro Themengebiet öffentlich geförderte Forschungsprojekte aus drei amtlichen Projektregistern. Das ist eine Kontext-Schicht (Wer forscht bereits gefördert an diesen Themen?) — sie ändert nicht, wie Briefe geschrieben, Quellen aufgenommen oder KI-Eignungen bewertet werden.

24.1 Datenbasis

Drei Registries, alle als Register-Datenbestand bezogen und lokal versioniert (data/external-records/):

• FFG-Projektdatenbank (projekte.ffg.at, Österreichische Forschungsförderungs- gesellschaft): 307 Records mit Wien-/Klima-Bezug.
• EU CORDIS (Open-Government-Data-Bulk der EU-Kommission, Rahmenprogramme HORIZON Europe + Horizon 2020 + FP7): 4.124 Records mit Wien- und Klima-Filter.
• FWF Open API (openapi.fwf.ac.at, Index projects, Österreichischer Wissenschaftsfonds, Abruf 14.08.2026): 51 Records. Der Weg dorthin, jede Zahl mit ihrem Nenner: 20.380 Projekt-Records im Gesamtbestand → 12.117 nach dem Wien-Gate (Allowlist aus 36 ROR-IDs Wiener Einrichtungen, dedupliziert über die Grant-DOI) → 51 nach dem Klima-Gate (Disziplin-Taxonomie des FWF, eng gefasst auf Climate change und Climatology). Davon tragen 29 von 51 mindestens einen Themen-Cluster und sind damit im Dashboard sichtbar; 22 von 51 tragen keinen und bleiben unsichtbar (§24.7). Der Zuwachs am external-Korpus beträgt 51 von 4.431 vorher bestehenden Records = 1,15 % — die Aufnahme ist nicht mit der Menge begründet, sondern mit der ORCID-Abdeckung (§24.6).

Datenschutz-Disziplin: Aus FFG und CORDIS werden ausschließlich Organisations-Daten übernommen (Titel, Akronym, Laufzeit, koordinierende Institution, Fördersumme, Registry- Permalink) — keine Personendaten; persons[] ist dort in 0 von 307 bzw. 0 von 4.124 Records befüllt. Wo das Quell-Register Personen führt, werden sie beim Ingest verworfen und die Auslassung pro Record im Audit-Feld persons_omitted gezählt (nachvollziehbar, ohne die Daten selbst zu speichern) — bei FFG betrifft das 181 natürliche Personen. FWF ist die einzige Ausnahme und trägt Personendaten; Umfang und Begründung stehen in §24.6.

24.2 Matching auf Themengebiete

Die Zuordnung Record → Themen-Cluster (1–9) erfolgt keyword-basiert in das Feld linked_clusters — bewusst auf Cluster-Ebene, NICHT auf Frage-Ebene: ein Förderprojekt-Abstract trägt nicht genug Signal, um es ehrlich einer einzelnen der 204 Forschungsfragen zuzuordnen; die Themengebiets-Ebene ist die gröbste Ebene, auf der die Keyword-Klassifikation belastbar ist. Präzisions-Hinweis: In den Clustern 8 und 9 (quer liegende Themen mit generischen Keywords) ist die Trefferschärfe am niedrigsten — deshalb wird kuratiert gekappt statt voll gelistet (siehe §24.3).

FWF weicht in der Klassifikation bewusst ab. Dort läuft die erste Stufe nicht über Freitext-Keywords, sondern über die Disziplin-Taxonomie des Registers selbst — ein Record muss auf Taxonomie-Ebene als Climate change oder Climatology geführt sein. Der Grund: FWF liefert keinen Abstract (0 von 51 aufgenommenen Records), sodass eine Freitext-Zuordnung auf dem Titel — Median 6 Wörter bei den 51 Records — plus den Keywords (Median 6, 0 von 51 ohne Keywords) entscheiden müsste. Wie viel diese Enge kostet und was die breite Alternative gemessen geliefert hätte, steht in §24.7. Ein leeres Cluster-Ergebnis ist dabei ein zulässiges Ergebnis, kein Fehler: die 51 Records verteilen sich auf 32 Cluster-Platzierungen (3 von 51 fallen in zwei Cluster), sehr ungleich — Cluster 5 erhält 10, Cluster 8 sieben, Cluster 1 fünf, Cluster 6 vier, Cluster 9 drei, die Cluster 3, 4 und 7 je einen, Cluster 2 keinen. Bei diesen Größenordnungen ist jede Aussage über ein einzelnes Themengebiet eine Aussage über eine einstellige Menge.

24.3 Aufbereitung (Build-time-Precompute)

Pro Cluster wird zur Build-Zeit eine kompakte Sidecar data/external-projects/<N>.json vorberechnet (ADR-0004; scripts/gen-external-projects.ts) — die Roh-Register bleiben aus dem Request-Pfad und dem Runtime-Image. Inhalt: Aggregat (Anzahl, Registry-Split FFG/EU/FWF, Fördersumme, Jahres-Range) + eine Top-12-Projektliste, sortiert nach Laufzeit-Ende (Aktualitäts-Proxy). Fail-closed (ADR-0006): Nur Records mit verifiziertem Provenance-Anker (Registry-Permalink) werden promoted; quarantänisierte oder anker-lose Records erscheinen nie in der Auslieferung.

24.4 Anzeige

Die Förderprojekt-Sektion erscheint auf den Themengebiet-Seiten und ist flag-gated (EXTERNAL_PROJECTS_V1, Default OFF → Production byte-identisch bis zur Freigabe). Jede Projekt-Zeile trägt einen Provenance-Deep-Link auf den Registry-Eintrag (projekte.ffg.at bzw. cordis.europa.eu) — jede Angabe ist damit gegen das amtliche Register nachprüfbar.

24.5 Attribution und Nutzungsrechte

• CORDIS: © Europäische Union; Weiterverwendung unter CC-BY mit Namensnennung — die Attribution steht sichtbar in der Fußzeile der Sektion.
• FFG: Nutzung der Projektdatenbank-Daten wurde projektseitig geklärt; Quellenangabe „FFG-Projektdatenbank" in der Fußzeile.
• FWF: CC0 — keine Attributionspflicht. Die FWF Open API Documentation v1.1 sagt das an zwei Stellen wörtlich zu (S. 4 und S. 19): Die Daten sind ohne Einschränkung nutz-, veränder- und weitergebbar. Die Quellenangabe „FWF Open API“ erfolgt hier freiwillig zur Konsistenz mit den beiden anderen Registern, nicht als Auflage. Der FWF behält sich vor, die API jederzeit zu ändern oder einzustellen.
• Stand-Datum: Jede Sidecar trägt generated_at; die UI zeigt das Stand-Datum in der Fußzeile. Die Register wachsen — ein Refresh ist ein bewusster Re-Ingest + Regen-Lauf, kein Live-Fetch.

24.6 Personenbezug — FWF als dokumentierte Ausnahme

FWF ist das erste der drei Register, aus dem Personendaten übernommen werden. Aufgenommen wird pro Projekt genau eine Zeile für die Projektleitung (principal-investigator) mit Vorname, Nachname und ORCID — bei 51 von 51 Records, also 100 %; die 51 Personen-Zeilen entfallen auf 45 verschiedene ORCIDs (sechs Personen leiten mehr als ein Projekt der Menge).

Warum überhaupt: Diese ORCID ist der eigentliche Grund für die Aufnahme des Registers. Sie verbindet ein gefördertes Projekt an einer Wiener Einrichtung mit einem maschinell auflösbaren Personen-Identifier und ist damit ein von der Selbstauskunft unabhängiger Beleg-Pfad für eine Wien-Affiliation — die Anstellungsangaben in §21.11 sind zu 668 von 746 Einträgen self-asserted, eine Förderzusage ist demgegenüber eine Angabe des Fördergebers. Ausgewertet ist diese Brücke noch nicht: Es gibt derzeit keinen Abgleich der FWF-ORCIDs gegen data/orcid-employments/, keine daraus abgeleitete bestätigte Affiliation und keine Anzeige, die sich darauf stützt. Der Datenbestand liegt vor, die Auswertung steht aus.

Was ausdrücklich nicht übernommen wird: keine Kontaktdaten. Das Schema hat für E-Mail, Telefon, Adresse oder Geburtsdatum kein Feld; erlaubt sind ausschließlich Anzeigename, ORCID, OpenAlex-ID und Rolle (ADR-0006-Amendment, Epic #326 — dieses Amendment trug bereits, es brauchte kein neues). Die Beschränkung wird zusätzlich serverseitig durchgesetzt: die FWF-API kennt eine Feld-Projektion, sodass nicht angeforderte Personenfelder den FWF-Server gar nicht erst verlassen. Personennamen, die in Freitext-Angaben zu Instituten eingebettet sind, werden weiterhin verworfen und nur gezählt (persons_omitted) — in dieser Menge trat der Fall nicht auf: 0 von 51.

Verantwortung: Die CC0-Freigabe betrifft das Urheberrecht, nicht den Datenschutz. Der FWF weist in den Nutzungsbedingungen ausdrücklich darauf hin, dass die rechtmäßige Weiterverwendung — einschließlich Auskunfts-, Berichtigungs- und Löschansprüchen betroffener Personen — Sache der Nutzer:innen ist. Diese Verantwortung liegt damit bei diesem Projekt.

24.7 Genauigkeit vor Menge — warum das FWF-Gate eng ist

Die enge Taxonomie-Regel (§24.2) war eine Entscheidung gegen eine gemessene Alternative, keine Auslassung. Die breite Regel — Klima-Gate über Freitext plus die bestehende Cluster-Keyword-Logik wie bei CORDIS — wurde gebaut und ausgezählt: sie liefert 212 Records statt 51, also gut das Fünffache. Eine systematische Stichprobe von 10 der 212 (4,7 %) ergab jedoch nur 2 klar tragende Cluster-Zuordnungen, 3 teilweise richtige (richtiges Thema, falscher Cluster) und 5 harte Fehltreffer, davon 3 reine Wortgleichheits-Kollisionen ohne jeden Klimabezug. Eine Kontroll-Stichprobe über eine mittlere Variante zeigte dasselbe Muster: Die Taxonomie hebt die thematische Trennschärfe, die Cluster-Trennschärfe bleibt schlecht, solange kein Abstract vorliegt.

Deshalb: lieber 51 präzise als 212 mit hoher Fehlerquote. Jeder Fehltreffer erschiene sonst als Kennzahl auf einer Themengebiet-Seite und müsste einzeln widerlegt werden.

Was diese Stichprobe nicht hergibt: 10 von 212 sind 4,7 %. Bei 5 harten Fehltreffern ist das 95-%-Konfidenzintervall der Fehlerquote grob 19–81 % — die Richtung ist eindeutig, eine Punktschätzung wäre es nicht. Die Entscheidung stützt sich auf die Richtung.

Der Preis, offen ausgewiesen: 22 von 51 aufgenommenen FWF-Records tragen keinen Cluster. Sie sind ingested und versioniert, erscheinen aber in keiner Themengebiet-Seite und in keiner ausgelieferten Kennzahl — sichtbar sind 29 von 51. Wer „51 FWF-Projekte“ ohne diese Aufteilung liest, liest die Zahl falsch.

Nicht gewählt, nicht ausgeschlossen: Eine modellgestützte Cluster-Zuordnung (Titel + Keywords + Disziplin) wäre die einzige sichtbare Option, Menge und Genauigkeit zugleich zu erreichen. Sie wurde bewusst nicht mitgebaut, weil sie einen eigenen Bewertungszyklus mit versioniertem Prompt und gepinntem Modell (G5) sowie eine neue Stichprobe als Abnahme erfordert — und ungeprüft angenommen wird hier nichts.

24.8 Cross-Refs

• ADR-0004 (Sidecar-Pattern) · ADR-0006 (Provenance-/Quarantäne-Disziplin, auf Register-Records übertragen wie in §21.4 für Forschende)
• §21.11 (ORCID-Registry-Abgleich der Anstellungsangaben — Gegenstück zur ORCID-Brücke aus §24.6)
• schemas/external-record.zod.ts (Register-Records) · schemas/external-projects.zod.ts (Cluster-Sidecars, url-Allowlist ffg/cordis/fwf)
• scripts/gen-external-projects.ts (Precompute) · scripts/lib/fwf-ingest.ts (FWF-Abruf)
• docs/decisions/2026-08-14-fwf-orcid-bruecke.md (Begründung der FWF-Aufnahme in voller Länge) · Issues #333, #334

• §24 erweitert um FWF (2026-08-14, deep-Session Welle 3, #334; Version-Entscheidung offen — siehe unten) — §24 heißt jetzt „Externe Förderprojekt-Daten (FFG + CORDIS + FWF)“. Neu in §24.1: FWF Open API (openapi.fwf.ac.at, Index projects, Abruf 14.08.2026) als dritte Registry mit 51 Records und der vollen Ableitungskette 20.380 Gesamtbestand → 12.117 nach Wien-Gate (36 ROR-IDs, dedupliziert über Grant-DOI) → 51 nach engem Klima-Gate, davon 29 sichtbar / 22 ohne Cluster; Zuwachs 51/4.431 = 1,15 %. §24.2 ergänzt um das taxonomie-basierte FWF-Gate (statt Freitext-Keywords), die Begründung „kein Abstract, Titel-Median 6 Wörter“ und die Cluster-Verteilung der 32 Platzierungen (C5:10 · C8:7 · C1:5 · C6:4 · C9:3 · C3/C4/C7:je 1 · C2:0). §24.3 auf den dreiteiligen Registry-Split gezogen. §24.5 um die FWF-Lizenz ergänzt: CC0 ohne Attributionspflicht (Open API Documentation v1.1, S. 4 + S. 19) — die Quellenangabe erfolgt freiwillig, anders als bei CORDIS (CC-BY mit Namensnennungspflicht). §24.6 neu — Personenbezug: FWF ist die erste Registry mit Personendaten (Name + ORCID der Projektleitung, 51/51 = 100 %, 45 distinct ORCIDs auf 51 Personen-Zeilen); Abgrenzung zu FFG (0/307 befüllt, 181 ausgelassene Personen) und CORDIS (0/4.124); keine Kontaktdaten (Schema hat kein Feld, ADR-0006-Amendment Epic #326 trug bereits — kein neues Amendment), serverseitige Feld-Projektion, persons_omitted 0/51; ausdrücklicher Hinweis, dass die ORCID-Brücke zu §21.11/#335 gebaut, aber nicht ausgewertet ist, und dass die datenschutzrechtliche Verantwortung laut FWF-Nutzungsbedingungen bei uns liegt. §24.7 neu — Genauigkeit vor Menge: die verworfene breite Regel (212 Records) mit der Stichprobe 10/212 = 4,7 % → 2 klar tragend / 3 teilweise / 5 harte Fehltreffer, inklusive des Konfidenz-Vorbehalts (95-%-Intervall der Fehlerquote grob 19–81 %, nur die Richtung ist belastbar), der offen ausgewiesenen 22 unsichtbaren Records und der bewusst nicht gebauten modellgestützten Zuordnung (eigener Bewertungszyklus nach G5). Bisheriges §24.6 Cross-Refs → §24.8. TLDR-Bullet „Woher die Förderprojekt-Daten kommen“ auf drei Register plus Personenbezug-Ausnahme gezogen.
  • Zahlen-Korrektur gegenüber der Session-Vorgabe: Die Vorgabe nannte für die Cluster-Zuordnung „~12 Wörter Titel“; am aufgenommenen Bestand nachgemessen sind es 6 Wörter im Median (Mittel 5,96, n=51). Publiziert ist der gemessene Wert. Alle übrigen Zahlen der Vorgabe reproduzierten sich exakt (51 · 29 · 22 · 32 · 51/51 ORCID · 51/51 ROR · 4.431).
  • Version-Entscheidung bewusst NICHT hier getroffen: Das Frontmatter steht unverändert auf 2.3. Ein Minor-Bump auf 2.4 wäre nach dem Präzedenzfall v2.3 (§21.11) argumentierbar, weil §24.6 eine kundenlesbare Aussage über Personendaten trifft. Er ist aber nicht folgenlos: der String Methodik v<version> ist per Drift-Sentinel (tests/scripts/drift-sentinel-methodology-footer.test.ts) hart an apps/dashboard/components/site-footer.tsx gekoppelt, der PDF-Footer in apps/dashboard/lib/pdf-template.ts wird literal in tests/dashboard/f118-ux-polish-batch.test.ts geprüft. Diese drei Dateien liegen außerhalb des Scopes dieses Doku-Schritts; Bump und Footer-Sync gehören daher in einen Schritt, der alle Träger gleichzeitig zieht.
• v2.3 (2026-08-13, deep-Session Welle 3 + 4, #335/#336) — §21.11 neu + Update zu §21.1 und TLDR. Add §21.11 „ORCID-Registry-Abgleich der Anstellungsangaben" neu: Datenbasis 144 Sidecars / 363 Personen-Zeilen (168 distinct) / 746 Anstellungs-Einträge aus ORCID-API v3.0; wörtlicher Anzeige-Vertrag „ORCID-Eintrag (Selbstauskunft): Anstellung ‹Org› · Registry-Stand ‹MM.YYYY› · abgerufen ‹TT.MM.YYYY›" mit expliziter Absage an „Affiliation bestätigt am ‹Datum›" (falscher Akteur + falsches Datum); vier unterscheidbare fetch_status-Zustände (ok 287 · no-employments 46 · not-checked 30 · error 0) mit der Regel, dass not-checked nicht als geprüft gilt; Qualitätsvorbehalt in Zahlen (668/746 = 89,5 % self-asserted; 176 von 393 laufenden Einträgen = 45 % zuletzt vor 2023 geändert); ROR-Auflösung 663/746 = 88,9 % über drei Stufen (orcid-disambiguation 202 · wien-institutions.yaml 58 · api.ror.org/v2 403), 83 offen; Konflikt-Ausweisung statt stiller Korrektur (28 Konflikte bei 121 prüfbaren von 182 Institutions-Behauptungen, 61 ohne ORCID-Datengrundlage). §21.1: Ist-Stand-Datum auf 2026-08-13 gezogen und der Verifikations-Stand beziffert (0 von 456 Einträgen menschlich verifiziert · 278 maschinell · 178 ohne Label; 0 dokumentierte Urteile bei 177 Personen); orcid ist nicht mehr als reines Ergebnis-Feld ohne Validierungs-Semantik beschrieben, sondern verweist auf §21.11. TLDR-Box: zwei neue Bullets („Woher die Anstellungsangabe der Forschenden kommt", „Was menschlich geprüft ist"), bestehender Bullet von „Expert:innen-Stichprobenprüfung in Vorbereitung" auf „steht aus" korrigiert.
  • Zahlen-Korrektur gegenüber der Session-Vorgabe: Zwei Werte wurden am Bestand nachgemessen und weichen ab — ROR-Auflösung 88,9 % (663/746, nicht 90,2 %; die Stufen-Zahlen der Vorgabe lagen auf einem anderen Nenner) und 45 % der laufenden Anstellungen zuletzt vor 2023 geändert (176/393; die kursierenden 57 % stammen aus der n=25-Stichprobe vom 2026-08-12 im Schema-Header, nicht aus dem Vollbestand). Publiziert sind die am Vollbestand gemessenen Werte.
  • Minor-Bump 2.2 → 2.3 (rein doku-additiv: ein neues Sub-Kapitel innerhalb §21 plus Präzisierung von §21.1 und TLDR, keine Rücknahme bestehender Aussagen, kein Schema-/Prompt-Pflicht-Change in dieser Methodik-Datei). Begründung für den Bump statt eines stillen Nachtrags: §21.11 trifft eine öffentliche Aussage über Herkunft, Selbstauskunfts-Charakter und Prüfstand der Anstellungsangaben — eine kundenlesbare Methodik-Aussage verdient die Sichtbarkeit im Footer. Präzedenz: v2.1 war ein Minor für die additive Sub-Sektion §21.10. Footer-Sync (F-107, synchron in Welle 4 statt deferred): Der Footer-String Methodik v<version> ist per Drift-Sentinel (tests/scripts/drift-sentinel-methodology-footer.test.ts) hart an dieses Frontmatter gekoppelt und wurde in apps/dashboard/components/site-footer.tsx auf Methodik v2.3 gezogen. Erledigt (Welle 4, gleiche Session): der zweite customer-sichtbare Träger derselben Zeile, der PDF-Footer in apps/dashboard/lib/pdf-template.ts (renderFooter(), literal geprüft in tests/dashboard/f118-ux-polish-batch.test.ts), steht ebenfalls auf Methodik v2.3 — verifiziert an einem echt gerenderten PDF. Die bekannte R-58-Drift (Web-UI v2.3 vs. PDF v2.2) ist damit geschlossen; beide Träger sind wortgleich. Die §21.10-, §23.7- und §24-Nachträge blieben demgegenüber bewusst ganz unversioniert.
  • Drift-Annotation: Keine Prompt-Drift. Schema-Drift: keine — schemas/orcid-employments.zod.ts ist CONTRACT-LOCK auf schema_version: 1 und wird hier nur beschrieben, nicht geändert. §§1–21.10 und §§22–24 unverändert; keine Renummerierung (§21.11 hängt sich hinter §21.10, §22 folgt unverändert).
• 2026-05-08: Skeleton angelegt (Phase-0-Wrap-Up-Session, #13 prep).
• 2026-05-09: v1 — Vollinhalt nach Pivot-PRD 2026-05-09 (§4 Source-Whitelist-Reihenfolge, §5 Quality-Checklisten Pre/Per/Post/Cross, §6 Subagent-Disziplin). Worked-Examples-Sektion als Platzhalter angelegt, Befüllung in Wave 3 der Deep-Session 2026-05-09 (Issue #143).
• 2026-05-09 (W3-3E): v1.1 — §7 Worked Examples mit drei Goldstandard-Walkthroughs (WFK-2.1.5, WFK-1.4.1, WFK-6.1.1) befüllt. §5 Post-Synthese: Status-Werte auf schema-konform korrigiert (draft → drafted, review-ready → reviewed, gemäß schemas/workflow.zod.ts STATUSES) und Audit-Trail-Block-Bullet ergänzt (Output-Vertrag aus prompts/ai-rating.v1.md).
• 2026-05-09 (Phase-1.5 W1, SQ-10): v1.2 — Draft, finalisiert in Phase A W4.
  • DOI-Hierarchie kodifiziert (§2.3.1) — war: disjunktiv „DOI oder Permalink"; jetzt: ordered list DOI > Permalink (Wayback) > Stabile URL > Plain URL.
  • doi_unavailable_reason als Pflicht-Feld bei Non-DOI-Sources dokumentiert (§2.3.1, verweist auf ADR-0002-Amendment 2026-05-09).
  • Source-Quality-Checkliste neu (§2.4, 5-Punkt-Liste: DOI-Resolve / Wayback-Snapshot / Content-Match / Tier / OA-Status).
  • Diversitäts-Regeln neu (§3.1, 3 Rules: D1 Disziplinen-Spread Soft, D2 Autoren-Spread Soft, D3 Wien-Anker Hard).
  • Reachability-Check Pflicht (§5.3, Hard-Gate via Pre-Commit gemäß SQ-05; Override nur via Sidecar content_match_override).
  • Cross-Referenzen ergänzt um ADR-0004, ADR-0005 und PRD-Amendment 2026-05-09-source-quality-hardening.
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md — Synthesis-Prompts bleiben unberührt; v1.2 betrifft nur den Source-Aufnahme-Workflow und Quality-Gates, nicht die Synthese-Wortzahl-Vorgaben oder den Synthesis-Prompt-Vertrag.
  • Finalize-Pass: in Phase A W4, nach Vorliegen der SQ-08-28-Broken-Triage-Daten (kann z.B. die DOI-Coverage-Realitäts-Korridor-Aussage in §2.4 schärfen).
• 2026-05-12 (Phase-1.5, F-31a): v1.3 — Reframe + 3 neue §§ (Methods/Confidence/Limitations). Abgeleitet aus PRD-Amendment docs/prd/2026-05-12-format-reframe-forschungs-brief.md (Pfad-β-Entscheidung End2End-Format-Audit 2026-05-12).
  • Begriffs-Reframe „Synthese" → „Forschungs-Brief" in allen customer-sichtbaren Stellen (§§1-10 plus neue §§11-13). Engineering-Code-Variablen (synthesis_word_count, parseSynthesisBody, syntheses/-Pfade, prompts/synthesis.v1.md) bleiben unverändert — dokumentierte Drift gemäß CLAUDE.md.
  • §11 PRISMA-ScR-Light neu — Pflicht-Felder pro Brief (databases, search_strings, date_range, last_run, inclusion/exclusion_criteria, records_screened/included). Quelle: PRISMA-ScR Extension Tricco et al. 2018, JBI Manual, Cochrane Rapid Reviews Garritty et al. 2024.
  • §12 IPCC-Calibrated-Language neu — Rubric (confidence × evidence × agreement) für mindestens 3 Key-Claims pro Brief mit Beispielen pro Achse. Quelle: IPCC AR6 Uncertainty Guidance (Mastrandrea et al. 2010), APCC AAR2 SPM-DE als nationale Präzedenz.
  • §13 Limitations-Boilerplate neu — 4 Standard-Bausteine (Single-Screener / Suchsprache DE-EN / Stand der Recherche / keine formale Critical Appraisal). Quelle: Cochrane Rapid Reviews Garritty et al. 2024.
  • Cross-Referenzen ergänzt um docs/prd/2026-05-12-format-reframe-forschungs-brief.md.
• v1.4 (2026-05-13, W2-D Deep #16) — §13 Reihenfolgen-Hinweis präzisiert: Audit-Trail-JSON ist inline in ## KI-Eignungs-Bewertung-Sektion, Limitations folgt danach am Body-Ende. Entscheidungsdokument: docs/decisions/2026-05-12-audit-trail-limitations-order.md (Reihenfolge A approved 2026-05-13).
• v1.5 (2026-05-13, W2-F Deep #17) — Drei additive Sektionen für die K3-Wave-2/3-Skalierung. Abgeleitet aus K3-Wave-2-Pre-Vet (_research/k3-wave-2-prevet-2026-05-13.md, WFK-3.1.1 K3-PASSIVE-Verdict + WFK-4.2.1 DPIA-WITH-CAVEATS) und Decision-Doc K3-Skalierung (docs/decisions/2026-05-12-k3-active-scaling.md).
  • §14 PASSIVE-Brief-Pattern neu — Muster für normativ-juristische und qualitativ-gestaltende Fragen (AI-Score low/none, D2 ≤ 1, KI-Rolle preparatory, mehrheitlich autoritative Quellen (Tier-1-Legal-Government, Tier-1-Institutional) + ≥1 K3-Critical-Gegenposition, Limitations-Boilerplate-Erweiterung Baustein 5, IPCC-Confidence-Mapping mit anderer Semantik). Vorbild: WFK-6.1.1; erster expliziter PASSIVE-Brief: WFK-3.1.1 (Wave 3-B; 4/9 = 44% Tier-1-Legal/Government — Pattern erfüllt per Worked-Example-Note).
  • §15 DPIA-Disclaimer-Pattern neu — Muster für Briefe mit personenbezogenen / personen-rekonstruierbaren Daten (DSGVO Art. 35 explizit, Re-Identifikations-Risiko-Floor de Montjoye et al. 2013, Privacy-by-Design k-anonymity ≥20 / Differential Privacy / synthetische Ersatzdaten, NGO-Critical-Voice als wissenschaftlicher Skeptizismus, Sample-Bias-Hierarchie Garber et al. 2022, drei zulässige Placement-Optionen). Sub-Variante: WFK-1.2.1a; erster expliziter DPIA-Brief: WFK-4.2.1 (Wave 3-A).
  • §16 Tier-1-Legal-Government Source-Acceptance neu — Erweiterung der Source-Whitelist (docs/source-catalog.md Tier-Strategy) um Tier-1-Legal: Gesetzestexte, EU-Verordnungen, amtliche Kommentare, Höchstgerichts-Urteile als authoritative Primärquelle für normative Fragen. Examples: EU-CPR-Recast 2024, AT-AWG 2002 §3, AT-ABGB §§922-933b, Wiener BO. Frontmatter-Type-Fallback type: standard bis Schema-Extension (F-Issue für legal-text to SourceTypeSchema enum, filed in Deep #17 W5 ISSUES-sync). Citation-Discipline: Article-/Paragraph-Nummer Pflicht im Wikilink-Anchor.
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md oder schemas/source.zod.ts. v1.5 ist rein doku-additiv; die Schema-Extension für legal-text ist explizit als Folge-Issue ausgelagert (Anti-PSA-Disziplin: erst zweiter realer Konsument rechtfertigt Enum-Erweiterung).
• v1.6 (2026-05-14, Deep #18 W5) — Eine additive Sektion für die K3-Wave-3-Roll-Out-Erkenntnisse. Abgeleitet aus den zwei erprobten PhD-Reviewer-Passes in Deep #18 W2-Inter-Gate (3 Briefe, 3× SHIP-WITH-TWEAKS) + W3-Inter-Gate (2 Briefe, 2× SHIP-WITH-TWEAKS inkl. 1 CRITICAL-Blocker vor W4 gefixt).
  • §17 PhD-Reviewer-Pass-Pattern neu — institutionalisierter Inter-Wave-Gate nach K3-Brief-Drafting-Waves. Trigger ≥1 K3-active Brief gedrafted, Panel ≥3 Disziplinen + Chair, 9 Review-Kriterien (Layer-3-Discipline), Output Markdown-Report mit Per-Reviewer Strong-Points + Weaknesses + Suggested-Edits + Verdict (SHIP/SHIP-WITH-TWEAKS/RESHAPE), Findings-Loop Severity-getaggt (Critical → coord-direct vor W4, High → W3-C, Medium → W4-Q, Low → F-Issue defer). Template prompts/phd-reviewer-pass.v1.md (versioniert per G5 AI-Prompt-Discipline). Layer-1-Bundle-B-Decision per feedback walkthrough-prevet-then-decision.
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md oder Schemas. v1.6 ist rein prozess-additiv (Inter-Wave-Gate-Spec); kein Refactor an existierenden §§1-16. prompts/phd-reviewer-pass.v1.md ist NEW prompt — Convention G5 (Modell-Pinning + Prompt-Version in rated_by Audit-Trail) gilt analog.
• v1.7 (2026-05-14, Deep #19 W2-T12) — Eine additive Sub-Sektion zur Resolution der F-100-Spec-Inkonsistenz Topic-Lead vs. direct-h2. Abgeleitet aus dem F-100-Audit (_research/k3-f100-topic-lead-audit-2026-05-14.md, 15/15 K3-active Briefe geprüft: 14 direct-h2 / 1 topic-lead WFK-8.1.1) und der Decision Option C in Deep #19 W1-Gate (docs/decisions/2026-05-14-topic-lead-spec.md, status decided).
  • §11.0 Topic-Lead-Konvention neu — Topic-Lead ist optional, brief-typ-abhängig; Default direct-h2. Erlaubt bei HYBRID-Briefen (Vorbild WFK-8.1.1), DPIA-Disclaimer-Briefen (§15) und Edge-Cases mit ungewöhnlicher Methodik-Asymmetrie. Wortlaut-Spec: 1–2 Sätze, ≤ 60 W, deklarativ, keine Wikilink-Citations, keine IPCC-Confidence-Tags, kein H2-Header. Zählt nicht als Sektion für die "6 H2-Sektionen"-Invariante; synthesis_word_count-Total = Topic-Lead-Wörter + 6-H2-Body-Wörter.
  • Brief-Alignment-Impact: Null. 14/15 Briefe (direct-h2) und WFK-8.1.1 (topic-lead, HYBRID-Pattern-konform) sind bereits compliant.
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md, prompts/phd-reviewer-pass.v1.md oder Schemas. v1.7 ist rein doku-additiv (Topic-Lead-Konvention). Cross-Ref _research/k3-goldstandard-verification-2026-05-14.md §Wave-3-Drafting-Specification §1 ("Pre-H2 Topic-Lead" als NON-NEGOTIABLE) wird auf §11.0-Optional-Spec geupdatet; PhD-Reviewer-Pass-Kriterium 6 (Section-Balance) verweist optional auf §11.0 für Topic-Lead-Check.
• v1.8 (2026-05-14, Housekeeping F-88) — F-88: §15 EU AI-Act Annex III bullet added. §15 DPIA-Disclaimer-Pattern um einen kompakten Pflicht-Bullet zur EU-AI-Act-Annex-III-Hochrisiko-Klassifikation erweitert (parallel zur DSGVO-Art.-35-DPIA, nicht alternativ). Pflicht-Checkpunkte: Annex-III-Screening (Punkt 1/2/5/8), Konformitätsbewertung vor Deployment (Art. 43), Fundamental-Rights-Impact-Assessment (Art. 27), Risikomanagement-System (Art. 9). Cross-Refs: Verordnung (EU) 2024/1689 (KI-Verordnung). Anwendung erprobt in WFK-4.2.1 / WFK-9.1.1 / WFK-7.1.1. Abgeleitet aus Deep #17 W4-B-Finding M-4 (DSGVO-Tiefe ohne parallelen AI-Act-Pfad).
• v1.8-update (2026-05-14, Deep #20 F-105) — §16 Stale-Fix: „type: standard Fallback"-Wording entfernt; canonical type: legal-text + Pflicht-legal_jurisdiction (Enum EU | AT-Bund | AT-Land-Wien | Höchstgericht) als Schema-Vertrag dokumentiert. Cross-Ref ADR-0002 Amendment A7 (F-82 Schema-Extension closed in Deep #20). Folge-Issue-Verweis aus v1.5 §16 obsolet — entfernt. Kein Major-Version-Bump (rein doku-erfüllend, kein neuer Pattern).
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md, prompts/phd-reviewer-pass.v1.md oder Schemas. v1.8 ist rein doku-additiv (ein Bullet in §15). Footer-String Methodik v1.7 in apps/dashboard/app/layout.tsx:50 ist out-of-scope dieser Housekeeping-Task (File-Lock auf docs/methodology.md) und bleibt als Follow-up offen — Bump auf v1.8 erfolgt in nächster Dashboard-Session.
• v1.9 (2026-05-15, F-121) — Drei additive Sektionen aus dem Quellen-Integritäts-Audit. Abgeleitet aus dem Vollkorpus-Audit (audit_method_version 2, gesamter Korpus geprüft) + docs/runbook/source-audit.md (8-Step-Protokoll) + ADR-0006 (Source-Integrity-Policy). Die internen Audit-Roh-Befunde werden im nicht-öffentlichen Runbook geführt.
  • §18 Source-Integrity-Audit (post-F-121) neu — Anlass, Methode (Verweis auf Runbook-Vollspec), Ergebnis/Konsequenz (Quarantäne nicht-bestätigbarer Quellen, ausgelieferte Briefe zitieren ausschließlich triangulierte Quellen), stehendes Auslieferungs-Gate + Provenance-Pflicht.
  • §19 Source-Provenance-Pflicht (going-forward policy) neu — Drei Provenance-Optionen pro neuer Source: (a) DOI-Crossref-Match (Title+Author exact-match), (b) Wayback-Snapshot ≥ 1 Jahr vor retrieved, (c) Institutional-Registry-Eintrag (WHO/IPCC/IEA/EEA/OECD/Statistik Austria/Stadt Wien Open Data/RIS/EUR-Lex). Enforcement-Pfad: ADR-0006 + scripts/audit-source.ts CI-Pre-Add-Gate (F-121-Sub-MethodV2). verified_by-Audit-Trail-Format spezifiziert. Tier-1-Legal-Government-Sonderfall (Option (c) per Definition via Registry-Permalink, legal_jurisdiction bleibt Pflicht).
  • §20 Verifikations-Subtypen (5 Patterns) neu — Diagnostisches Vokabular für Audit-Berichte + automatisierte Verifikations-Läufe: §20.1 Real-Institution-Fake-Title, §20.2 DOI-Resolves-To-Wrong-Paper, §20.3 Real-Paper-Fake-Authors, §20.4 Real-Paper-Paraphrased-Title, §20.5 Wrong-DOI-Assignment. Subtypen nicht-exklusiv; dominanter Subtyp im evidence-String + Tracking-Sheet-notes-Spalte.
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md, prompts/phd-reviewer-pass.v1.md. ADR-0006 hängt mit §19 verbindlich zusammen (Schema-Refinement: schemas/source.zod.ts ggf. um verified_by-Feld in W4-A — out-of-scope dieses Files). Footer-String Methodik v1.7 in apps/dashboard/app/layout.tsx:50 bleibt weiterhin out-of-scope (Drift-Sentinel-Test wäre Follow-up).
• v1.10 (2026-05-15, Deep #24, Forschende-Mapping-Initiative #222) — Add §21 Forschende-Discovery-Methodology (Wiener Researchers via OpenAlex). Eine additive Sektion mit 8 Subsektionen (Ziel · Pipeline-Schritte · Wien-Institutions-Definition · Provenance-Pflicht · Admin-Review-Gate · Feedback-Loop · Risks · Cross-Refs). Abgeleitet aus PRD docs/prd/2026-05-15-forschende-mapping.md und Recon-Briefing _research/openalex-recon-2026-05-15.md (~25 min Spike, 13 ROR-Lookups, 3 Pilot-WFK-Topic-Discoveries, Rate-Limit-Verifikation). Provenance-Disziplin (§21.4) ist die ADR-0006-Übertragung auf Researcher-Records; Admin-Review-Gate (§21.5) ist die strukturelle F-121-Lehre für customer-sichtbare Auto-Discovery-Outputs. Footer-String Methodik v1.9 in apps/dashboard/app/layout.tsx:50 wird synchron auf v1.10 gebumpt (F-106/F-107 Drift-Pattern, jetzt in-task gefixt statt deferred). Cross-Refs: ADR-0007 (NEU, Auth-Gate), docs/runbook/forschende-discovery.md (W2-E Runbook), data/wien-institutions.yaml (Registry).
  • Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md, prompts/phd-reviewer-pass.v1.md. NEW prompts prompts/forschende-translate.v1.md und prompts/forschende-rerank.v1.md folgen Convention G5 (Modell-Pinning + Prompt-Version in Audit-Trail) analog. Schema-Refinement (schemas/researcher.zod.ts, schemas/question.zod.ts-Extension um wiener_researchers) erfolgt in der Foundation-Wave separat — out-of-scope dieses Files.
• v1.11 (2026-05-15, Deep #25) — Add §22 Für Themenpat:innen — Navigations-Abschnitt mit Cluster-Direkt-Links für Magistrats-Abteilungen und Wien-Energie-Mitarbeitende (AC-7, Issue #226). Rein doku-additiv, keine Schema- oder Prompt-Drift.
• v1.12 (2026-05-15, Deep #28, Issue #196) — §19.3 verified_by als strukturiertes Objekt schema-enforced (method + evidence + checked_at statt flat-string aus v1.9). Drei Provenance-Optionen (a/b/c) unverändert, nur ihre Repräsentation ist jetzt schema-seitig erzwungen via schemas/source.zod.ts. Drift-Annotation: ADR-0006 wurde entsprechend amendiert; existierende Sources werden im Migration-Lauf von audit-source.ts automatisch in das strukturierte Format überführt.
• v1.13 (2026-05-16, /test-Audit Customer-UX-Sweep) — Reframe ohne neue Methodik-Sektion: TLDR-Kurz-Methodik-Box am Anfang des Dokuments (vor §1) eingefügt, Versionierungs-Übersichts-Block aus dem Header an das §Changelog am Ende konsolidiert (war redundant). Keine inhaltliche §§-Änderung, kein neuer Pattern. Hintergrund: End-zu-End-UX-Audit hat den Engineering-Changelog-am-Anfang als customer-facing Friction-Punkt identifiziert (Wall-of-Text, keine Einstiegshilfe für Außenstehende). Parallele UI-Änderungen: veralteter Audit-Status-Banner aus Landing + Methodology-Page entfernt (faktisch überholte Snapshot-Zahlen), Brief-Detail bekommt SectionCard-Pattern + At-a-Glance-Header + Wikilink-Tier-Pills statt Source-Type-Badges, Quelldatei-GitLab-Link entfernt (Customer hat keinen Repo-Access), ResearchersCollapsible bekommt OpenAlex-Topic-Suche-Footer-Link für Customer-Erweiterungspfad jenseits der Top-3. Drift-Annotation: Keine erwartete Drift mit prompts/* oder Schemas. Footer-String Methodik v1.12 in apps/dashboard/app/layout.tsx wird synchron auf v1.13 gebumpt.
• v1.14 (2026-05-16, Deep #29 Wave 2 IC-4) — §21.9 PhD-Coordinator-Pattern (Anthropic-API-Bypass) neu. Dokumentiert den in Deep #28 empirisch erprobten alternativen Ausführungspfad für Forschende-Discovery, bei dem ein Claude Code Coordinator (Opus 4.7 / Sonnet) die LLM-Translate- (§21.2 Step 1) und LLM-Re-Rank-Subschritte (Step 6) ohne separaten Anthropic-API-Key durch Subagent-Calls ersetzt. Kernelemente: Motivation + Break-Even-Faustformel (≤ 50 WFK Coordinator, > 50 WFK API-Pfad), Architektur-Übersicht (5 Schritte, Parallelisierungs-Pattern 3 Subagents × 5 WFK = ~30 min Pilot), Editor≠Verifier-Pass (§21.9.3, 5-Punkt-Checklist, phd-curator-verified_by-Suffix), Provenance-Sidecar-Schema (_research/forschende-pilot-smoke-2026-05-15-sidecars/<WFK-id>.json), Cost-Comparison-Tabelle (API-Pfad ~$0.82 / 204 WFK vs. 0 Kosten Pilot-Set), Cross-Refs §17/§18/§21.2/§21.4/§21.5/ADR-0006. Drift-Annotation: Keine erwartete Drift mit prompts/* oder Schemas. Footer-String Methodik v1.13 in apps/dashboard/app/layout.tsx bleibt out-of-scope dieses Wave-Agents — Bump auf v1.14 erfolgt in W5-F2 (SSOT-Sync).
• §24 neu (2026-08-11, MR !73 feat/external-projects-ui-2026-08-11, #333; KEIN Version-Bump — Version-Entscheidung beim Flag-ON) — Add §24 „Externe Förderprojekt-Daten (FFG + CORDIS)" neu (6 Sub-Sektionen): Datenbasis FFG-Projektdatenbank 307 Records + EU-CORDIS-OGD-Bulk (HORIZON/H2020/FP7) 4.124 Records Wien+Klima, org-only ohne Personendaten mit persons_omitted-Audit; keyword-basierte linked_clusters-Klassifikation bewusst auf Cluster-Ebene (KEINE Frage-Ebene, Präzisions-Hinweis Cluster 8/9); Build-time-Precompute je Cluster mit Top-12 nach Laufzeit-Ende und fail-closed-Promotion (nur Records mit Provenance-Anker, ADR-0006); Anzeige auf den Themengebiet-Seiten flag-gated (EXTERNAL_PROJECTS_V1, Default OFF), jede Zeile mit Provenance-Deep-Link; Attribution CORDIS © Europäische Union (CC-BY) + FFG projektseitig geklärt; Stand-Datum via generated_at. Dazu ein Kurz-Methodik-Bullet in der TLDR-Box. Drift-Annotation: Keine Schema-/Prompt-Drift in dieser Methodik-Datei (Schemas external-record.zod.ts/external-projects.zod.ts sind Teil desselben MR); Version bleibt 2.2 — die Sektion beschreibt ein noch flag-OFF-Feature, die Version-Entscheidung (Bump + Footer-Sync, F-107) fällt beim Flag-ON-Rollout.
• Update zu §21.1 + TLDR (2026-08-11, fix/researchers-badge-honesty; KEIN Version-Bump — Korrektur eines faktisch falschen Ist-Claims, kein Methodik-Change) — §21.1: Der Ist-Claim „jeder Output durchläuft ein Admin-Review-Gate (§21.5) bevor er customer-sichtbar wird" auf den realen Zustand korrigiert: Review-Tooling (Admin-Edit-UI /admin/researchers) existiert, ein verpflichtendes Gate vor Customer-Sichtbarkeit ist noch nicht implementiert; Expert:innen-Stichprobenprüfung in Vorbereitung. TLDR-Box: „manuell verifiziert" → „LLM-gestützt kuratiert; Expert:innen-Stichprobenprüfung in Vorbereitung". Anlass: Der Datenbestand enthält 0 menschlich verifizierte Forschenden-Einträge (alle 278 verified_by-Werte sind LLM-Kampagnen-Labels, 182 Einträge ohne verified_by). Parallel wird das Dashboard-Badge in ResearchersCollapsible.tsx von „kuratiert & verifiziert" auf „automatisiert ermittelt · LLM-kuratiert" umgestellt. §21.5 selbst bleibt als Spezifikation unverändert. Drift-Annotation: Keine Schema-/Prompt-Drift; Footer Methodik v2.2 unberührt.
• Update zu §23 (2026-07-15, deep-Session feat/stadt-wien-w1-w4-2026-07-15, #298 Task 2+3; KEIN Version-Bump — additive Prosa, Footer-Sync bleibt Dashboard-/SSOT-Sync-Session, F-107) — §23.7 „Wissenschaftlich begutachtete Quellen — Peer-Review-Signal + kein Google Scholar (W3)" neu (kundenlesbar): wie das Peer-Review-Signal aus OpenAIRE refereed erhoben und die Evidenz-Stufe „gewertet"/„Kontext" abgeleitet wird; DOAJ nur Gold-OA-Zusatzsignal, nie Ausschluss; UNKNOWN wird nicht als peer-reviewed behauptet; Kurz-Begründung „kein Google Scholar" (keine offizielle API, Scraping/SerpAPI = ToS-/DSGVO-Risiko) mit Verweis auf das Decision-Doc docs/decisions/2026-07-15-google-scholar-openalex-openaire.md. Bestehende §23.7 Cross-Refs → §23.8 renummeriert. Belege: Spike #268 (docs/decisions/2026-06-18-detail-ux-data-validation-spike.md: OpenAIRE 97,4 % peerReviewed / 0 % UNKNOWN), scripts/derive-evidence-grade.ts, schemas/source.zod.ts (EvidenceGradeSchema = counts | context). Drift-Annotation: Keine Schema-/Prompt-Drift; rein doku-additiv (ein Sub-Kapitel innerhalb §23); Version bleibt 2.2 — additive §23.7-Prosa rechtfertigt keinen Footer-Bump, layout.tsx-Footer Methodik v2.2 ist out-of-scope dieses docs-only-Agents (File-Lock auf docs/), F-107-Drift-Sentinel bleibt grün.
• Update zu §21.10 (2026-06-21, deep-1 main-2026-06-21-deep-1, #269-Fix + #259-Modul; KEIN Version-Bump — Footer-Sync bleibt Dashboard-/SSOT-Sync-Session, F-107) — §21.10 aktualisiert: (a) #269-Fix-Absatz auf korrektes Datum 2026-06-21 deep-1 korrigiert (war fälschlich deep-3 2026-06-20); (b) Recall-Regressions-A/B-Gate als PASSED markiert (bakeoff-set-30 EU gemma $0: geo-fill 100 %, final-recall 5,1 % == Baseline, pool-recall 23,1 % == Baseline); (c) GEO_DIVERSITY_V1-Default-Flip als #224-gated (kein quality-Blocker mehr) dokumentiert; (d) Runbook-Cross-Ref auf docs/runbook/source-enrichment-regen.md §5.5 aktualisiert (neuer Abschnitt GEO-on Regen + transient-empty-Guard). Drift-Annotation: Keine Schema-/Prompt-Drift; rein doku-additiv; Version bleibt 2.2 (additive §21.10-Prosa rechtfertigt keinen Footer-Bump).
• v2.2 (2026-06-19, deep main-2026-06-19-1822, Kunden-Features #280–#283) — Add §23 „Quellen-Anreicherung + Cluster-Auswertung" neu (7 Sub-Sektionen): SJR-Quartil + Source-Metriken als Zusatzsignal (#280, SCImago-CSV manuell/jährlich, kein Aufnahme-Gate, ändert Evidenz-Stufe nicht); Source-Provenance als neutrales immutables Herkunfts-Label (#280, orthogonal zur Qualität); Doppel-Bewertung wissenschaftlich-vs-alle als abgeleitete Filter-Sicht (#280, Anti-PSA); Cluster-Themengebiet-Auswertung mit GETRENNTER Quantität/Qualität + kuratiertem cluster-topics.yaml-Pinning gegen den #264-Generalisten-Bias (#282); Quellen-Geo-Übertragbarkeit als GRADE-Indirectness-Dimension (#281, „any-Wien gewinnt", global nie ausgeblendet, IIASA=at); Plain-Language-Management-Summary-Prompt-v2 mit WSF/LIX-WARN (#283, ≤ Schulstufe 10, v1 behalten). Minor-Bump (rein doku-additiv, eine neue Top-Level-Sektion, kein Schema-/Prompt-Pflicht-Change in dieser Methodik-Datei). Cross-Refs: ADR-0002-Amendment A8, ADR-0003-Amendment 2026-06-19 (Seams), ADR-0004-Amendment 2026-06-19 (Sidecars), docs/runbook/source-cluster-enrichment.md, Issues #280–#283. Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md/ai-rating.v1.md/phd-reviewer-pass.v1.md; prompts/management-summary.v2.md ist additiv (v1 bleibt, G5). Footer-String Methodik v2.x in apps/dashboard/app/layout.tsx out-of-scope dieses docs-only-Agents (File-Lock auf docs/) → Bump als Follow-up in der nächsten Dashboard-/SSOT-Sync-Session.
• v2.1 (2026-06-19, deep #279; aktualisiert deep-2 2026-06-20) — Add §21.10 Geo-Diversität der Forschenden (opt-in GEO_DIVERSITY_V1) neu. Eine additive Sub-Sektion: opt-in-Lockerung des Gate-3-Frische-Filters (jemals-Wien-affiliierte, inzwischen ausländische Forschende → füllt at/eu/global-Buckets via unveränderte deriveGeoBucket), Anzeige der aktuellen Nicht-Wien-Institution, harte Abhängigkeit GEO_DIVERSITY_V1 ⇒ RETRIEVAL_V2=1 (echter Rerank-Pfad, #264-Bias-Schutz), Default OFF = byte-identisch, plus das Recall-Regressions-Gate (bakeoff-set-30: final-recall darf nicht fallen, pool-recall ≤ 2 pp, Geo-Fill ≥ 60 % Fragen, Median Nicht-Wien/Frage ≥ 1). Minor-Bump (rein doku-additiv, ein neues Sub-Kapitel innerhalb §21, kein Schema-/Prompt-Change). Cross-Refs: ADR-0003-Amendment (2026-06-19, Seam-/Anti-PSA-Begründung), docs/runbook/forschende-full-run.md §5.7 (Lauf-Befehle), Issue #279. Drift-Annotation: Keine erwartete Drift mit prompts/synthesis.v1.md, prompts/ai-rating.v1.md, prompts/phd-reviewer-pass.v1.md, prompts/forschende-*.v1.md oder Schemas. Footer-String Methodik v2.0 in apps/dashboard/app/layout.tsx bleibt out-of-scope dieses docs-only-Wave-Agents — Bump auf v2.1 als Follow-up in nächster Dashboard-/SSOT-Sync-Session. Update (deep-2 2026-06-20): §21.10-#279-Fix-Absatz aktualisiert: pool-decoupling-Fix beschrieben, Recall-Regressions-A/B-Ergebnis (PASSED: final-recall 5,1 % = Baseline, geo-fill 96,7 %, Wien 975 = 975) eingetragen, neuer Default-Flip-Blocker #269 (works_count-Rauschen in Geo-Buckets) dokumentiert. deriveCurrentInstitutionDisplay-Korrektur für geo=wien-Forscher (country_code aus angezeigter Inst).
• 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).