> 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/understand-your-coverage.md).
# Understand your coverage
A control you can't see the edges of isn't a control. Compliance Studio shows you exactly which AI systems and actions are enforced, and which aren't.
You can't control what you can't see. The first thing a compliance manager needs to know about enforcement isn't what the rules say. It's which AI systems and which actions the rules actually reach.
Solcis is explicit about this boundary. The Solcis Policy Engine governs the actions that pass through it; Compliance Studio shows you which those are.
## The boundary of enforcement
An action is governed when it passes an enforcement point. The Solcis Policy Engine enforces on the action path and at model, tool and MCP endpoints; the Solcis SDK is how you place it on an AI system's action path. Gateways, your own or the Solcis Gateway, put enforcement in the traffic path. NVIDIA OpenShell and Microsoft AGT enforce security and infrastructure controls, and Compliance Studio can supply them enforcement policies and collect their decisions and evidence. Actions that don't pass through any enforcement point aren't evaluated and aren't recorded.
That sounds like a limitation. It's the opposite. A product that implied it governed everything would be making a claim no one could test. Compliance Studio states the boundary exactly, so you can measure your coverage against your AI estate and close the gaps you find.
## Coverage you can read
Compliance Studio records which AI systems are connected, which connections are active and which policies are enforced on which paths. The result is its coverage map: a statement of what's governed, what's in shadow and what isn't connected at all.
Each enforcement path has a state. A policy in shadow evaluates every matching action and records what it would have decided, without affecting the action. A policy that's enforced changes what happens. A connected path with no policy applied is visible as exactly that. The states are named, and they appear in the compliance receipts, so an auditor can tell them apart.
## Scope isn't set by a latency budget
Compliance scope is set by how much checking a system can do quickly. A control that adds noticeable time to every call gets scoped down. Somebody decides which paths are important enough to inspect, and everything else runs uninspected. The gap between "what we govern" and "what we say we govern" opens there, quietly.
The Solcis Policy Engine runs where your AI systems run, in your infrastructure. There's no round trip to a remote hosted service, so there's no reason to scope enforcement down to the paths somebody thought were important. The checking work is done by a deterministic check and by a model you host. Both are next to the workload.
## What coverage lets you say
With a coverage map, the answer to "what are our AI systems allowed to do?" becomes specific. You can say which AI systems are connected, which controls apply to them, and which actions are denied, escalated or rated. You can also say, honestly, which aren't connected yet. A board or regulator that hears both halves of that answer is hearing something they can rely on.
Without one, the answer is a policy document and a hope.
## What coverage doesn't prove
The evidence ledger records what passed through the Solcis Policy Engine (and other enforcement points). It can't record what didn't. A complete ledger proves that every connected action was evaluated. It doesn't prove that every AI system in your estate was connected. That's why the coverage map exists alongside the ledger: one says what was governed, the other says what was decided.
{% columns %}
{% column width="41.66666666666667%" %}
{% endcolumn %}
{% column width="58.33333333333333%" %}
#### **A question unanswered?**
Access locked content, licensing, procurement, or anything else. Tell us what you're trying to do and a person will reply.
Contact us
{% endcolumn %}
{% endcolumns %}
---
# 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/understand-your-coverage.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.
