Template context reference

Every template DeltaVault renders is handed one context object. This reference documents that contract: which top-level variables (roots) each template family receives, every field on every root, and when a conditional field is present. Use it to write your own templates against the same data the built-in templates read.

How a template gets its context

Rendering is the same everywhere it happens: a project Build writing artifacts, the Preview tab on a catalog table, and the template playground all assemble a context the same way. Three steps decide what a template sees. One example end to end: the path databricks/staging/sql/combined_load.jinja names the staging-family contract, the family names its builder, and the builder assembles this, source, sources, target, and the rest of the declared roots.

The path names the family. Every template path resolves to exactly one context family. A family is the contract: it declares which roots a template of that shape is handed at render time, and which preview sources are honest for it. Templates in the same family always receive the same roots, whatever platform folder they live in.

The family names the builder. Each family maps to one context builder, the code that reads your catalog (tables, columns, connections, layers, naming patterns) and assembles the declared roots. One family, one builder: there is exactly one answer to “what does this table’s context look like for this template”.

The builder reports gaps instead of guessing. When data a root needs is missing (an unlinked source, a missing system-column role), the builder either raises the gap as an error (a Build) or renders anyway and reports the gap as a diagnostic (a preview). It never silently invents values.

Path to family resolution

Resolution runs in two steps, exact match first.

1. Exact path. Every built-in template path is listed in the engine’s registry and wins outright.

2. Folder prefix, where a rule is registered. A template you author into a folder carrying a prefix rule inherits that folder’s family: drop a fork into snowflake/staging/ and it is a staging-family template. The longest matching prefix wins. A template that matches neither step resolves to no family and previews with an explicit unknown-family diagnostic instead of a guessed context.

A rule is registered only for folders that host exactly one family, but the converse does not hold: hosting one family does not earn a folder a rule. Two kinds of folder have none. Folders that host more than one family, such as databricks/landing/ and fabric/staging/notebook/, cannot have one. And databricks/orchestration/ deliberately does not have one even though control.jinja is the only template in it today, so that a later stray dropped into that folder gets the unknown-family diagnostic rather than silently inheriting the control notebook’s contract.

Folder prefix	Family
`_base/`, `_helpers/`	`helper`
`adf/_platform/datasets/`	`adf-dataset`
`adf/_platform/linked_services/`	`adf-linked-service`
`adf/_platform/triggers/`	`adf-trigger`
`adf/orchestration/`	`adf-orchestration`
`adf/staging/`	`adf-pipeline`
`databricks/_platform/resources/pieces/`	`bundle-job-task`
`databricks/ci/`	`ci-workflow`
`databricks/deploy/`	`ddl-runner`
`databricks/landing/pieces/`	`ingest-piece`
`databricks/persistent_staging/`	`step-notebook`
`databricks/staging/`	`staging-family`
`databricks/tests/`	`data-tests`
`fabric/_platform/`	`fabric-platform-file`
`fabric/orchestration/`	`workflow`
`fabric/staging/warehouse/`	`staging-family`
`snowflake/orchestration/`	`workflow`
`snowflake/persistent_staging/`	`staging-family`
`snowflake/staging/`	`staging-family`

Family index

Every family, its roots, and how it previews. A root marked conditional is present only under that family’s presence rule: read the family’s section for it. “Sample” preview means the playground renders a curated sample context; “live” means it assembles the real context from a subject you pick, and the kind in parentheses is what you pick.

A family name that links has a field-by-field section in this reference. A name that does not is indexed here with its real roots and preview kind, and its detailed section is still to be written.

