Policy components

Governance lets you define how projects are reviewed, approved, and classified using policies written in YAML. These policies are managed in the Governance Console and applied to governed bundles to enforce consistent, auditable workflows. Each policy defines what evidence needs to be collected, who must approve it, how risk is assessed, and whether any warnings or gates should apply. Once a policy is published, it can’t be edited. This guarantees that any bundle stays tied to the exact policy version it was approved under. Only Governance administrators can create or edit policies. Roles and security has details and role assignment steps.

How policies are written

Policies are defined in YAML using a modular structure. Each policy is made up of components like stages, approvals, inputs, and checks. Each component is declared with an artifactType and a details section that sets its behavior. Writing policies in YAML makes them easy to version, reuse, and review, whether you’re building one from scratch or editing an existing template.

What this page covers

This page explains how to define each type of policy component using YAML. It includes examples for:

Organizing stages and approvals
Grouping and reusing evidence
Running metrics checks and scripted checks
Creating input fields and guidance elements
Defining classification logic and visibility rules
Gating high-risk actions

Stages

Governance Admins define stages in YAML to organize evidence and approvals. Each stage can include:

One or more evidence sets (for direct evidence)
One or more approvals, each with a name, list of approvers, and optional evidence

You can assign multiple approvers to any stage or bundle, as long as they are already members of the project. Example: Define stages in YAML
This example defines two stages by name:

stages:
  - name: stage1
  - name: stage2

Approvals

Approvals are defined within a stage. Each approval includes:

A name
A list of approvers (users or organizations)
Optional evidence, which must be satisfied before approval can be granted

You can assign multiple approvers to any stage or bundle, as long as they are already members of the project. Evidence may be used to support the approval process, but it is not required in all cases. Example: Define an approval with evidence
In this example, the stage includes an approval named Stage 4: validation sign off, which includes a checklist prompt for the approver:

- name: 'Stage 4: validation sign off'
  approvers:
    - model-gov-org
  evidence:
    id: Local.validation-approval-body
    name: Sign-off
    description: The checklist for approvals
    definition:
      - artifactType: input
        details:
          label: "Have you read the model validation reports?"
          type: radio
          options:
            - Yes
            - No

Revalidation

Revalidation schedules are defined within an approval to enforce recurring renewal. See Periodic Revalidation for the full configuration model. Example: Define a revalidation schedule
This example opens a 30-day renewal window, recurring every year starting from January 1, 2026:

revalidation:
  openWindowDaysBefore: 30
  recurring:
    every: 1
    unit: year    # or "month"
    startDate: 2026-01-01T00:00:00Z

Sequential workflows

Sequential workflows define multi-stage approval processes where each stage must be completed before the next becomes available. Stages unlock in order, mirroring real-world review flows and helping maintain control throughout the governance process. Progression is gated by required fields. All mandatory information must be provided before a bundle can move forward, supporting structured, auditable workflows and built-in compliance. Sequential workflows are currently defined in YAML using the enforceSequentialOrder field. Example: Define a sequential approval workflow
The following YAML example enforces sequential approvals across designated approvers within the model-gov-org group:

enforceSequentialOrder: true
approvers:
  - name: model-gov-org
    showByDefault: true
    editable: false

Evidence and evidence sets

Evidence defines the inputs, approvals, or checks required during a stage. You can define evidence directly in a stage, or organize it into an evidenceSet for reuse and clarity. When you define local evidence, it must be declared in full the first time it’s used. Later references can reuse it by id. Example: Define evidence sets
This example defines a local evidence set named sample local evidence:

evidenceSet:
  - id: Local.sample
    name: sample local evidence
    description: Describe the sample local evidence
    definition: Define the evidence

Metrics checks

Metrics checks use model metadata to validate performance against thresholds. These checks run automatically and reduce manual review. Each check supports aliases to match metric names, as well as threshold logic to compare against expected values. Example: Define metrics checks
This check validates model accuracy using multiple aliases and a minimum threshold of 0.8.

metrics:
  - id: Local.model-quality
    name: Model Quality
    description: Validates model accuracy meets minimum standards
    definition:
      - artifactType: metadata
        details:
          type: modelmetric
          metrics:
            - name: Acc
              label: Accuracy
              aliases:
                - acc
                - Correct Classification Rate
                - Percentage Correct
              threshold:
                operator: '>='
                value: 0.8

Scripted checks

Scripted checks run custom validation logic as part of a policy. Each one defines a command, parameters, and expected outputs. The script referenced in command must exist in the project’s files before the check can run. In Git-based projects, commit and push the script to the repository first: Domino can’t run the command until the script is pushed to Git. Scripted checks can also run with user input. Define each input as a text parameter under parameters. When the check runs, Domino replaces the parameter’s ${name} placeholder in command with the value entered at run time, or with the parameter’s default. The example below passes model_hub and model_name to the evaluation script this way. Scripted checks require an environmentID and hardwareTierID.

