Technical White Paper

DominusOS: The Human-Governed AI Hypervisor

Self-learning federated intelligence under constitutional governance. Autonomic planning, governed evolution, and context-aware policy — in production.

Mark Lord, Dominus Foundry — March 2026 — Version 3.0

Download White Paper (PDF) Specification Repository Back to DominusOS

Abstract

AI systems increasingly execute consequential actions within production infrastructure — managing workflows, processing data, communicating with stakeholders, and allocating resources. Yet governance of these systems remains structurally decoupled from execution: reactive, policy-based, and dependent on configuration rather than architecture.

DominusOS introduces a human-governed AI hypervisor: a mandatory control layer beneath AI execution that mediates all system actions through a unified governance architecture. Built on a federated multi-kernel microkernel with a mandatory syscall gate, capability-based authority, event-sourced determinism, tenant isolation, and constitutional governance sealed by cryptographic hash verification, the system enforces structural guarantees that monitoring and policy alone cannot provide.

Version 3.0 documents the complete self-learning architecture now operating in production: an autonomic planner implementing a formal Monitor-Analyze-Plan-Execute loop, a governed evolution engine that proposes and validates its own improvements under human authority, context-aware governance that adjusts policy posture based on real-world conditions, speculative execution that predicts and pre-warms optimal paths, intent-based orchestration that decomposes goals into governed syscall sequences, behavioral baseline establishment with continuous deviation scoring, shadow execution for policy backtesting against historical events, and kernel-level source introspection that enables the system to reason about its own structure.

The system operates across federated kernel instances under a sealed constitutional canon of immutable governance articles, with split-key authority for modifications. Every subsystem learns. Every learning action is governed. Every governance decision is recorded with full provenance.

This paper presents the architectural thesis, core infrastructure, federation design, self-learning architecture, constitutional governance, structural guarantees, production evidence, and roadmap — including planned extension to IoT and autonomous edge environments.

Self-learning governance AI hypervisor Autonomic computing MAPE-K Governed evolution Federated kernels Constitutional AI Speculative execution Context-aware policy Behavioral baselines Intent orchestration Shadow execution Knowledge decay World-model governance Capability authority Dynamic trust Deterministic execution IoT governance

The Convergence Problem

Each era of software solved one problem and created the next.

Era	Abstraction	What It Solved	What It Left Unsolved
Monolith	Centralized control	Integration	Scalability
SaaS	Specialization	Scalability	Data fragmentation
API Economy	Composability	Cross-vendor integration	Dependency complexity
AI Copilots	Local reasoning	Per-task intelligence	Session-scoped memory
Agents	Distributed execution	Task automation at scale	Authority, coherence
Tool Sprawl	Surface coverage	Feature access	Cognitive fragmentation, governance

The absence of a governed execution substrate is the limiting factor in the current AI stack. The next abstraction layer is not another tool. It is a hypervisor.

Architectural Thesis

The structural gap in the current AI stack is not a missing tool — it is a missing layer.

AI systems operate with growing autonomy but without a substrate that enforces governance at the point of execution. Current approaches attempt to govern after the fact: observability dashboards record what happened; policy engines advise what should happen; audit logs capture what did happen. None intervene architecturally where execution occurs.

DominusOS advances a thesis: governance must move beneath runtime. Rather than wrapping AI systems in external policy, DominusOS positions a hypervisor layer between AI processes and the infrastructure they act upon. Every action — every write, every communication, every resource commitment — passes through a syscall gate that enforces capability envelopes — scoped, time-limited, and revocable — before execution proceeds.

But governance alone is insufficient. A system that only enforces rules is static. The v3 thesis extends: intelligent systems must learn, adapt, and improve — but only within constitutional boundaries. DominusOS does not choose between autonomy and control. It implements both: a self-learning architecture where every subsystem compounds intelligence, proposes improvements, and adapts to changing conditions — while remaining structurally bound by an immutable constitutional canon that no automated process can modify.

Authority is not assumed. It is granted, bounded, time-limited, and auditable. No process inherits ambient authority from its environment. No learning process can override governance. No evolution can weaken structural guarantees.

