Four unrelated things share one name
"Synthetic data" is four different engineering practices wearing one label, and most arguments about it are really arguments about which of the four someone means. The first is simulation output: physics-based rendering, radar and RF propagation models, flight dynamics, discrete-event logistics models. The generator here is a model of the world, and its fidelity is an engineering property you can reason about. The second is augmentation: transformations applied to real records, such as rotation and noise injection on imagery, or jitter on sensor traces. The information still comes from the real sample. The third is generative sampling: fitting a model to a real dataset and drawing new records from it, whether a copula, a tabular diffusion model, or a language model writing case narratives. The fourth is fixture generation: rule-driven fake records built from a schema, used to exercise software. That is a testing tool and nothing more.
The confusion is expensive because the four have different risk profiles, different evaluation methods, and different answers to the only question that matters. Simulation can create genuinely new information, because the physics encodes knowledge the sample never contained. Generative sampling cannot. A model fitted to 4,000 records and asked to produce 400,000 has added rows, not knowledge. Every downstream argument about whether synthetic data is honest reduces to whether the team understood that distinction on the day they chose the method.
The question that settles legitimacy
Before generating anything, we ask one question: where does the information in this dataset come from? If the answer is a physical model, an instrument, a validated simulator, or a real sample, the work is legitimate and the remaining questions are engineering. If the answer is "the generator assumed it," then the synthetic dataset encodes the team's beliefs and any model trained on it learns those beliefs. That is not automatically wrong. It is wrong when the results get reported as evidence about the world.
This is the same test applied in a different vocabulary throughout the federal evidence chain. A hearing officer, a program office, or an auditor is entitled to ask which observation supports a claim. A number produced by a generator that was fitted to nothing does not answer that question, and it is much better to find that out in week two than in the acceptance review.
Where Synthetic Data Earns Its Place: Use-Case Fit
Editorial weighting from our delivery practice and public literature; illustrative, not a measured statistic.
The cases where it is the right tool
Development and test under access restriction. The engineers writing the ingestion code often cannot see production records, and should not. A generated dataset that matches the schema, the cardinalities, the null patterns, and the referential integrity of the real feed lets the build proceed while the access paperwork moves in parallel. This is the highest-value case in federal work and the one we set up most often.
Load and failure testing. Nobody needs statistical fidelity to find out what happens at 40,000 events per second, or when a required field arrives empty for eleven straight hours. Volume and pathology are the point, and generated data supplies both on demand.
Rare-event coverage from a real model of the world. When a validated simulator exists, sampling from it does add information. Sensor models, propagation models, and vehicle dynamics have decades of validation behind them. The honest framing is that the simulator is the evidence and the generated records are its output, so the simulator's validation record travels with the claim.
Class rebalancing inside the training split. Oversampling a minority class with SMOTE (Chawla et al., 2002) or a fitted generator can help a classifier find a decision boundary. It is legitimate only when the synthetic rows never touch validation or test, which brings us to the decision that costs the most to reverse.
Decisions that are expensive to walk back
Fitting the generator before locking the split. If the generator sees the eventual test records, every metric computed afterward is contaminated, and no later fix restores the result. Lock the split first, fit on the training partition only, and record the split hash. Teams that skip this discover it three months later when a customer reproduces the evaluation and gets different numbers.
Evaluating on synthetic data. The hold-out must be real. A synthetic test set measures how well the model learned the generator, which is a fact about your code and not about the mission. When real hold-out truly does not exist, the correct move is to say so in the report and describe the evaluation as a functional check rather than a performance claim.
Mixing without provenance. Every synthetic row needs a provenance flag that survives every join, export, and hand-off. Once real and generated records are commingled in a table with no marker, separating them later is guesswork. We carry an origin column plus a dataset version on every record we generate, and we treat losing it as a defect.
Assuming generation strips the sensitivity. A dataset derived from controlled unclassified information is not automatically releasable because a model sat in the middle. The CUI program under 32 CFR Part 2002 and the safeguarding obligations in DFARS 252.204-7012 attach to the information, and the determination that a derived product is releasable belongs to the data owner, not to the contractor who generated it. The same logic governs health data: HIPAA de-identification has two defined routes at 45 CFR 164.514(b), expert determination and safe harbor, and "we generated it" is neither.
Ignoring the rights chain. Under FAR 52.227-14 and, on defense work, DFARS 252.227-7013 and 252.227-7014, delivered data carries rights categories that are negotiated before delivery and painful to renegotiate after. SBIR-developed data holds its protected status for twenty years from award under DFARS 252.227-7018 and the SBIR/STTR Policy Directive. A synthetic dataset derived from government-furnished data can inherit constraints from its source, so the rights conversation belongs in the kickoff, alongside the government-furnished data discussion.
Evaluation: what good looks like numerically
"It looks realistic" is not a result. A synthetic dataset gets four measurements before we will let it leave the bench, and each one catches a failure the others miss. The thresholds below are the working defaults we use for tabular work; they move with the domain, and we state the ones in force in the report.
| Axis | Measure and working target | What it misses |
|---|---|---|
| Marginal fidelity | Kolmogorov-Smirnov statistic per continuous column and total variation distance per categorical column; target below 0.05, investigate above 0.10. | Every column can match perfectly while the relationships between them are destroyed. |
| Dependence structure | Mean absolute difference between the real and synthetic correlation matrices below 0.05; check conditional distributions on the three or four pairs the mission actually depends on. | Higher-order and rule-based constraints, such as a discharge date that must follow an admission date. |
| Downstream utility | Train on synthetic, test on real (TSTR) versus train on real, test on real. A gap under 2 points of AUROC is usable; 5 points or more means the generated set does not carry the signal. | Whether the gain is real or leakage. TSTR that beats TRTR is a red flag, never a win. |
| Distinguishability | Train a classifier to separate real from synthetic and read its AUROC. Near 0.50 is indistinguishable; above 0.80 means it found an artifact, and the feature importances tell you which one. | Memorization. An exact copy of a real record is perfectly indistinguishable and perfectly unsafe. |
| Privacy distance | Distance to closest record and the nearest-neighbor distance ratio against the training sample; membership-inference AUC near 0.50. Zero exact matches, always. | Formal guarantees. Only differential privacy at fit time provides those. |
| Formal guarantee | If differential privacy is used, report the epsilon, the delta, the accounting method, and the unit of privacy. NIST SP 800-226 (2025) is the reference for how to evaluate what a claimed epsilon is worth. | Utility. A very small epsilon can produce a dataset that is private and useless. |
Two numbers deserve special attention. The distinguishability test, which appeared in the statistical literature as the propensity-score mean squared error (Snoke et al., 2018), is the fastest way to find a generator bug: a classifier that separates real from synthetic at 0.95 AUROC usually caught a formatting tell, such as a timestamp that always lands on the second or a currency field that never carries cents. And the TSTR-beats-TRTR result is the one we treat as an automatic stop. A synthetic training set that outperforms real data is telling you it saw the answers.
The failure modes teams actually hit
The tail disappears. Generators fit the mass of the distribution and drop the extremes, which are frequently the exact records the project cares about: the fraud case, the anomalous flight, the equipment that failed. Check coverage of the tail explicitly by comparing counts in the top and bottom percentiles, because aggregate fidelity scores will look fine while the rare class is gone.
Memorization. Modern generators can reproduce training rows verbatim, especially for records that were unusual to begin with. Run an exact-match and near-match scan against the source before any release, and treat a single exact match as a release blocker rather than a rounding error.
Recursive collapse. Training successive model generations on their own outputs degrades them, an effect documented by Shumailov and colleagues in Nature in 2024. In practice this shows up quietly: a team refreshes a synthetic corpus each quarter using the previous quarter's synthetic corpus as input, and eighteen months later the variance is gone. Always re-fit from the real snapshot, never from the last generated set.
Synthetic labels. Generating features is one problem. Generating the label is a different and much harder one, because the label is the thing the system is supposed to predict. A dataset where a language model wrote both the narrative and the classification teaches the downstream model to imitate the labeler. If the labels matter, real annotation is the answer, and a real labeling workflow is cheaper than the rework.
The simulation gap. For imagery and sensing, photorealism to a human eye is not realism to a detector. Sensor noise characteristics, compression artifacts, lens and atmospheric effects, and label conventions differ between the simulator and the instrument, and the model latches onto whichever cue is easiest. Domain randomization helps; a real validation set is what proves it.
Schema drift. The generated dataset was built against last spring's schema. The production feed added two fields and changed an enumeration. The pipeline built on the synthetic version fails on contact. Pin the generator to the schema version and fail the build when they diverge.
Production concerns: cost, latency, monitoring
Cost is arithmetic, so do it first. Tabular generators are inexpensive; fitting a copula or a tabular diffusion model on a few million rows is a single-digit number of GPU hours. Text generation is where budgets break. One million synthetic case narratives at roughly 300 output tokens each is 300 million tokens, and at a list price on the order of $10 per million output tokens for a mid-tier hosted model in early 2026, that is about $3,000 per full regeneration, before retries and before the discarded first three attempts. Two regenerations a month is a real line item, and it is worth pricing against the labeling budget it was supposed to replace.
Latency shows up in the places people forget. Most generation is offline and batch, so the service-level question is regeneration cadence rather than response time. The exception matters: when generated data backs on-demand sandboxes or ephemeral test environments, the generator becomes a production service with an availability target, a queue, and a failure mode that blocks other teams. Size it accordingly and cache aggressively, because the same seed should yield the same dataset.
Reproducibility is the deliverable. Every dataset we ship carries the generator commit hash, the random seed, the source snapshot identifier, the split hash, the library versions, and the evaluation report. Federal customers increasingly write reproducibility requirements directly into acceptance criteria, and a dataset that cannot be regenerated bit-for-bit is a dataset that cannot be defended.
Monitoring is about the gap, not the data. The thing to watch is the distance between the live feed and the snapshot the generator was fitted to. We run a scheduled job that computes the same KS and total-variation statistics between current production traffic and the generator's training snapshot, and alerts when any column crosses the threshold. That alert is the signal to re-fit. Without it, the synthetic environment slowly stops resembling the system it stands in for, and nobody notices until an integration test passes on data that no longer exists.
The Sequence We Run
When a simpler method is the right answer
We talk customers out of synthesis more often than we build it, because four cheaper methods cover most of what people come asking for.
You need a test fixture. Then a schema-driven fake-record library with constraint rules is the answer. It runs in seconds, it is deterministic, it produces the pathological cases you want on purpose, and it requires no statistical defense.
You need a safe development environment. Then masking, tokenization, and referentially consistent subsetting are usually cheaper, faster, and easier to explain to a privacy office than a fitted generative model. They preserve the real structure exactly, and the residual risk is well understood.
You have class imbalance. Then try class weights, threshold tuning against the actual cost matrix, and stratified sampling before any generator. A properly tuned decision threshold routinely beats an oversampled training set, and it costs an afternoon.
You cannot get the data. Then the problem is contractual, not technical, and generation is a way of feeling productive while the real blocker sits untouched. The faster path is an email that names the data steward, a data-sharing agreement, and a delivery clause in the statement of work. Most stalled projects we are asked to rescue stalled at the data access step, and no amount of generated data moves that gate.
What ships with a synthetic dataset
- A datasheet in the sense of Gebru et al. (CACM, 2021): purpose, source, method, composition, and permitted uses
- Generator commit hash, random seed, library versions, and source snapshot identifier
- The locked split hash, so the evaluation can be reproduced exactly
- The five-axis evaluation report with the thresholds that were in force
- Differential-privacy parameters and accounting method, when DP was used
- A provenance column on every record and a documented handling determination from the data owner
- A re-fit date, after which the dataset is considered stale
This packaging maps cleanly onto the Measure and Manage functions of the NIST AI Risk Management Framework (AI RMF 1.0, January 2023), which is the vocabulary most federal customers now use when they ask how a dataset was controlled. Producing it costs a few hours at the end of a build and saves weeks during review.
Bottom line
Synthetic data is a good answer to a narrow set of questions: how do we build while access is pending, how do we test at scale, how do we cover events a validated simulator understands better than our sample does. It is a poor answer to the question of whether a system works, because that question is only settled by real data the model has never seen. Teams that hold that line get a useful tool. Teams that cross it get numbers nobody can defend, usually at the exact moment the numbers start to matter.
Frequently asked questions
Sometimes for part of the training set, almost never for all of it, and never for evaluation. The test to run is train-on-synthetic, test-on-real against a train-on-real baseline. A gap under 2 points of AUROC means the synthetic set carries the signal; 5 points or more means it does not.
No. A generator can reproduce training records verbatim, and membership-inference attacks work against poorly fitted generators. Only differential privacy applied at fit time gives a formal guarantee, and the epsilon has to be reported and interpreted. NIST SP 800-226 sets out how to evaluate such a claim.
Not on its own. The CUI program at 32 CFR Part 2002 and the safeguarding requirements at DFARS 252.204-7012 attach to the information, and the determination that a derived product may be released rests with the data owner. Get that determination in writing before the dataset leaves the enclave.
Five measurements: marginal fidelity, dependence structure, downstream utility, distinguishability from real data, and privacy distance. A dataset that passes fidelity but fails utility is decorative. One that passes everything at a suspiciously high level is usually leaking.
Tabular generation is cheap, at single-digit GPU hours for a few million rows. Text generation scales with tokens: a million narratives at 300 output tokens each is 300 million tokens per regeneration, so the recurring cost, not the first build, is what to budget for.