Environment IDs can be found under Govern > Environments. Select an environment, and the ID is shown as the last part of the URL.
Hardware tier IDs are listed in the Admin Portal, under Manage resources > Hardware tiers.

Contact your administrator if you don’t have access to view these settings. Example: Define scripted checks
This scripted check runs a command-line model evaluation with input parameters and produces text and image output:

- artifactType: policyScriptedCheck
  details:
    name: Ethic and Fairness Evaluation
    label: Ethic and Fairness Evaluation
    command: evaluate_model.py create --model-hub ${model_hub} --model-name ${model_name}
    parameters:
      - name: model_hub
        type: text
        default: openai
      - name: model_name
        type: text
        default: gpt-4
    outputTypes:
      - txt
      - png
    environmentId: [your environmentID]
    hardwareTierId: small-k8s
    volumeSizeGiB: 4

Monitoring checks

Monitoring checks connect governance to Domino Model Monitoring (DMM) to respond to drift, data quality, and other detection alerts. When an alert triggers, governance executes actions like notifications and creates findings with severity levels and owners, with all activity logged for traceability and audit compliance. Example: Define a monitoring check
This monitoring check listens for drift and data quality alerts, then sends notifications and creates findings with assigned owners:

- artifactType: policyMonitoringCheck
  details:
    name: Model Drift Detection
    label: Model Drift Detection
    alertTypes:
      - drift
      - data_quality
    actions:
      - type: notification
        recipients:
          - model-gov-org
      - type: createFinding
        severity: high
        owner: model-gov-org

Input artifacts

Input artifacts define form elements used to collect user input during policy execution. These inputs appear in the governed bundle approval interface and can be used as evidence, classification references, or dynamic visibility triggers.

Radio buttons

Radio buttons present users with a single-select list of labeled options. Each is defined by a display label and submitted value. Example: Define radio buttons
This example defines a radio group with three labeled choices:

- artifactType: input
  details:
    type: radio
    label: "How would you rate the model risk?"
    options:
      - label: "High"
        value: "High"
      - label: "Medium"
        value: "Medium"
      - label: "Low"
        value: "Low"
    tooltip: "Guidance text"

Text inputs

Text inputs collect short, freeform written responses from users. Example: Define text inputs
This example defines a single-line input field with placeholder and help text (helpText):

- artifactType: input
  details:
    type: textinput
    label: "What are the expected business benefits?"
    placeholder: "Explain the benefit"
    helpText: "The text under the input box to help the user"

Text areas

Capture longer, multi-line responses. You can customize the visible height of the input. Example: Define text areas
This example defines a 10-line textarea input:

- artifactType: input
  details:
    type: textarea
    label: "What are the expected business benefits?"
    height: 10
    placeholder: "Explain the benefit"
    helpText: "The text under the input box to help the user"

Select dropdowns

Select dropdowns provide a list of options where only one can be selected. Example: Define select dropdowns
This example defines a dropdown to select a base model template:

- artifactType: input
  details:
    type: select
    label: "Please select the base model template."
    options:
      - label: "base model1"
        value: "baseModel1"
      - label: "base model2"
        value: "baseModel2"

Multi-select dropdowns

Multi-select dropdowns allow selection of multiple options from a list. Example: Define multi-select dropdowns
This example defines a multi-select input for selecting data sets:

- artifactType: input
  details:
    type: multiSelect
    label: "Please select the data sets used in the model."
    options:
      - label: "data set1"
        value: "dataset1"
      - label: "data set2"
        value: "dataset2"
      - label: "data set3"
        value: "dataset3"

Checkbox groups

Checkbox groups display multiple options with checkboxes. Users can select any combination. Example: Define checkbox groups
This example defines checkboxes for department selection:

- artifactType: input
  details:
    type: checkbox
    label: "Please select the departments that will use the model."
    options:
      - label: "Sales"
        value: "DEPT001"
      - label: "Customer Success"
        value: "DEPT002"

Date inputs

Date inputs allow users to select or enter a date. You can specify a start date and format. Example: Define date inputs
This example defines a date input in ISO8601 format:

- artifactType: input
  details:
    type: date
    label: "What is the scheduled release date?"
    startDate: 20240612
    format: ISO8601

Numeric inputs

Numeric inputs collect numbers within a defined range. Example: Define numeric inputs
This example defines an input for F-score with min and max constraints:

- artifactType: input
  details:
    type: numeric
    label: "What is the allowed F-score for the model to be deployed?"
    min: 0
    max: 1

