Synthetic Data

01 The Problem

Most important business questions are about things that have not happened yet. What if we enter that market? What if the supplier fails? What if we change the underwriting rule? There are no historical records of a decision you have never made.

There is a second, more common problem. The records exist, but you cannot use them. They contain customer names, patient files, or trading positions. Legal will not release them. The vendor cannot see them. The pilot stalls before it starts.

Synthetic data answers both. It is data that is generated by a model rather than collected from the world. Done well, it behaves like the real thing without being the real thing. Done badly, it is an expensive way to fool yourself.

02 Two Starting Points

Everything depends on one question: do you already have real data? The two paths look nothing alike.

Path A: you have the data, but cannot share it. Here the goal is a stand-in. You study the real records, fit a model that reproduces their patterns, and generate new records from that model. No real person appears in the output, but the shape of the population survives. This is a privacy and access problem.

Path B: the data does not exist. No history covers the scenario. Here you cannot copy anything, so you build the model first and let it produce the data. The raw material is not a database. It is what your experts know: the operators, underwriters, engineers, and clinicians who have watched the system behave for twenty years.

Path B is the harder one, and the one that matters most in the enterprise. It is also the one that requires a causal model, because you are not describing what happened. You are describing how the system works, then asking it what would happen.

03 The Build

The sequence below is the expert-driven path. It is a structured interview, followed by a model, followed by data.

What makes the result credible in the room is specificity. Your customer mix, your seasonal swings, your known operational quirks, your actual rate of rare events. Generic synthetic data is rejected on sight by anyone who knows the business.

04 Proving It

Synthetic data is not trustworthy because it was generated carefully. It is trustworthy because it passed tests. There are three, and all three should appear in the deliverable.

Does it look right? Compare the distributions and the relationships between variables against what is known. If your real customer base is sixty percent commercial, so is the synthetic one.

Does it work? Build something on the synthetic data and test it against reality. If a model trained on generated records performs about as well as one trained on real records, the synthetic set is carrying real information.

Is it safe? Check that no generated record sits suspiciously close to a real one. A "synthetic" file that has quietly memorized actual customers is a privacy breach wearing a costume.

One governance point that gets skipped: get the data owner to sign off that the synthetic set is releasable. Absent that signature, it inherits every restriction attached to the source, and you have gained nothing.

05 The Trap

Here is the failure that costs the most and is noticed the least.

A causal model knows the direction of things. It knows that price affects demand and not the reverse. It knows which factors must be held constant before a comparison means anything. That knowledge is the expensive part, it came out of the expert workshops, and it cannot be recovered from the numbers alone.

The moment you export the model as a spreadsheet, that knowledge is gone. The file contains columns of numbers. Nothing in it says which arrow pointed where.

Whoever receives that file will fit a standard model to it. That model will find correlations, including the misleading ones your causal structure was specifically built to rule out. You will have taken a tool that answers intervention questions and converted it into one that cannot.

There is a second trap in the same family. A million generated rows feel like a million observations. They are not. The real information content is whatever went into the model, the workshops, the documents, the expert judgment. Generating more rows adds precision, not knowledge. This bites hardest on rare events: if something happens once in ten thousand cases, ordinary sampling will barely produce it, and you will end up estimating your most expensive risk from a handful of examples.

06 The Rule

Use the model directly whenever you can. It answers questions exactly, and it keeps the causal structure intact. Generate data when there is a real reason to: someone needs rows in a tool that cannot host a model, a downstream team needs to build on it, or the question involves a quantity the model does not track as a variable.

When you do generate it, ship the diagram with the data. The causal map, the assumptions, and a note on where each number came from. The file without the diagram is half a deliverable, and it is the half that gets misused.