Synthetic population generation

A synthetic population is a set of generated records designed to reproduce selected distributions and relationships in a reference population, without its rows being copies of specific people. It is useful when you need data that behave like the real data for development, testing or training. The difference from anonymised data lies in their origin: an anonymised dataset starts from records of real people and transforms them to reduce re-identification risk; a synthetic population is generated from the statistical properties of the population. When it is generated from reference distributions alone, no record derives from a person. If the generator is fitted to real microdata, the label ‘synthetic’ is not enough: a model that reproduces rare combinations can disclose information, so we also assess disclosure risk before the population is shared.

It has two main uses. The first is to create a development and validation environment when access to the real data is restricted: it lets you check that an analysis or pipeline works, or train a team, with plausible structures and patterns while governance is being resolved, and then validate the work with the real data. The second is to support model-based estimates or simulations for subgroups or areas where the survey or register does not have a large enough sample, with one condition: a synthetic population contains no information beyond the sources and assumptions used by the generator, so it does not fill an evidence gap by itself. It is a good fit when the bottleneck is access or sample size, not when you need to discover new relationships or replace the data collection required for an empirical conclusion.

The synthetic population reproduces the properties that have been explicitly modelled, the known marginal distributions and the dependence structure between variables, and fidelity is claimed for those, not for everything. This is worth understanding before using it, because "it resembles the real thing" has a specific scope. The marginal distributions of the target population are reproduced and the detail layer is generated conditionally on strata, preserving the dependencies that could be characterised and modelled; what is preserved and what is not is stated explicitly. That honesty is deliberate: a synthetic population is not a copy equivalent to the real data in every property, but a faithful reproduction of the properties that have been characterised. Fidelity is validated by checking the distributions and dependencies of the generated population against the reference ones before signing it off. Claiming fidelity for what has been modelled, and no more, is what separates defensible synthetic data from data that promise a resemblance they cannot sustain.

No: a synthetic population is for developing, validating and disaggregating, not for replacing real data in a study's definitive inference. It reproduces the properties built into its generator, so conclusions drawn from it reflect that model and its generation assumptions; it does not create new evidence about the real population. It can be used to develop an analysis, check that a pipeline works, train a team or explore scenarios before the final data are available, and it can support model-based estimates if they are presented as such and their behaviour is validated against observed sources. A confirmatory conclusion, however, must rest on suitable real data or independent external evidence. Synthetic data can accelerate and unblock parts of the work; they cannot replace the observations needed to establish what is happening in the population.

No. This service generates synthetic populations for development, validation and disaggregation; it does not produce synthetic control arms for clinical trials. This limit is worth stating because synthetic data generation is sometimes associated with that regulatory application, which is a different field. A synthetic control arm intended to replace a comparison group in a trial with a regulatory purpose requires its own methodological framework and set of requirements, which fall outside the scope of this service. The boundary is clear: synthetic populations for test environments, training, systems validation and estimation at fine-grained levels of disaggregation, yes; synthetic control arms for confirmatory inference in a regulatory trial, no. Anyone who needs that regulatory application will find an explicit boundary here, not a vague promise. The focus stays on the service's two legitimate uses.

Generation is reproducible and auditable: with a fixed seed and version-controlled code, the same input always produces the same population, and the process can be followed step by step. This applies to any use of the synthetic population, where opaque generation would be impossible to defend or to maintain. Reproducibility means that the dataset can be re-run and shared without ambiguity, and that anyone with the code, the seed and the same execution environment can reproduce the same population. Auditability means that the modelling decisions, such as which distributions are reproduced, which strata condition the generation or which dependencies are preserved, are in plain view, not hidden in a black box. On top of this comes fidelity validation, which checks the generated population against the reference distributions and dependencies. A synthetic population is only useful if you can trust how it was made, and that trust comes from the traceability of the process, not from how the result looks.

You need a characterisation of the target population: the known distributions, the available sources that describe it, and the strata and dependencies the synthetic population must preserve. The client provides knowledge of the population and the reference sources, and then uses the generated population for their own purposes; the service models, generates the population conditionally by strata with a fixed seed, and validates its fidelity. The full real microdata are not always essential. Work often starts from reference distributions and a known structure, and in those cases the resulting population is generated from reference distributions and dependencies, not from a copy of real individuals. What does determine the scope is the quality of the starting characterisation: the fidelity of the synthetic population depends on how well the properties it must reproduce are known. The service delivers the generation engine and the population; how it is used is the client's decision.

You receive the synthetic population together with the version-controlled generation code, the fixed seed and the fidelity validation that checks its distributions and dependencies against the reference ones. This applies if you need a reproducible working environment that is often reusable beyond its initial purpose. The population remains an asset: because it can be re-run and shared, it serves as a test bed for training, as a validation environment for future developments and as a regression-testing dataset, with fewer access restrictions than the real data, provided the conditions of use defined for that synthetic population are respected. The documented code makes it possible to regenerate or extend the population when needs change, without redoing the work from scratch. The service generates, models and validates; the client decides what to use it for. What you receive is not just a data file but the reproducible process that generates it, which is what makes it an asset rather than a one-off delivery.