Family	Layer	Provided roots	Preview
`ingest-pipeline`	Landing	`workflow, this, connection, source, sources, ingest, dv`	live (landing table) + sample
`ingest-notebook`	Landing	`this, connection, source, sources, environment, extract, dv`	live (landing table) + sample
`ingest-workflow`	Landing	`workflow, dv`	live (workflow) + sample
`ingest-piece`	Landing	`this, source, sources, connection, environment, extract, ingest, dv`	live (landing table) + sample
`lakeflow-entry`	Landing	`this, source, sources, connection`	live (landing table) + sample
`staging-family`	Staging	`this, source, target, refs, extraction, behavior, dv`	live (staging table) + sample
`step-notebook`	Staging	`workflow, step, source, sources, this, methodology`	live (table) + sample
`fabric-with-logging`	Staging	`this, source, sources, pipeline`	live (staging notebook) + sample
`vault-entity`	Data Vault	`this, cdc, source, sources, hubHashKeys, dependentChildColumns, ghost`	live (table) + sample
`vault-control`	Data Vault	`source, tiers, threadCount`	live (table) + sample
`vault-load-keyed`	Data Vault	`kindLabel, this, keyColumn, source, sources, ghost, ghostHashKeyColumns, sequenceColumn, recordSourceColumn`	live (table) + sample
`vault-load-versioned`	Data Vault	`kindLabel, this, source, sources, keyColumns, sequenceColumn`	live (table) + sample
`vault-load-reference`	Data Vault	`this, codeColumn, source, sources`	live (table) + sample
`vault-load-bridge`	Data Vault	`this, bridge`	live (table) + sample
`vault-load-pit`	Data Vault	`this, pit`	live (table) + sample
`vault-combined-load`	Data Vault	`source, tiers, load, behavior`	live (table) + sample
`vault-piece-hub`	Data Vault	`object`	live (table) + sample
`vault-piece-link`	Data Vault	`object`	live (table) + sample
`vault-piece-satellite`	Data Vault	`object`	live (table) + sample
`vault-piece-link-satellite`	Data Vault	`object`	live (table) + sample
`mart-dimension`	Data Mart	`this, cdc, source, sources`	live (table) + sample
`mart-fact`	Data Mart	`this, excludedColNames, dimRefs, source, sources`	live (table) + sample
`view`	Views	`view`	live (table) + sample
`derived-history-view`	Views	`view, columns, base, partition_keys, effective_from, effective_to, default_end_date`	live (table) + sample
`ddl-table`	Shared DDL	`table, options, build`	live (any table) + sample
`schema-ddl`	Shared DDL	`schema`	live (table) + sample
`data-tests`	Tests	`workflow, step, source, sources, this, methodology, tests, connection`	live (test) + sample
`workflow`	Orchestration	`workflow`	live (workflow) + sample
`workflow-rollup`	Orchestration	`rollup, dv`	live (workflow) + sample
`adf-orchestration`	Orchestration	`pipeline, workflow`	sample
`adf-pipeline`	Orchestration	`pipeline, table, connection`	live (table) + sample
`adf-dataset`	Orchestration	`dataset`	live (table) + sample
`adf-linked-service`	Orchestration	`connection`	live (connection) + sample
`adf-trigger`	Orchestration	`trigger`	sample
`bundle-root`	Platform	`project, databricksTargets, build, dv`	sample
`bundle-pipelines`	Platform	`landingPipelines, target, tables, connections, project, dv, ingestionRuntimes, vaultTableCount`	sample
`bundle-lakeflow`	Platform	`workflow, dv`	sample
`bundle-workflows`	Platform	`dv`	live (workflow) + live (project) + sample
`bundle-workflow-pipeline`	Platform	`workflow`	sample
`bundle-job-task`	Platform	`task`	sample
`ci-workflow`	Platform	`bundlePath, targetEnvironment`	sample
`ddl-runner`	Platform	`project, catalogs, schemas, ddlStatements, dv`	sample
`fabric-platform-file`	Platform	`artifactType, displayName, logicalId`	sample
`helper`	Platform	(none)	never previewed

The `dv` root

Several families declare a root named dv. It is the linked model: the project, its workflows, its tables and the edges between them, reachable as one object graph rather than as the flat roots beside it. A body that has to join across two of those, a task to the table it loads for example, walks dv instead of asking for another flat root. Where a linked node points back at its parent, the back edge is a followable reference string rather than a repeated object, so the graph can be read in the Context tab without looping.

The Data Vault combined load

vault-combined-load and the four vault-piece-* families render the combined load, which emits one artifact per source instead of one per vault object. The families and their templates are real and you can preview them today. The generated artifact is not yet routed into a build, so nothing you change in them reaches a deployed pipeline until that wiring ships.

Layers and families

The functional layer of the table you are generating for decides which families apply. Layer-filtered preview kinds only offer tables from the matching layers; a table with no stamped layer stays visible under every filter.

Layer	Families that write it	Table picker filter
Landing	`ingest-pipeline`, `ingest-notebook`, `ingest-workflow`, `ingest-piece`, `lakeflow-entry`, `ddl-table`	landing tables only
Staging	`staging-family`, `fabric-with-logging`, `ddl-table`	staging + persistent staging
Persistent staging	`staging-family`, `step-notebook`, `ddl-table`	staging + persistent staging
Data Vault	`vault-entity`, `vault-control`, `vault-load-` (5 load families), `vault-combined-load`, `vault-piece-` (4 piece families), `ddl-table`, `view`, `derived-history-view`	unfiltered (generic table kind)
Data Mart	`mart-dimension`, `mart-fact`, `view`, `ddl-table`	unfiltered (generic table kind)
Any (orchestration)	`workflow`, `workflow-rollup`, `adf-orchestration`, `data-tests`	not table-grained
Project-wide	`bundle-*`, `ci-workflow`, `ddl-runner`, `fabric-platform-file`	not table-grained

Reading this reference

Three conventions repeat across every family. Conditional means absent, not empty: when a rule says a root or field is conditional, the builder omits it entirely, so a template guard takes the same branch a real Build would. Counts accompany arrays: wherever a template needs to branch on emptiness, the context carries a precomputed count, because an empty array is truthy in the template language. Serialized companions carry the finished byte: a field with a Literal, Escaped, or Json suffix is the same value already quoted for the document it lands in (a JSON body, a Python formatted string, a SQL literal); emit it as is, never re-quote it.