When you assign an aliasForClassification to a numeric input, its answer is available to visibility rules as a number through the numericInputs map.

File uploads

File upload artifacts let reviewers attach a file as evidence in the approval interface. The file is stored in the evidence notebook and automatically uploaded to the project directory. Use file uploads when reviewers must submit supporting documents, such as validation reports or compliance forms. Unlike text inputs, file uploads capture and store the document itself. Example: Define file uploads
This example defines a file input field labeled Model Validation Report. The uploaded file becomes part of the governed evidence.

- artifactType: metadata
  details:
    type: file
    label: Model Validation Report
    description: Upload the model validation report. Make sure the file size does not exceed 500MB.

Guidance artifacts

Guidance artifacts provide informational content to users, such as Markdown-formatted instructions or visual banners. These elements do not collect input but help orient users during policy execution.

Text blocks

Text blocks display long-form guidance using Markdown syntax. Example: Define text blocks
This example shows how to include Markdown-formatted context as part of the policy:

- artifactType: guidance
  details:
    type: textblock
    text: >-
      [Map 1.4](https://ournistpolicyreferenceurl.com) The business value or
      context of business use has been clearly defined or - in the case of
      assessing existing AI systems - re-evaluated.

Text banners

Text banners provide high-visibility messages to users. Example: Define text banners
This example shows how to display a banner with a policy reference:

- artifactType: guidance
  details:
    type: banner
    text: >-
      [Map 1.4](https://ournistpolicyreferenceurl.com) The business value or
      context of business use has been clearly defined or - in the case of
      assessing existing AI systems - re-evaluated.

Classification

Classification is a top-level policy feature used to assign a risk tier (such as low, medium, or high) to a governed bundle. You can base classifications on user inputs, define rules to evaluate them, and display tooltips to guide decisions.

Classification inputs

You can link input artifacts to a classification by assigning an alias. These inputs appear in stages like any other artifact but can be referenced in classification logic. Example: Define classification artifacts
This example defines a radio button input for model risk and links it to a classification alias:

classification:
  rule:
  artifacts:
    - model-risk

stages:
  - name: classificationExample
    artifacts:
      - id: Local.model-risk
        name: Model Risk
        description: Describe the risk of the model
        definition:
          - artifactType: input
            aliasForClassification: model-risk
            details:
              label: "How would you rate the model risk?"
              type: radio
              options:
                - High
                - Low

Classification rules

Use rules to evaluate classification inputs and assign a final label. You can define simple conditions or write custom logic using scripts. Example: Define a classification rule
This example returns "High" if the sum of all input values is greater than or equal to 1:

func() string {
    var sum float64
    for _, value := range inputs {
        sum += value
    }
    if sum >= 1 {
        return "High"
    }
    return "Low"
}()

Example: Complex classification rule
This example classification rule uses evidence values to define whether the classification for this bundle should be "High" or "Low".

classification:
  rule: |
    var ans string
    ans = "Low"
    if classificationInputs["model-risk"].(string) == "High" || classificationInputs["change-type"].(string) == "Major" {
      ans = "High"
    }
    return ans

Note: You can reference this classification output in a custom visibility rule to conditionally show or hide a section.

Visibility rules

Visibility rules control whether certain artifacts, such as evidence sets or individual questions, appear in the interface. You can base visibility on classification outcomes, user input, or any other evaluated condition. Attach a visibilityRule in either of two places:

Inside an artifact’s details block, to show or hide a single question.
On an evidenceSet item, at the same level as definition, to show or hide the entire evidence card.

A visibilityRule is a Go boolean expression. The artifact appears when the expression evaluates to true. Rules can reference four variables, keyed by each input’s aliasForClassification:

Variable	Type	Contains
`classificationValue`	`string`	The bundle’s computed classification.
`inputs`	`map[string]string`	Answers from `radio`, `select`, `textinput`, `textarea`, and `date` questions.
`arrayInputs`	`map[string][]string`	Answers from `checkbox` and `multiSelect` questions.
`numericInputs`	`map[string]float64`	Answers from `numeric` questions.

Rules can also call these helper functions:

slices.Contains(list, value) checks whether an array-typed answer includes a value.
atoi(value) and atof(value) convert a string to an int or float64. Every question type except numeric answers with strings, so use these helpers to compare a numeric-looking string answer, such as a radio option whose value is "3", as a number.

An unanswered question resolves to its zero value: inputs["x"] is "", arrayInputs["x"] is an empty list, and numericInputs["x"] is 0. Example: Show a question based on a numeric threshold
This example shows a follow-up question only when the answer to a numeric question aliased as drift-score is greater than 0.75:

- artifactType: input
  details:
    type: textarea
    label: "Describe the drift remediation plan."
    visibilityRule: numericInputs["drift-score"] > 0.75

Example: Show an evidence set based on classification or a numeric answer
This example hides an entire evidence card unless the bundle is classified High or the model has been in production for more than 24 months:

evidenceSet:
  - id: Local.escalation-review
    name: Escalation review
    visibilityRule: classificationValue == "High" || numericInputs["age"] > 24
    definition:
      - artifactType: input
        details:
          type: textarea
          label: "Document the escalation review."

Example: Combine array membership and numeric conversion
This example shows a question only when the model is deployed in the USA and a radio question whose option values are numeric strings, aliased as authority-level, is at least 3:

visibilityRule: slices.Contains(arrayInputs["regions"], "USA") && atoi(inputs["authority-level"]) >= 3

For multi-step logic, write the rule as a block of Go statements that ends with an explicit return. If the word return appears anywhere in a rule, including inside a quoted string, Governance treats the rule as a full block and the rule must supply its own return statement. Example: Evaluate each element of an array-typed answer
This example shows a question when any selected option, converted to a number, is at least 500:

visibilityRule: |
  for _, v := range arrayInputs["exposure-tiers"] {
      if atoi(v) >= 500 {
          return true
      }
  }
  return false

Gating

Gates define policy controls for high-impact actions, like deploying a published App, Agent, or model Endpoint. Each gate specifies:

What action the gate applies to. The only supported action is Deploy, which covers deploying a published App, Agent, or model Endpoint. Preview deployments of App drafts are not gated.
Which parameter values trigger it, like hardwareTierId or dataPlaneId
What approvals are required for the action to proceed

The CreateApp and CreateEndpoint actions are deprecated. Use Deploy in new policies. Existing policies that use CreateApp or CreateEndpoint are still respected.

Gates are optional but provide a way to prevent risky operations without manual oversight. Before defining a gate, you need to know the valid parameter values for your Domino instance:

Hardware Tier IDs control compute resources like CPU and GPU. You can find available hardware tier IDs in Hardware tiers or by contacting your administrator.
Data plane IDs control where workloads run. You can find available data plane IDs in Data planes or by contacting your administrator.

Example: Define a gate for resource-heavy deployments
In this example, the gate blocks deployment of Apps, Agents, and model Endpoints that use the large-k8s or gpu-small-k8s hardware tiers unless the Validation sign off stage has been completed:

gates:
  - name: Prod
    rules:
      - action: Deploy
        parameters:
          hardwareTierId:
            - large-k8s
            - gpu-small-k8s
    approvals:
      - Validation sign off

Use the any keyword to apply a gate to all values of a parameter. This is useful when you want to gate an action regardless of which hardware tier or data plane is selected. Example: Gate all hardware tiers
This gate blocks deployment on any hardware tier until the Validation sign off stage is complete.

gates:
  - name: Prod
    rules:
      - action: Deploy
        parameters:
          hardwareTierId: "any"
    approvals:
      - Validation sign off

Next steps

Define policies: create and configure policies in the Policy Builder
Gates: control governed actions based on approval status
Roles and security: understand permissions and role assignment in Governance

Core Concepts

Features

Policy components

How policies are written

What this page covers

Stages

Approvals

Revalidation

Sequential workflows

Evidence and evidence sets

Metrics checks

Scripted checks

Monitoring checks

Input artifacts

Radio buttons

Text inputs

Text areas

Select dropdowns

Multi-select dropdowns

Checkbox groups

Date inputs

Numeric inputs

File uploads

Guidance artifacts

Text blocks

Text banners

Classification

Classification inputs

Classification rules

Visibility rules

Gating

Next steps

​How policies are written

​What this page covers

​Stages

​Approvals

​Revalidation

​Sequential workflows

​Evidence and evidence sets

​Metrics checks

​Scripted checks

​Monitoring checks

​Input artifacts

​Radio buttons

​Text inputs

​Text areas

​Select dropdowns

​Multi-select dropdowns

​Checkbox groups

​Date inputs

​Numeric inputs

​File uploads

​Guidance artifacts

​Text blocks

​Text banners

​Classification

​Classification inputs

​Classification rules

​Visibility rules

​Gating

​Next steps

How policies are written

What this page covers

Stages

Approvals

Revalidation

Sequential workflows

Evidence and evidence sets

Metrics checks

Scripted checks

Monitoring checks

Input artifacts

Radio buttons

Text inputs

Text areas

Select dropdowns

Multi-select dropdowns

Checkbox groups

Date inputs

Numeric inputs

File uploads

Guidance artifacts

Text blocks

Text banners

Classification

Classification inputs

Classification rules

Visibility rules

Gating

Next steps