DominusOS ยท Authority and execution control behind Sabina
DominusOS is the authority and execution-control layer behind Sabina. Company rules define what she may do, when approval is required, and how permitted work is recorded. Sabina’s understanding of the company can grow. Her authority continues to come from the permissions the company grants.
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 — Technical Detail
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.
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 Fits
Sabina runs on a core model trained and operated by Foundry. Our proprietary memory and teaching systems shape that foundation around your company, while your permissions define what she may do. DominusOS is the part that holds those permissions: the responsibilities, grants, conditions, approvals, and revocations your company sets, and the record of what was permitted and done.
Teaching Sabina, the company memory she keeps, and the training of the core model are different mechanisms. None of them widens her authority. As useful company knowledge carries forward, she can understand more of the work; what she may act on still comes only from what your company has granted.
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.
Company Boundaries
Your company’s knowledge, memory, operating instructions, and permissions remain specific to your company. Access follows the sources and authority you approve, and every session carries a verified company claim that is checked before it can act.
For people who must protect discretion, confidentiality, and fiduciary duty, this is not a feature. It is the reason to choose DominusOS.
Any future use of eligible derived information beyond providing your company’s service requires separate, specific agreement. See Sabina’s trust and company-data page for how company information is handled.
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.
Foundry configures, deploys, and operates Sabina for your company. Your team teaches her the business and decides what she may handle.
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.