Private workspace
A dedicated customer environment is provisioned only after an agreed SOW.
Defined in SOW Trust & validation
Treat every synthetic release as a measurable risk decision.
MirrorFoundry starts with the intended use, source boundary, disclosure threat model, utility requirement, reviewer, and evidence that must remain.
04
PurposePrivacyUtilityRelease decision
Accepted evidence boundary
Clear claim boundary
This page describes MirrorFoundry's proposed delivery and validation model. It does not claim guaranteed anonymisation, regulatory approval, or any particular third-party certification.
Six control surfaces
Make the release boundary visible at every stage.
Final controls depend on the intended use, applicable law, source risk, deployment, and signed agreements.
Data minimisation
Sources, fields, destinations, purposes, and retention are limited to the approved workflow.
Defined in SOWEmpirical privacy testing
Releases can be assessed for similarity, memorisation, inference, and rare-record exposure.
Defined in SOWTask-based utility
Fidelity is measured against the analyses or models the synthetic release is intended to support.
Defined in SOWAdmin-led access
Customer administrators invite authorised employees; no public signup exists.
Defined in SOWContract-defined controls
Residency, subprocessors, encryption, deletion, audit, support, and incident terms are agreed during diligence.
Defined in SOWRelease-gate agenda
Set the evidence threshold before running the generator.
A release policy should make the stopping condition, exception path, and reviewer explicit.
01
What intended use and legal basis are in scope?
02
Which sources, fields, people, and destinations are permitted?
03
Which disclosure attacks and similarity risks must be tested?
04
Which analytical or model tasks define useful enough?
05
Which rare cohorts and model failure modes require coverage?
06
Who can approve a deviation from a threshold?
07
What evidence, configuration, and limitations must be retained?
08
How will deletion, exit, incidents, and subprocessors be handled?
Start with one release
Put the validation requirements into the first scope.
Bring your intended use, source constraints, privacy questions, model tasks, and required evidence. We’ll make them explicit before implementation.
Request an assessment