OmegaOS™ Kernel
Deterministischer, auditierbarer Entscheidungskernel.
Gibt Wahr / Falsch / Unbestimmt aus — wobei Unbestimmt (I) der native Status bleibt, bis Beweis- und Governance-Schwellenwerte eine Schlussfolgerung zulassen.
Eine neue Kategorie
Wir liefern nicht einfach nur ein weiteres Tool aus. Wir definieren eine Kategorie: eine steuerbare Entscheidungsinfrastruktur, bei der Unsicherheit ein korrektes Ergebnis ist, kein Defekt.
Das Problem
In kritischen Systemen führen erzwungene binäre Entscheidungen (Ja/Nein) zu Fehlern, rechtlichen Risiken und anfälligen Audits. Intransparente KI-Scores und Black-Box-Modelle verschlimmern dies — Entscheidungen werden schwer zu rechtfertigen, zu reproduzieren oder anzufechten.
Der Wandel
Unbestimmt (I) ist die Ausgangsbasis. Wahr und Falsch lassen sich nicht willkürlich erzeugen — sie werden nur abgeleitet, wenn Beweisschwellen und Governance-Regeln erfüllt sind.
Das Ergebnis
Jede Entscheidung ist steuerbar: Wer entscheidet, wann und auf Basis welcher Beweise. Jede Argumentationskette ist reproduzierbar. Unsicherheit tritt als stabiler, auditierbarer Zustand auf — nicht als stilles Versagen.
Drei Zustände
Binäre Systeme zwingen jede Entscheidung in Gewähren oder Verweigern. Sind Beweise widersprüchlich oder fehlen, raten sie. OmegaOS™ Kernel rät nicht.
Gewähren
Unterstützende Beweise ausgewertet. Richtlinienbedingungen erfüllt. Die Entscheidung, die Beweiskette und die Richtlinienversion werden im nur-anhängenden Ledger aufgezeichnet.
Unbestimmt
Beweise sind widersprüchlich oder unzureichend. Die Engine setzt das Urteil aus. Kein voreiliges Verdikt. Der Konflikt wird zur menschlichen Überprüfung offengelegt, beide Beweisketten sind im Anhang.
Verweigern
Widerlegende Beweise ausgewertet. Richtlinienbedingungen nicht erfüllt. Die Verweigerung bietet dieselbe Beweistiefe wie ein Gewähren — jede Ablehnung ist gleichermaßen nachvollziehbar.
| Aktive Beweise | Lösung | Konflikt | HTTP |
|---|---|---|---|
| Nur unterstützend (V) | Gewähren | Nein | 200 |
| Nur widerlegend (F) | Verweigern | Nein | 200 |
| Beides V + F | Unbestimmt | Ja | 409 |
| Keine | Unbestimmt | Nein | 200 |
409 Conflict. Wenn eine Betrugs-Engine rät, zu blockieren, und eine KYC-Prüfung zustimmt, entscheiden sich binäre Systeme still und leise für einen Gewinner. OmegaOS™ Kernel gibt 409 mit beiden Beweisketten zurück — der Widerspruch ist sichtbar, nachvollziehbar und auditierbar.
Beweisarchitektur
- Unveränderliche Auflösungsszenarien mit kryptografischen Beweisen.
- Deterministische W/F/I-Ergebnisse, verknüpft mit spezifischen Richtlinienversionen.
- Offline-Verifikation durch verifizierbare JSONL-Snippets.
Deterministisch im Großbetrieb
Während eines Lidschlags löst OmegaOS 882.000 Entscheidungen mit vollständigen Beweisketten.
Architektur
Zwei Rust-Dienste. Ein Postgres-Ledger. Optionales Upstream-PDP.
Beweisfluss
Eine Anfrage erreicht das Gateway. Das Gateway sammelt Beweise aus Ihrem PDP, bewertet sie in einer Dreizustands-Lösung und schreibt die Entscheidung mit ihrer vollständigen Beweiskette in den Ledger. Die Antwort enthält die Entscheidung, die Beweiserweise und die Ledger-Eintrags-ID.
Laufzeitdienste arbeiten ausschließlich mit INSERT-Rechten. Keine UPDATEs. Keine DELETEs. Der Audit-Trail ist auf Anwendungsebene strukturell unveränderlich.
Evidence Pack
Das Compliance-Artefakt. Exportieren, offline verifizieren, jedem Prüfer präsentieren.
SHA-256 Manifest
Der Exporter berechnet SHA-256 in Echtzeit für jede JSONL-Datei. Das Manifest erfasst Hashes pro Datei, Zeilenanzahl, Mandanten-ID, Zeitraum und Build-Fingerabdruck. Jede Änderung macht den Hash ungültig.
Ed25519 Bescheinigung
Wenn Signaturschlüssel bereitgestellt werden, werden Lizenzen und Build-Attestierungen mit Ed25519 signiert. Der öffentliche Schlüssel wird zur Kompilierungszeit eingebettet. Die Verifizierung erfordert kein Netzwerk, keinen Lizenzserver, keinen externen Dienst.
Offline-Verifikation
Ein Prüfer kann die Integrität eines Beweispakets überprüfen, ohne Zugriff auf das Produktionssystem zu benötigen. Das Paket ist autark: Datendateien, Integritäts-Hashes und Testierungssignaturen.
Deterministischer Replay
Jede historische Entscheidung erneut ausführen und beweisen, dass sie korrekt ist.
Exakter Replay
Jede vergangene Entscheidung aus ihrem Ledger-Eintrag mit den ursprünglichen Beweisen und dem Richtlinien-Snapshot erneut ausführen. Das System gibt ein match_original-Flag zurück: Wahr bestätigt deterministische Konsistenz. Falsch deckt eine Nicht-Determinismus-Anomalie auf.
Kontrafaktisch
Beantworten Sie “Was hätte sich mit Richtlinie B geändert?” ohne die Historie zu ändern. Der kontrafaktische Replay berechnet den Unterschied zwischen Original- und Alternativergebnis für die Was-wäre-wenn-Analyse.
AuditPack
Batch-Replay generiert ein AuditPack mit SHA-256-Verifikations-Hash, direkt exportierbar für die regulatorische Einreichung. Jede Aussage im Pack verweist auf einen Ledger-Eintrag. Formate: JSON, Markdown.
Mehrsprachige Erklärungsengine
Jede Entscheidung in FR/DE/IT/EN erklärt — kein LLM, kein generierter Text.
Deterministische Erklärungen verfolgen jedes Kriterium einer Entscheidung bis zum exakten Beweisfeld zurück: Quelle, Wert, Schwellenwert und Zeitstempel. Jede Aussage ist ein template-gerendeter Fakt — kein generierter Text. Kein LLM. Die Ausgaben sind reproduzierbar und auf Anforderung auditierbar.
Unbestimmte Entscheidungen füllen automatisch ein action_required-Feld und einen escalation_reason aus und leiten den Fall mit sprachgerechter Anleitung an die menschliche Überprüfung weiter. Erfüllt EU AI Act Art. 13 (Transparenz) und DSGVO Art. 22 (Recht auf Erklärung).
Merkle-Beweiskette
Manipulationssicherer Ledger mit gerichtsadmissiblen Zeitstempeln.
RFC 9162 Merkle-Baum
Jede Entscheidung wird in einen Append-only-Merkle-Baum eingefügt, bei dem jede nachträgliche Änderung den Root-Hash bricht — Manipulation ist sofort durch Dritte erkennbar.
Inklusionsbeweis
Generieren Sie einen Inklusionsbeweis für jede historische Entscheidung: verifizierbar in O(log n) Operationen, ohne andere Entscheidungen preiszugeben, ohne der OmegaOS™-Infrastruktur zu vertrauen.
RFC 3161 Zeitstempel
Merkle-Roots werden periodisch bei einer qualifizierten Zeitstempel-Behörde (RFC 3161, konform mit ZertES und eIDAS) verankert und liefern rechtlich bindende Beweise für den Entscheidungszeitpunkt, die vor Schweizer und EU-Gerichten zulässig sind.
Multi-Regulierungs-Engine
Eine Entscheidung. Acht regulatorische Frameworks. Individueller Compliance-Beweis pro Verordnung.
Regulierungsübergreifendes Overlay
Jede Entscheidung wird gleichzeitig gegen alle anwendbaren Verordnungen bewertet. 27 Artikel über 8 Frameworks: EU AI Act, LPD/nDSG, DORA, MiFID II, FINMA, DSGVO, SOX, Basel III. Jede Verordnung erzeugt ihre eigene Compliance-Kette.
Compliance-Matrix
Compliance-Matrix pro Tenant mit Framework-x-Artikel-Status auf einen Blick. Presets für gängige Profile: swiss_bank_complete (20 Richtlinien), eu_fintech_complete (18 Richtlinien). Echtzeit-Lückenanalyse.
Regulatorischer Stresstest
Simulieren Sie bevorstehende Verordnungsänderungen und messen Sie die Auswirkungen auf bestehende Entscheidungen. Was-wäre-wenn-Analyse für Durchsetzungstermine. Quantifizieren Sie Compliance-Lücken, bevor sie zu Verstössen werden.
AI Bill of Materials
SPDX 3.0 AI Profile. Vollständige Transparenz über jede Komponente hinter jeder Entscheidung.
BOM pro Entscheidung
Jede Entscheidung ist mit ihrer vollständigen KI-Komponentenkette verknüpft: verwendete Modelle, Beweisquellen, Richtlinienversionen, Hash-Integritätsprüfung. Exportierbar als SPDX 3.0 JSON-LD, JSON kompakt oder Markdown.
System-Level BOM
Vollständiges KI-System-Inventar: alle Komponenten, Beziehungen, Datenherkunft und Trainingsprovenienz. Erfüllt die Transparenzverpflichtungen des EU AI Acts für Modelldokumentation und Komponenten-Nachvollziehbarkeit.
Integritätsprüfung
Jedes BOM trägt einen kryptografischen Integritäts-Hash. Verifizieren Sie, dass keine Komponente seit der BOM-Erstellung verändert, hinzugefügt oder entfernt wurde. Manipulationssicher durch Konstruktion.
Art. 73 Vorfallmeldung
Automatisierte Erkennung, Klassifizierung und Behördenbenachrichtigung schwerer Vorfälle.
Schweregrad-Klassifizierung
Vorfälle werden automatisch nach Schweregrad klassifiziert mit berechneten Fristen: 2 Tage (kritisch), 10 Tage (hoch), 15 Tage (Standard). Countdown-Verfolgung mit Überfälligkeits-Alarmen stellt sicher, dass keine Frist verpasst wird.
Berichterstellung
Automatisierte Erstellung von Erst- und Vollberichten gemäss den Anforderungen von Art. 73. Verknüpft mit den Entscheidungen und Drift-Alarmen, die den Vorfall ausgelöst haben. Jeder Bericht verweist auf Ledger-Einträge.
Behördenbenachrichtigung
Strukturierte Benachrichtigungs-Pipeline an nationale zuständige Behörden. Zeitplanverfolgung von der Erkennung über den Erstbericht bis zum Vollbericht. Vollständiger Audit-Trail aller Kommunikationen.
Öffentliches Verifikationsportal
Zero-Knowledge-Entscheidungsverifikation für externe Prüfer und Regulierungsbehörden.
Externe Parteien — Regulierungsbehörden, Prüfer, Gegenparteien — können verifizieren, dass eine bestimmte Entscheidung getroffen wurde, wann sie getroffen wurde und dass sie nicht manipuliert wurde. Sie benötigen keinen Zugang zu Ihren Systemen.
Die Verifikation verwendet eindeutige Token, die an Merkle-Inklusionsbeweise gebunden sind. Der Verifizierer bestätigt, dass die Entscheidung im Append-only-Ledger existiert, ohne andere Entscheidungen, interne Richtlinien oder Beweisdetails zu sehen. Kryptografischer Beweis, nicht Vertrauen.
Unveränderlicher Ledger
Jede Entscheidung, jeder Beweis und Widerruf wird aufgezeichnet. Der Ledger wächst nur.
Append-Only
Datenbankrollen zur Laufzeit haben nur INSERT-Rechte. Kein UPDATE, kein DELETE. Der Audit-Trail kann nicht aus der Anwendung heraus manipuliert werden.
Row-Level Security
Jeder Tenant arbeitet innerhalb einer Postgres-RLS-Grenze. Tenant A kann die Daten von Tenant B nicht lesen, referenzieren oder abfragen. Isolation wird auf Datenbankebene sichergestellt.
Beweiskette
Jede Entscheidung verweist exakt auf die Beweise, die sie erzeugt haben. Beweise verweisen auf ihre Quellen. Die Kette ist von jedem Punkt rückwärts bis zum ursprünglichen Beweis rekonstruierbar.
Technische Souveränität
Speichersicherer Rust-Code. Reproduzierbare Builds. Auditierbarer Open-Core-Code.
Ausschließliches On-Premise-Deployment. Kein SaaS. Keine Telemetrie. Keine ausgehenden Netzwerkanrufe. Offline-verifizierte Ed25519-Lizenz — kein Lizenzserver.
Für Privatbanken und Family Offices ist rechtliche Souveränität kein Verkaufsargument. Es ist eine regulatorische Voraussetzung.
Anwendungen
Sektoren, in denen Autorisierungsentscheidungen Beweise erfordern, nicht Vertrauen.
Finanzdienstleistungen
Transaktionsfreigabe mit vollständigem Audit-Trail. Widersprüchliche Signale zwischen Betrugserkennung und Compliance werden offengelegt, nicht unterdrückt.
- Evidence-Packs zur Unterstützung von SOC 2 / ISO 27001-Auditprozessen
- Transaktionsbeweisketten
- Konflikterkennung bei AML/KYC-Signalen
Regierung & Verteidigung
Berechtigungsprüfung, bei der jede Zugriffsentscheidung rekonstruierbar sein muss. Der gesamte Beweisweg von der Anfrage bis zum Ergebnis wird bewahrt.
- Zugangskontrolle basierend auf Sicherheitsfreigaben
- Audit-fähige Entscheidungsprotokolle
- Multiquellen-Beweisauswertung
Kritische Infrastrukturen
Zugriff auf operative Technologien, bei denen fehlerhafte Authorisierung physische Konsequenzen hat. Unbestimmter Status verhindert voreiliges Handeln.
- SCADA / OT Access-Governance
- Beweisketten zur Unterstützung von DORA / NIS2-Anforderungen
- Verifikation von Handlungen des Bedieners
API-Schnittstellen
RESTful. JSON. OpenAPI 3.1 Spezifikation.
Core API :3100
| POST | /decisions/resolve | Entscheidung erstellen |
| POST | /decisions/re-resolve | Beweise hinzufügen, neu auflösen |
| GET | /decisions/{id}/why | Vollständiger Audit-Trail |
| GET | /decisions | Auflisten (paginiert) |
| POST | /proofs/revoke | Beweise widerrufen |
| GET | /health | Service-Status |
Gateway :3200
| POST | /gateway/decision | Subjekt/Aktion/Ressource |
| POST | /gateway/http-check | HTTP Methode/Pfad |
| GET | /gateway/health | Modus + Lizenz |
| GET | /gateway/metrics | Prometheus |
Operator Toolbox
Sechs CLI-Tools für Day-Two-Operationen. Tenant-Management, Schlüsselrotation, Audit-Export, Schema-Migrationen, Partitionsverwaltung, Integritätsprüfungen nach Restore.
Alle laufen als hovo_admin. Keine davon wird in Produktions-Images mitgeliefert.
| Tool | Zweck |
|---|---|
| hovo-admin | Tenant CRUD + Key-Rotation |
| hovo-license | Keygen, signieren, verifizieren (offline) |
| hovo-export | JSONL Audit-Export + SHA-256 |
| hovo-migrate | Schema-Migrationen (idempotent) |
| hovo-maint | Partition + Aufbewahrungs-Mgmt |
| hovo-verify | Integritätsprüfung (Post-Restore) |
Häufig gestellte Fragen
Warum drei Werte statt zwei?
Binäre Systeme müssen jede Mehrdeutigkeit in Gewähren oder Verweigern auflösen. Wenn Beweise fehlen oder sich widersprechen, raten sie leise. Eine dreiwertige Logik macht diese Ambiguität explizit und prüfbar — das unbestimmte Ergebnis ist ein korrektes, nachverfolgbares Resultat.
Warum ist "Unbestimmt" der native Status?
Weil das Fehlen von Beweisen kein Beweis für eine Freigabe ist. (I) ist die Norm, bis unterstützende oder ablehnende Beweise den festgelegten Governance-Schwellenwert erreichen. Dies verhindert vorschnelle Urteile in Umgebungen mit hohen Risiken.
Kann ein binäres Resultat erzwungen werden?
Ja. Governance-Schwellenwerte können so konfiguriert werden, dass unbestimmte Ergebnisse einer Standardrichtlinie (ablehnen, eskalieren oder mit Protokollierung zulassen) zugeordnet werden. Diese Wahl ist ausdrücklich und auditierbar — kein stillschweigender Systemstandard.
Ersetzt das unser bestehendes PDP?
Nein. OmegaOS™ fungiert als Overlay. Ihr bestehendes PDP bleibt als Signalquelle oder Fallback erhalten. Sie können schrittweise beobachten, verdecken ("shadow") und durchsetzen — mit vollständigem Rollback in jeder Phase.
Mit einem Guided Pilot deployen
Beobachten, spiegeln, durchsetzen. Ausgelegt für unterbrechungsfreie Umschaltung. Volles Rollback in jedem Schritt.