Wien Forschungsfragen Klima

Der KI-Eignungs-Score je Forschungsfrage wird aus vier Dimensionen gebildet: Datenverfügbarkeit (D1), Aufgabentyp (D2), Methoden-Reife (D3) und Ethik/Recht (D4). Jede Dimension liefert 0 bis 3 Punkte, die Summe (0 bis 12) mappt auf none/low/medium/high. Eine reine Summe reicht aber nicht, weil sie kategorische Sperren verwischen würde. Deshalb gelten zwei harte Override-Caps, die unabhängig von der Summe greifen: D1 = 0 oder D2 = 0 deckelt auf "none". Ohne nutzbare Daten oder ohne übersetzbaren KI-Aufgabentyp ist ein KI-Verfahren schlicht nicht anwendbar, egal wie reif die Methode oder wie unkritisch die Domäne ist. D4 = 0 deckelt auf maximal "medium". Eine Hochrisiko-Domäne (etwa Sozialleistungs-Zuteilung) bleibt vorsichtig eingestuft, selbst bei dichter Datenlage. Eine zweite Sicht, der Positiv-Count (eine Dimension zählt ab Score 2 als positiv), dient nur der Plausibilisierung. Bei Widerspruch gewinnt die Summenregel. Ein dokumentierter Divergenzfall macht das konkret: eine Frage mit den Werten D1=2, D2=1, D3=2, D4=1 ergibt Summe 6 und damit "low". Der Positiv-Count sieht zwei positive Dimensionen (D1 und D3) und würde "medium" nahelegen. Hier gewinnt die Summe, weil zwei Dimensionen mit Wert 1 gemeinsam ein klares Dämpfungs-Signal senden, das die binäre Schwelle der Plausibilisierungs-Sicht nicht abbildet. Solche Grenzfälle nahe einer Phasen-Schwelle werden im Review besonders kritisch geprüft. Der Effekt ist Reproduzierbarkeit: zwei Bewerter mit denselben vier Dimensions-Werten kommen zwingend zum selben Score, und kategorische Ausschlüsse bleiben sichtbar statt in einer Summe unterzugehen.

Das Dashboard exportiert Synthesen als PDF. Statt einen Headless-Browser direkt in die Next.js-Anwendung einzubetten, läuft der Export über einen separaten HTTP-Service (ein Wrapper um eine etablierte Konvertier-Engine). Die Anwendung rendert die Seite zu HTML und schickt diesen per POST an den Service, der das PDF zurückliefert. Der Hauptgrund ist die Service-Grenze. Ein inline eingebetteter Browser zieht ein rund 300 MB grosses Chromium-Binary in die Abhängigkeiten der Anwendung, belastet den Build-Cache und verlangsamt den Cold-Start. Der ausgelagerte Service hält den Anwendungs-Build schlank, bringt gehärtete Defaults (deaktiviertes JavaScript, Cache-Clear je Request, Sandbox, Speicher-Limit) ab Werk mit und ist über das eine Feature hinaus wiederverwendbar. Multi-Seiten-Bündel entstehen über einen nativen Merge-Endpoint, ohne eigene PDF-Bibliothek. Zwei betriebliche Fallstricke sind dokumentiert: Beim Start prüft die Anwendung den Health-Endpoint des Service mit kurzem Timeout. Ist der Service nicht erreichbar, zeigt die Oberfläche einen klaren Hinweis statt eines harten 502-Fehlers. Der Konvertier-Endpoint ist strikt bei der Benennung. Sowohl der Formularfeld-Name als auch der Dateiname der hochgeladenen HTML-Datei müssen exakt "index.html" lauten, sonst antwortet der Service mit HTTP 400. Dieser Fallstrick wurde beim ersten Test mit einem abweichenden Dateinamen real ausgelöst und ist deshalb als Konstante im Client festgeschrieben, abgesichert durch einen Test, der den 400-Fehler bei abweichendem Namen reproduziert. Der Trade-off ist ein laufender Zusatz-Service und ein Netzwerk-Hop, beides vernachlässigbar bei lokalem Betrieb. Als Rückfall-Option bleibt der inline eingebettete Browser dokumentiert, falls die Service-Anbindung in einer Umgebung mehr Aufwand als Nutzen bringt.

