Masking data is easy. Proving it worked is the product.

Writing the masking is the part people budget for. It is also the part that takes an afternoon. An UPDATE that overwrites users.email with a generated address is not difficult, and most teams already have one.

The failure is never in that statement. It is in the eleven other places the same address also lives, and in the fact that nothing checked.

Where identifying data actually survives

A masking script written against the schema masks the columns somebody thought of. In practice the ones that get missed are the ones that are not shaped like a person:

• Denormalised copies. A billing_email on the invoice, captured at the time of purchase so it would not change.
• JSON columns. A webhook payload stored whole in a jsonb column, with the customer's address nested three levels down where no column-level rule reaches.
• Free text. A support note reading “called them on 555-0142, will retry Tuesday.”
• Audit and event tables. Append-only by design, frequently the largest tables in the database, and routinely excluded from a masking pass because they are awkward.
• Anything added since. The column somebody shipped last month, which the masking config predates.

That last one is the structural problem. A masking configuration is a list, the schema is a moving target, and a list maintained by hand against a moving target is wrong within a quarter. It fails silently, because a missed column produces no error. It produces a database that looks anonymised.

Determinism, and why it is not optional

Random replacement destroys the data. If orders.customer_email and users.email are masked independently, the join breaks and a checkout flow that depends on it no longer exercises anything. The environment stops reproducing the behaviour you built it to reproduce.

So the mapping has to be deterministic: the same input produces the same fake output, in every table, on every refresh. That preserves referential integrity across the whole database and means a bug found against one branch is reproducible against the next one.

Antifailure compiles masking to SQL and executes it in resumable chunks, deterministically, so the same customer maps to the same fake customer across every table and every refresh. Resumable matters more than it sounds: at production row counts these operations run long enough that something will interrupt one, and a masking pass that cannot resume is a masking pass that gets skipped under time pressure.

The read-back

Everything above is still just a better script, and a better script is still unverified. The check that matters runs afterwards and asks a different question. Not “did the rules execute” but “is there anything identifying left.”

So a scanner reads back every column of every table looking for anything that still parses as an email, a card number, a phone number or a key. Every column, including the ones nobody configured, which is the entire point: the column added last month is exactly the one the configuration does not know about, and a read-back does not need to know about it in advance.

Every column, and a sample of the rows. The scan takes up to two thousand rows per column by default and the attestation records the number it used, so what it proves is bounded and the bound is written down. That is a deliberate trade and it is worth saying out loud rather than leaving in the code: the failure this is built to catch is a rule that missed a column entirely, which shows up in the first hundred rows, and a full read of a wide schema turns seconds into minutes. A single real value hiding in one row out of a million is not what this finds.

It then signs an attestation, which turns the result into something that can be checked later rather than a line in a log that scrolled past.

A check nobody can skip

The last part is the one that decides whether any of this holds up. A verification step that can be waived will be waived, at the worst possible moment, by somebody reasonable who needs an environment before a demo.

So the rule is that an unverified golden cannot be branched, and it is enforced in code rather than in a checklist. There is no flag. A dataset that has not passed the scan is not available to branch from, which means the failure mode is an environment you cannot create rather than an environment full of real customer data that looks fine.

That inversion is the whole design. Checklists document intent. Gates produce outcomes. The difference shows up on the day somebody is in a hurry, which is the only day it was ever going to matter.