Ein Cockpit für abgeschlossene Zeitfenster

Wenn für eine Stunde keine Daten vorliegen, zeigt das Mission Cockpit „keine Daten“ statt 0. Der Wert 0 ist nur zulässig, wenn die Quelle tatsächlich gemessen und kein Ereignis gefunden hat. Eine Stunde ohne Ereignisse löst deshalb auch keine Störungsmeldung aus. Das Cockpit verarbeitet ausschließlich abgeschlossene Zeitfenster und bewahrt jeden abgeleiteten Stand als unveränderliches Artefakt. Echtzeitüberwachung und Störungsbearbeitung bleiben getrennte Aufgaben.

Die Anwendung verbindet drei eigenständige Produkte. SubKit führt die wiederholbare Kontrollfolge aus. ContentKit veröffentlicht geschützte Reports. WikiKit archiviert belegbare Befunde, aus denen später kuratiertes Wissen entstehen kann. Keines dieser Produkte wird durch das Cockpit definiert. Sie stellen ihre gewöhnlichen Verträge bereit und wissen nicht, welcher Verbraucher die Antworten später verwendet.

Der Name „Cockpit“ braucht dabei eine klare Grenze. SubKit, ContentKit und WikiKit besitzen jeweils ein eigenes Web-Cockpit für menschliche Arbeit im Produkt. Auch WorkKit, CodeKit und WatchKit haben ihre eigenen Oberflächen. Das Mission Cockpit ist keine davon. Es ist eine private ContentKit-Site, auf der abgeschlossene Berichte für Betrieb, Nutzung und Datenqualität gelesen werden.

Zwei Arten menschlicher Oberfläche

Ein Produkt-Cockpit zeigt den fachlichen Zustand seines Produkts. Im SubKit-Cockpit werden Connectoren, Workflow-Versionen, Ausführungen und anstehende Entscheidungen verwaltet. Das ContentKit-Cockpit macht Inhalte, Revisionen, Vorschauen, Releases und Audit-Ereignisse zugänglich. Im WikiKit-Cockpit werden Quellen, Konzepte und Änderungsvorschläge geprüft.

Diese Oberflächen folgen gemeinsamen Mustern für Zustände und Entscheidungen, aber keiner gemeinsamen Laufzeit und keinem zweiten Datenbestand. Jede Oberfläche verwendet die Regeln, Berechtigungen und Zustände ihres Produkts. Eine Entscheidung im SubKit-Cockpit wird deshalb nicht plötzlich zu einer ContentKit-Freigabe. Ein freigegebener WikiKit-Claim aktiviert keinen öffentlichen Release.

Das Mission Cockpit beantwortet eine andere Frage: Was war in einem abgeschlossenen Zeitraum messbar, welche Eingaben fehlen und welche Abweichung verdient Aufmerksamkeit? Die Antwort entsteht aus den Verträgen der drei Produkte und wird als eigener, geschützter ContentKit-Report veröffentlicht.

flowchart LR
    H["Menschliche Arbeit<br/>in Produkt-Cockpits"] --> S["SubKit<br/>Abläufe und Entscheidungen"]
    H --> C["ContentKit<br/>Inhalte und Releases"]
    H --> W["WikiKit<br/>Quellen und Kuration"]
    S -->|"geschlossener Zeitraum"| A["Unveränderliche<br/>Faktenartefakte"]
    C -->|"Produktstatistik"| S
    W -->|"Produktstatistik"| S
    S -->|"Produktstatistik"| S
    A --> R["Mission Cockpit<br/>geschützte ContentKit-Site"]
    A --> E["WikiKit<br/>Evidence-Modus"]

Der Rückpfeil von SubKit zu sich selbst ist kein Versehen. SubKit ist gleichzeitig ausführendes System und eine der gemessenen Produktquellen. Der Workflow liest seine verdichteten Statistiken über denselben begrenzten Produktvertrag, den auch ein anderer berechtigter Verbraucher verwenden würde. Interne Tabellen bleiben außerhalb des Ablaufs.

Die Produkte besitzen ihre Daten

Der kleine gemeinsame Vertrag verhindert, dass der Reporting-Workflow interne Produktmodelle nachbauen muss. Das Reporting fragt keine fremden PostgreSQL-Tabellen ab und benötigt kein gemeinsames Datenmodell für alle Produkte. SubKit, ContentKit und WikiKit liefern jeweils eine verdichtete, authentifizierte Sicht auf ihr eigenes Zeitfenster. Der Workflow kennt deren Antwortschemata, aber keine Migrationen oder internen Statuswerte.

