After bundles are approved through the governance lifecycle, gates enforce those approval requirements by controlling specific user actions in real time.
Gates help teams limit risk, automate compliance, and respond quickly to policy changes. Gating decisions are applied automatically and recorded for audit.
Governance Admins define gates in policies to control actions based on parameters such as hardware tiers or data planes. When a policy with gates is attached to a project, Domino evaluates any actions at creation and on restart. Users are blocked from completing these actions until the required approval is granted.
Common use cases include:
-
Blocking GPU or high-cost hardware tiers until reviews are complete
-
Controlling deployments to specific data planes
-
Rechecking approval status on restart to maintain compliance
Gates apply only to governed actions in projects where a bundle with gating policies has been attached.
Governance Admins define gates as part of a policy using YAML. Each gate includes:
-
One or more rules that define the governed action and its parameters
-
A list of required approvals for the action to proceed
- Example: Define gates in YAML
-
In this example, the gate blocks creation of apps that use the
large-k8sorgpu-small-k8shardware tiers unless theValidation sign offstage has been completed:
gates:
- name: Prod
rules:
- action: CreateApp
parameters:
hardwareTierId:
- large-k8s
- gpu-small-k8s
approvals:
- Validation sign offWhen a practitioner attaches a bundle with gating policies to a project, the system begins enforcing the gate rules. Only governed actions and parameters are affected. All other activity proceeds normally.
Gates remain active as long as the bundle is attached and the policy requires the relevant approvals.
When a user attempts a governed action, the system evaluates gate rules in real time. If the action and its parameters match a gated rule, the system checks for approval before allowing it to proceed.
-
During creation: invalid configuration options are blocked in the UI
-
On restart: users receive an error if a previously approved configuration no longer meets policy requirements
| Action | Result |
|---|---|
User creates an app using allowed settings | Action proceeds |
User selects a gated hardware tier without approval | Action is blocked |
Approval is granted after creation | Gated actions become allowed |
Approval is revoked after creation | Gated actions are blocked on restart |
Gating is enforced by two internal services:
-
Governance Service: manages policies, approvals, and gate definitions
-
Rules Service: applies gate logic and determines whether to allow or block actions in real time
Gate rules are stored in the shared governance database. When a policy is activated, the Rules Service sets all governed actions to "deny" by default. Actions are allowed only after the required approvals are granted.
All rule evaluations and gating outcomes are:
-
Recorded in the Audit Log
-
Tracked in MixPanel to support compliance reporting and usage analysis
-
Governance lifecycle shows you how governed bundles progress from creation to production readiness.
-
Create governed bundles describe how to create governed bundles.
-
Automated evidence collection runs validation checks as bundles progress through approval stages.
-
Monitoring checks respond to drift and data quality alerts from deployed models.
