> 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/understand-solcis/where-solcis-fits-in-your-enterprise-architecture.md).
# Where Solcis fits in your enterprise architecture
How Solcis fits into your enterprise architecture: what it connects to, what moves in and out, and how the Solcis Policy Engine enforces your controls on every action your AI systems take.
Solcis Compliance Studio connects to systems you already run. Your controls come into Compliance Studio from your GRC programme. Escalated actions go to a ticket or a chat message where an authorised person approves or rejects them. Evidence then flows back to your GRC platform, your SIEM, your data warehouse, or anywhere else you need it.
Compliance Studio and the Policy Engine are both containerised and run on your infrastructure. No data leaves your deployment for the Policy Engine to reach a decision, so you keep sovereign control and the decision loop stays fast. The systems Solcis connects to can sit anywhere, on your own infrastructure or in the cloud. You choose which ones to connect and what access each connection carries.
Examples only. Solcis connects only to the systems you choose.
## What connects
Solcis integrates in six areas. Compliance Studio brings in controls, context and discovery, and sends out oversight requests and evidence. The enforcement layer sits in the path of your AI systems.
| Integration area | Solcis product | Systems | Direction |
| -------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ |
| Controls | Compliance Studio | GRC platform, policy repositories, framework libraries, CI/CD | In |
| Context and identity | Compliance Studio | Data classification, identity provider, CMDB, workload identity, approval registers | In |
| Discovery | Compliance Studio | AI security posture management, CASB and SaaS discovery, cloud asset inventory, model gateways, API discovery | In |
| Enforcement layer | Enforcement layer | Solcis Policy Engine (with the Solcis SDK, at model, tool and MCP endpoints); Solcis Gateway or your own gateway; NVIDIA OpenShell; Microsoft AGT | Inline |
| Human oversight | Compliance Studio | ITSM, collaboration | Out and back |
| Evidence and signal | Compliance Studio | SIEM, GRC platform, data warehouse, BI, observability, WORM archive, transparency log | Out |
## Controls
The Solcis Policy Engine enforces the controls your organisation has adopted. Solcis does not write them.
Controls come into Compliance Studio from your GRC platform, your policy repositories, or a framework library. Each control keeps its identifier and its lineage to the framework requirement it satisfies. Where a control has no framework behind it, the decision cites the control and its owner instead.
In Compliance Studio, an AI assistant you choose can help draft rules from your controls. Only a person can approve a rule and promote it to enforcement, after testing it in shadow mode. See [Govern by default](/design-principles/govern-by-default.md).
## Context and identity
A control needs more than its own text to be applied. The Policy Engine needs to know what your data classifications mean, who holds authorisation, and which AI system is making the call. That context comes from your classification scheme, your identity provider and approval registers, and the workload identity of the calling system. Human identity and AI system identity are separate inputs to a Policy Engine decision, and both are recorded in the Compliance Studio evidence ledger.
The Policy Engine evaluates a control two ways. A deterministic check resolves a control against known facts and gives the same answer every time. An inference check uses an AI model you host, chosen from the curated model list in Compliance Studio, and is slower and less repeatable. The more context the Policy Engine has, the more of your controls move from inference checks to deterministic checks.
Where context is connected, the Policy Engine returns a decision. Where context is missing, the Policy Engine does not guess. It holds the action for a person, or denies it, and says what information was missing, so you know what to connect next. See [Understand your coverage](/design-principles/understand-your-coverage.md).
## Discovery
Compliance Studio works with the discovery tools you already use. An AI system whose actions don't pass through an enforcement point is not governed, which is why discovery matters.
A discovery tool identifies an AI system. You register that AI system in Compliance Studio and it is issued a workload identity. You can also register AI systems directly, in Compliance Studio, or through its API as part of your build and deployment tooling. Once its actions go through an enforcement point (the Solcis Policy Engine, the Solcis Gateway or your own gateway, NVIDIA OpenShell or Microsoft AGT), every one is checked.
## Enforcement layer
Actions are checked inline by the enforcement layer. Compliance Studio sends enforcement policies to each enforcement point and receives decisions and evidence back.
The Solcis Policy Engine, called on the action path from your code, suits AI systems you build, because adding it is a code change. The Solcis SDK builds it into your application or agent. The Policy Engine can also enforce at the model, tool and MCP endpoints your AI systems call.
The Solcis Gateway, or your own gateway, sits in the network path and suits AI systems you cannot change, including ones you buy, as long as their calls to models, tools and MCP servers are routed through it. It needs no change to application code.
NVIDIA OpenShell and Microsoft AGT enforce security and infrastructure controls in the agent runtime. Compliance Studio can supply them enforcement policies and collect their decisions and evidence. See [Where Solcis enforces](/where-solcis-enforces.md).
The Solcis Policy Engine evaluates each action and returns one decision: Allow, Deny or Escalate, each with a severity rating, before the action proceeds. The severity rating is set by the rule's author.
The Solcis Policy Engine writes a compliance receipt for each decision; Compliance Studio's universal evidence ledger collects receipts from every enforcement point. An action that reaches no enforcement point isn't evaluated or recorded; Compliance Studio's coverage and agent discovery show where the gaps are.
## Human oversight
Compliance Studio routes escalated actions to where your people already work: a ticket in ServiceNow or Jira, an approval in Teams or Slack.
The answer returns to the Policy Engine decision and is recorded with it. Who approved, on what basis, against which control, at what time.
## Evidence and signal
Every evaluated action produces a compliance receipt in the Compliance Studio evidence ledger. A compliance receipt is the record of a single decision: the action, the control that drove it, the outcome, and the context the Policy Engine used. The universal evidence ledger in Compliance Studio is the append-only, tamper-evident record of every enforcement decision, and it is the source of truth. Compliance Studio writes evidence out to a number of destinations, depending on your requirements, and altering or deleting a record in any of them does not affect the ledger.
| Destination | What goes there |
| ---------------- | -------------------------------------------------------- |
| SIEM | Decisions, with severity |
| GRC platform | Compliance receipts and control coverage |
| Data warehouse | Ledger replication for analysis |
| BI | Reporting over the replicated ledger |
| Observability | Decision latency and enforcement point availability |
| WORM archive | Retention against your obligations |
| Transparency log | Signed fingerprints, for external verification. Optional |
An external transparency log keeps signed fingerprints of your evidence outside your organisation, so nobody, including whoever runs the deployment, can rewrite its history without it showing. Your decision records stay with you, and decisions never wait on the transparency log. The transparency log needs a connection, so it is not available in air-gapped deployments.
## Frequently asked questions
Does Solcis run in my infrastructure or as a hosted service?
Both Compliance Studio and the Policy Engine run in your infrastructure. Solcis is containerised and self-hosted, with no SaaS tier. Every component, including the AI model the Policy Engine uses for inference checks, runs inside your deployment.
Can Solcis run in an air-gapped environment?
Yes. The Policy Engine reaches a decision without any external connection. The only feature unavailable in an air-gapped deployment is the external transparency log, which requires a connection to an outside witness.
Do I have to connect Compliance Studio to my GRC platform?
No, but it is the usual path. Controls can also come from policy repositories, a framework library, or direct entry in Compliance Studio. Connecting a GRC platform lets Compliance Studio keep each control's identifier and framework lineage, so every decision cites the clause behind it, and lets Compliance Studio push evidence back against those controls.
Does Solcis write into my systems?
Compliance Studio writes evidence, not actions. It can create a ticket, post an approval request, or write compliance receipts back to your GRC platform, under credentials you issue to destinations you configure. Neither the Policy Engine nor Compliance Studio performs the action it was asked to govern.
What happens when Solcis is missing the context a control needs?
The Policy Engine does not guess. It holds the action for a person or denies it, and names the connection that would have answered the question.
For how Solcis sits against other approaches, see [How Solcis compares](/how-solcis-compares.md) and [The Solcis Guarantee](/the-solcis-guarantee.md).
---
# 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/understand-solcis/where-solcis-fits-in-your-enterprise-architecture.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.
