undoom.news

Gute Geschichten aus aller Welt, als Tagesausgaben in zehn Sprachen. Für die Leser eine Karte, dahinter ein Redaktionssystem mit KI für Recherche, Schreiben und Übersetzung.

Ein anderer Blick auf die Nachrichten

undoom.news versammelt Geschichten über Menschen, Wissenschaft, Natur und konstruktive Veränderungen. Es ist ein privates, nicht kommerzielles Projekt: Entwicklungen, die im täglichen Nachrichtenstrom leicht untergehen, bekommen einen eigenen Platz. Der Relaunch hat sowohl die Leseransicht als auch das System zur Vorbereitung der Ausgaben neu aufgebaut.

Die Startseite gibt einer Geschichte Raum und markiert ihren Ort mit einem Lichtpunkt auf der Karte. Leser können zwischen Geschichten wechseln, die Karte erkunden oder einen Artikel öffnen. Der dunkle Hintergrund bleibt in der Artikelansicht erhalten. Quellen sind verlinkt, und die Inhalte lassen sich in zehn Sprachen lesen, darunter Arabisch, Persisch und Hebräisch mit Schreibrichtung von rechts nach links.

Aufmerksamkeit für konkrete Veränderungen

Die Idee hinter undoom ist, den Blick auf die Welt zu erweitern. Neben Berichten über Konflikte und Krisen gibt es Menschen, die Probleme lösen, Wissen zugänglich machen oder Lebensbedingungen verbessern. Solche Entwicklungen verdienen Aufmerksamkeit aus ihrem eigenen Inhalt heraus. Eine Geschichte soll konkret zeigen, was sich verändert hat, für wen das etwas bedeutet und worauf die Darstellung beruht. Eine gute Absicht allein ist noch kein nachgewiesener Erfolg.

Die Karte gehört zu diesem Gedanken: Jede Geschichte hat einen Ort. Sie macht sichtbar, dass bemerkenswerte Entwicklungen aus unterschiedlichen Weltregionen kommen. Die begrenzte Tagesausgabe und die ruhige Darstellung geben einzelnen Geschichten Raum. Die zehn Sprachfassungen machen dieselbe Auswahl für unterschiedliche Leser zugänglich.

KI macht es möglich, diese Arbeit als Einmann-Redaktion zu organisieren. Sie unterstützt die Sichtung von Quellenmaterial, das Schreiben, die Prüfung und die Übersetzung. Welche Texte ich freigebe und zu einer Ausgabe zusammenstelle, bleibt eine redaktionelle Entscheidung. Der Maßstab ist, ob eine Geschichte nachvollziehbar und lesenswert ist.

Quellenbindung statt erfundener Tatsachen

Der redaktionelle Grundsatz ist eindeutig: Es soll nichts veröffentlicht werden, was die KI als Tatsache frei erfunden hat. Ein flüssig geschriebener Text ist kein Beleg. Aussagen müssen sich auf nachvollziehbares Quellenmaterial zurückführen lassen; was darin nicht gestützt wird, muss geklärt, korrigiert oder weggelassen werden.

Dafür trennt das System Schreiben und Quellenprüfung in eigene Schritte. Die Prüfung vergleicht Aussagen der konkreten Artikelfassung mit dem gespeicherten Quellenmaterial und ordnet sie als gestützt, unbelegt, widersprochen oder nicht beurteilbar ein. Sie führt Quellenstellen zu den bewerteten Aussagen auf. Zusätzlich kontrolliert der Code, ob angegebene Belegzitate tatsächlich in den gespeicherten Originalpassagen vorkommen. Ein Modell kann damit nicht einfach eine erfundene Fundstelle als gültigen Beleg einschleusen.

Prüfergebnis und redaktionelle Freigabe bleiben getrennt dokumentiert. Eine positive automatische Prüfung veröffentlicht noch keinen Artikel. Die Freigabe gilt für eine bestimmte Fassung und wird bei Textänderungen nicht stillschweigend übernommen. Das System erlaubt auch eine ausdrückliche manuelle Annahme durch die Redaktion; diese wird als redaktionelle Entscheidung gespeichert, nicht als bestandener automatischer Faktencheck.