Der gemeinsame Teil bleibt bewusst klein: Beginn und Ende des Zeitfensters, Herkunft, Vollständigkeit und Datenqualität. Die fachlichen Werte dürfen unterschiedlich bleiben. SubKit berichtet über Workflow- und Connector-Ausführung. ContentKit liefert Veröffentlichungs- und Darstellungsdaten. WikiKit beschreibt Ingests, Reviews und Nutzung seiner Wissensoberflächen.

Diese Abhängigkeitsrichtung schützt Produkte und Reporting-Workflow vor internen Änderungen der jeweils anderen Seite. Ein Produkt kann seine Speicherung ändern, solange sein öffentlicher Vertrag stabil bleibt. Das Mission Cockpit kann neue Auswertungen hinzufügen, ohne dafür eine fachfremde Reporting-Funktion in jedes Produkt einzubauen. Eine weitere Quelle braucht einen eigenen begrenzten Vertrag und einen Connector – keinen Zugriff auf die Datenbanken der vorhandenen Produkte.

Die Produktquelle ist deshalb genau benannt. Der betriebliche Stundenreport sammelt SubKit, ContentKit und WikiKit. ContentKits Darstellung ist keine vierte Quelle. Sie verarbeitet die bereits gebildeten Fakten zu einer Lesefläche.

Eine Stunde wird erst nach ihrem Ende interessant

Das Mission Cockpit ist kein Echtzeitsystem. Es startet standardmäßig einige Minuten nach der vollen Stunde und liest die vorherige, vollständig abgeschlossene UTC-Stunde. Dadurch besitzt jeder Lauf eine feste Unter- und Obergrenze. Ein späterer Wiederholungslauf bezieht sich auf dasselbe Intervall und lässt sich mit dem ursprünglichen Ergebnis vergleichen.

schedule:
  cron: "7 * * * *"
  timezone: UTC
input:
  window: previous_closed_hour
output:
  source_snapshots: 3
  fact_set: 1
  analysis: 1
  manifest: 1

Der Zeitplan ist Konfiguration eines gespeicherten SubKit-Workflows. Connector-Bindings, Wiederholungsgrenzen und die Reihenfolge der Schritte gehören ebenfalls in die versionierte Workflow-Definition. Eine Änderung daran verlangt keine neue SubKit-Engine und kein vollständiges Produkt-Deployment. Sie erzeugt eine prüfbare neue Workflow-Version, die getrennt aktiviert oder zurückgerollt werden kann.

Für Alarmierung wäre diese Taktung zu langsam. Dafür bleiben Observability, Logs und Incident-Prozesse zuständig. Der Report unterstützt Entscheidungen, die von einem vollständigen Zeitraum profitieren:

• Ist der Datenfluss für die letzte Stunde vollständig?
• Welche Abweichung wiederholt sich über mehrere Tage oder Wochen?
• Fehlt eine Quelle, ohne dass der Report daraus einen Nullwert erfindet?
• Welcher frühere Stand belegt, wann sich ein Muster verändert hat?

Die Taktung folgt damit der Frage und nicht dem Wunsch nach möglichst vielen Messpunkten.

Fakten bleiben von ihrer Darstellung getrennt

Jeder Lauf erzeugt getrennte Quell-Snapshots, einen normalisierten Faktensatz, eine Analyse und ein Manifest. Die Objektschlüssel enthalten den SHA-256-Hash ihres Inhalts. Identische Eingaben verwenden bei einer Wiederholung dasselbe unveränderliche Objekt. Geänderte Eingaben erzeugen neue Artefakte. Nur ein kleiner latest-Zeiger darf auf den jüngsten vollständig abgeschlossenen Lauf umgestellt werden.

{
  "schema_version": 1,
  "period": {
    "start": "2026-08-17T05:00:00Z",
    "end": "2026-08-17T06:00:00Z"
  },
  "quality": {
    "partial": true,
    "reasons": ["source_unavailable"]
  },
  "facts": [
    {
      "metric": "workflow_failures",
      "value": 0,
      "unit": "count"
    }
  ]
}

Der Unterschied zwischen value: 0 und source_unavailable ist fachlich entscheidend. Null bedeutet, dass eine Messung stattfand und kein passendes Ereignis beobachtet wurde. Eine fehlende Quelle sagt, dass keine belastbare Aussage möglich ist. Der Report zeigt diese Lücke als Datenqualitätsproblem und rechnet sie nicht stillschweigend in eine Kennzahl ein.