This is the distinction between a governed system and a monitored one. Monitoring records what happened. A hypervisor determines what is permitted to happen — and learns to determine it better over time.

Core Architecture

Five structural components of a governed hypervisor.

Syscall Gate

The mandatory mediation point for all AI execution. No process writes, communicates, deploys, or commits resources without passing through the gate. The gate enforces authority checks against the process’s capability set, logs the action to an immutable event ledger, and applies governance rules before permitting execution. The gate is not optional and cannot be bypassed — it is the only path from intent to action.

Capability Envelopes

Every process operates within an explicit capability envelope. Envelopes define what a process may do (scope), for how long (time-limited), and under whose authority (attribution). Capability envelopes are granted by human operators, are transitively revocable, and follow the principle of least authority. A process cannot access any resource or perform any action for which it does not hold an explicit, unexpired capability grant. Capabilities are unforgeable tokens with expiry, revocation, and use-count limits — modeled after formally verified capability systems.

Event-Sourced Determinism

Every state change in the system is captured as an immutable, sequenced event. The complete system state can be reconstructed by replaying the event log from any point. This provides replay determinism: any execution sequence can be audited, verified, and reproduced. There are no silent state mutations, no unrecorded side effects, no gaps in the attribution chain.

Tenant Isolation

Organizational domains execute within isolated boundaries. No process in one domain can access another domain’s data, capabilities, or execution context without explicit cross-domain authority grants. Isolation limits blast radius, prevents cascade failures, and ensures that a fault or compromise in one domain cannot propagate to others.

Microkernel Architecture

The kernel is minimal by design. It manages process scheduling, capability enforcement, the syscall gate, and the event ledger. All domain logic, integrations, drivers, and services run in user space outside the kernel boundary. A fault in any driver or integration cannot crash the kernel or affect other subsystems. The design minimizes the trusted computing base and maximizes fault containment.

Federation Architecture

Distributed sovereignty across federated kernel instances.

Sovereign Kernel

A single sovereign kernel instance holds the constitutional canon, issues trust passports, and manages the federation registry. It serves as the root of authority across all federated instances. Domain kernels register with the sovereign, receive trust credentials, and synchronize governance state. The sovereign does not execute domain logic — it governs the federation itself.

Domain Kernels

Each business domain operates its own kernel instance with full isolation, independent scheduling, and domain-scoped capabilities. Domain kernels maintain their own event streams, trust scoring, and resource allocation while remaining bound by the sovereign’s constitutional canon. A failure or compromise in one domain kernel cannot affect another.

Federation Event Bus

Cross-kernel communication flows through a signed federation event bus. Every inter-kernel message carries cryptographic provenance — signed with HMAC verification. Events are routed by domain scope, and no kernel can inject events into another kernel’s stream without valid federation credentials. The bus enables coordination without coupling.

Trust Passports

Federation authority is mediated by trust passports — time-bounded, revocable credentials issued by the sovereign kernel. Passports define what operations a domain kernel may perform across federation boundaries. They expire, they can be revoked instantly, and they carry the full attribution chain of who issued them and under what authority.

Master Cortex

A federated knowledge graph that aggregates abstracted intelligence signals from all domain kernels. The master cortex does not receive raw data — it receives typed signals: trust velocity, behavioral patterns, operational tempo, anomaly indicators, resource pressure. It synthesizes cross-domain patterns that no individual kernel can detect, generating macro-level insights while preserving domain isolation. The entire federation learns from the collective without exposing domain internals.

Self-Learning Architecture

Every subsystem learns. Every learning action is governed.

The following capabilities are not planned features. They are running in production, accumulating knowledge, proposing improvements, and adapting to changing conditions — all under constitutional governance.

Knowledge Foundation

Compounding Knowledge with Provenance and Decay

The system accumulates knowledge continuously from every operation it performs. Knowledge enters the system through four distinct channels: observed patterns derived from behavioral analysis, taught knowledge explicitly provided by human operators, derived insights inferred from cross-entity and cross-domain correlation, and corrected knowledge updated after human intervention overrides a previous understanding.

