Data that behaves like production. Without production data.
Pipewright learns from the real rows where they live, with no outbound calls. Keys and personal data are never learned. Every candidate is scored for fidelity, for how well a model trained on it does on real data, and against privacy attacks, and one is published only when every gate passes.
C-1048231NW324mC-2091758E143mC-3315044SE112mC-4120627N17mS-0000133NW621mS-0000255E34mS-0000346SE513mS-0000429N76mReal data stays where it is. Realistic data goes where the work is.
Development, testing, demos and partners all need data that behaves like production, and production data may not go there. Pipewright learns synthetic data inside the environment that holds the real data, and publishes it only when it is close enough to be useful and far enough to be safe.
What ML teams live with today (and what it costs)
Every request for data outside production is a ticket, an exception and an access review. Projects start late, or start on whatever sample someone made by hand.
Removing names leaves the rest of the record intact. A rare combination of age, postcode and tenure can still point to one customer, and nobody measured it.
When data protection asks what was shared, with whom and how close it was to real records, the answer is in emails and memory.
One switch in the use case. Gated before anyone sees a row.
Off until a team needs it. Turn it on in YAML, per environment, and Pipewright runs its own synthetic pipeline: no code to write, released and pinned like any other.
- Learned inside your environment: the engine runs in your project, inside your perimeter, with no outbound calls
- Keys and personal data are never learned: they get new values from rules, and a real holdout is kept back
- Scored three ways: fidelity, utility (a model trained on synthetic data, tested on real) and privacy attacks
- Several candidates, the best that passes: or nothing is published at all
- Purpose sets the bar: test data stays in the organisation; sharing gets stricter privacy gates
- Or no real data at all: rows from the data contract alone, for CI and demos
fidelity0.952 at least 0.92passutility0.016 AUC lost at most 0.05passexact copies0 none allowedpassdistance1.14 × real-to-real at least 0.9passtoo close3.2% at most 10%passsingling out0.16 at most 0.3passlinkability0.01 at most 0.1passinference0.08 at most 0.5passRelated tables and histories
Customers with their feature tables and event sequences, learned together. Keys match across every table, each history keeps its timing against the cut-off, and the gates are measured on the same point-in-time join training uses.
Drafted with Gemini, decided by a person
Gemini on Vertex AI, in your own project, reads a profile of the table (names, types, counts, never a row) and drafts the settings with a reason for each. Pipewright validates the draft and leaves it switched off for review.
$ pipewright synthetic-draft --usecase churn drafted: config/synthetic.draft.yaml (off)
Released like a model is promoted
Moving synthetic data to another environment needs every required approver group first, then the gates again under that environment's rules. Only that run's rows move, and an evidence pack records it, write-once.
Teams build and test on realistic data from the first sprint, instead of waiting for an extract.
Data protection sets the rules once per environment, instead of judging every request.
Pipelines, edge cases and CI run on data with production's shape, gaps and relationships.
Every release carries its scores, its approvers and where the rows went.
One switch in the use case.
Learning and gating synthetic data is open source. Releasing it between environments, with approvers and evidence, is Enterprise.