Technical Architecture Note — Version 1.0

Status Controlled Public Artifact
Version 1.0
Release date 2026-02-17
Jurisdiction Switzerland
Scope Demonstration boundary

Problem

Most authorization systems rely on probabilistic scoring or heuristic classification. These approaches introduce ambiguity at the decision point and make deterministic guarantees difficult. OmegaOS™ evaluates explicit policy rules against provided evidence and allows a third outcome: INDETERMINATE. When the available evidence is insufficient to resolve the policy conditions, the evaluation result is INDETERMINATE.

System Model

Evidence → Policy Version → Resolve() → Decision → Ledger → Replay
  • Evidence — Structured input data provided to the system.
  • Policy — A versioned rule set defining evaluation conditions.
  • Resolve() — Deterministic evaluation function producing the decision.
  • Decision — Output state: ALLOW, DENY, or INDETERMINATE.
  • Ledger — Append-only record storing the evidence set, policy version, and decision output.
  • Replay — Ability to recompute historical decisions from stored inputs.

The policy version used for evaluation is recorded together with the evidence set and decision result, allowing exact historical replay.

Evidence origin and policy definition are external to the runtime. OmegaOS™ evaluates evidence but does not assert its correctness.

Trust model — OmegaOS™ assumes that the provided evidence set and policy definitions are supplied by external systems. The runtime evaluates these inputs deterministically but does not guarantee their correctness.

Deterministic Guarantee

A decision is considered deterministic if and only if all of the following conditions hold:

  • The policy version is immutable and version-locked at evaluation time.
  • The evidence set is complete as defined by the policy schema.
  • The evaluation function contains no randomness, no side effects, and no external calls.
  • The output is one of exactly three states: ALLOW, DENY, or INDETERMINATE.
  • The decision and its inputs are recorded in the append-only ledger.

Verifiability Property

Any decision can be recomputed using the original evidence set and the exact policy version that was active at the time of evaluation. If the inputs are identical, the result is identical.

This property allows external auditors to reproduce decisions without relying on the original runtime environment.

Decision Function Property

The evaluation function is pure and deterministic. Its output depends solely on the provided evidence set and policy version.

INDETERMINATE is not treated as a primitive truth value. It is produced by the evaluation function when the available evidence does not satisfy the policy conditions required to resolve the decision.

Core Invariants

These constraints are structural properties of the system. They cannot be disabled or overridden at runtime.

  • Determinism — Identical inputs produce identical decisions. No randomness, no time dependency, no external state.
  • Evidence-bound extraction — No decision is produced without a complete evidence record. The system does not fabricate, assume, or default missing fields.
  • Append-only ledger — Decision records cannot be modified or deleted. Immutable by design and enforced at every layer.
  • Tenant isolation — Evidence from one tenant cannot influence or be accessed by another. Enforced at the storage layer with strict access boundaries.
  • Uncertainty-preserving semantics — Uncertainty is preserved unless sufficient evidence resolves it. ALLOW and DENY are outputs of the resolve function, never primitive inputs.
  • Non-self-executing architecture — The system produces decisions but never executes actions. Enforcement is delegated to the calling system.

Verification

  • Mutation testing — Ensures the test suite detects injected defects. All non-equivalent mutants in production code are killed.
  • Property-based testing — Explores large randomized input spaces across core logic.
  • Differential testing — Compares production logic against an independent reference implementation sharing zero code.
  • Coverage-guided fuzzing — Feeds adversarial inputs to critical components.
  • Formal verification (Kani) — Proves algebraic properties of the trilean kernel via bounded model checking.
  • Model checking (TLA+) — Exhaustive state-space exploration of system invariants via the TLC model checker.

Metrics

600+

mutation tests executed

0

surviving production mutants

13M+

fuzz inputs generated

100K+

property-based evaluations

13

formal proofs (Kani)

3M+

model-checked states (TLA+)

700+

deterministic test cases

Auditability

Every decision record contains:

  • Policy version
  • Evidence set
  • Decision output
  • Timestamp
  • Cryptographic integrity hash

Any independent party with access to the evidence set and policy version can recompute the decision and verify the result.

Reproducibility

The verification pipeline can be executed locally using a single script.

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

Typical runtime: 30–60 minutes depending on hardware. The pipeline is idempotent and produces deterministic pass/fail results.

The full verification pipeline can be executed locally with a single command:

make verify

Sovereign Modules

Cryptographic primitives, Merkle verification, temporal replay, and trust anchors are implemented offline as SOVEREIGN modules. They are excluded from the current verification scope. The same verification pipeline will be applied once these components are completed.

Demonstration Boundary

This document describes the architecture in a controlled demonstration environment. It does not represent a certified production system. The demonstration operates under synthetic data, constrained load, and limited tenant scope. Organizations evaluating this architecture should perform their own independent assessment.

Limitations

OmegaOS™ guarantees deterministic policy evaluation and decision reproducibility.

It does not guarantee the correctness, authenticity, or completeness of externally provided evidence.

Evidence acquisition, policy definition, and enforcement of resulting decisions remain the responsibility of external systems.

Integrity Fingerprint

This artifact documents the architectural invariants and verification results of the OmegaOS™ demonstration runtime. Independent replication and evaluation are encouraged.

The signed PDF artifact includes a cryptographic integrity fingerprint. Contact HOVO to obtain the signed version under NDA.

Contact

Request Full Artifact

Obtain the complete technical architecture note as a signed document under NDA.

Request PDF