Structure-preserving synthesis is an AI data transformation method that rebuilds restricted, scarce, or unusable enterprise data into a fully usable dataset while holding the statistical structure, column relationships, and rare patterns of the original intact, so a model can learn from the rebuilt data as if it had trained on the source.
Most enterprise AI projects do not stall on the model. They stall on the data feeding it. Synthesizing data to repair a weak training set is not a new idea: SMOTE, the canonical technique from JAIR 2002, generates synthetic minority-class examples to correct class imbalance, but imbalance is only one of the ways enterprise data fails. When the training set is locked behind privacy rules, too small to cover the cases that matter, or too messy to feed a model, the project quietly dies. Structure-preserving synthesis exists to reopen that path.
What structure-preserving synthesis actually preserves
The word “synthetic” carries a lot of baggage. People hear it and picture random rows that look plausible but teach a model nothing. That is not what this method does. Structure-preserving synthesis is defined by what it keeps, not by what it invents.
It preserves three layers of the source data. First, the marginal distributions: each column keeps its real shape, its range, its skew, its outliers. Second, the joint relationships: if income and default risk move together in the source, they move together in the rebuilt set. Third, and hardest, the rare patterns: the fraud case that shows up once in ten thousand rows, the defect that appears on one part in a batch, the cohort that only a handful of patients belong to. Generic synthetic generators tend to smooth these away because they are statistically inconvenient. A rebuild that erases the rare cases produces data a model can fit but not learn the hard problem from.
DTS, CUBIG’s AI-ready data transformation engine, runs this as a three-step loop: Diagnose, Transform, Rebuild. It first diagnoses where the source data blocks execution, then transforms the restricted or scarce parts, then rebuilds a dataset that carries the original’s structure forward. The engine uses a non-access architecture, so the rebuild happens without a person or an external system reading the raw records, and differential privacy can be applied as a technique inside the transform step when the source demands a formal privacy budget.
Why plain masking and generic synthetic data fall short
Two older approaches try to solve the same problem and leave a gap. Masking, or anonymization, strips or scrambles identifying fields. It protects individuals, but it damages exactly the relationships a model needs, and re-identification research keeps showing that masked data is less anonymous than teams assume: Rocher et al. estimated that 99.98% of Americans would be correctly re-identified in any dataset using 15 demographic attributes, and that even heavily sampled anonymized datasets are unlikely to satisfy GDPR anonymization standards. Generic synthetic data goes the other way: it fits a broad generator to the data and samples new rows, which is fine for volume but tends to flatten the tails where the valuable, rare signal lives.
Structure-preserving synthesis sits between those failures. It does not just hide values and it does not just manufacture volume. It diagnoses the structure worth keeping and rebuilds toward it. The table below lays out the difference.
Where the method earns its keep: rare-pattern augmentation
The clearest payoff shows up when the signal you care about is rare. Fraud, financial crime, equipment defects, and uncommon clinical presentations all share the same shape: the interesting cases are a tiny fraction of the data, and that fraction is often the part locked down hardest for privacy or compliance reasons.
A model trained on data where fraud is one row in ten thousand will happily predict “not fraud” every time and score well on accuracy while being useless. Rare-pattern augmentation rebuilds more examples of the rare class that stay faithful to how those cases actually behave, rather than duplicating rows or injecting noise. The model then has enough real structure to separate the hard cases. This is why teams reach for DTS on fraud and anti-money-laundering data, on clinical cohorts too small to train on, and on manufacturing lines where a defect is precious precisely because it almost never happens.
A fair caveat: rebuilt data is representative until you reproduce the result on your own source. The point of the method is to get a model that works on the real distribution, so validation against held-out real data is part of the process, not an afterthought.
How to tell if you need structure-preserving synthesis
Run this quick self-check against a stalled or blocked project. If two or more of these are true, generic tooling is probably the wrong fit.
- Your best training data sits behind a privacy or regulatory wall your model pipeline cannot cross.
- The cases you most need the model to catch are rare, and accuracy hides how badly it misses them.
- You tried masking and model quality dropped, because the relationships the model needed went with the masked fields.
- You tried an off-the-shelf synthetic generator and the rebuilt data lost the outliers and edge cases.
- You need a formal, defensible privacy statement for the data you train on, not just a promise.
- You cannot grant raw-data access to a transformation tool, so the rebuild has to happen without anyone reading the records.
Where AI data transformation fits in an AI-ready platform
Structure-preserving synthesis is one engine, not the whole system. For production AI the question is not only which model ran but which data state and execution conditions produced the result. DTS runs on the CUBIG Syntitan platform, so a dataset it rebuilds becomes a versioned input the rest of the platform can score, bind to a run, and reproduce later. That connection matters: a rebuilt dataset that no one can point back to is a liability, while a rebuilt dataset tied to a recorded data state is an asset an auditor can accept.
In practice a team diagnoses a blocked source with DTS, rebuilds it into trainable data, and then treats that rebuilt set as a first-class data state on the platform rather than a one-off export — AI data transformation as a recorded pipeline step, not a side script. The rebuild engine solves the “we cannot use this data” problem; the platform around it solves the “prove what you used” problem. If you want the broader picture of what makes a dataset trainable in the first place, start with our overview of what AI-ready data means, then see how DTS works end to end and how rare-pattern synthesis applies to fraud and AML.
A short worked example
Consider a bank with two years of transaction records that cannot move out of a regulated environment, where confirmed fraud is roughly 0.1% of rows. The team wants a model that flags fraud in real time. Masking the account identifiers breaks the network patterns that make fraud detectable. Exporting the raw data is not allowed. A generic synthetic tool produces a clean-looking dataset that misses the coordinated, rare fraud rings entirely.
With structure-preserving synthesis as the AI data transformation step, DTS diagnoses the transaction graph and the fraud tail, rebuilds a trainable dataset that keeps both the everyday spending structure and the rare coordinated patterns, and applies a differential-privacy budget so the output carries a defensible privacy statement. A budget alone is not the whole story: NIST SP 800-226 provides guidelines for evaluating differential privacy guarantees and documents the common implementation pitfalls it calls privacy hazards. The team trains on the rebuilt set, then validates on held-out real records inside the regulated environment. The number that matters is not how good the rebuilt data looks; it is whether the model reproduces its catch rate on the real distribution.
Try it on your data for free. Run a sample proof and see it on your own workflow.
