Governance
Governance controls what is allowed to go live on the platform. You write policies that describe what must be true before something ships (facts to record, statements to acknowledge, metrics to hit, documents to upload, reviewers who must approve). You apply those policies to a solution: a named group of the workloads you want to govern. From then on, every time one of those workloads goes live (a deploy, a start, a launch, a create that runs something), the platform checks the solution's requirements and blocks the action until they are complete.
How it fits together
| Concept | What it is |
|---|---|
| Policy | A reusable set of ordered stages. Each stage can collect form fields, can require one gate (acknowledgment, approval, threshold, evidence, input, or guardrail), and can gate resource types, meaning it blocks them from going live. See Policies. |
| Solution | A group of workloads (specific resources, or every resource of a type) plus the policies applied to them. See Compliance. |
| Requirement | Every required field and every gate of every applied policy becomes a requirement on the solution, with a status: pending, satisfied, failed, or waived. |
| Enforcement | At go-live, the platform finds the solutions containing the workload and blocks it while any requirement that gates its type is pending or failed. See Enforcement. |
| Review | Approval gates are decided by the reviewers you name (users, roles, or organization groups) on the Reviews page. See Stages & Reviews. |
| Audit trail | Every policy, solution, and requirement action is recorded for administrators. See Compliance. |
A policy on its own does nothing. It takes effect when it is published (Active and not a draft) and applied to a solution that contains the workloads you want to govern.
Where to find it
Governance is in the sidebar under Governance:
| Page | What you do there |
|---|---|
| Solutions | Create solutions, add workloads and policies, complete requirements, upload evidence. This is also the Governance landing page. |
| Policies | Browse, create, edit, and delete policies in the Policy Builder. |
| Reviews | Approve or deny the approval gates you are a reviewer for. |
| Audit Log | The governance audit trail. Administrators only. |
When a go-live is blocked anywhere in the platform (for example Deploy on an app, Start on a workspace, Create on an avatar), a Governance requirements window opens right there so the requirements can be completed and the action retried. See Enforcement.
Resource types you can govern
A solution can include any of these workload types, and a policy stage can gate any of them. For types marked type level only, you add "All type resources" to a solution instead of picking individual resources, because the resource does not exist until the action that governance checks.
| Type | Key | Checked when | How you add it to a solution |
|---|---|---|---|
| App | app | The app is deployed | Pick apps, or all apps |
| Workflow | workflow | The workflow is deployed (including deploying a version, or promoting a workflow to an agent) | Pick workflows, or all workflows |
| Addon | addon | The add-on is created (creating it deploys it) or deployed | Pick add-ons, or all add-ons |
| Workspace | workspace | The workspace is deployed, started for the first time or after an error, or launched from its project (resuming a stopped workspace is not checked again) | Pick workspaces, or all workspaces |
| Volume | volume | The volume is created | Pick volumes, or all volumes |
| Project | project | A workspace of the project is deployed, started for the first time or after an error, or launched from the project | Pick projects, or all projects |
| ML Model | mlModel | A model is published or deployed from the model registry, AutoML, fine-tuning, or self-hosted serving; requests to a self-hosted model through the AI Gateway | Pick models, or all models |
| Fine-tuning Job | fineTuningJob | The fine-tuning job is created | Pick jobs, or all jobs |
| AutoML Job | automlJob | The AutoML job is created | Pick jobs, or all jobs |
| Data Source | dataSource | The data source is created | Type level only |
| Agent | agent | The agent is started | Type level only |
| Avatar | avatar | The avatar is created | Type level only |
| Job | job | A job run is triggered (manually or by its schedule) | Type level only |
| Code Session | codeSession | The code session is deployed | Type level only |
| A/B Test | abTest | The A/B test is deployed or an experiment is started | Type level only |
| Marketplace App | marketplaceApp | A marketplace app is deployed | Type level only |
| AI Gateway Model | aiGatewayModel | Every request to a model through the AI Gateway | Type level only |
| Workflow Tool | workflowTool | The workflow tool is deployed | Type level only |
| Data Forge Project | dataForge | Data generation is started | Type level only |
"All type resources" governs every resource of that type, including ones created later, for everyone the solution applies to. Use it deliberately: a type-level workload in a solution with open requirements blocks that type for your whole organization (or the whole platform in a single-organization installation).
Getting started
1. Create a policy
Go to Governance > Policies and click Create Policy. Name it, pick a category and severity, tick the Applicable Resource Types, and add stages. In each stage add the form fields to collect, optionally turn on a gate, and tick the Gated Resource Types the stage should block. Turn Active on and switch Draft to Published, then click Save Policy. See Policies.
2. Create a solution
Go to Governance > Solutions and click Create Solution. Name it, add workloads (specific resources, or "All type resources"), select the policies to apply, and click Create Solution. See Compliance.
3. Complete the requirements
Open the solution. The Gate Requirements section lists every requirement grouped by policy, each with its own form: enter values, tick acknowledgments, submit metrics, upload evidence, verify guardrails, and request approvals. The solution's status moves to Compliant when every requirement is satisfied or waived.
4. Review and approve
Reviewers are notified when an approval is requested. They approve or deny it on Governance > Reviews (a denial needs a comment). See Stages & Reviews.
5. Go live
Deploy, start, or create the workload as usual. If requirements are still open, the Governance requirements window lists exactly what blocks it, lets you complete it in place, and enables Retry once everything is done. See Enforcement.
Who can do what
| Action | Who |
|---|---|
| Create a policy or a solution | Any user with access to Governance |
| See a policy | Its creator and administrators. Published policies are visible to everyone in your organization (or everyone, in a single-organization installation) so they can be applied. |
| Edit or delete a policy | Its creator or an administrator. A policy applied to any solution cannot be deleted. |
| See and change a solution (name, workloads, policies, delete) | Its owner and administrators |
| See and complete a solution's requirements | Everyone the solution can govern: users in the same organization (every user in a single-organization installation), plus the owner and administrators. This is what lets a developer whose go-live is blocked by someone else's solution finish the requirements. |
| Decide an approval gate | The reviewers named on the gate. Administrators can decide any approval gate at any time, and their decision settles it. |
| Waive a requirement | Administrators only, with a written reason |
| View the audit log | Administrators only |
Administrators see every policy and solution across all organizations.
Regulatory frameworks
Policies are a general mechanism: model each obligation of a framework as a stage requirement, gate the resource types that must not ship until it is met, and the platform tracks completion and keeps the evidence and decisions. Tag policies with the framework (for example soc2, hipaa, gdpr, iso-27001) to find them later. See Regulatory compliance and the EU AI Act guide.
Automating governance
Everything on these pages is also available through the REST API (authenticate with an X-API-Key that has the governance:read / governance:write scopes) and the Python SDK.
Introduce blocking gradually. Start with stages that gate nothing, so teams see and complete the requirements without being stopped, then tick Gated Resource Types on the stages that matter once the process is working.