> 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/four-engineering-problems-solved.md). # Four engineering problems solved The Solcis Policy Engine enforces controls on connected AI actions, and Compliance Studio records the evidence, in regulated, sovereign and edge environments. ## Context and what this means for you AI agents now issue refunds, update records, move money, and operate physical infrastructure. Before regulated organisations approve wider deployment, they need evidence that each action followed their controls. **The Solcis Policy Engine evaluates each action in its enforcement path against the applicable controls before the action proceeds. It records the decision in a compliance receipt that a third party can verify.** > #### **The Solcis secret** > > **Rules make the decisions. When a rule needs judgement, an AI model weighs in, but it can only add caution. It can never approve an action on its own. When the Policy Engine isn't sure, a person decides.** To do this in regulated, air-gapped, or edge environments, the Solcis Policy Engine must meet four constraints:
Speed. The check must finish before the action takes effect.
Scope. The check must select the applicable rules from a library of any size.
Sovereignty. The deployment must run where the data is processed, including with no network path in or out.
Size. The Solcis Policy Engine must fit where the agent runs: a data centre, a factory floor, or a satellite.
Each constraint is manageable alone, but they pull against each other. Fast checks are easier with fewer rules. Large rule libraries are easier when latency doesn't matter. Air-gapped deployments are easier on a server rack. The Solcis Policy Engine meets all four. Every decision lands in the tamper-evident evidence ledger in Compliance Studio, which a verifier can check without trusting the deployment's operators.

Speed Scope Sovereignty Size

