Deleting a user isn't one action — it's a staged lifecycle with individually tracked outcomes at every step, because a real deletion touches more than one system and “trust me, it worked” isn't good enough for a compliance claim.
Requesting a deletion kicks off a lifecycle with six possible states, not an instant delete. That's deliberate: real user data usually spans more than the warehouse — connected SaaS tools, source tables you've opted into redacting — and each of those has to individually confirm it actually cleaned up before Chameleon will claim the deletion is complete.
The key is destroyed immediately and synchronously, before anything else runs. Everything after that is the cascade: Chameleon working through every other system that might hold a copy, recording each outcome individually rather than assuming success.
A deletion request moves through these states in sequence. The certificate is only ever issued from the last one — nothing earlier is good enough.
A deletion request is created for a user. Nothing has happened yet — this just starts the lifecycle.
The user's encryption key is erased. This is synchronous and happens first, before any downstream cleanup — see below for exactly what “destroyed” means here.
Chameleon works through every other system that might hold this user's data — connected SaaS tools, and any source table you've opted into redacting — and identifies what needs cleaning up.
Every downstream destination has individually confirmed its cleanup succeeded. A deletion request only reaches this state if nothing failed.
A signed Certificate of Destruction is generated. This is the only state a certificate can come from — it's the proof that everything, not just the key, is actually accounted for.
When a downstream cleanup fails
If any destination in the cascade reports a failure, the request lands in Cascade Partial Failure instead of Cascade Complete — and the certificate is withheld until that failure is resolved. A certificate is a claim that everything succeeded; issuing one while a cleanup is still outstanding would make it false, so Chameleon simply doesn't.
“Key destroyed” means the user's key material was erased from the key registry — a synchronous operation that completes in the same request that triggered it. It is not a Cloud KMS key-version destruction, which carries a mandatory multi-hour scheduling window before it actually takes effect. Waiting on that window would make an immediate “complete” misleading, so Chameleon doesn't rely on it for this guarantee.
Every certificate states its key-destruction method explicitly as key-material erasure, precisely so it can never be misread as a stronger KMS-level claim it isn't making. The infrastructure-level key that wraps each user's key is never destroyed — only that specific user's key material is, which is exactly what makes their data (and only their data) unrecoverable.
| Strategy | What happens on deletion | When to use it |
|---|---|---|
| None (default) | The source table is left untouched. Only the central encrypted copy is shredded. | You don't need the original source row cleaned up — it's redundant with, or upstream of, what's already protected elsewhere. |
| Redact in place | A real update runs against your own source table, scoped to that specific user, clearing the declared fields. | You want the source of truth itself cleaned, not just Chameleon's copy — e.g. a raw ingestion table you query directly. |
| Shadow copy | A redacted copy is written alongside the original instead of mutating it directly. | You need the original left intact (e.g. for a downstream process) but still want a safe, redacted version available. |
Coverage claims are deliberately conservative
A deletion's lineage coverage reports exactly which destinations were actually checked — never an implied claim that every system a user's data ever touched was inventoried. Similarly, if a ghost-data scan hasn't run for a given cleanup, that's stated explicitly rather than left ambiguous — an empty findings list is never presented as “confirmed scanned, nothing found” unless a scan genuinely ran.
Can a deletion be undone?
No. Key destruction is the point of no return — once a user's key material is erased, every copy of their data that was encrypted with it becomes permanently unreadable. This is intentional: it's what makes the deletion mathematically certain rather than dependent on finding and removing every copy by hand.
What happens if a SaaS connector (like a CRM) is temporarily down during deletion?
That destination reports a failure, the request lands in Cascade Partial Failure, and the certificate is withheld until it's resolved. The key itself is already destroyed at that point, so the user's core data is already unrecoverable — the partial-failure state just means the SaaS-side cleanup still needs to complete before Chameleon will certify the whole deletion as done.
Why isn't row deletion enough on its own?
Row deletes in most warehouses don't actually remove the data immediately — time-travel windows, fail-safe retention, and snapshot/clone features can all leave recoverable copies behind for days. Destroying the encryption key makes every copy unreadable at once, regardless of how many snapshots or clones exist.
How the signed, hash-chained Certificate of Destruction is generated and independently verified.
How resources get declared, and where source-redaction strategies are configured.
All available developer documentation.