DominusOS ยท The governance layer behind Sabina
Sabina is your company’s own AI, hired first to carry the work between promised and done. Knowing isn’t permission. DominusOS is the governance layer behind her: it addresses what the AI is permitted to do, the conditions on that authority, and the record needed to distinguish a proposed action from a completed one.
Start with a short operational assessment of your business.
Three structural guarantees
No capability runs beyond what was granted. A restriction — a boundary the owner writes — bites immediately. Widening authority is inert until it is deliberately confirmed; nothing Sabina reads, notices, or infers can grant it to herself. She cannot promote herself.
Every action is written to the record before it is carried out — whether it is committed, refused, or still waiting on a person. Standing rules carry who wrote them and when. Revoking one stops future actions without erasing what already happened.
She cannot tell a customer something is booked, sent, or changed until the record shows it actually happened. The check runs on every sentence before it reaches a caller’s ear or a customer’s inbox — not on a policy she is trusted to remember.
The Problem
Most AI tools force a choice between capability and accountability. Either a system acts freely — creating risk nobody can trace back to a decision — or it is locked down so tightly it cannot do real work. As AI takes on more of an organization’s work, the owner still has to answer for outcomes they did not personally review.
Monitoring tells you what already happened. Governance has to answer a different question before the fact: what is this system permitted to do right now, and can it prove it stayed inside that boundary.
How It Works — Today
A customer-facing follow-up is prepared. The system checks the current authority for that company and responsibility. Where the approved scope requires approval, the action waits. Where it is permitted, the supported execution path carries it out and records the result. If it fails or remains uncertain, the system must not describe it as completed.
Every action Sabina attempts is written to the record before it is carried out — a row that exists whether the action is committed, refused, or still waiting on a person. Anything that reaches the outside world needs a permit: a signed, single-use token bound to the tenant, the capability, the exact arguments, and a time window. The permit is minted once and consumed once; a verifier can check its signature, but only the authority service can mint one.
The rules an owner writes are restrictions, not grants. There is no instruction in the rule grammar that widens what Sabina can do, spends money, or turns a suggestion into a standing rule — that term does not exist for the compiler to accept. A one-time approval is consumed and expires; it never becomes a standing permission.
Her authority is also bounded by a signed attestation of what she is currently permitted to run. That attestation expires on a fixed schedule, and if it lapses — or the code it is pinned to changes — every capability demotes automatically to propose-only until it is re-signed.
Before anything becomes a spoken or written sentence, a check runs against the record: she cannot claim a booking, a payment, or a change that the system does not show as actually committed. How your information is processed depends on the service path in use. See the current processing and privacy disclosures before sharing business material.
None of this lives in an editable log. Grants, rule changes, revocations, and approval events are written once and never altered — a rule can be withdrawn, but the record that it existed, who wrote it, and when, stays.
Where It’s Going
Dominus Foundry also runs the DominusOS kernel family — three kernel instances, each checking its own governance file against a stored hash at boot and refusing to start if the two do not match. That mechanism is real and running today.
It does not yet govern Sabina. No action she takes currently passes through this kernel family; the permit-and-record system described above is what governs her live paths today. DominusOS is converging toward that kernel architecture as its deeper substrate — a governed kernel underneath every AI process, not only the permit system above it — but that convergence is a direction Dominus Foundry is building toward, not a description of how Sabina is governed today.
Kill Switch
A single stop command refuses new sessions, marks active ones stopped, and closes the calls and sends already gated behind it. It states its own limits rather than promising more than it does: a caller already mid-sentence may hear up to one more line before the line closes, and the switch does not yet reach every process Sabina touches. The stop is fail-closed — until it is deliberately resumed, gated sends stay blocked.
Anyone told this switch is instantaneous everywhere has been told something that is not yet true. Extending its reach across every path, and rehearsing it on a schedule so it is exercised before the day it is needed, is work still ahead — not a claim on this page.
Authority Structure
The authorized business sets boundaries. Broader permission follows the approved confirmation process; it does not appear because the model learned something new or because one action was approved once. Revocation stops future work under the withdrawn authority. It does not erase the record or reverse an action already completed.
Who It’s For
DominusOS is built for operators and owners who cannot afford black boxes — and cannot afford to slow down to avoid them. It assumes someone must always be able to explain what happened, why it happened, and who authorized it. Governance is not bolted on after the fact; it is the record and the permit an action needs before it happens.
The Foundation
Every session carries a verified tenant claim, checked before it can act. Sabina’s data and yours are meant to be reachable only through your own session — enforced today in application code, with database-level checks layered on top for the connections that carry the most risk. “Difficult by design” is the honest claim; enforcing isolation at the database layer for everything, not only the highest-risk paths, is ongoing work, not a finished guarantee.
For people who must protect discretion, confidentiality, and fiduciary duty, this is not a feature. It is the reason to choose DominusOS.
Identity, data access, and AI processing are separate boundaries. Tenant-scoped access controls do not themselves establish where model processing occurs.
In Production
DominusOS is not a proposal or a whitepaper exercise. It is the live governance layer behind Sabina’s supported work paths: proposed actions are recorded before execution and permitted customer-facing actions require a signed permit; and a stop switch — with its limits stated plainly above — can halt her from starting anything new.
What is not yet true: there is no automated planner that proposes and ships its own changes to production traffic; cross-company pattern-sharing is not operating today; and there is no rehearsed kill-switch drill on the record. The kernel family described above is real and running for what it already does today, and it is the direction this layer is converging toward — not a claim about how Sabina is governed right now.
How your information is processed depends on the service path in use. See the current processing and privacy disclosures before sharing business material.
Contact
For the people accountable for delegated work: bring a specific action, source, and authority question. We will distinguish the public operating model from the coverage demonstrated by the current work.
Start with a short operational assessment of your business.