## Speed **Every compliance check must finish before the action takes effect.** A preventive control works only before an action takes effect. The Solcis Policy Engine sits where connected actions are checked: the agent requests an action, the Policy Engine evaluates it, and then the action proceeds. Slow evaluation pushes checks after the event, turning preventive controls into detective controls. The Solcis Policy Engine runs the full evaluation loop inline. {% stepper %} {% step %} #### Run a rule-based check Evaluate the action against the rules that apply. {% endstep %} {% step %} #### Run an AI check Use a customer-hosted model to assess what rules alone cannot express. {% endstep %} {% endstepper %} The Policy Engine combines both results into one decision (`Allow`, `Deny` or `Escalate`, with a severity rating) and writes a compliance receipt. **Result:** the Policy Engine checks and records the action before it takes effect.
### What this unlocks * **Preventive control.** A `Deny` stops the action rather than reporting it afterwards. * **Full rule libraries.** The Policy Engine selects applicable rules before it evaluates the action. * **Checks on every covered action.** When a rule needs context, every action it covers is checked, not a sample. > **Example.** A bank's customer-service agent can have a refund checked and recorded before the customer sees confirmation. ### Frequently asked questions
Does the inference step run on every action, or only some? Every action that passes through the Solcis Policy Engine can run both the rule-based check and the AI check. If you configure it in Compliance Studio to skip the AI check for certain actions, the compliance receipt records that the step was skipped.
What happens if the inference step times out or the model is unavailable? An unavailable AI model never becomes an approval. If the model is slow or unavailable, the configured fallback holds the action for a person or denies it. The compliance receipt records the fallback.
Does adding more rules slow down each check? Adding rules to the library does not add them to every check. The Policy Engine routes each action to the applicable rules first, so the number of rules evaluated per action depends on the action's context, not on the size of the library.
## Scope **The Solcis Policy Engine selects the rules that apply to each action from a library of any size.** Organisations don't run one framework. A single agent action can fall under internal policy, sector regulation, privacy law and contractual obligations at the same time. Evaluating every rule against every action doesn't scale: latency grows with the library, and irrelevant rules add noise to the decision. The Policy Engine routes each action to the rules that apply to it. Routing uses the context of the action, such as the agent, the tool, the data involved and the deployment's jurisdiction. Only the selected rules are evaluated, so adding rules to the library doesn't add them to every check. **Result:** the Policy Engine routes each action to the applicable rules, whatever the library size.
### What this unlocks * **One rule library.** Internal controls, regulatory requirements, and business rules can share one library. * **Multi-jurisdiction deployments.** One deployment can select applicable rules for each action. * **Specific rules.** Controls authors can write narrow rules without applying every rule to every action. > **Example.** An insurer can apply the relevant privacy rules to each customer across several countries. ### Frequently asked questions
How does the Policy Engine decide which rules apply to an action? Routing uses the context attached to the action, such as which agent is acting, the tool it's using and the data involved. Controls authors set the scope of each rule when they write it. An action is routed to every rule whose scope matches its context.
What if an action matches no rules? The action is allowed, and the compliance receipt records that no rules applied. If you'd rather hold these actions, add a catch-all rule so anything unmatched goes to a person instead.
Can two rules that apply to the same action disagree? Yes. When rules disagree, the most cautious decision wins: a refusal beats a hold for a person, and a hold beats an allow. The compliance receipt records every rule that applied and its individual result, so a verifier can see how the final decision was reached.
Can I test how an action would be routed before enforcing a rule? Yes. In Compliance Studio you can switch a new rule on in shadow mode first. A rule in shadow mode is evaluated and its result recorded in the compliance receipt, but it does not affect the decision.
## Sovereignty **Compliance Studio and the Solcis Policy Engine run in your infrastructure, including air-gapped deployments.** Many of the organisations that most need agent governance can't send action payloads to an external service. Government agencies, financial institutions and critical infrastructure operators are often bound by data residency rules, classification requirements or regulator expectations. Both products run entirely in your infrastructure. Every component, including the AI check, can run in an air-gapped deployment: one with no network path to or from the deployment. You choose and host the model used for the AI check. **Result:** both products are fully self-hosted and can be run air-gapped.
ComponentRuns inData handledLeaves the deployment?
Where actions are checked (Solcis Policy Engine, Solcis Gateway or your own gateway, NVIDIA OpenShell, Microsoft AGT)Customer's environmentAction payloads, decisionsNo
AI checkCustomer's environment, using a customer-hosted modelAction payloadsNo
Evidence ledger (Compliance Studio)Customer's environment, on customer-managed storageCompliance receiptsNo
Compliance StudioCustomer's environmentConfiguration, rules, runtime policiesNo
Licensing (Compliance Studio)Customer's environmentLicence entitlement fileNo
### What this unlocks * **Governance for sensitive workloads.** Government, financial, and critical infrastructure deployments can govern connected actions without sending payloads to a third party. * **Data stays in your environment.** Action payloads, decisions, and compliance receipts stay where the deployment runs. Your legal team confirms applicable obligations. * **Your model.** You choose and host the model used for the AI check. > **Example.** A government department can check and record agent actions inside its network, with no network path out. ### Frequently asked questions
How does licensing work when there is no network path out? Your Compliance Studio licence is a signed file you load into Compliance Studio. It says what you're entitled to and for how long, and Compliance Studio checks it locally. When it's due for renewal, you load a new file. Compliance Studio never contacts a licensing service.
Which models can I use for the inference step in an air-gapped deployment? Any suitable model you can run inside your deployment using common model-serving tools. You manage models in Compliance Studio, with a curated model list, routing and model performance. In an air-gapped deployment, the model runs entirely inside your environment.
## Size **The Solcis Policy Engine runs where connected AI systems run, including edge environments.** Agents are moving out of the data centre and into physical systems: robots, industrial controllers, vehicles and satellites. These environments have limited memory and compute, intermittent or no connectivity, and no room for a full server stack. Governance has to run where the agent runs. The Solcis Policy Engine is designed for edge and embedded hardware. Evaluation happens on the device, with no call to an external service. **Result:** the Solcis Policy Engine can run alongside the agent, from a data centre to edge hardware. ### What this unlocks * **Governance where the agent runs.** Robots, industrial controllers, and vehicles can evaluate actions on the device. * **Enforcement through disconnection.** Remote sites keep their controls when a link drops. * **The same rules everywhere.** Controls can apply in the data centre, at the edge, and on embedded hardware. > **Example.** At a remote mine site, autonomous equipment can continue following controls when connectivity drops. *** ## Underpinned by the evidence ledger **A record written before an action is evidence. A record written after it is a story.** Every action the Policy Engine evaluates produces a compliance receipt. It records the action, the applicable rules, the decision, and the time in UTC. It also identifies the control and framework requirement behind the decision. Receipts are written before the action proceeds. The evidence ledger is tamper-evident. Each receipt is digitally signed and linked to the previous receipt. Changing or deleting a record breaks the chain and exposes the change. A verifier can detect whether a receipt was altered or removed after it was written. The ledger alone cannot show whether every AI system was connected. The coverage view in Compliance Studio shows what the Solcis Policy Engine governs and what remains outside the enforcement boundary.
--- # 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/four-engineering-problems-solved.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.