> Canonical: https://antifailure.dev/product/safe-state > Sanitized, referentially consistent, production-shaped Postgres. Masking is compiled to SQL, read back by a scanner, and signed before it can be branched. # Production-shaped Postgres without production identities. Snapshot restore, referentially consistent subsetting, and deterministic masking inside the customer boundary. A live session is deleted outright, and a key is replaced by a keyed hash that grants nothing. The output is a sanitization evidence report, not a dataset. A production snapshot passes through deterministic masking and credential deletion inside the customer boundary, producing a verified sanitization attestation. ## Realistic enough to fail for the right reasons. Toy fixtures miss the row that breaks the constraint. - Snapshot restore Logical restore for portability, or provider-native copy-on-write branches when supported. - Referential subsets Keep joins valid. Long-tail and malformed historical state stay in the subset. - Deterministic masking Format-preserving replacement with uniqueness preserved, inside the customer boundary. - Nothing that grants access survives A session token is deleted. A key, a secret and a password become a keyed hash of the same length that unlocks nothing. - Free-text PII Scan for emails, cards, phones, and keys that schema rules miss. - Evidence report Distribution validation, schema-drift handling, and a signed sanitization attestation. ## A 12% subset that still joins. Dropped parents take their children. Rare rows stay. Subsetting is available and off by default, so a first run masks the whole database and you turn subsetting on with a seed table when you want it. With it on, the twin keeps referential integrity, long-tail billing states, and malformed history, the records that actually break migrations, while volume stays bounded. Illustrative Six rows of a worked example, with the ratio chosen. What a real subset keeps depends on the shape of your own data. What is fixed is the rule: a dropped parent takes its children, and a rare row is kept on purpose rather than sampled away. A twelve-percent seed sample expands by foreign-key closure, deliberately keeps a rare billing state, drops children with dropped parents, and deletes live sessions. ## Postgres first. Deep enterprise data platforms can be an external provider, not a rebuild. The built-in engine covers common Postgres cases: restore, subset, mask, delete credentials, validate distribution, then destroy. Matching a dedicated test-data platform’s connector depth is not the point. What this returns is a decision about a deployment, not a dataset. - 01 Restore logical / native COW - 02 Subset FK closure · optional - 03 Sanitize mask + delete - 04 Validate shape + schema drift - 05 Destroy journaled teardown The built-in Postgres adapter restores, optionally subsets, sanitizes, validates, and destroys a branch. External data platforms can implement the same verified snapshot contract. ## Masking never leaves your cloud. The control plane receives evidence, not records. Deterministic masking runs inside the customer-hosted data plane. Raw snapshots, secrets, and captured request bodies do not enter the hosted control plane. **ruleset** hash **coverage** summary **status** verified Raw snapshots, secrets, and request bodies stay inside the customer-hosted data plane. Only a sanitization attestation containing hashes, coverage, and verification status crosses to the hosted control plane. - Side-Effect Firewall The twin cannot act on the real world. Read - Isolated Twin Where the sanitized state is restored. Read - Migration Safety What a branch with production's shape shows. Read ## Know what happens before you deploy. Create a disposable production twin for every risky change. Catch migration failures before they reach customers.