> For the complete documentation index, see [llms.txt](https://docs.solcis.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.solcis.ai/design-principles/govern-by-default.md). # Govern by default Enforcement is the path every connected action takes, not an add-on someone remembers to switch on. Once an agent is connected, every action it takes passes through your controls. There's no unmonitored fast path, no per-agent opt-in and no setting that lets a team route around enforcement because a deadline is close. Governance is the default condition of a connected agent, not a feature applied afterwards. This page explains what that means in practice, and why it was designed that way. ## Every action, before it happens A connected agent's action is evaluated before it proceeds. The Solcis Policy Engine returns `Allow`, `Deny` or `Escalate`, each with a severity rating. A denied action is refused. An escalated action is held until an authorised person decides. A rated action proceeds with a rating attached. An allowed action proceeds, and the fact that it was allowed is recorded. There's no fifth outcome in which an action passes through unevaluated. If a connection is active, the action is decided and the decision is recorded. ## Controls you already have Govern by default doesn't mean Solcis decides what your controls should be. It means the controls you already operate under apply to agents from the moment they're connected. Most organisations already have the material. Their governance, risk, and compliance (GRC) programme holds a control library mapped to the frameworks they answer to. Compliance Studio imports those controls through its GRC integrations and expresses them as policies the Solcis Policy Engine enforces. The control keeps its identifier. The policy records which framework requirement it satisfies. When an agent's action is denied, the compliance receipt names the control that denied it and the requirement behind it. *How it works › Controls to policy* describes the path from control to policy. ## Nothing is enforced by accident A policy that governs by default has to be trustworthy before it's enforced. Compliance Studio makes that a lifecycle, not a hope. A policy is drafted, approved by someone other than its author, then run in shadow. In shadow, it evaluates every matching action and records what it would have decided, without affecting the action. You read those receipts and see what the policy would have done to real traffic. Only then is it promoted to enforced.
Every transition is recorded: who approved, who promoted, when. ## The default when something fails Governing by default has to include the failure cases. What happens to an action in flight when the model behind the inference check is unavailable, or times out? What happens during a policy transition? The Solcis Policy Engine applies a fallback, configured in Compliance Studio, for each of these, and the documentation states it rather than leaving you to discover it. The compliance receipt for an action decided under a fallback says so. ## Why the default matters Controls that depend on someone remembering to apply them are applied unevenly, and unevenly applied controls are what auditors find. An agent estate grows quickly. New agents are stood up by teams that aren't thinking about compliance, for good reasons. If governance is something each team switches on, coverage tracks attention rather than risk. Making enforcement the default path for a connected agent inverts that. A team connects an agent, and the organisation's controls apply. Nobody has to remember. The compliance manager's job becomes deciding what the controls should be and reading what they did, which is the job they're qualified for. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.solcis.ai/design-principles/govern-by-default.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.