Compliance

Compliance is tracked on solutions. A solution is a named group of workloads with policies applied to them. Every requirement of those policies is tracked on the solution, the solution's status is computed from them, and every action is recorded in the audit log.

Solutions

A solution usually represents one product or capability, for example "Customer Support Assistant": the app, the workflows, and the models behind it, plus the policies they must meet before going live.

The Solutions page

Governance > Solutions lists the solutions you own (administrators see all of them), most recently updated first, with a search box. Each row shows the number of workloads and policies, the status, and the last update. Click a row to open the solution, or the delete button to delete it.

Creating a solution

1. Click Create Solution.

2. Under Solution Details, enter a Name (required) and a Description.

3. Under Workloads, choose a Workload type, then:

   • click Add next to All type resources to govern every resource of that type, including ones created later, or
   • for types where individual resources can be picked (apps, workflows, add-ons, workspaces, volumes, projects, ML models, fine-tuning jobs, AutoML jobs), search and click Add next to specific resources.

   Selected workloads appear under Selected workloads; click one to remove it.

4. Under Policies, search and click the policies to apply. Only published policies (Active, not drafts) are listed.

5. Click Create Solution.

A solution can be created empty and filled in later from its page.

The solution page

Section	What it shows and does
Header	The name and description (click the pencil to edit them), the status, and Delete.
Compliance Progress	Requirements satisfied out of the total, with the number failed and pending.
Workloads	Each workload with its type. Add Workload opens the same picker as Create Solution; the remove button takes a workload out of the solution (it is no longer governed by it).
Applied Policies	Each policy with its category, severity, and number of stages and requirements. Add Policy lists the published policies not yet applied. Removing a policy also deletes its submissions and evidence on this solution.
Gate Requirements	Every requirement, grouped by policy, with a form to complete it.

Deleting a solution deletes its submissions and evidence files; its workloads stop being governed by it. The deletion is recorded in the audit log.

Completing requirements

Each requirement in Gate Requirements shows its name, a red asterisk (it is required), its status (Pending, Satisfied, Failed, or Waived), and its kind:

Kind	What you do
Input (required fields and input gates)	Enter the value (text, number, date, URL, email), pick an option from the list, or tick the options that apply, then Submit. Values are checked against the field's rules; a value that breaks one is marked Failed with the reason, and you can correct it and submit again.
Acknowledgment	Read the statement, tick the box, and Submit.
Approval	Click Submit for approval. Reviewers are notified; progress shows how many reviewer entries have approved. See Stages & Reviews.
Threshold	Enter the metric value and Submit. The card shows the requirement (for example gte 0.9); a value that does not pass is marked Failed until a passing value is submitted.
Evidence	Choose a file; it uploads immediately. The card shows the allowed file types, the maximum size, the minimum number of files, and the expected documents. Uploaded files are listed with download links and can be removed until the requirement is satisfied.
Guardrail	Check that the listed guardrails (and minimum filter level) are configured on your AI Gateway model, then click Verify guardrails.

Administrators also see Waive on any requirement that has been submitted. See Enforcement.

The solution page is available to the solution's owner and administrators. Anyone else the solution governs (people in the same organization as the solution, or everyone in a single-organization installation) completes its requirements in the Governance requirements window that opens when their go-live is blocked, or through the API.

Solution status

The status is recomputed after every submission, decision, waiver, and policy change:

Status	Meaning
Compliant	Every requirement is satisfied or waived, or the solution has no published policies.
Non-Compliant	At least one requirement failed (a denial, a missed threshold, or a value that broke a field rule).
In Progress	Nothing failed, but requirements are still pending.

Requirements come only from published policies. Deactivating a policy or turning it back into a draft removes its requirements from the solution's status (and from enforcement) until it is published again.

Evidence

Evidence gates take real file uploads:

• The gate can restrict file types (by extension) and size; the platform limit is 50 MB per file.
• Each file is stored by the platform and attached to the requirement with its name, type, size, uploader, and upload time.
• Each file has a download link, available to everyone who can see the solution's requirements (including reviewers on the Reviews page).
• Removing a file returns the requirement to Pending if fewer files than the minimum remain.
• Evidence files are deleted with their submissions when the policy is removed from the solution, the solution is deleted, or the policy is deleted.

Audit log

Every governance action is recorded. Administrators view the trail at Governance > Audit Log.

The Audit Log page

The page shows the most recent entries, newest first (choose Limit 50, 100, or 200), with:

• a search box matching the entity's name, the user, the entity ID, and the action,
• an entity filter (policy, solution, gate-submission, notification),
• an action filter listing the actions present in the loaded entries.

Each row shows when, who, the action, the entity by name (the policy or solution name, or solution / policy / gate for a requirement; hover over it to see its ID), and an excerpt of the details.

What is recorded

Entity	Actions
policy	created, updated, deleted
solution	created, updated (name or description), workload_added, workload_removed, policy_added, policy_removed, deleted
gate-submission	gate_submitted, gate_approved, gate_denied, gate_conditional, gate_waived; an administrator reversing an already-decided gate is recorded as gate_approved_admin_override or gate_denied_admin_override; reviewers_orphaned_after_policy_edit when a policy edit removes a reviewer who had already voted

Each entry records who acted, when, and the details: the state before and after for policy and solution changes, and the solution, policy, gate, status, comments, and reason for gate actions. Entries are kept when the policy or solution they describe is deleted.

The audit trail is also available through the REST API (GET /api/v1/governance/audit, administrator API key with governance:read) with a search and filters for entity, solution, action, user, and date range. See the API reference.

Regulatory compliance

Mapping a framework to policies

1. List the obligations of the framework that apply to you.
2. Turn each into a stage requirement: a required field for facts, an acknowledgment for attestations, an evidence gate for documents, a threshold for measured controls, an approval for sign-offs.
3. Tag the policies with the framework (soc2, hipaa, gdpr, iso-27001, pci-dss, and so on).
4. Group the in-scope workloads into solutions and apply the policies.
5. Gate the resource types that must not ship until the obligations are met.

What auditors can see

Record	What it shows
Policy definitions and versions	Which controls exist, and when they changed
Requirement submissions	What was submitted, by whom, and when
Approval decisions	Who approved or denied, with comments and times
Evidence files	The documents themselves
Waivers	Each exception, with the administrator and the reason
Audit log	The full history of governance actions

Best practices

• Group workloads by product or capability, and give solutions names reviewers will recognize: they appear on the Reviews page and in blocked go-live messages.
• Apply the smallest set of policies that covers the obligations.
• Remove workloads that leave a solution's scope so they are no longer governed by it.
• Prefer waivers with reasons over deleting policies to unblock a release.
• Review admin overrides and orphaned-reviewer entries during audits; they flag decisions that deserve a second look.