Define policies

Policies define review and approval workflows for deliverables, such as models, reports, and AI systems. Use policies to codify internal risk controls, regulatory frameworks, or corporate standards across your organization.

Only Governance administrators can create, edit, or publish policies. Roles and security has details on role assignment.

You can build policies in two ways:

  • Policy Builder: A visual UI for defining policies step-by-step

  • YAML: A code-based method for advanced customization

Once published, policies enforce compliance at runtime when applied to governed bundles.

Use cases for policies

Policies can:

  • Require approvals before releasing models or reports

  • Capture evidence and risk classifications during review

  • Show or hide questions based on input

  • Define multi-stage workflows with approvers and conditions

  • Use gates to restrict specific actions, such as publishing apps or creating model endpoints, until all required approvals are complete

Create a policy

You can create a policy either from scratch or by using an existing template. Both methods allow you to use the Policy Builder UI or the Code editor.

Start a new policy

Follow these steps to begin defining your policy:

  1. Go to Govern > Policies, then click Create Policy.

  2. Choose None (start from scratch) or choose a policy template.

  3. Enter a name and description and click Create.

Choose a view

Once created, the policy opens in the Policy Builder by default. You can switch between these views at any time:

  • Policy Builder (UI editor): Guided form for building stages, rules, and questions

  • Graph view: Visual overview of the policy’s workflow

  • Code editor: Raw YAML editor for advanced configuration

Note: If editing YAML directly, remember to replace user-organization-name with your organization’s name to correctly assign approvers.

Policies are written in YAML and must be published before use. Build governance policies in our documentation has more building blocks for advanced customization.

Use the Policy Builder

The Policy Builder is a guided interface for defining policy components without writing YAML.

Governance Policy Builder

In this UI editor, you can:

  • Define policy stages such as validation or deployment

  • Assign approvers to each stage

  • Add evidence questions approvers must answer

  • Add scripted checks for model validation

  • Configure classification and visibility rules

Domino automatically generates YAML behind the scenes as you work in the builder. You can view or modify this YAML in the Code editor at any time.

Define rules and logic

You can use rules to evaluate evidence, classify policy executions, and control which sections of a policy are shown to users. Classification and visibility rules often work together. For example, a classification rule can drive a visibility rule.

Classification rules

You can use classification rules to apply tags or labels to a policy execution based on collected evidence. These outputs can:

  • Trigger downstream rules

  • Influence policy bundle matching

  • Inform audit or compliance filters

Policy components has YAML configuration details and examples for classification rules.

Visibility rules

Visibility rules can be applied to sections of a policy, such as to show or hide specific stages or questions based on earlier responses. Use the eye icon in the section header to define a visibility condition.

Visibility Rules Form

To configure a rule:

  • Choose the input question to evaluate

  • Specify the value that must be selected to make the section visible

Use a custom visibility rule if you need to:

  • Reference more than one input question

  • Use classification values to control visibility

Custom visibility rules can reference the output of a classification rule. This allows you to show or hide sections based on computed logic, not just raw inputs.

Policy components has YAML configuration details and examples for visibility rules.

About gating

Gating controls when certain operations are allowed based on policy status. For example, you can block a user from publishing an app until all stages in the associated policy bundle are approved.

Gates must be defined in YAML. Gates has details about how gates work and how to define them.

Create a new version of a policy

You can modify a published policy by creating a new version. The new version remains in draft until it is published.

When publishing the new version, you can:

  • Choose whether the update is mandatory or optional for bundles using an earlier version

  • Select which bundles will be affected

  • Decide whether to retain or revoke existing approvals

Domino displays a list of bundles using the current version. If you mark the update as mandatory, you must select which bundles it applies to. Those bundles will be marked out of compliance until upgraded.

You can choose whether to retain or revoke existing approvals. Only revoke existing approvals if the new version includes significant or breaking changes.

Mandatory version update

When publishing a mandatory update:

  • Select the bundles that must upgrade during the publish step

  • Affected bundles will be blocked from further edits until upgraded

  • To upgrade a bundle, open it and click Upgrade Policy in the warning message

Optional version update

For minor or non-blocking changes, you can publish the new version as an optional update.

  • Bundles governed by the previous version will display a warning that a new version is available

  • These bundles are not blocked and can continue to be edited

Archive policies

You can archive policies to reduce clutter in the policy table. Archived policies:

  • Cannot be restored

  • Do not link to a detail page

  • Only appear when the Archived filter is applied

To archive a policy:

  1. Go to Govern > Policies and find the policy to archive.

  2. Click the … menu next to the policy and select Archive.

  3. If no active bundles use the policy, click Confirm.

  4. If active bundles are using the policy, Domino shows a warning and prevents archival.

Next steps