Redaktioneller Content-Pipeline-Vertrag v1

Stand: 7. Oktober 2026

Tatsächlicher Veröffentlichungsstand

Der öffentliche Wissensbereich enthält genau zwölf menschlich freigegebene veröffentlichte Beiträge. Aktuell gibt es null unfreigegebene Entwürfe. Die drei zusätzlich freigegebenen Beiträge aus CON-02 behandeln Klimadaten für Grundstücke, die richtige Einordnung einer Brachflächenpotenzialkarte und Hochwasserhinweise für Grundstücke; die erste CON-03-Datenstory ordnet den amtlichen Häuserpreisindex Österreichs im EU-Vergleich ein, die zweite den OeNB-Fundamentalpreisindikator zur geschätzten Über- und Unterbewertung von Wohnimmobilien, die dritte das Radonpotenzial der Gemeinden je Bundesland. Drei Erklärbeiträge behandeln ÖV-Güteklassen, Flächenwidmung in Niederösterreich sowie Erdbebenzone und Hitzetage am Standort.

Der Cofounder hat die drei CON-02-Beiträge am 2026-08-25T19:18:42+02:00 ausdrücklich menschlich freigegeben. Der öffentliche Freigabenachweis belegt die Entscheidung. Die Datenstory hat er am 2026-09-23T11:14:40+02:00 freigegeben; der öffentliche Freigabenachweis belegt diese Entscheidung. Die zweite Datenstory ist seit 2026-09-25T13:11:37+02:00 menschlich freigegeben; der öffentliche Freigabenachweis dokumentiert den Schlussreview. Die dritte Datenstory und die drei Erklärbeiträge sind seit 2026-10-04T21:03:51+02:00 menschlich freigegeben (Freigabenachweis); die Korrektur am Beitrag „Standort-Check richtig einordnen“ seit 2026-10-04T21:04:52+02:00 (Nachweis), die Korrektur am Beitrag „Flächenwidmung in Niederösterreich lesen“ seit 2026-10-04T22:56:55+02:00 (Nachweis), dessen erneute Korrektur (Version 1.2, Oberösterreich) seit 2026-10-08T13:42:00+02:00 (Nachweis). Die Wiedervorlage „Datenstand und Abdeckung richtig lesen“ (Version 1.3) ist seit 2026-10-04T23:40:09+02:00 freigegeben (Nachweis), die Wiedervorlage „Häuserpreise in Österreich im Vergleich zur EU“ (Version 1.1, Preisdaten 2026-Q2) seit 2026-10-06T09:32:54+02:00 (Nachweis). Die einzelnen Beiträge binden Person, Zeitpunkt, Nachweis und finale Artefakte an ihren Reviewvertrag.

Ein technischer Build, ein vollständiger Entwurf oder ein bestandener Audit ist keine redaktionelle Freigabe. Es gibt keine automatische Veröffentlichung. Das Phase-2-Ziel von sechs menschlich freigegebenen veröffentlichten Beiträgen ist erfüllt; künftige Beiträge benötigen denselben menschlichen Schlussreview.

Redaktioneller Ablauf

Themenbrief: Nutzerfrage, Zielgruppe, eindeutige Suchintention, Abgrenzung und passendes Werkzeug festhalten.
Quellenpaket: Primärquellen, Quellenstand, räumliche Abdeckung, Nutzungsrechte, Belegstellen und erlaubte Aussagen sichern.
Entwurf: Inhalte ausschließlich innerhalb des dokumentierten Briefs und Quellenpakets erstellen; KI-Unterstützung kenntlich machen.
Faktenprüfung: materielle Aussagen einzeln gegen die belegte Quelle prüfen; Modelle, Datenlücken und fachliche Grenzen sichtbar erklären.
Menschlicher Schlussreview: verantwortliche Person, Prüfzeitpunkt und Freigabenachweis ausdrücklich dokumentieren.
Artefaktbindung: finalen Text, Themenbrief, Quellenpaket, Bildbytes, sichtbare Metadaten und Reviewerstand an einen SHA-256-Digest binden.
Publish-Gate: nur freigegebene, unveränderte und quellenqualifizierte Beiträge öffentlich ausliefern.
Wiedervorlage: Reviewtermin, Korrekturen und materielle Änderungen der gebundenen Quellen laufend getrennt einordnen.

