What is Synthetic Data?
Data generated by models or simulation engines, used to fill gaps where real data is scarce, cover long-tail scenarios, and control cost.
Synthetic data is generated by models or simulation engines rather than collected from the world. It exists because real data is scarce, expensive, or unavailable for the cases that matter most, and because the long tail of rare scenarios is exactly what a simulator can produce on demand.
The category carries a risk no other category has: the output can look correct and still be wrong along a dimension that matters. A generated image can be photorealistic and physically impossible, and a model trained on it learns the impossibility.
The uses are filling gaps where real data is thin, covering long-tail scenarios that are rare or unsafe to collect, and controlling cost where real collection is prohibitive. Each use implies a different validation requirement.
What buyers get wrong
The risk with synthetic data is distribution shift: however realistic the output looks, it can still diverge from real data along dimensions that matter, and the model fails once it ships.
The specification detail that decides everything
The generation method, the model version used, and whether alignment with real data was validated all have to be documented.
This is the line item that most often separates a dataset that works from one that gets re-ordered. It belongs in the specification before production starts, not in the delivery review.
How we source it
We do not hold inventory in this category. A requirement comes in, we match it to a producer who can meet the specification, and we agree the quality bar with both sides before recording begins. A pilot batch goes first so misalignments surface early.
Scenarios this covers
Buyers rarely ask for a category by name. They describe a situation, and the situation is what tells us whether this category is the right one. If yours is in the list, name it in the brief and it goes straight into the specification. If it is not, describe it anyway, because it usually means the requirement sits in a neighbouring category.
What good Synthetic Data looks like
Synthetic data is judged on its validation against real data, not on how it looks. Five things have to be documented.
-
Generation method and model version
Which simulator or which generative model, at which version, because the same method at a different version produces a different distribution.
-
Real-data validation, with the comparison stated
Whether the synthetic set was compared against real data and on which dimensions, because appearance is not the dimension that matters.
-
Coverage claims bounded by the generator
What the generator can and cannot produce, stated honestly, because a simulator of indoor scenes does not produce outdoor weather.
-
Label provenance
Whether labels come from the generator, from a model, or from human review. Generated labels are exact only for what the generator actually modelled.
-
Provenance and licensing of the generator
Model-generated content can carry terms from the model that produced it, and the chain has to be documented before the data is used commercially.
Public datasets in this category
These are openly documented resources, not products we sell. Each one covers part of the category, and knowing where each stops is usually what decides whether a project needs a collection of its own.
-
SYNTHIA and GTA5
Driving-scene datasets rendered from a game engine with pixel-perfect labels. They demonstrate the core advantage of synthetic data, which is exact annotation, and the core problem, which is the appearance gap to real footage.
-
BlenderProc and similar generators
Open pipelines for rendering photorealistic scenes with automatic labels. The tooling is public and the resulting datasets are usually bespoke, which is how synthetic data is actually used.
-
Synthetic instruction corpora
Text datasets generated by language models, such as instruction-following collections distilled from larger models. Widely used, and their quality is bounded by the generating model and by the filtering applied afterwards.
-
Why synthetic data is a complement
Synthetic material covers rare cases cheaply and cannot substitute for real data, because a model trained only on simulation learns the simulator. The practical pattern is synthetic for coverage, real for grounding.
Questions to ask a supplier
Questions that separate a supplier who validated the data from one who merely rendered it.
- Which generator and which version produced this, and is the version recorded per record?
- Was the synthetic set compared against real data, and on which dimensions?
- Where do the labels come from: the generator, a model, or human review?
- What are the generator's known limitations, and how are they reflected in the coverage claims?
- What licensing terms attach to content produced by the generator?
The vague answer in this category is about the generator. A supplier who says the data is synthetic without naming the model or the pipeline that produced it has described a category rather than a product. Synthetic content inherits the characteristics and the restrictions of whatever generated it.
A verifiable answer names the generator, its version, the filtering applied afterwards, and the measured diversity of the output. Ask for the ratio of synthetic to real records where both are present, because that ratio is the main lever on how much the model learns the simulator rather than the world.
Technical attributes
The items below are the ones a specification can hold a producer to, and the ones that decide whether a delivery is usable for training rather than only present.
| Generation method | Simulator or model, named |
|---|---|
| Generator version | Recorded per record |
| Real-data validation | Dimensions compared, and the result |
| Label provenance | Generator, model, or human review |
| Coverage boundary | Stated limitations |
| Delivery format | Data with generation metadata per record and a validation report |
The generator provenance column decides the licensing position, and it is the one most often omitted. Content produced by a model carries whatever terms apply to that model, and those terms change between versions. A corpus that does not record the generator cannot be evaluated for that risk at all.
The values come from the purpose the data serves. Synthetic material is usually bought to cover rare cases cheaply, so the specification should name those cases and the required coverage. A supplier proposing a broad synthetic corpus without asking which cases are missing is proposing volume rather than coverage.
A mistake here is measured as a gap between simulation and reality. A model trained on synthetic data performs well on more synthetic data and poorly on real data, and the gap is invisible while evaluation uses the same generator. Closing it requires real data, which means the synthetic corpus was a cost rather than a substitute.
How Synthetic Data is collected
Generation is cheap; validation is the work, and it is what the buyer is paying for.
- Target defined against the real gap. The synthetic set is designed to cover what real data does not, rather than to reproduce what real data already covers.
- Generator selection and version pinning. The generator is chosen for the domain and its version is pinned and recorded, because an unpinned version makes the corpus unreproducible.
- Generation with parameter variation. Scene parameters, lighting, object placement and sensor configuration are varied deliberately, and the variation is logged.
- Real-data validation. A sample is compared against real data on the dimensions the use case depends on, and the comparison is reported rather than summarized as a pass.
- Label verification and delivery. Labels are checked against the generator's model, and the limitations and validation results are delivered with the data.
After generation, the output is filtered for quality and duplicates, diversity is measured against the target distribution, and the files are packaged with a manifest naming the generator and the filtering rules. The diversity measurement is the step that distinguishes a large corpus from a varied one.
The pilot for synthetic data is a small generation run with the intended generator and the intended filtering, evaluated against a held-back slice of real data before the full run. Its purpose is to measure the gap between the generated distribution and the real one, because that gap is the only thing that decides whether the synthetic material substitutes for real records or only supplements them. A pilot measures it cheaply.
Acceptance is checked on the measured diversity and on the generator provenance record, both against figures stated before generation. The specification should name the cases the synthetic material is meant to cover before the run starts, because a generator asked for volume produces volume. Where the pilot shows the gap is large, the generator or the filtering is changed rather than the target relaxed.
How a delivery goes wrong
The defects below are the ones that recur across this category. Each is decided at collection or annotation time, which is why none of them can be repaired in delivery review.
-
The generation model is not disclosed
Synthetic content carries the characteristics and the restrictions of whatever produced it. A delivery that does not name the generator cannot be evaluated for licensing risk or for the biases it inherits.
-
Synthetic and real records are not distinguished
Where a corpus mixes both, each record has to say which it is. Without the flag, the buyer cannot control the ratio, and the ratio is the main lever on how much the model learns the simulator.
-
Diversity collapses at scale
Generated content tends to repeat its own patterns. A large synthetic corpus is often far less varied than its size suggests, and measuring that requires a diversity check rather than a row count.
Why this matters to buyers
The long tail is where real collection fails. Rare events, dangerous scenarios and expensive setups are exactly what a system needs to handle and exactly what is impractical to record, and simulation is the only practical source.
The second driver is cost. Where real collection is possible but prohibitive, synthetic data changes the economics. That holds only if the set is validated, because an unvalidated set that produces a model failing in deployment has cost more than the real collection would have.
A model trained mostly on synthetic data learns the simulator. It behaves correctly in the environments the generator produces and incorrectly everywhere else, and the errors are systematic rather than random. Discovering this after deployment means the real-data collection happens under schedule pressure rather than as part of the plan.
The second cost is licensing. Generated content can carry restrictions from the model that produced it, and a corpus that cannot name its generator cannot be cleared. Buyers in regulated industries ask for this first, and a negative answer ends the evaluation regardless of the data quality.
Synthetic material that was measured against real data gives coverage of the rare cases that motivated the purchase, at a cost real collection cannot reach. The team knows how far the synthetic set can be pushed before the simulation gap dominates, and that boundary is what makes it usable rather than risky.
The second gain is that the generator is documented. Terms attached to generated content change between model versions, and a delivery that records the generator and its version can be re-cleared when those terms change. That record is what keeps the corpus usable over time.
Specification at a glance
| Category | Synthetic Data |
|---|---|
| Group | New data paradigm |
| Critical spec | The generation method, the model version used, and whether alignment with real data was validated all have to be documented. |
| Included by default | Pilot batch, metadata schema, source and consent documentation |
| Pricing | Quoted from specification. No published rates |
Related categories
-
Embodied AI Data
Multimodal data generated as robots and embodied agents operate in real environments: vision, action trajectories, and language instructions.
-
World Model Data
Environment interaction data for training world models, emphasizing temporal consistency, physical plausibility, and predictability.
Questions about Synthetic Data
How do we know the synthetic data is good enough?
By comparing it against real data on the dimensions the use case depends on, and reporting the comparison. Visual similarity is the least informative check; what matters is whether the distributions agree where the model will be evaluated.
Does the generator version really matter?
Yes, and it is the most commonly missing piece of documentation. A generative model at a new version produces a different distribution, so a corpus that does not record its version cannot be reproduced or extended consistently.
Where do the labels come from?
From the generator where it models the label exactly, which is one of the advantages of simulation, and from a model or human review where it does not. The provenance is recorded per record because it determines how much the label can be trusted.
Is synthetic data a substitute for real data?
No, it is a complement. It covers what real data cannot reach and does so cheaply, but a model trained only on synthetic data meets the real distribution as an unseen one. Most programmes combine them.
Do you have Synthetic Data available now?
No. We do not hold inventory. Everything is produced against a specification. That means the timeline starts when the spec is agreed rather than immediately, and it also means the data matches your requirement instead of approximately matching something already built.
Can this be combined with other categories in one delivery?
Yes, and it is common. A single specification can cover several categories across several languages, with one pilot batch and one quality bar. It usually reduces total cost because contributor recruitment and project setup are shared.
What does the consent documentation cover?
Signed contributor consent stating the intended use, the collection methodology, and the annotation guideline the data was produced under. For projects involving EU data subjects the chain is built to satisfy GDPR, including the transfer mechanism. The terms for moving the data across a border.
Request Synthetic Data
Tell us the language, the hours, and what the data needs to look like. You will get a real number and a real timeline, not a range. If we cannot source it well, we will tell you that instead.
- Pilot batch before the full run, so problems surface early.
- Consent documentation delivered with the data.
- No medical or clinical data. No recorded telephone calls.
- You send the spec Language, hours, recording conditions, and the deadline.
- We reply within two business days A real number and a real timeline, not a range.
- You approve a pilot batch A small run first, so problems surface before the full order.
- Full run, then delivery with documents Audio, transcripts, and the consent record for every speaker.