Technische Architekturnotiz — Version 1.0

Status Kontrolliertes öffentliches Artefakt
Version 1.0
Veröffentlichungsdatum 2026-02-17
Rechtsordnung Schweiz
Geltungsbereich Demonstrationsgrenze

Problemstellung

Konventionelle Autorisierungssysteme stützen sich auf probabilistische Inferenz, score-basierte Schwellenwerte oder heuristische Klassifizierung zur Erzeugung von Entscheidungen. Diese Ansätze führen Ambiguität am Entscheidungspunkt ein und machen es strukturell unmöglich, deterministische Ergebnisse unter adversarialen oder unvollständigen Bedingungen zu garantieren. Die in diesem Dokument beschriebene Architektur verfolgt einen Indeterminacy-first-Ansatz: Das System ist darauf ausgelegt, für jede Eingabe eine formal begrenzte Entscheidung zu erzeugen — einschliesslich eines expliziten INDETERMINATE-Zustands. Dies eliminiert die Fehlerklasse, die aus erzwungener binärer Resolution entsteht, und stellt sicher, dass jede Entscheidung nachvollziehbar, wiederholbar und evidenzgebunden ist. Die Architektur leitet keine Absichten ab, prognostiziert keine Ergebnisse und interpoliert keine fehlende Evidenz. Sie evaluiert ausschliesslich das, was präsentiert wird, innerhalb formal deklarierter Grenzen.

Formale Invarianten

Die folgenden fünf Invarianten sind architektonische Constraints, die auf jeder Schicht des Systems durchgesetzt werden. Sie sind nicht konfigurierbar, nicht optional und nicht durch Laufzeit-Overrides änderbar.

1. Keine probabilistische Inferenz

  • Definition: Das System verwendet weder maschinelles Lernen, statistisches Scoring, Bayessche Inferenz noch irgendeine Form probabilistischer Schlussfolgerung in seinem Entscheidungspfad.
  • Garantie: Jede Entscheidung wird durch deterministische Evaluierung explizit deklarierter Richtlinienregeln gegen präsentierte Evidenz erzeugt.
  • Grenze: Externe Systeme, die Daten in die Plattform einspeisen, können probabilistische Methoden verwenden; diese Invariante gilt ausschliesslich für den Entscheidungsevaluierungspfad.

2. Evidenzgebundene Extraktion

  • Definition: Keine Entscheidung kann ohne einen vollständigen Evidenzdatensatz erzeugt werden. Das System erfindet, nimmt nicht an oder setzt keine fehlenden Evidenzfelder voraus.
  • Garantie: Jede Entscheidungsausgabe wird von einem kryptografisch verknüpften Evidenzsatz begleitet, der zum Zeitpunkt der Evaluierung vorhanden war.
  • Grenze: Die Evidenzvollständigkeit wird durch das Richtlinienschema definiert. Das System validiert nicht die Wahrhaftigkeit der Evidenz — nur deren strukturelle Präsenz und Formatkonformität.

3. Deterministische Wiederholbarkeit

  • Definition: Bei gleicher Richtlinienversion und gleichem Evidenzsatz muss das System bei jeder Ausführung die identische Entscheidungsausgabe erzeugen.
  • Garantie: Die Wiederholung von Entscheidungen ist eine erstklassige Audit-Fähigkeit. Jede historische Entscheidung kann mit ihren ursprünglichen Eingaben erneut evaluiert werden, um die Konsistenz zu verifizieren.
  • Grenze: Die Wiederholbarkeit setzt unveränderliche Richtlinienversionierung voraus. Wenn eine Richtlinienversion direkt mutiert wird (ein Verstoss gegen das operative Protokoll), gelten die Wiederholbarkeitsgarantien nicht.

4. Nicht-selbstausführende Architektur

  • Definition: Das System erzeugt Entscheidungen, setzt sie jedoch nicht durch. Es hat keine Fähigkeit, Aktionen auszuführen, externe Systeme zu modifizieren oder nachgelagerte Effekte autonom auszulösen.
  • Garantie: Die Entscheidungsausgabe ist ein beratendes Artefakt. Die Durchsetzung wird stets an das aufrufende System delegiert, das die volle Kontrolle über die Aktionsausführung behält.
  • Grenze: Integrationsmuster können Aktionen basierend auf der Entscheidungsausgabe automatisieren. Eine solche Automatisierung ist extern zur Architektur und ausserhalb des Geltungsbereichs dieser Invariante.