Digest prüfen und für eine Korrektur neu berechnen

npm run content:review-digest -- <artikel-slug> prüft wie bisher über die validierte Registry. Ein geändertes veröffentlichtes Artefakt blockiert bereits beim Laden mit reviewArtifactChanged.

Für die Vorbereitung eines erneuten menschlichen Reviews gibt es ausdrücklich npm run content:review-digest -- --recompute <artikel-slug> (Issue #691). Dieser CLI-Modus berechnet nur den aktuellen Digest. Er schreibt keine Dateien, ändert weder Registry noch Review-Baseline und erteilt keine Freigabe. Die JSON-Ausgabe enthält mode: "recompute", currentDigest, den weiterhin hinterlegten reviewedDigest, matchesApprovedReview, editorialIssues und publicationIssues. Bei einer Änderung bleiben matchesApprovedReview: false und die Sperre reviewArtifactChanged sichtbar. Weitere Publikationssperren, etwa ein fehlender Freigabenachweis, bleiben ebenfalls in der Ausgabe erhalten.

Exit 0 bestätigt im Rechenmodus nur eine erfolgreiche Berechnung bei strukturell vollständigem Artefakt, keine Publikationsfreigabe. Fehlende Artefaktdateien oder strukturelle Mängel führen zu Exit 1; fehlende oder ungültige Argumente, unbekannte Optionen und unbekannte Slugs zu Exit 2. Der optionale Schalter darf vor oder nach dem einzigen Slug stehen.

Nur dieses CLI verwendet im Rechenmodus die ungeprüften Registry-Daten. Anwendung, Build und Publikationspfade importieren weiterhin den automatisch geprüften Einstiegspunkt lib/content/articles.ts; dort gibt es keinen Schalter und keine Umgebungsvariable zum Abschalten der Freigabeprüfung. Ein neu berechneter Digest darf erst zusammen mit der ausdrücklich belegten menschlichen Freigabe der konkreten Fassung als freigegebener Digest übernommen werden. Anschließend sind Standardprüfung und Content-Audit erneut auszuführen.

Artikelzustände

Zustand	Redaktionelle Bedeutung
`approved`	menschlich freigegeben; Artefakt und Quellenbindung stimmen
`human_review_required`	vollständiger Entwurf; menschlicher Schlussreview fehlt
`review_due`	geplanter Reviewtermin erreicht
`review_required`	materielle Quellenänderung verlangt erneuten Human-Review
`source_unavailable`	erforderliche Quelle oder qualifizierter Stand nicht belegbar

Eine neue oder erneute Veröffentlichung verlangt approved, ein gültiges, menschlich bestätigtes Artefakt und den Registry-Status published. Fehlende Briefings, Quellenpakete, Bilder, Reviewnachweise, Quellenfreigaben oder ein geänderter SHA-256-Digest blockieren diese Neufreigabe fail-closed. Der Quellenaudit verändert weder ARTICLE_REGISTRY noch bestehende öffentliche Routen. Bereits veröffentlichte Beiträge bleiben bis zu einer ausdrücklichen redaktionellen Entscheidung sichtbar; es gibt keine automatische Depublikation.

Semantischer Quellenfingerprint

Jeder Beitrag ist an seine tatsächlich verwendeten qualifizierten Quellen gebunden. Ein gemeinsamer Quellenwechsel wird auf jeden betroffenen Beitrag gefächert; unabhängige Beiträge bleiben unberührt.

Der deterministische Fingerprint bewertet nur fachlich wirksame Eigenschaften:

Quellenslug, Provider, kanonische URL, sichtbare Bezeichnung und Quellentyp;
Rechte, Lizenzkennung, Lizenz-URL und erforderlichen Quellenhinweis;
Quellenstand, Distribution, freigegebene Capabilities und Aktivierungskanal;
Coverage-Status, abgedeckte Regionen und dokumentierte Datenlücken;
Qualitätsstatus, erforderliche Prüfungen und relevante Warnungen.

Release-UUID, Pointer-Version, Event-ID, operative Zeitstempel, Abrufzeiten, Manifest-Hashes, Zeilenzahl und technische Freshness-Fristen gehören nicht zu diesem semantischen Fingerprint. Ein bloßer Pointer-Wechsel ist deshalb nicht automatisch eine redaktionell materielle Änderung.

Beobachtung	Bedeutung	Redaktionelle Folge
`unchanged`	Pointer und fachliche Quellenaussage bleiben unverändert	Freigabe unverändert
`source_refreshed`	neuer Pointer; derselbe fachliche Quellenfingerprint	Freigabe bleibt gültig; kein unnötiges Re-Review
`material_change`	fachliche Quellenaussage oder Rechte ändern sich	betroffene Beiträge benötigen neuen Human-Review
`source_unavailable`	erforderliche qualifizierte Quelle nicht nachweisbar	Neufreigabe blockiert; redaktionelle Entscheidung

Insbesondere werden veränderte Coverage, neue bekannte Lücken, abweichende Lizenzen, ein neuer fachlicher Quellenstand oder verschlechterte Qualität allen betroffenen Beiträgen als redaktioneller Handlungsbedarf zugeordnet. Fehlt eine Quelle vollständig, bleibt die Neufreigabe blockiert; bereits veröffentlichte Beiträge werden nicht automatisch depubliziert.

Preview-, Indexierungs- und Produktionsgrenze

Aktuell existieren keine unfreigegebenen Entwürfe. Künftige unfreigegebene Entwürfe werden ausschließlich in einer expliziten, geschützten Preview- oder Entwicklungsumgebung bereitgestellt. Production, Tests und unbekannte Umgebungen schalten solche Entwürfe nie frei. Nicht generierte Draft-Routen bleiben wegen dynamicParams = false geschlossen.

Für Preview-Seiten gilt:

noindex, nofollow, nocache;
keine Canonical und kein BlogPosting-JSON-LD;
keine Entwürfe in öffentlichen Produktionsrouten, Wissensindex oder Homepage;
keine Entwürfe in Sitemap, RSS-Feed oder llms.txt;
keine öffentlichen Links auf unveröffentlichte Entwurfsrouten.

Diese Grenzen gelten auch bei vollständigem Text, vollständigem Quellenpaket und technisch bestandenem Build. Das erfüllte Sechs-Live-Beiträge-Gate zählt ausschließlich tatsächlich menschlich freigegebene Veröffentlichungen, niemals geschützte Previews.

Audit und Prüfung vor dem Merge

npm run content:audit
npm run content:audit -- --live

npm run content:audit überprüft standardmäßig deterministisch und offline Artikelregistry, redaktionelle Artefakte, menschliche Freigaben, Quellenbindungen, Preview-Grenzen und Re-Review-Übergänge. Derselbe Befehl ist Bestandteil von npm run check:local (Job verify, Schritt CON-02) und steht unverändert in ci.yml; die GitHub-CI ist seit 05.10.2026 absichtlich aus, vor dem Merge gilt der lokale Lauf.

Der optionale Modus npm run content:audit -- --live ergänzt ausschließlich lesende GET-Abfragen des öffentlichen Provenienzvertrags. Weder der lokale Audit noch der Live-Readback darf publizieren, depublizieren, Active Pointer verändern, Quellen aktivieren oder Daten schreiben.

Korrekturen, Datenschutz und Abgrenzung

Der einzige öffentliche Korrekturweg ist der vorhandene Kontakt im Impressum. Eine neue Korrektur-API, ein Formular mit zusätzlicher personenbezogener Speicherung oder eine automatische Veröffentlichung existieren nicht.

Die Content-Pipeline führt keine zusätzliche personenbezogene Persistenz, keine neue API und keinen neuen Veröffentlichungskanal ein. Rechte-, Coverage- und Produktgrenzen bleiben unverändert; ein Wissensbeitrag eröffnet weder Katasterexporte noch Hochwasser-WMS-Fallbacks oder gesperrte NÖGIS-Rechte.

Weitere Einordnung: Wissensbereich und menschliche Redaktion, Produktstatus und Datenschutz & Compliance.