Rule templates
A rule template is a named, reusable set of data-quality rules that is not tied to any data asset. You author it once — or save an asset's current rules as a template — and then apply it to one or more assets. Applying a template copies its rules onto each asset, mapping column names where they differ. It's the fastest way to give twenty similar tables the same checks: apply the template, add the assets to a validation, and schedule it.
A template differs from the two things it sits between:
- A rule is asset-bound — it belongs to exactly one data asset — so it can't be reused across assets on its own. A template has no asset binding, so the same template applies to many assets.
- A validation is the runnable unit. A template is not runnable; it's a blueprint that fills assets with rules, which validations then run.
Data model
RuleTemplate lives in the per-tenant schema. It is workspace- and team-scoped like the rest of the catalog, and — deliberately — carries no data_asset_id and no soft-delete tombstone (a template is a blueprint; deleting it never touches already-applied assets).
| Column | What it stores |
|---|---|
name / description | Human label + optional summary. |
rules | The rule list — the same [{"rule_type": …, "kwargs": {…}}, …] shape an asset's rules use. A rule names its target column via kwargs.column; there is no table binding on the rule (the asset supplies the table at apply time). |
tags | Free-form catalog tags. |
workspace_id / team_id | Isolation scope (NULL workspace_id = workspace-shared org-wide; NULL team_id = shared across the workspace). |
Copy-on-apply
Applying a template is a copy, not a subscription: the rules are merged into the asset's rules as independent, editable copies. Editing a template later does not retro-change assets you already applied it to, and deleting a template leaves every applied asset untouched. If you want a change to reach applied assets, re-apply the template (or edit those assets' rules directly).
The merge is additive: a template apply never removes or reorders an asset's existing rules — it appends the template's rules and de-duplicates any that are already present (same rule type + kwargs). So applying a template can only add checks; it never clobbers rules you authored by hand.
Operations you can do
- Author a template — save an asset's current rules as a template with Save as template on the data-asset Rules tab, or create one through the
POST /api/v2/.../rule-templatesendpoint. Templates are managed through the CRUD endpoints (GET/PATCH/DELETE .../rule-templates[/{id}]); the UI surfaces them as actions (there is no separate Templates navigation entry). - Apply a template to an asset — Apply template on the data-asset Rules tab. Pick a template; if any of its columns aren't on this asset, a column map lets you point each one at the right asset column (or leave it as-is). A live preview shows how many rules will be added versus how many are already present, then Apply merges them in. Under the hood this is
POST /api/v2/.../data-assets/{asset_id}/rules/apply-templatewith{template_id, column_map?, dry_run?};dry_run: truereturns the would-be merge without persisting (it drives the preview). - Create a validation from a template — in Validations → New validation, choose Start from a template, then pick the assets to apply it to. Each selected asset gets the template applied, and those assets are added to the new validation in one step — with its assets. Leave the template unset (or select no assets) to create the validation without assets and populate it later.
Where to go next
- Apply a template end to end and schedule the result: Apply a rule template.
- The runnable unit a template feeds: Validations.
- The per-asset rules a template merges into: Rules.