The dbt package that caught PII leaking into our marts — without scanning a single row.

email_token had reached dim_users. Nobody declared it. Nothing noticed.

Our staging layer carries an email_token column — an HMAC surrogate of the user's email, used as a join key. Somewhere along the way a dbt model selected it into dim_users, a mart-layer table, and from there it was one SELECT away from every dashboard and export in the company. No scanner complained, because scanners look at data values, and a hex digest looks like nothing. No review caught it, because the column was never declared anywhere a review would look.

The package's discovery model flagged it on the first run: a column matching a PII naming pattern, present in a mart table, declared in no schema.yml. The query behind that finding read column names from INFORMATION_SCHEMA — metadata, not rows. The registry and lineage models that put the finding in context billed exactly zero bytes, because they never touch the warehouse at all: they read the dbt graph.

That is the design thesis of chameleon_pii: most PII governance work is a metadata problem, and metadata is free. You should not need a data-scanning platform — or a data-scanning bill — to know where your PII is and where it flows.

Three planes, separated by cost.

Every capability in the package is assigned to a cost plane, and the expensive one is off by default. This is what makes it safe to run on every single dbt build.

Five tables, built in your own warehouse.

Everything materializes as ordinary dbt models in your project's schema. Nothing leaves your warehouse; there is no service to sign up for.

Declare once, in the schema.yml you already maintain.

There is no separate catalog to fill in. PII is declared where dbt users already document columns — meta.pii on the column, with a classification (DIRECT_IDENTIFIER, CONTACT, SENSITIVE, QUASI_IDENTIFIER, BEHAVIORAL, SYSTEM_IDENTIFIER) and an optional handling that defaults sensibly from it.

Anything you forget is the point of the rest of the package: name inference records it with INFERRED confidence so you can review and promote it, discovery flags it if it lives in a table dbt never documented, and the CI test makes the omission loud instead of silent.

What it doesn't do (yet).

It is BigQuery-only for now — the discovery and content models use BigQuery-specific SQL. Cross-warehouse support via adapter dispatch is the most-requested next step, and Snowflake would come first.

Graph-based models only see columns documented in schema.yml; that blind spot is exactly what the INFORMATION_SCHEMA discovery plane exists to cover. And name matching is deliberately high-recall: a column called subscription_name will be flagged even though it isn't a person's name. Findings are candidates to review, not verdicts — tune the patterns, promote the real ones, allowlist the rest.

Finding PII is also only half the problem. Once the registry tells you a user's data reaches nine downstream tables, you still have to erase it from all nine — and prove you did. That deletion-and-proof layer is what Chameleon itself does, with crypto-shredding and signed deletion certificates; the package is how your dbt project describes what needs protecting.