Antifailure
GitHubDocs
Sign inStart free
Safe State Engine

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.

Start the quickstartRequest hosted access
safe-state / public.users
SANITIZE
Sanitized branch is safe to share internally
verified
Snapshot input
Production shape, unsafe values.
emails and names presentsecrets still livecomments may contain PII
Sanitization contract
Deterministic masking with free-text scanning
Structured identifiersmasked
Free-text fieldsscanned
Live credentialsdeleted
joins
remain valid
secrets
removed
audit
attested
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.

IllustrativeSix 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.

Unverified goldens
An unverified golden cannot be branched. Sanitization evidence is required before a snapshot becomes a reusable golden.
subset / referential closure
KEEP
Seed budget
12% seed grows only where relationships require it.
foreign-key closure keeps parents and children consistent; rare billing states stay represented.
seed closure
public.users
u_8f2a
selected seed
KEEP
u_bb12
sampled out
DROP
user_idclosure
public.orders
o_441
parent u_8f2a
KEEP
o_902
parent u_bb12
DROP
billing_state · lapsed
rare-state preservation
keep
session · live
credential policy
delete
Foreign-key closure verifiedbounded volume
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.

adapter / postgres
PIPELINE
postgres adapter
customer-hosted execution
  1. 01
    Restore
    logical / native COW
  2. 02
    Subset
    FK closure · optional
  3. 03
    Sanitize
    mask + delete
  4. 04
    Validate
    shape + schema drift
  5. 05
    Destroy
    journaled teardown
Built in
Common Postgres paths
logical restore
provider-native branch
same contract
Pluggable
External data provider
same evidence contract
provider-owned depth
verified safe snapshotaudit evidence, not copied data
The built-in Postgres adapter restores, optionally subsets, sanitizes, validates, and destroys a branch. External data platforms can implement the same verified snapshot contract.
Customer-hosted masking

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.

Customer boundary
Production data stays in the customer boundary. What crosses the trust boundary is a sanitization attestation: hashes, coverage, and whether it verified. Not the rows.
trust boundary / sanitization
ATTEST
Customer cloud
data plane
01
Raw snapshot
restored locally
02
Masking worker
rules execute locally
03
Evidence builder
signs attestation
Hosted
control plane
Receives attestation
ruleset
hash
coverage
summary
status
verified
decision evidence only
Outbound contractaudit-ready attestation
raw snapshots stay local
secrets stay local
request bodies stay local
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.
Keep reading
Next

Know what happens before you deploy.

Create a disposable production twin for every risky change. Catch migration failures before they reach customers.

Start the quickstartRequest hosted access