Model context
Connect model metadata with resources in the PII registry so policy does not stop at raw tables.
Carry PII metadata through dbt models.
Chameleon uses dbt context to help privacy and data teams understand how customer-data policy follows warehouse transformations and derived models.
Derived identifiers
Track surrogate identifiers and aggregate-only handling where customer data changes shape through transformations.
Owner clarity
Make model ownership and policy status visible when a privacy review needs a data-team answer.
PII doesn't stop at the raw table.
A customer's email enters the warehouse in a raw table, but dbt is built to move and reshape it. Staging models clean it, intermediate models join it, and mart models derive surrogate identifiers and aggregates from it. By the time analysts query the data, the personal information has fanned out across a dependency graph — and a privacy policy attached only to the raw table no longer describes reality.
Without lineage, a deletion request that names one table silently misses every model downstream of it. That is the single most common way an erasure workflow ends up incomplete.
Let lineage carry the policy.
Chameleon reads dbt manifest metadata to understand which models descend from a PII source. When a raw column is classified as personal data, that classification propagates along the lineage graph, so every derived model inherits the correct privacy context and deletion strategy automatically.
The payoff shows up at deletion time: because Chameleon knows the full set of models that inherited a user's data, key destruction covers the derived marts as well as the raw source — and the proof certificate lists them. Lineage stops being a debugging tool and becomes part of your compliance boundary.
01 / Declare
Use dbt metadata as policy context for warehouse resources and transformations.
02 / Trace
Keep customer-data context attached as raw records become staging, intermediate, and mart models.
03 / Review
Flag policy warnings where derived identifiers or manual-review strategies need attention.
04 / Prove
Include model context in deletion proof workflows when a request touches transformed data.
source: dbt manifest metadata
model: mart_customer_metrics
pii_context: user_surrogate_id
strategy: manual_review
model: mart_customer_metrics
pii_context: user_surrogate_id
strategy: manual_review
Common questions
How does dbt help with PII compliance?
dbt's lineage graph records how data flows from raw sources through staging and into marts. Chameleon uses that lineage to propagate PII classification and deletion strategy to every downstream model, so privacy policy follows the data instead of stopping at the raw table.
Do I need to tag PII in my dbt models manually?
You can declare PII in dbt metadata, but you don't have to tag every downstream model by hand. Chameleon infers which models inherit personal data from the lineage graph, so a classification on a source column carries forward automatically.
Does the dbt integration change my transformations?
No. Chameleon consumes dbt manifest metadata for context; it does not rewrite your models. Your transformation logic stays exactly as you authored it — Chameleon adds the privacy and deletion layer on top.
Where the encrypted PII actually lives, and how key destruction reaches every derived table.
The same encrypted-PII model, for teams whose warehouse is Snowflake instead of BigQuery.
The registry that dbt lineage feeds into — a live map of personal data across your warehouse.
How undeclared PII slips into derived models, and why lineage-aware detection catches it.