Als der Review-Prozess mit mehreren Personen begann, brauchte er eine kleine Datenhaltung für veränderliche Ablauf-Daten: Zugänge der Reviewer, eingereichte Bewertungen, der Verlauf von Status-Änderungen und ein Veto-Fenster vor der automatischen Freigabe. Dafür kam eine schlanke lokale Datenbank zum Einsatz, ausdrücklich nur für diese Ablauf-Daten. Die eigentlichen Inhalte bleiben als versionierte Dateien die verbindliche Quelle. Das frühere Vorgehen, Zugänge über Konfigurationswerte zu verwalten, skalierte für eine Gruppe von fünf bis acht Reviewern nicht mehr.

Die Forschungs-Briefe, Quellen und Fragen werden als einfache Textdateien mit strukturiertem Kopf versioniert abgelegt und nicht in einer Datenbank gehalten. Der Grund ist Nachvollziehbarkeit: Redaktion, Review, Dashboard und Export greifen alle auf dieselbe Quelle zu, und die Versionierung liefert Verlauf, Änderungsvergleich und Freigabe ohne zusätzliche Infrastruktur. Der strukturierte Kopf jeder Datei ist der einzige verbindliche Vertrag zwischen Ablage und allen Konsumenten. Für diese Projektphase ist eine Datenbank für die Inhalte bewusst ausgeschlossen.

Bei einer Stichprobe fielen Quellen mit plausiblem Titel und plausiblen Autoren auf, deren Kennung nicht auflöste, deren Verweis ins Leere zeigte und für die sich keine unabhängigen Belege fanden. Die wahrscheinliche Ursache: Parallel arbeitende KI-Helfer hatten Quellen-Platzhalter erzeugt, ohne dass die Publikation wirklich existiert. Vier davon waren bereits in Briefen für den Kundenversand zitiert. Die Konsequenz war eine vollständige Prüfung aller damals erfassten Quellen sowie eine neue Pflicht: Jede neue Quelle muss gegen eine unabhängige Datenbank abgeglichen werden, sonst wird sie zurückgehalten. Lehre: KI-generierte Quellenangaben müssen verifiziert werden, bevor sie in ein Lieferergebnis gehen.

Für den Walkthrough mit der Kundin wäre ein Login eine Hürde gewesen: Sie sollte die Adresse einfach öffnen können, ohne vorab Zugangsdaten zu erhalten. Das Dashboard blieb deshalb öffentlich lesbar, der Verwaltungsbereich blieb rollenbasiert geschützt. Das Risiko war, dass noch nicht freigegebenes Material dauerhaft in Suchmaschinen landet. Die Lösung war ein Ausschluss aus dem Suchindex auf drei Ebenen: im Seiten-Kopf, in den Antwort-Kopfdaten für reine Datei-Downloads wie CSV und PDF sowie ein bewusstes Zulassen für Suchmaschinen, damit diese die Seite überhaupt abrufen und den Index-Ausschluss sehen können. Ein pauschales Sperren hätte den Ausschluss unsichtbar gemacht und die Adresse trotzdem auffindbar gelassen.

Das Projekt wird intern leicht mit einem Klima-Daten-Dashboard verwechselt. Es ist aber ein Mapping des Forschungsstands je Frage plus KI-Eignungs- Bewertung, abzugrenzen vom bestehenden klimadashboard.at. Dazu kommt eine bewusste Drift zwischen Customer-Sprache und Code: nach außen heißt das Artefakt Forschungs-Brief, im Code bleiben die Identifier auf Synthese (syntheses/, SynthesisCard, synthesis_word_count). Lehre: bei mehrdeutigen Projektnamen die Abgrenzung explizit dokumentieren, und ein späteres Customer-Rename nicht in den Code durchziehen, wenn es nur Churn erzeugt.