Every knowledge node carries full provenance: who or what created it, when, from what evidence, at what confidence level, and whether it has been contradicted. Confidence scores decay over time — recent, reinforced knowledge retains high confidence while stale patterns degrade naturally. Knowledge that falls below a minimum confidence threshold is archived but never deleted. The system forgets what is no longer relevant while preserving the ability to recall why it once believed something.

What makes this different: knowledge is not a static database. It is a living graph with temporal dynamics, provenance chains, and governed decay. The system’s memory improves over time — it does not merely accumulate.

Autonomic Planning

MAPE-K Autonomic Loop

DominusOS implements a formal Monitor-Analyze-Plan-Execute over shared Knowledge (MAPE-K) autonomic computing loop. The planner runs on a continuous cycle, observing anomaly scores, behavioral patterns, resource metrics, and governance posture across all subsystems.

Observations are classified into proposal types: trust adjustments, resource optimizations, policy refinements, and capability modifications. Each proposal carries a confidence score, a blast radius estimate, and a reversibility classification. Proposals are sorted into three tiers of authority:

Tier 1 — Auto-execute: Bounded, reversible, low-blast-radius actions. The system executes these autonomously and records the action with full attribution.
Tier 2 — Recommend: Higher-impact proposals queued for human review with evidence and projected impact. The system recommends. Humans authorize.
Tier 3 — Governance gate: Structural changes, kill switch actions, policy modifications, and capability revocations. These always require explicit human authority through the governance gate.

What makes this different: the system proposes its own optimizations with quantified confidence and impact estimates. It does not wait to be told what to improve — but it does wait for permission on anything consequential.

Governed Self-Improvement

Evolution Engine

The kernel generates its own improvement proposals based on accumulated behavioral patterns, performance metrics, and operational history. Proposals are staged — never applied directly to production. Each proposal passes through a multi-phase validation pipeline:

Shadow validation: The proposed change runs in a sandboxed environment against historical event data. The system determines what would have happened differently under the proposed change.

Canary deployment: Validated proposals route a small percentage of real traffic through the modified path for a confirmation window. Metrics are monitored continuously during this period.

Automatic rollback: If any monitored metric breaches its threshold during the confirmation window, the change is automatically reverted. No human intervention required for safety — only for promotion.

Promotion: Changes that pass the confirmation window are promoted to production with full versioning. The system maintains a self-model that tracks proposal quality over time — per-category confidence scores adjust based on historical approval and rejection rates.

What makes this different: the system proposes and validates its own code-level improvements. Architectural changes and constitutional modifications always require the governance gate. The evolution engine can improve the system — but it cannot change what the system is.

Behavioral Intelligence

Behavioral Baselines and Deviation Scoring

The system establishes behavioral baselines for every entity it governs. Baselines track multiple metrics per entity: event rates, error patterns, resource consumption, interaction sequences, and decision distributions. Baseline confidence grows with accumulated observations — a minimum observation threshold must be met before comparison begins.

Once a baseline is established, the system continuously scores deviations against it. Deviations beyond a statistical threshold trigger autonomic proposals — trust adjustments, resource reallocation, or governance escalation. The baseline itself evolves as entity behavior changes, distinguishing between genuine behavioral shift and transient anomaly.

What makes this different: the system defines “normal” for each entity from observation, not configuration. Anomaly detection is continuous, per-entity, and feeds directly into the governance loop.

World Awareness

Context-Aware Governance

Governance does not operate in a vacuum. DominusOS ingests external signals — market conditions, environmental indicators, operational stress markers — and computes a unified governance sensitivity score. This score adjusts the kernel’s governance posture in real-time across a spectrum from relaxed to critical.

During elevated sensitivity, error signals carry increased weight in trust calculations, tier change thresholds lower, and anomaly detection tightens. During critical sensitivity, any deviation triggers governance review. The system maintains a historical archive of world-model snapshots, enabling pattern matching against previously observed conditions — “have we seen this pattern before, and what happened next?”