Die unveränderliche Ablage bewahrt außerdem die Trennung zwischen Beobachtung und Interpretation. Ein Snapshot hält die begrenzte Produktantwort fest. Der Faktensatz normalisiert nur vereinbarte Metriken. Die Analyse verweist auf diese Fakten. Das Manifest verbindet die verwendeten Eingaben und Ausgaben über ihre Hashes. Eine spätere Auswertung kann dadurch nachvollziehen, welche Daten eine Aussage getragen haben, ohne den damaligen Bericht umzuschreiben.

Dauerhaft speichern heißt vorher begrenzen

Unveränderlichkeit ist nur dann ein Vorteil, wenn der gespeicherte Inhalt dauerhaft vertretbar ist. Ein versehentlich aufgenommenes Geheimnis lässt sich aus einem append-only Bestand nicht einfach herauskorrigieren. Die Reporting-Strecke begrenzt deshalb schon am Produktvertrag, welche Daten das Quellsystem verlassen dürfen.

In die betrieblichen Statistiken gehören aggregierte Aufrufe, Fehlerraten, Laufzeiten, Mengen und klar begrenzte Qualitätsmerkmale. Prompts, Nachrichten, Dokumentinhalte, Zugangsdaten, IP-Adressen, User Agents und ungefilterte Pfade bleiben außerhalb des Vertrags. Wo eine exakte Akteurs- oder Sitzungszahl gebraucht wird, verwendet das Produkt lokale Pseudonyme, die nicht zwischen Produkten verbunden werden können. Ein Bericht kann damit Aktivität einordnen, aber keine produktübergreifenden Personenprofile bilden.

Die Begrenzung passiert zweimal. Zuerst liefert die Produkt-API nur die freigegebene verdichtete Sicht. Danach übernimmt der Workflow ausschließlich Felder aus einer expliziten Allowlist in Snapshot und Faktensatz. Eine neue Kennzahl erscheint daher nicht zufällig, weil ein Provider seine Antwort erweitert hat. Sie benötigt eine bewusste Änderung am Vertrag, am Schema und an der Workflow-Version.

Das macht auch die Aussagekraft ehrlicher. Technische Aktivität belegt keine Kundengewinnung, und eine veröffentlichte Revision beweist keine Reichweite. Fehlen Analytics-, Finanz- oder Kampagnendaten, weist der Report eine Evidenzlücke aus. Er leitet diese Größen nicht aus Workflow-Aufrufen oder Release-Zahlen ab.

Wiederholungen dürfen keine doppelten Artefakte erzeugen

Ein stündlicher Lauf kann nach einem Transportfehler wiederholt werden. Dabei soll weder ein zweiter Faktensatz mit identischem Inhalt noch ein zweiter abgeschlossener Stand entstehen. Inhaltsadressierte Objekte lösen diese Aufgabe: Gleiche Bytes führen zum gleichen Schlüssel.

Entscheidend ist die Reihenfolge. Quell-Snapshots, Fakten und Analyse werden zuerst geschrieben und geprüft. ContentKit erhält den daraus gebildeten Report über seinen gewöhnlichen Revisions- und Release-Vertrag. WikiKit archiviert die Befunde. Erst wenn diese Schritte erfolgreich abgeschlossen sind, schreibt der Workflow das Manifest und verschiebt zuletzt den latest-Zeiger. Ein sichtbarer aktueller Stand verweist dadurch nie auf einen halbfertigen Lauf.

Eine Wiederholung mit identischem Inhalt verwendet dieselben inhaltsadressierten Objekte und erzeugt keinen neuen abgeschlossenen Stand. Ändert sich eine Eingabe innerhalb desselben begrenzten Zeitfensters, entsteht ein neuer belegter Stand, ohne den vorherigen zu überschreiben. Der Unterschied bleibt im Manifest nachvollziehbar. Idempotenz bedeutet hier nicht, Fehler zu verstecken. Sie verhindert lediglich, dass derselbe fachliche Sachverhalt durch technische Wiederholung mehrfach gezählt oder veröffentlicht wird.

Fünf Zeiträume sind fünf Leserfragen

ContentKit veröffentlicht die menschliche Lesefläche als geschützten, nicht indexierten Report. Reader-Authentifizierung bleibt von Verwaltungszugängen getrennt. Der vollständige Faktensatz wird nicht als endlose Tabelle in die Seite kopiert. Der Report zeigt eine begrenzte Auswahl, während Schlüssel und Hash des maschinenlesbaren Artefakts die vollständige Evidenz auffindbar halten.

Stunde, Tag, Woche, Monat und Jahr sind keine identische Ansicht mit wechselndem Datumsfilter. Sie verdichten unterschiedliche Entscheidungen. Die Stunde prüft den jüngsten Datenfluss. Der Tag unterstützt den nächsten betrieblichen Schritt. Woche und Monat machen Richtung und wiederkehrende Ausnahmen sichtbar. Das Jahr begründet eine längerfristige Schwerpunktentscheidung.

