Governance rules

The four types

Scopes

A scope names where the rule looks. Five surfaces, and one result is produced per scoped surface — a rule with scope: [job, warehouse] produces two results.

required_tag

The most-used type. A missing key is always a violation, in every enforcement mode.

Only the companion field for the chosen mode may be set. Supplying allowed_values on a fixed rule is a validation error rather than a silently ignored field.

The five enforcement modes

Examples

- name: Owner tag
  type: required_tag
  action: warn
  key: owner
  scope: [job, pipeline, warehouse]
  enforcement: unlimited

- name: Team tag on compute
  type: required_tag
  action: block
  key: team
  scope: [job_cluster, pipeline_cluster]
  enforcement: allowlist
  allowed_values: [data-engineering, ml, platform, analytics]

- name: Cost centre format
  type: required_tag
  action: block
  key: cost_center
  scope: [job_cluster, pipeline_cluster]
  enforcement: regex
  pattern: "^CC-[0-9]{4}$"

- name: No prod warehouses
  type: required_tag
  action: warn
  key: environment
  scope: [warehouse]
  enforcement: blocklist
  blocked_values: [prod, production]

naming_convention

Resource names must match a pattern in full, and optionally stay within a maximum length. The pattern is validated when the rule is saved, so an invalid regex is a configuration error rather than a run-time surprise in somebody's pipeline.

- name: Resource naming
  type: naming_convention
  action: warn
  scope: [job, pipeline, warehouse]
  pattern: "^(dev|staging|prod)-[a-z0-9-]+$"
  max_length: 128

Naming is a cost rule in disguise. A resource nobody can attribute is a resource nobody turns off, and the fastest way to make a workspace unattributable is to let every team name things its own way.

required_compute_policy

Checks that every compute cluster references a Databricks compute policy — job shared clusters, per-task inline clusters and pipeline clusters. Takes no fields beyond a name and a severity, and covers all compute surfaces automatically.

- name: Compute policy required
  type: required_compute_policy
  action: block

Clusters that have a policy are listed in the audit output; clusters without one are reported as violations. This is the rule that stops instance-type sprawl at the source rather than reporting it afterwards.

serverless_usage_policy_required

Requires every serverless job and pipeline to reference a usage policy. Usage policies stamp their tags onto every billing record of the workloads that use them, which is how an organization groups serverless spend by its own dimensions: domain, execution mode, cost centre.

- name: Serverless usage policy
  type: serverless_usage_policy_required
  action: block

It is not needed to attribute cost to a data product. That comes from the identity tag on the job or pipeline itself; see Actual cost. This rule is optional, and no organization receives it by default.

Reading the results

 Rule                       Scope             Result  Resources
 Team tag on compute        job_cluster       PASS    3 checked
 Team tag on compute        pipeline_cluster  FAIL    customer_scd/default
 Resource naming            job               WARN    daily-ingest-v2
 Compute policy required    —                 PASS    5 checked

• PASS — every resource in that scope satisfied the rule.
• WARN — violated, but the rule's action is warn. The build passes.
• FAIL — violated with action: block. finowl guard exits 1.

Every result names the resources that produced it, so a failure points at a file rather than at a policy.

Rolling out a rule

Governance rules touch every resource in every bundle, which makes them the easiest kind to introduce badly. A tag rule created as block on a Friday fails every pipeline in the organization on Monday.

• Create it as warn, targeted at every environment.
• Read a fortnight of runs. The violations tell you how much remediation the rule implies.
• Fix the bundles, then promote to block — production first if the remediation is large.