5. Grenze der menschlichen Übersteuerung

  • Definition: Jede vom System erzeugte Entscheidung unterliegt menschlicher Prüfung und Übersteuerung. Die Architektur enthält keinen Pfad, der die menschliche Autorität umgeht.
  • Garantie: Übersteuerungsereignisse werden im selben Append-only-Ledger wie die ursprünglichen Entscheidungen aufgezeichnet, wobei die vollständige Audit-Kette einschliesslich der Identität und Begründung der Übersteuerung erhalten bleibt.
  • Grenze: Die Plattform stellt den Mechanismus für die Aufzeichnung von Übersteuerungen bereit. Organisationsrichtlinien, die regeln, wann Übersteuerungen zulässig sind, liegen ausserhalb des Systemgeltungsbereichs.

Definition der deterministischen Garantie

Eine Entscheidung gilt als deterministisch, wenn und nur wenn alle folgenden Bedingungen erfüllt sind:

  • Die für die Evaluierung verwendete Richtlinienversion ist unveränderlich und zum Zeitpunkt der Anfrage versionsfixiert.
  • Der Evidenzsatz ist gemäss dem Richtlinienschema vollständig, ohne abgeleitete oder voreingestellte Felder.
  • Die Evaluierungsfunktion enthält keine Seiteneffekte, keine externen Aufrufe und keine zufälligen Eingaben.
  • Die Ausgabe ist einer von genau drei Zuständen: ALLOW, DENY oder INDETERMINATE.
  • Das vollständige Eingabe-Ausgabe-Paar wird in einem Append-only-Ledger aufgezeichnet und steht für eine unabhängige Replay-Verifikation zur Verfügung.

Verifikationsstapel

OmegaOS™ ist mit einem mehrschichtigen Verifikationsstapel konzipiert, der darauf ausgelegt ist, logische Defekte, Invariantenverletzungen und unerwartete Zustandsübergänge zu erkennen. Der Verifikationsprozess kombiniert mehrere komplementäre Techniken:

  • Mutation testing — verifiziert, dass Tests injizierte Fehler erkennen.
  • Property-based testing — exploriert grosse randomisierte Eingaberäume.
  • Differential testing — vergleicht unabhängige Implementierungen der Kernlogik.
  • Coverage-guided fuzzing — unterzieht kritische Komponenten adversarialen Eingaben.
  • Formal verification (Kani) — beweist algebraische und logische Eigenschaften des Trilean-Kernels.
  • Model checking (TLA+) — validiert Systeminvarianten und Zustandsübergänge.

Verifikationsmetriken

600+

Mutationstests

0

überlebende Produktionsmutanten

13M+

Fuzz-Ausführungen

100K+

Property-based-Fälle

13

formale Beweise (Kani)

3M+

modellgeprüfte Zustände (TLA+)

700+

deterministische Testfälle

code → tests → mutation testing → fuzzing → formal proofs → model checking

Diese Techniken verifizieren die nicht-SOVEREIGN-Komponenten des Systems. Die verbleibenden SOVEREIGN-Module werden offline implementiert und mit derselben Pipeline verifiziert, sobald sie fertiggestellt sind.

Klausel zur Demonstrationsgrenze

Dieses Artefakt beschreibt die Architektur, wie sie in einer kontrollierten Demonstrationsumgebung implementiert ist. Es repräsentiert keine Produktionsbereitstellung, kein zertifiziertes System und keinen kommerziell betriebenen Dienst. Die Demonstrationsumgebung arbeitet mit synthetischen Daten, eingeschränkten Lastbedingungen und begrenztem Mandantenumfang. Es werden keine Aussagen bezüglich Skalierbarkeit, Verfügbarkeit oder regulatorischer Zertifizierung der beschriebenen Architektur gemacht. Organisationen, die dieses System für den operativen Einsatz evaluieren, müssen ihre eigene unabhängige Bewertung der Zweckeignung durchführen.

Integritätsfingerabdruck

Der cryptographic hash-Integritätsfingerabdruck wird zusammen mit dem signierten PDF-Artefakt veröffentlicht. Kontaktieren Sie das Engineering-Team, um die signierte Version unter NDA zu erhalten.

Team kontaktieren

Vollständiges Artefakt anfordern

Erhalten Sie die vollständige technische Architekturnotiz als portables Dokument unter NDA.

PDF anfordern