Dieser Abgleich prüft die Treue zum Quellenmaterial. Er beweist nicht unabhängig, dass bereits die ursprüngliche Berichterstattung in jedem Punkt richtig ist, und auch die KI-Prüfung kann etwas übersehen. Quellenlinks und gespeicherte Prüfbefunde machen die Grundlage der Texte nachvollziehbar. Der Anspruch bleibt, unbelegte Behauptungen vor der Veröffentlichung zu entfernen.

Ein Arbeitsablauf für eine Einmann-Redaktion

Die Redaktion trennt Entwürfe, Editionsplanung und Produktionsstatus. Entwürfe stehen in einem durchsuchbaren Kartenraster. Ich kann einen Text öffnen, Quellen und Prüfhinweise durchsehen, ihn bearbeiten und ein Bild auswählen, bevor ich ihn freigebe. Automatische Quellenprüfung und redaktionelle Freigabe werden getrennt festgehalten.

Freigegebene Artikel gelangen in den Planungsvorrat und werden per Ziehen in den Kalender oder über die Datumswahl einem Tag zugeordnet. Jeder Tag ist eine Spalte, sodass die Zusammenstellung der Ausgabe sichtbar bleibt. Der Produktionsstatus zeigt den Fortschritt von Erstellung und Übersetzung, ohne die Planung mit technischen Einzelheiten zu füllen.

Auf Deutsch veröffentlichen, danach übersetzen

Artikel entstehen zunächst auf Deutsch. Erst nach Veröffentlichung der deutschen Ausgabe reiht das System die anderen neun Sprachen ein. Damit werden keine Entwürfe übersetzt, die anschließend geändert oder verworfen werden. Zur Übersetzung gehören eine automatische Prüfung und bei Bedarf ein gezielter Korrekturdurchlauf. Verbleibende Sprachbefunde verlangen von mir keine Freigabe einer Sprache, die ich nicht beurteilen kann.

Veröffentlichung und Erstellung haben getrennte Zeitpläne. Der Server veröffentlicht eine freigegebene, eingeplante Ausgabe morgens um neun Uhr Oslo-Zeit. Der Produktionslauf am Mittag ergänzt den Entwurfsvorrat. Übersetzungen und neue KI-Arbeit warten, wenn der Mac offline ist; die Website und die geplante deutsche Veröffentlichung laufen weiter.

Produktion und Auslieferung trennen

React und TypeScript bilden die Leser- und Redaktionsoberflächen. PHP übernimmt Webzugänge und öffentliche Auslieferung, Python koordiniert die redaktionelle Verarbeitung. PostgreSQL speichert Arbeitsdaten und veröffentlichte Fassungen. Ein Worker auf meinem Mac fragt den Server nach KI-Aufträgen und meldet Ergebnisse zurück. Der Server benötigt weder eine eingehende Verbindung zum Laptop noch dessen Abo-Zugangsdaten.

Bei der Veröffentlichung entsteht eine feste Fassung für die Leser. Spätere redaktionelle Änderungen werden ausdrücklich erneut veröffentlicht. Der öffentliche Feed nutzt APCu, um aufbereitete Antworten wiederzuverwenden; Änderungen an Veröffentlichungen, Übersetzungen und Bildern werden dabei geprüft. Ein Seitenabruf ist damit nicht von einer Modellantwort abhängig.

Durch die Nutzung entwickelt

Den Relaunch habe ich iterativ mit Agentic Coding gebaut. PHP, Python und eine modulare Struktur standen früh fest; der genaue Arbeitsablauf entstand beim Benutzen. Eine kleine HTML-Entwicklungsseite verband Architektur, offene Entscheidungen und nächste Schritte.

Als der Ablauf brauchbar war, konsolidierte ich die Umsetzung. Getrennte Daten für Übersicht und Artikeldetails, gebündelte Abfragen und geprüfte Datenbankindizes reduzierten unnötige Arbeit. Erst danach kam Caching hinzu. Diese Änderungen verbesserten die Reaktionszeiten mit dem vorhandenen Bestand; eine bereits nachgewiesene Belastbarkeit bei sehr großen Datenmengen leite ich daraus nicht ab.