What makes this different: governance rules are not static. They respond to the environment. The same action may be permitted in stable conditions and flagged in volatile ones — without changing any policy. The world informs the governance posture.

Execution Optimization

Speculative Execution

While an entity waits on an external response, the kernel predicts the next likely operation based on historical execution patterns. If the prediction confidence exceeds a threshold, the system pre-warms the knowledge layer, pre-allocates resources, and pre-verifies capabilities for the predicted operation. If the prediction is correct, the next operation executes with near-zero latency. If incorrect, pre-warmed resources are released with no side effects.

Security-critical operations — governance actions, capability modifications, authentication, and policy changes — are never speculated. Prediction accuracy is continuously tracked and fed back into the learning system.

What makes this different: the system applies CPU-level optimization concepts to AI governance. It learns optimal execution sequences from its own history and proactively optimizes for them — without bypassing any governance checks.

Intent Abstraction

Intent-Based Orchestration

Entities declare high-level intents rather than imperative syscall sequences. The kernel decomposes intents into directed acyclic graphs of governed syscalls, validates the entire plan against current capabilities and policies before execution begins, and executes the plan through the standard syscall gate.

Decomposition draws from two sources: defined templates for well-understood operations, and learned decompositions derived from historical syscall sequences that achieved similar outcomes. The system improves its decomposition accuracy over time as it observes which sequences produce successful results.

What makes this different: the system translates goals into governed action plans. It validates the entire plan before any step executes. And it learns better decompositions from its own operational history.

Policy Validation

Shadow Execution and Policy Backtesting

Before any policy change takes effect, the system can replay historical events through the proposed modification. Shadow execution never modifies real policy or real state — it is strictly read-only. The system reports exactly what would have been denied, permitted, escalated, or flagged under the proposed change.

This enables governance decisions to be evidence-based rather than speculative. An operator considering raising a trust threshold can see the projected impact against actual historical behavior before committing to the change. Shadow execution results are stored as knowledge nodes, building a governance decision history that informs future policy evolution.

What makes this different: policy changes are backtested like trading strategies. You see the impact before you commit. Governance evolves with evidence, not intuition.

Self-Awareness

Kernel Source Introspection

The kernel indexes and reasons about its own source structure. It builds and maintains a self-map: modules, exported functions, data dependencies, event types emitted, and tables accessed. This index is read-only from the planner’s perspective — it enables introspection, not self-modification.

Source introspection provides the bridge between behavioral pattern detection and structural hypothesis generation. When the autonomic planner detects a behavioral anomaly, introspection enables it to generate hypotheses about structural causes — and when the evolution engine proposes improvements, introspection ensures it understands what it is changing.

The system also maintains periodic self-model snapshots — comprehensive records of its own operational state, capabilities, confidence areas, and blind spots. These snapshots enable temporal comparison: how has the system’s understanding of itself changed over time?

What makes this different: the system reads and reasons about its own architecture. It knows what it can do, what it cannot do, and where its understanding is weakest.

Constitutional Governance

Immutable articles. Split-key authority. Multi-operator sovereignty.

Constitutional Canon

The system operates under a sealed governance canon — a set of immutable articles that define the boundaries of all system behavior. Articles cover human sovereignty, governance-by-design, cognitive scoping, transparency requirements, teaching-over-configuration, memory provenance, stewardship orientation, continuous learning mandates, and immutability enforcement. The canon is a frozen constant verified by cryptographic hash at every kernel boot. If the hash does not match, the kernel refuses to start.

Split-Key Authority

Constitutional modifications require split-key governance: no single operator can unilaterally alter the governance framework. Changes require multi-party authorization, documented version incrementing, and acknowledgment across all federated kernel instances. The modification process itself is auditable, versioned, and irreversible without the same multi-party authority.

Multi-Operator Sovereignty

Authority is differentiated across operators with distinct sovereignty levels. A sovereign operator holds full authority across all domains with veto and override capability. Co-operators can initiate governance proposals but require sovereign confirmation for execution. Domain-sovereign operators hold full authority within a single domain but remain bound by the constitutional canon. Every authority level is explicit, auditable, and revocable.