ContentKit erhält dafür semantisches Markdown: Zielgruppe, Frage, These, Handlung, Grenze sowie geeignete Bausteine für Kennzahlen, Hinweise, Tabellen und Diagramme. Aus derselben Semantik entstehen responsive HTML- und statische SVG-Darstellungen. Im Browser ist keine Diagramm-Laufzeit nötig. Die zugrunde liegende Tabelle bleibt lesbar, und die Darstellung erfindet keine Bedeutung, die im Faktensatz fehlt.

Auch hier bleibt die Produktgrenze stabil. SubKit sammelt und ordnet. ContentKit entscheidet über die Veröffentlichungs- und Darstellungslogik. Das Mission Cockpit besitzt keinen eigenen Renderer und keinen zweiten Release-Mechanismus.

Aus einem Befund wird nicht automatisch Wissen

Ein maschineller Report kann eine wiederholte Abweichung zeigen. Er kann nicht allein entscheiden, ob sie dauerhaft wichtig, fachlich gewollt oder bereits geklärt ist. Deshalb gelangen die Reportbefunde in WikiKit zunächst über den Evidence-Modus.

WikiKit archiviert die Quelle, zerlegt sie in zitierbare Abschnitte und macht sie als Beleg auffindbar. Dieser Weg startet keinen LLM-Lauf und erzeugt keinen automatischen Änderungsvorschlag. Ein Mensch kann später eine dauerhafte Aussage aus genau diesen Archivstellen kuratieren. Erst der normale WikiKit-Review entscheidet, ob daraus sichtbares Wissen wird.

sequenceDiagram
    participant S as SubKit
    participant A as Artefaktspeicher
    participant C as ContentKit
    participant W as WikiKit
    participant H as Mensch
    S->>A: Quellen, Fakten und Analyse schreiben
    S->>C: Semantischen Report als Revision übergeben
    C-->>H: Geschützten Report bereitstellen
    S->>W: Befunde im Evidence-Modus archivieren
    S->>A: Manifest schreiben
    S->>A: Latest-Zeiger aktualisieren
    W-->>H: Zitierbare Quellenstellen anbieten
    H->>W: Dauerhafte Aussage mit Belegen kuratieren
    H->>W: Änderung prüfen und freigeben

Diese Grenze verhindert zwei Arten von Scheinwissen. Eine einzelne ungewöhnliche Stunde wird nicht automatisch zur allgemeinen Regel. Und eine plausible Modellerklärung wird nicht ohne Quelle in den dauerhaften Wissensstand übernommen.

Der Ablauf bleibt veränderbar, die Verantwortung nicht

Die Reporting-Strecke darf sich weiterentwickeln, ohne ihre Produkte zu verschmelzen. Neue Metriken werden zuerst Teil eines Produktvertrags. Ein weiterer Bericht bekommt eine eigene Workflow-Version und einen passenden Zeitplan. Neue Lesefragen werden in der ContentKit-Semantik beschrieben. Dauerhafte Erkenntnisse bleiben bei WikiKit und seiner menschlichen Prüfung.

Die Produkt-Cockpits machen diese Grenzen für Menschen bedienbar. Sie ersetzen weder APIs noch Freigaben und Verantwortlichkeiten. Im SubKit-Cockpit bleibt sichtbar, welche Workflow-Version lief und welche Entscheidung wartet. ContentKit zeigt Revision und Release getrennt. WikiKit trennt Quelle, Vorschlag und freigegebenes Konzept. Das Mission Cockpit verbindet diese Zustände nicht zu einer gemeinsamen Wahrheit; es zeigt einen nachprüfbaren Ausschnitt aus einem abgeschlossenen Zeitraum.

Damit bleibt die technische Grenze prüfbar. Wer innerhalb von Minuten reagieren muss, braucht weiterhin Zeitreihen, Logsuche und einen Incident-Prozess. Für abgeschlossene Entscheidungen hält der Entwurf drei Bedingungen fest: Sichtbare Werte stammen aus begrenzten Produktverträgen, fehlende Daten bleiben als Lücke erkennbar, und frühere Berichte lassen sich über ihre unveränderlichen Artefakte erneut prüfen.

Weiterführende Quellen

• Mission Cockpit – Architektur, Verträge und Betrieb
• SubKit – eigenes Web-Cockpit und Produktgrenze
• ContentKit – semantische visuelle Komposition
• WikiKit – kuratiertes Wissen mit Quellen und Review

Wie fandest du diesen Beitrag?

Kommentare