Architekturnotiz

Das Entscheidungsdatensatz-Modell

Eine Entscheidung ist keine wegwerfbare Ausgabe. Sie ist ein strukturierter Datensatz, gebunden an Evidenz, Richtlinie, Provenienz, Lebenszyklus, Überprüfbarkeit, regulatorischen Kontext und Audit-Verpackung.

Diese Seite beschreibt die architektonische Identität eines Entscheidungsdatensatzes. Der operative Geltungsbereich wird pro Deployment verifiziert.

Entscheidungsdatensätze als dauerhafte Objekte

OmegaOS behandelt eine Entscheidung nicht als Log-Eintrag. Jede Entscheidung ist ein Datensatz. Jeder Datensatz bewahrt die Eingaben, die ihn erzeugt haben, die Regeln, die sie evaluiert haben, und den Kontext, in dem die Evaluierung stattfand.

Ein Datensatz bleibt an seinen Evidenzsatz und seine Richtlinienversion gebunden. Er trägt einen Lebenszyklus. Er kann überprüft werden. Er fügt sich zu einer verpackten Audit-Oberfläche zusammen. Diese Eigenschaften sind keine auf eine Entscheidung aufgesetzten Funktionen — sie definieren, was eine Entscheidung in dieser Architektur ist.

Oberflächengrenzen

Attribute des Entscheidungsdatensatzes

Sechs Attribute definieren den Datensatz als Objekt. Jedes Attribut wird im Folgenden auf Modellebene beschrieben. Das operative Verhalten jedes Attributs wird pro Deployment verifiziert.

Zustand

  • Definition: Ein Entscheidungsdatensatz trägt einen Lebenszyklus-Zustand: aktiv, Revalidierung erforderlich, abgelaufen, ersetzt, widerrufen oder ungültig gemacht. Der Zustand wird zur Lesezeit aus dem Verlauf des Datensatzes berechnet. Er wird nicht auf dem Datensatz selbst gespeichert.
  • Was das Modell verlangt: Korrektheit zur Geburt (das Evaluierungsergebnis des Datensatzes) und Konsumierbarkeit zur Lesezeit (der aktuelle Zustand des Datensatzes) sind architektonisch getrennt. Ein bei Erzeugung korrekter Datensatz kann dennoch eine Revalidierung erfordern, wenn sich sein Richtlinien- oder Evidenz-Horizont verschiebt.
  • Pro Deployment verifiziert: Lebenszyklus-Semantik, Revalidierungs-Oberflächen und Lesezeit-Zustandsbehandlung sind für jeden Deployment-Geltungsbereich definiert.

Ursprung

  • Definition: Ein Datensatz bindet an seinen Evidenzsatz, seine Richtlinienversion und den Ausführungskontext, in dem er erzeugt wurde. Evidenz ist inhaltsadressiert; die Richtlinienversion ist zum Evaluierungszeitpunkt gesperrt.
  • Was das Modell verlangt: Evidenz und Richtlinienversion sind unveränderliche Eingaben des Datensatzes. Ein Datensatz kann nicht von den Eingaben getrennt werden, die ihn erzeugt haben.
  • Pro Deployment verifiziert: Die Vollständigkeit der Ursprungs-Metadaten und des exportierten Datensatzkontextes ist für jeden Deployment-Geltungsbereich definiert.

Genealogie

  • Definition: Ein Datensatz verweist auf seine Vorgänger, wenn er ersetzt wird. Die Genealogie verbindet Datensatz-, Evidenz-, Richtlinien- und Ersetzungsknoten.
  • Was das Modell verlangt: Provenienz wird aufgezeichnet, nicht abgeleitet. Jedes Glied der Kette ist unabhängig adressierbar.
  • Pro Deployment verifiziert: Genealogie-Oberflächen, Vorgängerverweise und Rekonstruktionsansichten sind für jeden Deployment-Geltungsbereich definiert.

Anfechtbarkeit

  • Definition: Ein Datensatz bleibt anfechtbar. Sein Evidenzsatz und seine Richtlinienversion werden bewahrt. Seine Genealogie ist auditierbar.
  • Was das Modell verlangt: Das Recht zur Überprüfung und zur Anfechtung eines Datensatzes ist eine Modelleigenschaft. Der Datensatz hört nicht auf, als Grundlage für eine Überprüfung zu dienen, auch wenn sich sein operativer Zustand ändert.
  • Pro Deployment verifiziert: Überprüfungsoberflächen, aufbewahrte Verweise und historische Vergleichsansichten sind für jeden Deployment-Geltungsbereich definiert.

Regulatorischer Horizont

  • Definition: Ein Datensatz trägt seinen regulatorischen Kontext: die evaluierten Rahmenwerke und die referenzierten Verpflichtungen. Wenn aktiviert, können Monitoring- und Vorfall-Oberflächen Datensätze nutzen, um Drift-Überprüfungs- und Vorfall-Klassifizierungs-Workflows zu unterstützen.
  • Was das Modell verlangt: Compliance ist eine zur Laufzeit aus Datensätzen abgeleitete Eigenschaft, keine statische Checkliste. Der Datensatz kennt die Rahmenwerke, unter denen er evaluiert wurde.
  • Pro Deployment verifiziert: Monitoring-Schwellen, Vorfall-Workflows und regulatorische Mappings sind für jeden Deployment-Geltungsbereich definiert.

Beweis-Hülle

  • Definition: Ein Datensatz und seine Evidenz sind inhaltsadressiert. Die Oberfläche des Audit Pack komponiert die Datensatz-, Genealogie-, Erklärungs-, Monitoring-, Compliance- und Vorfall-Sichten.
  • Was das Modell verlangt: Jede Komponente der Hülle ist unabhängig identifizierbar. Das Audit Pack ist die Verpackungs-Oberfläche — es ersetzt keinen der zugrundeliegenden Datensätze.
  • Pro Deployment verifiziert: Export-, Verpackungs- und Integritäts-Oberflächen sind für jeden Deployment-Geltungsbereich definiert. Private Verifikationsmechanismen werden auf dieser Seite nicht beschrieben.

Operativer Geltungsbereich

Das Modell ist eine strukturelle Identität. Der deployment-spezifische operative Geltungsbereich — was implementiert, demonstriert, verifiziert oder privat gehalten wird — wird über die unten stehenden Referenzen beschrieben.

Reality Boundary

Claim-Matrix für implementiert, demonstriert, benchmarked, auditierbar, privat oder nicht öffentlich.

Öffnen

Verify Offline

Verifikationsnotiz für exportierte Artefakte und Offline-Integritätsprüfungen.

Öffnen

Pilot Scope

Begrenzte Deployment-Prüfung mit Voraussetzungen, Lieferobjekten und Abbruchbedingungen.

Öffnen

Technical Artifact

Kanonische Definitionen für OmegaOS, OmegaOS Kernel, Endzustände, Evidenz, Replay und Ledger.

Öffnen

Grenzklausel

Diese Seite beschreibt ein Modell. Sie behauptet nicht, dass jedes Attribut in jedem Deployment operativ vollständig ist.

Deployment-spezifischer operativer Geltungsbereich, exportierte Artefakte, Runbooks, Topologienotizen und Integrationsverfahren sind nicht öffentlich. Sie werden über den Engagement-Pfad behandelt: Pilot Scope, Verify Offline und direkter technischer Kontakt im Review-Kontext.

Team kontaktieren