Enforcement

The enforcement engine evaluates governance compliance at deploy time. When you deploy a workload, the platform checks every solution that contains it, walks the applied policies' stages, and blocks the deploy if any requirement that gates the workload's resource type is pending or failed.

How Enforcement Works

Deploy Request
    ↓
┌──────────────────────────────────────────┐
│  1. Find solutions containing this       │
│     workload (by type + id)              │
├──────────────────────────────────────────┤
│  2. For each active, published policy    │
│     on those solutions, walk the stages  │
│     in order                             │
├──────────────────────────────────────────┤
│  3. A stage applies once its (or any     │
│     earlier stage's) gated resource      │
│     types include this workload's type   │
├──────────────────────────────────────────┤
│  4. For every applying stage, require:   │
│     - every required field submitted     │
│       and satisfied                      │
│     - the stage gate (if any) satisfied  │
│       or waived                          │
├──────────────────────────────────────────┤
│  5. Any pending or failed requirement    │
│     → deploy blocked                     │
└──────────────────────────────────────────┘
    ↓
Allowed / Blocked (with the full requirement list)

A workload that belongs to no solution has no governance applied and always deploys. Draft or inactive policies are skipped.

Enforcement Result

The enforcement check returns a structured result:

Field	Type	Description
allowed	Boolean	Whether the deploy can proceed
message	String	Human-readable summary, e.g., Deploy blocked: 2 pending requirements in solution "Production ML Pipeline".
pendingGates	Array	Requirements not yet submitted or awaiting approval
failedGates	Array	Requirements that failed (denied, missed threshold, failed validation)
satisfiedGates	Array	Requirements already met
waivedGates	Array	Requirements waived by an administrator
totalGates	Number	Total requirements evaluated
blockingSolutions	Array	The solutions whose requirements are blocking, with names

Each entry in the gate arrays describes the requirement: its gate kind, name, policy, stage, current status, and (where applicable) approval progress, threshold progress, or evidence progress.

Resolving a Blocked Deploy

When a deploy is blocked, the deploy dialog switches to a Governance requirements view instead of failing outright:

1. A banner explains the workload cannot be deployed yet
2. A progress bar shows satisfied / pending / failed requirements
3. Requirements are listed per blocking solution with the same inline forms used on the solution page: enter inputs, tick acknowledgments, submit metrics, upload evidence, verify guardrails, or request approval
4. Approval gates notify their reviewers automatically; the view updates live as reviewers act
5. Once every requirement is satisfied or waived, click Retry to run the deploy

You can also complete requirements ahead of time from the solution's detail page; see Compliance.

Waiving Requirements

Administrators can waive any requirement:

• A written reason is required
• The requirement's status becomes waived and counts as satisfied for both compliance status and deploy checks
• The waiver records who waived it, the reason, and when, and is written to the audit trail

Use waivers for documented exceptions instead of removing policies or workloads from a solution: the exception stays visible to auditors.

Guardrail Compliance

Two mechanisms connect governance to AI guardrails:

1. Guardrail gates. A policy stage can include a guardrail gate listing required guardrail IDs. The developer verifies the guardrails are configured on their AI Gateway model to satisfy the gate, and the verification is recorded with the submission.
2. Gateway-side compliance checking. The AI Gateway checks models that belong to governance solutions against their policies' required guardrails. When a required guardrail is missing from a model's configuration, a policy violation is logged to the governance audit trail.

Checking Enforcement via the API

The same check that runs at deploy time is available on demand:

GET /api/v1/governance/enforcement/check?resourceId=<id>&resourceType=<type>

Authenticate with your X-API-Key. The response is the enforcement result described above, so CI pipelines can verify a workload is deployable before attempting the deploy. Resource types are the same keys used by policies: app, workflow, addon, dataSource, volume, mlModel, aiGatewayModel, workspace, project.

Best Practices

Introduce Gating Progressively

• Start policies with stages that gate no resource types; they collect data and track compliance without blocking anyone
• Add gated resource types to the stages that matter once teams have completed the requirements at least once
• Keep the blocking stages few and meaningful; every gated stage is a deploy prerequisite

Keep Blocks Actionable

• Write clear gate names, labels, and descriptions; they are exactly what a blocked developer sees
• Prefer gates the developer can complete or trigger themselves (inputs, acknowledgments, evidence, approval requests)
• Configure approval gates with role or group reviewers so a single absent person cannot block all deploys

Handle Exceptions Deliberately

• Use admin waivers, with reasons, for justified exceptions
• Review waivers and admin approval overrides in the audit log; frequent waivers on the same gate suggest the policy needs adjustment

Important

Blocking is determined solely by each stage's Gated Resource Types. A policy with no gated resource types never blocks a deploy, no matter how many requirements are open. Verify your critical policies gate the resource types they are meant to protect.