Skip to main content

Enforcement

Enforcement is where governance takes effect. Whenever a governed workload goes live (deployed, started, launched, or created when creating it runs something), the platform checks the solutions that contain it and blocks the action while any requirement that gates its type is pending or failed. The resource types table lists exactly which action is checked for each type.

How the check works​

  1. Find the solutions. Every solution that lists the workload, either by itself or through "All type resources". A workload in no solution is never blocked.
  2. Collect the requirements. For each published policy on those solutions, walk the stages in order. A stage applies once it, or any earlier stage, gates the workload's type. Every required field and gate of an applying stage is a requirement. Inactive and draft policies are skipped.
  3. Decide. The action goes ahead when every collected requirement is satisfied or waived. Otherwise it is blocked, with the list of what is pending or failed and the solutions that block it.

In an installation with several organizations, only the solutions of the resource's own organization apply to its go-live, whoever performs it: an administrator deploying another organization's app is governed by that organization's solutions.

Resolving a blocked go-live​

When an action is blocked in the platform, a Governance requirements window opens instead of an error:

  1. A banner names the resource and says the action (for example Deploy, Start, Create) is blocked until the requirements below are complete.
  2. Progress shows satisfied, pending, and failed requirements.
  3. The requirements are listed per blocking solution with the same forms as the solution page: enter values, tick acknowledgments, submit metrics, upload evidence, verify guardrails, and request approvals. Only the requirements that block this resource type are listed.
  4. Approval gates notify their reviewers when requested. The window updates as requirements change.
  5. When everything is satisfied or waived, click Retry action (for example Retry Deploy). If the action then fails for a different reason (a budget limit, for example), that error is shown instead.

If more than one blocked action is waiting, the window shows how many are queued behind the current one.

You can also complete requirements before going live, from the solution page. See Compliance.

Waiving a requirement​

Administrators can waive a requirement to record a documented exception:

  • On the solution page, click Waive on the requirement, enter a Reason, and click Confirm waive.
  • A requirement can be waived once it has been submitted at least once (for an approval gate, once approval has been requested).
  • A waived requirement counts as satisfied for the solution's status and for enforcement. The waiver records who waived it, when, and the reason, shown on the requirement and in the audit log.
  • Submitting the requirement again replaces the waiver with the new submission.

Use waivers for justified exceptions instead of removing a policy or workload from the solution, so the exception stays visible to auditors.

Checking a resource ahead of time​

The same check can be run without going live, for example from a CI pipeline, with the REST API:

GET /api/v1/governance/enforcement/check?resourceType=app&resourceId=<app id>&organizationId=<the app's organization id>
X-API-Key: <your API key with governance:read>

The response says whether the resource is allowed, gives a message such as Deploy blocked: 2 pending requirements in solution "Support Assistant"., and lists pendingGates, failedGates, satisfiedGates, waivedGates, and blockingSolutions. See the API reference or client.governance.enforcement_check(...) in the Python SDK.

AI Gateway models​

For AI Gateway Model workloads the check runs on every request made to a model through the AI Gateway, not once at deploy time. While a solution containing "All AI Gateway Model resources" has open requirements that gate AI Gateway models, requests are refused with a governance error that lists the pending requirements. Self-hosted ML Model workloads are checked the same way on gateway requests, in addition to their deploy.

Best practices​

  • Introduce blocking gradually. Start with stages that gate nothing, so teams see and complete requirements without being stopped, then gate the stages that matter.
  • Keep blocks actionable. Gate names, labels, and descriptions are exactly what a blocked person sees. Prefer requirements people can complete or trigger themselves.
  • Avoid single points of failure. Use role or group reviewers so one absent person cannot block every release.
  • Handle exceptions deliberately. Waive with a reason rather than removing policies, and review waivers and admin overrides in the audit log. Frequent waivers on the same requirement mean the policy needs adjusting.
Important

Only a stage's Gated Resource Types (carried forward to later stages) decide what is blocked. A policy that gates nothing never blocks a go-live, however many requirements are open.