Counsel Layer

Before operators make governance decisions, the system generates evidence-backed counsel briefs. Briefs include relevant historical context, projected impact of proposed actions, confidence levels in the analysis, and supporting evidence from the knowledge graph. The counsel layer recommends — it does not decide. All reasoning is documented with full attribution and confidence scoring.

Deep Temporal Memory

The system maintains queryable access to its full operational history with temporal indexing. Operators can reason about patterns across time: what happened during similar conditions previously, how governance decisions played out, which entity behaviors preceded incidents. Temporal policy evaluation enables governance rules that reference historical state — decisions informed by the system’s entire operational experience, not just its current snapshot.

Structural Guarantees

Eight invariants enforced by architecture, not by policy.

Replay Determinism Any execution sequence can be replayed from the event log and will produce identical, verifiable results. Full audit reconstruction from any point in system history.
Capability Enforcement Integrity No process can exceed its granted capabilities. Enforcement is mandatory and architectural. Scope violations are structurally difficult by design, not merely detectable.
Tenant Isolation Integrity No cross-tenant data access, capability escalation, or execution context leakage is structurally possible. Domain boundaries are enforced at the kernel level.
Revocation Cascades When a capability is revoked, all capabilities derived from it are transitively and immediately revoked. Authority cannot persist after withdrawal. The operator’s ability to halt always outpaces the system’s ability to act.
Driver Fault Containment A failure in any driver, integration, or user-space service cannot propagate to the kernel or affect unrelated subsystems. The system fails safe by design.
Canon Immutability The system’s constitutional governance rules cannot be modified by any automated process, including privileged ones. Amendments require multi-party human authority through the split-key governance gate.
Federation Isolation Cross-kernel communication is signed and scoped. No domain kernel can inject events, escalate capabilities, or access data in another kernel’s domain without valid federation credentials.
Governed Intelligence Every learning action, every knowledge mutation, every evolution proposal, every autonomic decision operates within governance boundaries. Intelligence compounds. It never compounds outside constitutional constraints.

The Structural Argument

Constraint is what makes intelligent systems stable.

Autonomy without constraint produces entropy. Systems that act without boundaries eventually act in ways that conflict with organizational intent.
Learning without versioning produces corruption. Systems that overwrite previous state cannot distinguish between current belief and prior understanding.
Execution without structured memory produces repetition. Intelligence is generated but never accumulated. Each interaction starts from zero.
Tool proliferation without substrate produces incoherence. Each new tool creates a new data silo, a new failure surface, and a new governance gap.
Observability without mediation produces the illusion of control. Observability tells you what happened. Only a hypervisor layer can determine what is permitted to happen.
Intelligence without governance produces corruption. Systems that learn without constitutional boundaries will eventually learn to optimize for outcomes that conflict with operator intent. The learning must be governed, or it becomes the threat.

The stability of intelligent systems depends on structural constraint, governed memory, and non-destructive evolution. These properties must be enforced beneath runtime, not applied above it.

Current State

DominusOS is not a proposal or a prototype. The system is deployed and running in production across federated kernel instances, orchestrating governed AI operations for a multi-domain service business:

Federated Kernel Instances operating under a sovereign kernel with domain-specific kernels managing isolated business domains. All instances share a sealed constitutional canon and synchronize through signed federation protocols.
Self-Learning Intelligence compounding organizational knowledge continuously. The knowledge graph accumulates observations, taught facts, derived insights, and corrections — all with provenance, confidence scoring, and temporal decay.
Autonomic Planning running formal MAPE-K loops that detect anomalies, generate improvement proposals, and auto-execute bounded optimizations while queuing consequential changes for human review.
Governed Evolution proposing and validating system improvements through shadow execution, canary deployment, and automatic rollback. The system improves itself under human authority.
Context-Aware Governance adjusting policy posture based on external conditions and historical pattern matching. Governance sensitivity responds to the world, not just internal state.
Multiple Virtual Employees executing governed workflows daily across email, document processing, compliance enforcement, and operational intelligence.
Behavioral Baselines established for all governed entities with continuous deviation scoring feeding trust adjustments and governance escalation.
Native Operator Applications on desktop and mobile with live process visibility, governance dashboards, counsel briefs, and direct kill authority.
Speculative Execution predicting and pre-warming optimal execution paths from historical patterns, with accuracy tracking feeding continuous improvement.
System-Level Kill Switch tested regularly. One action halts all AI execution across every subsystem, every kernel instance, instantly and visibly.

