Requiring and enforcing governance

Governing source data inline introduces the requirements matrix and describes how requirement levels feed the governance panel’s completeness badge. Turning a property to Required only changes what counts toward that badge, though. It does not, by itself, stop anyone from doing anything. This guide covers the second half: four gates that turn a required-but-incomplete asset into an actual stop on a real action, and how to read the notice when one fires.

The governance settings page

Requirements and gates live on the same page: Settings → Data Governance (/admin/settings?section=data-governance), visible only to organization administrators. The page has three parts:

Enable governance requirements: the master switch, off by default. Off hides every governance panel’s requirement chrome and disables every gate, everywhere. It never hides the governance editors themselves, definition boxes, classification buttons, steward and owner pickers stay available and keep working exactly as they do with the switch on.
The requirements matrix: the per-asset-type, per-property table described in Governing source data inline. A property set to Required here is what a gate checks against.
Gates: one row per gate, described below.

The four gates

Each gate has a mode, Off or Block until complete, and a scope: which asset types the gate checks, set with checkboxes next to the mode selector. A gate only ever looks at required properties for the asset types in its scope.

Gate	Blocks	When
Generate build	Generating the dimensional build bundle and rendering the DDL, staging, and orchestration templates	At the moment generation runs, over the business entities and source tables the build touches
Approve definition	Approving a business entity’s definition	When an editor flips the entity’s definition status from Draft to Approved
Accept mapping	Accepting a table or column mapping draft from Map and match	When a person accepts a draft by hand, one at a time through the panel or in bulk through Map and match’s “Accept all”
Complete import	Finishing an import run	When the import’s mapped tables and columns are committed to the catalog

Turning a gate on with Block until complete means the action fails outright, with the notice described below, for any in-scope asset that still has an empty Required property. Turning a gate off, or leaving its scope empty of the relevant asset type, means the action always proceeds regardless of completeness. Requirement levels and gates are independent settings: a property can be Required for tracking and badge purposes without any gate enforcing it, and a gate can be configured before every property it depends on is marked Required, in which case it simply has nothing to block on yet.

Accept mapping does not cover the scheduled automatic accept run

The Accept mapping gate checks every accept action a person triggers directly, whether accepting one draft by hand through the panel or using Map and match’s bulk “Accept all” button: both honor the gate exactly the same way. It does not check the scheduled automatic accept run. If your organization’s acceptance discipline is set to auto-accept, matches at or above the confidence floor are accepted the moment a match run finishes, and that path is not gated, by design, since it is meant to run unattended over many drafts at once. The settings page carries this as help text under the gate: “Automatic accept runs are not gated. Turn automatic accepts off when this gate is on.” If you want every accepted mapping to satisfy governance before it lands, turn off auto-accept for your organization; the single-draft accept and the bulk “Accept all” already honor the gate on their own.

Complete import only covers assets that already exist

An import can both update tables and columns already in the catalog and mint brand-new ones. The Complete import gate checks only the tables and columns that already existed before the import ran. A table or column the import is about to create cannot fail a governance check for a property it does not have yet, so newly minted assets always pass through, no matter how the gate is configured. Govern them afterward, from the catalog or the business model, once they exist. Updates to existing tables and columns are checked against this gate today; only the newly created ones pass through unchecked, because they cannot be governed before they exist.

Reading a Blocked by governance notice

When a gate blocks an action, the response is a Blocked by governance notice, titled with the gate that fired, for example “Blocked by governance: Accept mapping”. Underneath, each blocked asset gets its own row naming the asset and listing exactly which required properties are still missing, spelled out (Definition, Classification, and so on), so you know exactly what to fill in and where. An asset that has never had its completeness computed yet shows “governance status not yet computed” instead of a property list; opening that asset once is usually enough to trigger the computation. The notice only tells you to close; there is no override or acknowledge action here, unlike some other blocking checks in DeltaVault. Fix the missing properties on the listed assets and retry the action.

The same verdict also shows up ahead of time, inline. Any governance panel already displaying a covered, incomplete asset carries its own line, “Blocked: {gate} needs {properties}”, naming the specific gate and properties responsible, so you can see the block coming before you attempt the action that would trigger the notice.

Governance never blocks a branch commit

None of the four gates touch Commit branch. Committing your changeset to Git is governed only by the existing validation rules check described in Data governance overview, which is a separate mechanism with its own severities and its own acknowledge action. However strict your requirements matrix and gates get, they never stand between you and committing your work. Governance enforcement is scoped to the four real actions in the table above, deliberately, so the git workflow itself always stays unblocked.

Governing source data inline: the requirements matrix, the governance panel, inline drafts on unmapped source data, and drafting definitions with AI
Data governance overview: classifications, ownership, and the definition approval lifecycle that Approve definition enforces
Map and match source metadata: accepting mapping drafts, bulk accept, and the acceptance discipline settings that control auto-accept