DominusOS · Authority and execution control behind Sabina
DominusOS supplies authority controls for supported paths. Sabina includes Forge for structured business records.
Start with the work and company information you want to evaluate.
Three supported-path controls
Supported capabilities are checked against the authority granted.
On admitted governed paths, owner restrictions constrain execution. Widening authority requires deliberate confirmation; model observations do not grant it. Verify enforcement and revocation for the path and version in use.
On supported governed paths, attempted actions are recorded before execution, including refusals and approval waits.
On those paths, standing rules identify their author and date. Check that revocation stops new work and preserves past records in the deployed version.
Supported completion checks require a saved result before a booking, send or change is described as complete.
This describes the supported completion-check path, not all speech or messaging. Inspect the relevant channel, failure case and resulting record before relying on it.
Authority Structure
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.
The supported rule grammar expresses restrictions, not grants. A boundary must be accepted and enforced by that path; receipt of a message alone is not evidence that enforcement changed.
On supported governed paths, an external effect requires a permit for the exact action — tenant, capability, arguments and a time window, signed once and consumed once. Registry changes invalidate permits on those paths; this is not a claim that every Sabina capability is admitted.
On supported governed paths, attempted work is recorded before execution and its result afterwards. Inspect the grant or approval that authorized it; the absence of a restriction is not itself a grant.
The design requires a time-limited, signed attestation of admitted capabilities. When it lapses, those capabilities must return to propose-only. Availability and enforcement are checked for the specific supported path before a company relies on it.
Broader permission follows the approved confirmation process; it does not appear because the model learned something new or because one action was approved once. On supported governed paths, revocation blocks future work under the withdrawn authority. It does not erase the record or reverse an action already completed.
How It Works — Technical Detail
This illustration follows a supported governed path. A follow-up is prepared and checked against the company’s current authority. 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.
Choose an outcome. The diagram and this paragraph mark the same step.
On supported governed paths, an attempted action has a record before execution. External effects admitted to the permit path require a signed, single-use token bound to the tenant, capability, exact arguments and time window. A verifier checks the signature; the authority service mints the permit. This does not establish coverage for every capability or channel.
The supported rule grammar expresses restrictions, not grants. It does not treat an owner restriction as permission to spend or a model suggestion as a standing rule. Verify that one-time approval is bound to the exact revision, consumed and expired on the deployed path.
The attestation design binds admitted capabilities to signed, time-limited evidence and a code revision. Lapsed or mismatched evidence must return covered capabilities to propose-only. Check that behavior for the exact deployed path; the design does not certify fleet-wide coverage.
On supported completion-check paths, a booking, payment or change needs a committed result before it is described as complete. Test the exact channel and failure handling; this is not evidence that every sentence is checked.
The governed-record design appends grants, rule changes, revocations and approvals while retaining their history. Inspect deployed access controls and retention before treating that record as tamper-evident; an architectural requirement is not proof that no administrator can change storage.
Where It Fits
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.
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.
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.
Implementation scope
The ledger records Foundry’s reported implementation scope. Verify the path, version and runtime evidence before relying on a control.
Foundry operates Sabina with Forge included. Moving agreed work into Forge is preferred; retained software needs a supported API connection. Specialist tools are confirmed in writing.
Foundry reports governance on supported work paths: records before execution, exact permits on admitted paths and a stop switch for gated work. The September 24 formal-model receipt checks the linked addendum against its named specification run. It is not a runtime audit or certification of every deployed capability.
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 Problem
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.
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.
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. On supported governed paths, authority is checked before execution and the outcome has a record.
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 supported governed sessions require a verified company claim before acting.
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.
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 the work and company information you want to evaluate.