OmegaOS™ Kernel
Deterministic, auditable decision kernel.
Outputs True / False / Indeterminate — where Indeterminate (I) is the native state until evidence and governance thresholds allow a conclusion.
A New Category
We’re not shipping another tool. We’re defining a category: a governable decision infrastructure where uncertainty is a correct outcome, not a defect.
The Problem
In critical systems, forced binary decisions (yes / no) produce errors, legal risk, and fragile audits. Opaque AI scores and black-box models make it worse — decisions become hard to justify, replay, or contest.
The Shift
Indeterminate (I) is the baseline. True and False cannot be created arbitrarily — they are extracted only when evidence thresholds and governance rules are met.
The Result
Every decision is governable: who decides, when, based on which evidence. Every reasoning chain is replayable. Uncertainty surfaces as a stable, auditable state — not a silent failure.
Three States
Binary systems force every decision into allow or deny. When evidence conflicts or is absent, they guess. OmegaOS™ Kernel does not guess.
Allow
Supporting evidence evaluated. Policy conditions met. The decision, the evidence chain, and the policy version are recorded in the append-only ledger.
Indeterminate
Evidence is contradictory or insufficient. The engine suspends judgment. No premature verdict. The conflict is surfaced for human review with both proof chains attached.
Deny
Refuting evidence evaluated. Policy conditions unmet. The denial carries the same proof depth as an allow — every rejection is equally traceable.
| Active Proofs | Resolution | Conflict | HTTP |
|---|---|---|---|
| Supporting only (V) | Allow | No | 200 |
| Refuting only (F) | Deny | No | 200 |
| Both V + F | Indeterminate | Yes | 409 |
| None | Indeterminate | No | 200 |
409 Conflict. When a fraud engine says block and a KYC check says allow, binary systems pick a winner silently. OmegaOS™ Kernel returns 409 with both proof chains — the contradiction is visible, traceable, auditable.
Proof Architecture
- Immutable resolution scenarios with cryptographic evidence.
- Deterministic T/F/I outcomes linked to specific policy versions.
- Offline verification through verifiable JSONL snippets.
Architecture
Two Rust services. One Postgres ledger. Optional upstream PDP.
Evidence Flow
A request enters the gateway. The gateway collects evidence from your PDP, evaluates it through three-state resolution, and writes the decision with its full proof chain to the ledger. The response includes the decision, the evidence references, and the ledger entry ID.
Runtime services operate with INSERT-only permissions. No UPDATE. No DELETE. The audit trail is structurally immutable at the application layer.
Deterministic at Scale
During one blink, OmegaOS resolves 882,000 decisions with complete proof chains.
Evidence Pack
The compliance artifact. Export it, verify it offline, present it to any auditor.
SHA-256 Manifest
The exporter computes SHA-256 on-the-fly for each JSONL file. The manifest records per-file hashes, line counts, tenant ID, time range, and build fingerprint. Any alteration invalidates the hash.
Ed25519 Attestation
When signing keys are provided, licenses and build attestations are signed with Ed25519. The public key is embedded at compile time. Verification requires no network, no license server, no external service.
Offline Verification
An auditor can verify the integrity of an evidence pack without access to the production system. The pack is self-contained: data files, integrity hashes, and attestation signatures.
Deterministic Replay
Re-execute any historical decision and prove it is correct.
Exact Replay
Re-execute any past decision from its ledger record using the original evidence and policy snapshot. The system returns a match_original flag: True confirms deterministic consistency. False reveals a non-determinism anomaly — itself an audit finding.
Counterfactual
Answer “what would have changed with policy B?” without modifying history. Counterfactual replay computes the diff between original and alternative outcomes, enabling what-if analysis for policy evolution.
AuditPack
Batch replay generates an AuditPack with SHA-256 verification hash, exportable directly for regulatory submission. Every claim in the pack points to a ledger entry. Formats: JSON, Markdown.
Multilingual Explanation Engine
Every decision explained in FR/DE/IT/EN — zero LLM, zero generated text.
Deterministic explanations trace each criterion of a decision to the exact evidence field that produced it: source, value, threshold, and timestamp. Every statement is a template-rendered fact — not generated text. No LLM involved. Outputs are reproducible and auditable on demand.
Indeterminate decisions automatically populate an action_required field and an escalation_reason, routing the case to human review with language-appropriate guidance. Satisfies EU AI Act Art. 13 (transparency) and GDPR Art. 22 (right to explanation).
Merkle Proof Chain
Tamper-evident ledger with court-admissible timestamps.
RFC 9162 Merkle Tree
Each decision is chained into an append-only Merkle tree where any retroactive modification breaks the root hash — making tampering immediately detectable by any third party.
Inclusion Proof
Generate an inclusion proof for any historical decision: verifiable in O(log n) operations, without revealing other decisions, without trusting OmegaOS™ infrastructure.
RFC 3161 Timestamps
Merkle roots are periodically anchored to a qualified Time Stamping Authority (RFC 3161, compliant with ZertES and eIDAS), providing legally-binding proof of decision timing admissible in Swiss and EU courts.
Multi-Regulation Engine
One decision. Eight regulatory frameworks. Individual compliance proof per regulation.
Cross-Regulation Overlay
Every decision is evaluated against all applicable regulations simultaneously. 27 articles across 8 frameworks: EU AI Act, LPD/nDSG, DORA, MiFID II, FINMA, GDPR, SOX, Basel III. Each regulation produces its own compliance chain.
Compliance Matrix
Per-tenant compliance matrix showing framework-by-article status at a glance. Presets for common profiles: swiss_bank_complete (20 policies), eu_fintech_complete (18 policies). Real-time gap analysis.
Regulatory Stress Testing
Simulate upcoming regulation changes and measure impact on existing decisions. What-if analysis for enforcement dates. Quantify compliance gaps before they become violations.
AI Bill of Materials
SPDX 3.0 AI Profile. Full transparency on every component behind every decision.
Per-Decision BOM
Every decision links to its complete AI component chain: models used, evidence sources, policy versions, hash integrity verification. Exportable as SPDX 3.0 JSON-LD, JSON compact, or Markdown.
System-Level BOM
Complete AI system inventory: all components, relationships, data lineage, and training provenance. Satisfies EU AI Act transparency obligations for model documentation and component traceability.
Integrity Verification
Every BOM carries a cryptographic integrity hash. Verify that no component has been altered, added, or removed since the BOM was generated. Tamper-evident by construction.
Art. 73 Incident Reporting
Automated serious incident detection, classification, and authority notification.
Severity Classification
Incidents are automatically classified by severity tier with computed deadlines: 2 days (critical), 10 days (high), 15 days (standard). Countdown tracking with overdue alerts ensures no deadline is missed.
Report Generation
Automated initial and complete report generation per EU AI Act Art. 73 requirements. Linked to the decisions and drift alerts that triggered the incident. Every report references ledger entries.
Authority Notification
Structured notification pipeline to national competent authorities. Timeline tracking from detection to initial report to complete report. Full audit trail of all communications.
Public Verification Portal
Zero-knowledge decision verification for external auditors and regulators.
External parties — regulators, auditors, counterparties — can verify that a specific decision was made, when it was made, and that it has not been tampered with. They do not need access to your systems.
Verification uses unique tokens tied to Merkle tree inclusion proofs. The verifier confirms the decision exists in the append-only ledger without seeing other decisions, internal policies, or evidence details. Cryptographic proof, not trust.
Immutable Ledger
Every decision, proof, and revocation is recorded. The ledger only grows.
Append-Only
Runtime database roles have INSERT permission only. No UPDATE, no DELETE. The audit trail cannot be tampered with from inside the application.
Row-Level Security
Each tenant operates within a Postgres RLS boundary. Tenant A cannot read, reference, or query Tenant B data. Isolation is enforced at the database layer.
Proof Lineage
Every decision references the exact proofs that produced it. Proofs reference their sources. The chain is reconstructable from any point backward to the original evidence.
Technical Sovereignty
Proven memory-safe Rust code. Reproducible builds. Auditable open-core.
Exclusive on-premise deployment. No SaaS. No telemetry. No outbound network calls. Ed25519 license verified offline — no license server.
For private banks and family offices, legal sovereignty is not a sales argument. It’s a regulatory prerequisite.
Applications
Sectors where authorization decisions require evidence, not trust.
Financial Services
Transaction authorization with full audit trail. Contradictory signals between fraud detection and compliance are surfaced, not suppressed. Deterministic replay enables immediate regulatory response — any decision can be re-executed and verified in seconds.
- Evidence packs that support SOC 2 / ISO 27001 audit processes
- Transaction proof chains with Merkle inclusion proofs
- Conflict detection for AML/KYC signals
- Art. 72 post-market surveillance with drift detection
- Deterministic replay for regulatory inquiries
Government & Defense
Clearance verification where every access decision must be reconstructable. The full evidence path from request to outcome is preserved.
- Clearance-based access control
- Audit-ready decision records
- Multi-source evidence evaluation
Critical Infrastructure
Operational technology access where incorrect authorization has physical consequences. Indeterminate state prevents premature action.
- SCADA / OT access governance
- Evidence trails that support DORA / NIS2 audit requirements
- Operator action verification
API Surface
RESTful. JSON. OpenAPI 3.1 specified.
Core API :3100
| POST | /decisions/resolve | Create decision |
| POST | /decisions/re-resolve | Add proofs, re-resolve |
| GET | /decisions/{id}/why | Full audit trail |
| GET | /decisions | List (paginated) |
| POST | /proofs/revoke | Revoke proofs |
| GET | /health | Service health |
Gateway :3200
| POST | /gateway/decision | Subject/action/resource |
| POST | /gateway/http-check | HTTP method/path |
| GET | /gateway/health | Mode + license |
| GET | /gateway/metrics | Prometheus |
Operator Toolbox
Six CLI tools for day-two operations. Tenant management, key rotation, audit export, schema migrations, partition maintenance, post-restore integrity checks.
All run as hovo_admin. None ship in production container images.
| Tool | Purpose |
|---|---|
| hovo-admin | Tenant CRUD + key rotation |
| hovo-license | Keygen, sign, verify (offline) |
| hovo-export | JSONL audit export + SHA-256 |
| hovo-migrate | Schema migrations (idempotent) |
| hovo-maint | Partition + retention mgmt |
| hovo-verify | Post-restore integrity check |
Frequently Asked
Why three values instead of two?
Binary systems must resolve every ambiguity into allow or deny. When evidence conflicts or is absent, they guess silently. Three-state logic makes that ambiguity explicit and auditable — the Indeterminate outcome is a correct, traceable result.
Why is Indeterminate the native state?
Because absence of evidence is not evidence of allowance. I is the default until supporting or refuting evidence reaches the configured governance threshold. This prevents premature verdicts in high-stakes contexts.
Can a binary outcome be forced?
Yes. Governance thresholds can be configured to route Indeterminate outcomes to a default policy (deny, escalate, or allow with logging). The choice is explicit and auditable — not a silent system default.
Does this replace our existing PDP?
No. OmegaOS™ operates as an overlay. Your existing PDP remains available as a signal source and fallback. You can observe, shadow, and enforce incrementally — with full rollback at every stage.
Deploy with Guided Pilot
Observe, shadow, enforce. Designed for zero-downtime mode switching. Full rollback at every stage.