Part I — Generated examples
What synthetic examples change
In this chapter, a synthetic example means a record whose input, target, or both were constructed or transformed rather than observed together as one intact case. This working definition concerns the record's origin, not its realism. A fictional patient simulated from demographic distributions and disease modules is synthetic even if every field is plausible; a real image whose label was predicted by a model combines an observed input with a synthetic target. Machine Learning Fundamentals explains examples and targets, while its treatment of generalization explains why fitting more rows is not itself the goal.
What was constructed?
| Intervention | Input | Target | What must be justified |
|---|---|---|---|
| Simulation or procedural generation | Constructed from a process model | Derived from simulator state or rules | The process and target rules represent relevant real conditions |
| Task-preserving augmentation | Transformed observation | Observed target, transformed when necessary | The transformation preserves or predictably changes task meaning |
| Pseudo-labeling | Observed but unlabeled input | Model prediction | The provisional label is accurate enough for its permitted use |
| Back-translation | Generated source sentence | Observed target-language sentence | The generated source preserves the target's meaning |
| Teacher-generated supervision | Observed or generated input | Teacher output or distribution | Teacher behavior is useful and its errors are controlled |
Turning points in generated data
Generated-data methods developed along several lines because practitioners faced different constraints. In 1949, Nicholas Metropolis and S. Ulam described Monte Carlo computation as repeated sampling from specified stochastic and deterministic processes when direct mathematical treatment was difficult. In 1995, David Yarowsky demonstrated iterative self-labeling for word-sense disambiguation, beginning with small seed sets and adding confident predictions. SMOTE, published in 2002, constructed minority-class feature vectors between neighboring examples rather than merely copying rare rows. Back-translation, reported by Rico Sennrich, Barry Haddow, and Alexandra Birch in 2015 and published in 2016, used observed target-language text with automatically generated source sentences. In 2017, Josh Tobin and colleagues varied simulated camera position, lighting, textures, distractors, and object placement to pursue transfer into real robotic scenes.
Different constraints, different construction methods
September 1949The Monte Carlo MethodSample specified event processes when direct mathematical treatment is difficult.
Contributors: Nicholas Metropolis and S. Ulam
What changed: Described repeated sampling of stochastic and deterministic event chains for mathematical-physics computation. This is a process-sampling tradition, not a claim that the paper introduced an ML training-data recipe.
June 1995Yarowsky’s self-labeling methodExpand small sense-specific seed sets with confident predictions on unlabeled text.
Contributors: David Yarowsky
What changed: Repeated classifier training and labeling until the unlabeled residual stabilized. Added cases could return to the residual when confidence fell, making provisional labels revisable rather than permanent.
June 2002SMOTEConstruct minority-class feature vectors between neighboring minority examples.
Contributors: Nitesh V. Chawla, Kevin W. Bowyer, Lawrence O. Hall, and W. Philip Kegelmeyer
What changed: The published method addressed class imbalance through interpolation rather than repeated copying. Its motivation was to encourage broader minority-class decision regions instead of increasingly specific regions around duplicates.
2015 report · 2016 publicationBack-translationGenerate source sentences while retaining observed target-language text.
Contributors: Rico Sennrich, Barry Haddow, and Alexandra Birch
What changed: Used monolingual target-language corpora to extend translation training without changing the translation architecture. Reported English-to-German improvements exceeded the parallel-data baseline; additional baseline training alone did not explain the gains.
March 20, 2017Domain RandomizationVary simulated scenes to train perception for real-world conditions.
Contributors: Josh Tobin and colleagues
What changed: The report varied cameras, lighting, textures, distractors, and object placement instead of precisely matching reality. Simulation-trained perception supported localization and grasping of tested real objects; ablations showed that the chosen randomizations mattered.
These were not stages in a replacement sequence. Simulation remains useful when a process can be modeled but observations are scarce or dangerous to collect. Augmentation encodes selected invariances. Pseudo-labeling exploits unlabeled observations. Teacher-generated records transfer behavior or create flexible language tasks. Each changes a different part of the evidence and can coexist with the others.
Part II — Specification and lineage
Write the generation contract
Generation should begin with a generation contract, not a prompt. First define the example unit and the intended task population. Then state the downstream role—training, development, challenge testing, or final assessment—and identify the missing capability or population slice. Specify allowed sources, constructed fields, required targets, validity constraints, desired variation, exclusions, duplicate policy, failure dispositions, and a stopping condition. A prompt is only one implementation artifact within this larger contract.
Contract fields
- Unit — What does one record represent, and which records share an ancestor or real-world entity?
- Population — Which situations should the resulting capability cover, including consequential slices and exclusions?
- Construction — Which fields come from observations, transformations, rules, retrieval, simulation, or a teacher model?
- Target authority — Who or what can establish the expected answer, and what properties can it actually observe?
- Acceptance — Which checks lead to acceptance, correction, quarantine, rejection, or unresolved status?
- Stopping — Which coverage, cost, or downstream result ends further generation?
A teacher model supplies candidate outputs or labels; it is neither automatically the downstream learner nor an authority on truth. Instructions and demonstrations can steer its behavior, as described in Turn a request into a task contract and Choose examples for coverage. Temperature, random seeds, and prompt variations change samples, but they do not prove that the samples occupy meaningfully different task regions. Self-Instruct, for example, generated and filtered instructions from a small human seed set, yet an audit found that valid-looking instructions and correct complete records were materially different sets.
Keep lineage at record level
Provenance records origin and production circumstances; lineage connects source entities, generation activities, derived records, verification results, and downstream releases. A useful record keeps stable identifiers for its permissible seeds, generator family and version, prompt or program version, sampling configuration, transformations, generation time, target source, verifier results, and release membership. This extends the general provenance responsibilities in Origins, times and permitted use and the release model in A release is a dependency graph.
Lineage enables focused correction. If a source is withdrawn, a prompt is found defective, or a verifier is recalibrated, dependency records identify affected candidates and releases. It also reveals shared ancestry: ten thousand rows derived from one seed, one teacher, and one judge are ten thousand records, but not ten thousand independent confirmations. Still, provenance proves neither correctness nor permission. A closed model can be named precisely while its training exposure remains unknown, and synthetic data can retain information about source individuals unless privacy is separately established in Privacy and Data Governance.
A release contains records and their dependencies
ExampleSeparate records may share seeds, configurations, and verifiers, creating common dependencies that a flat table hides.
Read the diagram as text
- Permitted source seed. Stable source identity, version, context, and eligibility metadata.
- Generator configuration. Model, prompt or program, sampling settings, and execution environment.
- Candidate A. Generated record with stable identity.
- Candidate B. A separate record sharing the same seed and configuration.
- Verification record. Checks, outcomes, reviewer identity, and unresolved properties.
- Release manifest. Immutable membership list and release identity.
- Permitted source seed → Candidate A: derivation source.
- Permitted source seed → Candidate B: derivation source.
- Generator configuration → Candidate A: generation activity.
- Generator configuration → Candidate B: generation activity.
- Candidate A → Verification record: checked candidate.
- Candidate B → Verification record: checked candidate.
- Verification record → Release manifest: acceptance evidence.
- Candidate A → Release manifest: release membership.
- Candidate B → Release manifest: release membership.
Part III — Coverage and acceptance
Design coverage for the task
Coverage begins with the target population: the situations about which the system's eventual claim is intended to hold. The generator can reach only a constructed frame within that population. If the contract omits mobile screenshots, multilingual requests, long conversations, or a consequential policy branch, producing more rows from the remaining frame cannot repair the omission. This is the same population–frame distinction developed in Population, frame and sample.
Variety is not one quantity
Several properties often called diversity answer different questions. Surface variety changes wording or presentation. Semantic variety changes the underlying scenario. Label balance changes target proportions. Difficulty changes the reasoning or control burden. Support coverage asks whether relevant regions of the intended population are present. Distributional precision and recall can diagnose unsupported or missing modes relative to a reference representation, but they do not establish task-specific slice coverage, correct labels, novelty, or downstream value.
Coverage ledger
| Task slice | Observed | Generated | Verified | Accepted | Known gap |
|---|---|---|---|---|---|
| Common condition | count | count | count | count | reason or none |
| Rare consequential condition | count | count | count | count | reason or none |
| Format or interface variation | count | count | count | count | reason or none |
| Intersection of conditions | count | count | count | count | reason or none |
Controlled variation is useful only when combinations remain coherent. DigiWorld's reported approach combined task templates, corresponding verifiers, mock data, and base interface state, then rejected invalid configurations. The mechanism illustrates why environment generation needs a compiler-like validity stage. It does not show that retained combinations match production frequencies; representative sampling and deliberate rare-case coverage remain different goals.
Establish the target separately
Generating an input and establishing its label are separate acts. A simulator can expose an internal state, a program can check an executable property, a source document can support an answer, a person can apply a rubric, and a model can supply a provisional judgment. These authorities observe different things. The correct choice depends on the target specification, including whether several answers are valid or the case should remain unresolved. See Specify the label and Choose checks that match the requirement.
An executable test oracle decides whether observed behavior satisfies encoded criteria. It may be partial, and the encoded criteria may misunderstand the intended requirement. A code test can miss an authorization rule; an exact string match can reject an equivalent value. Independent execution therefore validates only the specified checks. Human adjudication can address ambiguity but remains fallible. A model judgment is best treated as a measurement instrument: confidence and agreement describe model behavior, not ground truth.
Verification has a granularity
Answer-first construction can make checking easier. A synthetic question-answering pipeline may select a known source span, generate a question conditioned on it, and retain the case only if a separate answering model recovers that span. In reported round-trip filtering experiments, this improved downstream results, yet a small manual audit still found many accepted triples incorrect. Likewise, a correct final answer can conceal invalid intermediate reasoning. Verification should match the granularity of the claim: outcome checks support outcomes; process claims need process evidence.
Generate with the answer; check without it
The selected span conditions question generation but reaches the comparison without being supplied to the answering model.
Read the diagram as text
- Passage. Source text used for span selection, question generation, and answering.
- Selected answer span. Intended answer selected from the passage.
- Question generator. Generates a question conditioned on the passage and selected answer.
- Generated question. Candidate question about the passage.
- Answering model. Separately trained model receives passage and question, without the selected answer span.
- Recovered span. Answer predicted from the passage and generated question.
- Compare spans. Compare the recovered answer with the originally selected span.
- Retained triple. Passage, question, and selected answer retained on round-trip agreement.
- Discarded triple. Candidate excluded when the answering model does not recover the selected span.
- Passage → Selected answer span: select span.
- Passage → Question generator: source text.
- Selected answer span → Question generator: intended answer.
- Question generator → Generated question: generate.
- Passage → Answering model: source text.
- Generated question → Answering model: question.
- Answering model → Recovered span: predict.
- Selected answer span → Compare spans: intended span.
- Recovered span → Compare spans: predicted span.
- Compare spans → Retained triple: agreement.
- Compare spans → Discarded triple: disagreement.
Filter without erasing the task
Candidate filtering should preserve the meaning of each gate. Structural validation checks schema and required fields. Semantic validation checks whether values make sense together. Deduplication checks identity or similarity under a declared rule. Eligibility checks permitted use. Label verification examines the target. Difficulty selection changes the training distribution. Combining these into one opaque “quality score” makes failures hard to diagnose and hides which population survived.
The available dispositions are not merely pass and delete. Correction keeps a candidate with a recorded derivation. Quarantine preserves it for review without admitting it to the release. Abstention leaves a target unresolved. Rejection excludes it for a stated reason. Logging every disposition preserves evidence about the generator and the filter. Inspect rates by slice: C4 blocklist analysis found scientific, medical, identity-related, and dialect-associated text among rejected documents, illustrating how a filter can improve one criterion while changing corpus composition.
A threshold trades accepted coverage against error among accepted cases. Lower error after stricter filtering may simply reflect a smaller, easier retained population. Report both coverage and selective risk, and audit rejected cases. In visual-generation work, conventional aesthetic filters can remove deliberately low-fidelity styles; in reasoning-data experiments, a plausible quality filter can underperform random selection for the downstream student. Acceptance quality is therefore a hypothesis to test, not an intrinsic property of the filter score. Coverage means accepted candidates divided by all candidates; selective risk means errors divided by accepted candidates.
A stricter filter changes who remains
These 12 fixed candidates are a teaching example with independently adjudicated correctness labels. Selection scores are not probabilities of correctness.
Changing the threshold changes selection, not the candidates or their correctness.
Accepted: 9/12; coverage: 75.0%; selective risk: 22.2%. Rare slice: 1/4 accepted.
| Population | Accepted / all | Coverage | Errors / accepted | Selective risk |
|---|---|---|---|---|
| All candidates | 9/12 | 75.0% | 2/9 | 22.2% |
| Common slice | 8/8 | 100.0% | 2/8 | 25.0% |
| Rare slice | 1/4 | 25.0% | 0/1 | 0.0% |
Coverage = accepted / all candidates. Selective risk = errors / accepted candidates; it is undefined when none are accepted.
Common slice
- C1 Score 95✓ CorrectAccepted
- C2 Score 90✓ CorrectAccepted
- C3 Score 85× ErrorAccepted
- C4 Score 80✓ CorrectAccepted
- C5 Score 75✓ CorrectAccepted
- C6 Score 70× ErrorAccepted
- C7 Score 65✓ CorrectAccepted
- C8 Score 60✓ CorrectAccepted
Rare slice
- R1 Score 55✓ CorrectAccepted
- R2 Score 45✓ CorrectRejected
- R3 Score 35× ErrorRejected
- R4 Score 25✓ CorrectRejected
Compare 50 → 70: the error count stays at two while accepted cases fall from nine to six, so risk rises. At 90, risk is zero, but every rare case is excluded—including three correct cases.
Part IV — Defects and boundaries
Count independent information
A dataset's row count overstates its independent information when records share causes. The same teacher can repeat a factual error; the same prompt family can enforce a stylistic shortcut; the same seed can generate semantic clones; the same simulator can omit one physical effect; and the same verifier can approve the same loophole. Two different models are not automatically independent either. Research across multiple-choice datasets found that model pairs often selected the same wrong answer more frequently than a uniform-choice baseline, with shared providers and architectures associated with greater agreement.
Same marginal accuracy, different evidence
| Dataset | Records | Routine slice | Consequential slice | Accuracy | Interpretation |
|---|---|---|---|---|---|
| A: dispersed | 100 | 3 errors across several sources | 1 error across several sources | 96% | No single slice-source block contains every error |
| B: clustered | 100 | 0 errors | 4 errors from one generator family | 96% | One shared defect could explain every error and erase the consequential slice |
Recursive data is conditional, not doomed
Recursive use adds a specific feedback mechanism. When each generation replaces prior data with samples from the preceding model, finite sampling can drop rare regions and approximation errors can compound. Experiments on recursive replacement report degradation; experiments retaining earlier data and accumulating new samples kept error bounded in their tested settings. This does not imply that every synthetic mixture collapses or supply a universal safe ratio. Replacement, accumulation, filtering, model family, and task conditions must remain explicit.
Protect the assessment boundary
Contamination occurs when evaluation information reaches training, generation, selection, prompting, retrieval, or verifier development through a path the assessment intended to exclude. Exact duplicates are only one route. Paraphrased questions and solutions can evade overlap detectors while still conveying assessment information. A generator may already know a public benchmark, and repeatedly changing a pipeline after inspecting final results turns those results into development feedback. The broader evaluation contract appears in Protect the independent assessment.
Controls follow information paths
Split protected cases and their source families before data-dependent generation or resampling. Keep descendants of the same document, task, user, repository, or scenario family together when the claim concerns unseen families. Preserve private, fresh, temporal, or externally sourced assessments when appropriate. Record generator and verifier exposure as known, ruled out, or unknown. A recent test is not automatically independent, and complete recorded lineage cannot reveal undisclosed model-training data.
Part V — Uses and evidence
Keep each artifact’s role explicit
Generated records can supply training inputs, labels, demonstrations, preference comparisons, critiques, reasoning traces, challenge cases, or regression cases. The role determines the evidence. Producing teacher outputs is data creation; distillation is the later transfer process in which a student learns from teacher behavior. Distillation owns that mechanism. Likewise, Post-training and Alignment owns the optimization recipes that update parameters from demonstrations, preferences, or rewards.
Evaluation roles
| Collection | Selection purpose | Supported claim | Unsupported leap |
|---|---|---|---|
| Representative sample | Estimate behavior for a defined population or weighting design | Population performance under the sampling assumptions | Coverage of unobserved conditions |
| Challenge set | Concentrate difficult or consequential cases | Discovery and diagnosis of failures | Production prevalence |
| Metamorphic suite | Transform cases under an expected relation | Whether behavior follows that specified relation | Complete correctness |
| Regression set | Preserve known cases across changes | Whether previously tested behavior remains | Generalization to new conditions |
Once an evaluation artifact influences prompt, model, filtering, or training choices, it becomes development evidence and no longer remains an untouched final assessment. The same record can be reclassified deliberately, but a new protected assessment is then required for the final claim. Synthetic challenge cases are especially useful for boundary discovery; their failure frequency should not be reported as deployment prevalence without a justified population design.
Test downstream utility
The decisive question is not whether generated records look good, but whether they improve the intended capability. A controlled utility test compares a credible incumbent or real-only baseline with a named synthetic-data intervention on the same protected assessment cases. Freeze the task definition, model, optimization procedure, prompts, update or exposure budget, and assessment protocol as required by the hypothesis. Separate the numbers generated, accepted, and actually consumed during training so an apparent gain is attributed to the correct intervention.
Experiment matrix
| Arm | Generated | Accepted | Trained on | Changed ingredient | Common assessment |
|---|---|---|---|---|---|
| Baseline | 0 or incumbent amount | — | fixed budget | No new synthetic intervention | Protected cases and slices |
| Unfiltered candidate | record count | record count | fixed budget | Generation only | Same protected cases and slices |
| Verified candidate | same proposals | accepted count | fixed budget | Verification rule | Same protected cases and slices |
| Alternative generator | matched proposals | accepted count | fixed budget | Generator family | Same protected cases and slices |
Inspect paired changes on each protected case and consequential slice, including regressions. Then test transfer to independently sourced or later conditions. Train on Synthetic, Test on Real formalizes one useful direction: split real evidence before fitting the generator, train a predictor on generated records, and test it on held-out real records. It measures replacement-data utility, not whether adding synthetic data beats a real-only baseline at equal cost. OpenThoughts similarly shows why selection must be judged through the downstream student: teacher ranking and filtering heuristics did not translate uniformly across its tested domains.
Tune on development cases; compare on protected cases
ExampleBoth frozen systems receive identical assessment inputs, while references enter scoring and final results remain outside development.
Read the diagram as text
- Source-family split. Assign source families before data-dependent generation or resampling. Recorded separation cannot rule out unknown pretrained-model exposure.
- Development sources. Training sources and separate validation evidence. Only development evidence informs generation, filtering, and tuning.
- Generate and filter. Tune using development evidence; record generated and accepted quantities separately. Freeze the declared replacement or augmentation intervention before final assessment.
- Matched controls. Prespecify the common model setup, optimization procedure, exposure or update budget, and scoring protocol required by the hypothesis.
- Frozen baseline. Incumbent or real-only training arm under the declared controls.
- Frozen candidate. Training arm with the named intervention under matched controls. Record quantities actually consumed, separately from generated and accepted quantities.
- Protected cases. Assessment inputs and references remain outside generation, selection, and tuning. Identical case IDs are used for both arms.
- Paired protected scores. Compare both outputs against the same protected references, by case and consequential slice. Results terminate here rather than tuning the candidate.
- Independent later cases. Separately sourced or later-condition inputs and references assess transfer without changing either frozen system.
- Paired transfer scores. Compare both frozen systems on the same later-condition cases and references.
- Source-family split → Development sources: development families.
- Source-family split → Protected cases: reserved families.
- Development sources → Generate and filter: permitted sources and validation.
- Development sources → Frozen baseline: baseline training data.
- Development sources → Frozen candidate: permitted observed data.
- Generate and filter → Frozen candidate: accepted training records.
- Matched controls → Frozen baseline: common controls.
- Matched controls → Frozen candidate: common controls.
- Protected cases → Frozen baseline: assessment inputs.
- Protected cases → Frozen candidate: same assessment inputs.
- Protected cases → Paired protected scores: case IDs and references.
- Frozen baseline → Paired protected scores: protected-case outputs.
- Frozen candidate → Paired protected scores: protected-case outputs.
- Independent later cases → Frozen baseline: later-condition inputs.
- Independent later cases → Frozen candidate: same later-condition inputs.
- Independent later cases → Paired transfer scores: case IDs and references.
- Frozen baseline → Paired transfer scores: later-condition outputs.
- Frozen candidate → Paired transfer scores: later-condition outputs.
Repeatedly revising generation or filtering after reading final-assessment results adaptively overfits the holdout. Reserve validation evidence for those choices and open final evidence only after the comparison is frozen. Dataset conformance and system improvement remain separate contracts, as developed in Data checks are not system success and Compare changes on matched work.
Part VI — Decision
Generate, verify, collect, or stop
Generation is promising when the missing variation can be specified, generated coherently, verified affordably, kept independent from assessment, and shown to transfer. The next intervention should follow the binding evidence gap. More rows help only when insufficient candidate coverage is the constraint; they do not repair a faulty oracle, shared generator defect, inaccessible real-world information, or contaminated assessment.
Evidence to action
| Observed pattern | Likely bottleneck | Next experiment |
|---|---|---|
| Important coverage cells are empty before filtering | Generation specification or source access | Generate targeted valid candidates, then measure verified yield |
| Candidates exist but labels fail review | Target authority or verifier | Compare oracle designs on independently adjudicated cases |
| One slice is disproportionately rejected | Filter-induced narrowing | Audit false rejections and test a slice-aware disposition policy |
| Errors cluster by teacher, seed, or verifier | Correlated defects | Add a genuinely different source or checker and inspect disagreements |
| Synthetic metrics improve but protected outcomes do not | No downstream transfer | Stop scaling; test a different intervention or collect observed cases |
| Aggregate improves while a consequential slice regresses | Coverage or objective tradeoff | Hold deployment and isolate the slice mechanism |
| Final evidence influenced development | Contamination | Replace it with fresh, independent assessment evidence |
Collect or label observed cases when the generator cannot supply the missing information. Improve verification when acceptance error dominates. Diversify generators or real anchors when defects cluster. Stop when additional accepted records no longer improve protected outcomes or introduce unacceptable regressions. There is no universal real-to-synthetic ratio, confidence threshold, or cost cutoff: generation cost, automated checks, human review, collection delay, provenance uncertainty, and downstream value all belong to the task-specific decision.
Open questions
How can a team estimate the independent information added by generated records when model training data, prompt ancestry, and verifier dependencies are only partly known? Progress would require lineage-aware dependence measures that predict downstream transfer better than row count or marginal accuracy.
Which verification mixtures best control false acceptance without erasing rare but valid task regions? The difficulty is that executable checks, human review, and model judges observe different properties and can share specification errors. Progress would include slice-level audits of both accepted and rejected candidates against independently adjudicated references.
Under what conditions does accumulating real and synthetic data remain stable across repeated training generations? Existing recursive-data results depend on replacement versus accumulation, model family, task, filtering, and training schedule. Progress would look like controlled studies that vary those factors while tracking rare-region coverage and independently sourced performance.
How should generation effort be allocated between common production cases, rare consequential cases, and boundary cases? The collections serve different goals—prevalence estimation, capability learning, and diagnosis—so a single aggregate mixture can hide the tradeoff. Progress would combine explicit population designs, risk-focused suites, and protected downstream comparisons.
Can generator and verifier provenance remain useful when closed models do not disclose their training corpora? Recorded configuration can establish known derivations but cannot rule out hidden benchmark or source exposure. Progress would require stronger disclosure, fresh or private assessments, and methods that quantify rather than erase unknown exposure.














































