CONCEPT Cited by 2 sources

Branch-level governance propagation¶

Definition¶

Branch-level governance propagation is the property that governance policies (row filters, column masks, attribute-based access controls) attached to a database's catalog scope propagate automatically to every branch created from that database, at branch-creation time, without manual reapplication. The branch- creation primitive itself is the policy-distribution mechanism; governance becomes structurally inseparable from the branched data rather than a configuration step a human has to remember after provisioning.

The property is the structural answer to the non-production data leak class: when database branches are sub-second and free (concepts/database-branching economics), a sprint-rate of 30–40 branches per team makes manual masking-on-provisioning fail deterministically. Governance has to be tied to the branch-creation primitive itself, or it doesn't happen.

Canonical instance — Lakebase + Unity Catalog (2026-05-15)¶

From the Backstage with Lakebase Part 2 source: "When a Lakebase branch is created, Unity Catalog's attribute-level masking policies propagate automatically to the new branch. A developer working on their feature branch never sees unmasked production data — not because someone remembered to configure it, but because the governance layer enforces it at creation time. The CI branch that runs your PR tests is governed identically to production. The QA branch where a tester runs destructive scenarios is governed identically to production. There is no 'non-production exception' where sensitive data leaks because someone forgot to apply the policy."

The economic anchor cited in the same post: "According to Perforce's 2025 State of Data Compliance report, 60% of organizations have experienced breaches or theft in non-production environments where sensitive data was inadequately anonymized. The traditional approach — manually masking data when provisioning dev/test environments — doesn't scale when environments are created and destroyed in seconds. Governance has to be automatic, or it doesn't happen."

Three structural properties¶

Policy attaches at the parent scope, not the branch scope. The masking policy is bound to the Unity Catalog catalog/schema/ table layer (or to UC governed tags via ABAC), not to a specific branch. When a branch is created, it inherits the parent's policy set; no per-branch policy authoring is required.
Branch creation is the policy-distribution event. The branch does not exist in an unmasked transient state pending policy application — at the moment the branch is observable to a developer, the policies are already in force. This eliminates the "someone forgot to apply the policy" failure mode.
Governance equality across branch tiers. "The CI branch that runs your PR tests is governed identically to production. The QA branch where a tester runs destructive scenarios is governed identically to production." No tier-of-environment weakens the policy contract.

What it depends on¶

A unified governance substrate that spans the operational DB. The Lakebase + UC instance composes concepts/operational-analytical-governance-unification (UC reaches over the operational Postgres) + the branch primitive. Without the first leg, the catalog-scope policies don't apply to the operational DB at all; without the second leg, there's no branching to inherit.
An ABAC or tag-driven policy model. Per-table per-user GRANT- by-name doesn't propagate cleanly because new tables on the branch aren't enumerated in the parent's GRANT list. Tag-driven ABAC (patterns/tag-driven-attribute-based-access-control) generalises across the branch's table population.
Branch-creation-time policy evaluation, not query-time policy evaluation. The post's framing is that policies "propagate" on creation; the alternative — query-time evaluation against the parent's tag set — would also satisfy the contract but pushes governance state across the branch boundary at every query, which is harder to reason about than a one-shot propagation event.

What it doesn't say¶

The 2026-05-15 source asserts the propagation contract at the capability level. Not disclosed:

Whether masking policies are pushed down to Lakebase Postgres or evaluated at the Lakehouse Federation boundary above it.
The propagation latency at branch creation (does it bound the 1.09 s data-plane envelope from Part 1?).
How the propagation handles policies authored against the parent after branch creation (does the branch see them? on next query? at next branch refresh?).
Whether the propagation covers UC ABAC policies, governed tags, and data classification uniformly, or only the masking layer.

Sibling concepts¶

concepts/database-branching — the substrate primitive this concept extends. Without cheap branches, the manual-masking failure mode doesn't materialise; with cheap branches, branch-level governance propagation is the structural fix.
concepts/attribute-based-access-control — the policy layer that propagates well across new branched table populations.
concepts/separation-of-duties-data-governance — the three-role split that keeps the policy taxonomy stable while branches proliferate; both concepts are about decoupling governance authoring from per-environment provisioning.
concepts/governance-by-default — sibling concept (if surfaced in future ingest); branch-level propagation is the branch-tier instance of that property.

Seen in¶

sources/2026-05-15-databricks-backstage-with-lakebase-part-2 — First canonical wiki home for branch-level governance propagation. UC attribute-level masking policies inherit automatically when a Lakebase branch is created, so the CI / QA / feature branches that Part 1 made cheap can't leak unmasked production PII. Worked-example anchor: 6-developer team / 30–40 branches per sprint × 60% non-production-breach baseline (Perforce 2025) = the structural failure mode this concept prevents.