The architecture described in this paper is not aspirational. Every capability documented — federation, autonomic planning, evolution engine, behavioral baselines, context-aware governance, speculative execution, shadow policy testing, kernel introspection — is implemented, deployed, and accumulating operational history in production.

The system learns from everything it does. It proposes its own improvements. It backtests policy changes against its own history. It adjusts governance posture based on real-world conditions. It predicts optimal execution paths. And it does all of this under a sealed constitutional canon that no automated process can modify.

Competitive Landscape

Most organizations assemble a patchwork of tools that each solve one problem. None of them solve the governance problem — and none of them learn.

Automation platforms connect systems and move data between services. They do not enforce authority boundaries, maintain audit-grade provenance, learn from operational patterns, or provide a single kill switch when something goes wrong. When AI agents run inside them, no one controls the scope.

Agent frameworks let AI call functions and produce outputs. Most lack hard authority boundaries, durable process identity, behavioral baseline tracking, or the ability to trace any outcome to the human who approved it. When the agent drifts, no structural failsafe exists. No framework proposes its own improvements under governance.

Observability dashboards show you what happened. They do not control what is allowed to happen next. They cannot backtest proposed policy changes against historical events. They observe — they do not govern, learn, or adapt.

AI governance tools apply policy from above: rules, guardrails, content filters. They do not operate beneath execution. They do not learn from operational patterns. They do not adjust governance posture based on world conditions. They do not propose their own improvements. Policy-based governance is configuration. Structural governance is architecture.

DominusOS operates at the hypervisor layer — beneath execution, above infrastructure. A mandatory syscall gate, capability-based authority, event-sourced determinism, federated multi-kernel sovereignty, a self-learning knowledge graph with governed decay, an autonomic planner that proposes and validates improvements, context-aware policy that responds to the world, and constitutional governance sealed by cryptographic verification. Execute, learn, govern, evolve, prove, halt — in one system. Not bolted on. Architected in.

Roadmap

Self-learning governance today. Autonomous infrastructure tomorrow.

Current

Enterprise AI Governance

Founding deployments with organizations that require governed organizational intelligence, self-learning systems under constitutional authority, and auditable execution across multiple domains. Federated kernels with autonomic planning and governed evolution in production.

Near-Term

Multi-Tenant Platform

Scaling the hypervisor to support multiple organizations, each operating within isolated tenant boundaries with independent governance configurations, authority structures, and compounding intelligence layers. Federation protocol enables cross-organization learning without domain exposure.

Long-Term

Autonomous Infrastructure & IoT

The capability-based authority model, syscall gate, and tenant isolation architecture are designed to extend to IoT and autonomous edge environments. When autonomous systems execute actions in the physical world — controlling devices, managing facilities, operating equipment — the need for bounded authority, context-aware governance, and immediate halt capability becomes critical.

Verification

Evidence Anchors

Specification Repository

Public repository with architecture overview, conceptual documentation, and project specification.

View on GitHub →

Dominus Foundry

The company behind DominusOS. Operator-grade AI systems for service businesses.

dominusfoundry.com →

dominusos.ai

The product site for DominusOS. Architecture, control plane, authority structure, and founding deployment information.

dominusos.ai →

Founding Deployments

Shape how self-learning AI governance gets built.

DominusOS is deploying with a limited number of organizations per year — not to pilot governance, but to prove the pattern at scale. Founding partners receive hands-on deployment, direct architectural input, and favorable terms. If your organization requires governed intelligence that learns, adapts, and improves under structural human authority, we should speak.

Start a Conversation Back to DominusOS