The DTS Transform step is the stage where CUBIG’s AI-ready data transformation engine rebuilds restricted, scarce, or unusable data into a synthetic dataset a model can actually learn on, preserving the statistical structure of the original without ever exposing its raw records.
The gap between a promising pilot and a model that stalls in production is usually the data, not the algorithm, and regulation keeps the sanctioned routes narrow. HIPAA recognizes just two de-identification paths for health data: a formal Expert Determination, or Safe Harbor, which strips 18 enumerated identifiers and asks only that you hold no actual knowledge that what remains could identify someone. The DTS Transform step exists to close that gap: it takes the diagnosis of what blocks your data and produces a rebuilt dataset that keeps the patterns a model needs while dropping the exposure and access problems that kept the original locked away.
Where the Transform step sits in DTS
DTS, CUBIG’s AI-ready data transformation engine, runs three stages in order: Diagnose, Transform, Rebuild. Diagnose maps what makes your data unusable, whether that is regulatory restriction, a class that appears too rarely to train on, or fields you cannot move off-premises. Transform is the middle stage that acts on that map. Rebuild is the validation and delivery stage that confirms the output holds up.
Transform is where the actual synthesis happens. It reads the structure the Diagnose stage recorded, then generates new records that reproduce the joint distributions, correlations, and rare patterns of the source, without copying any individual row. Because the engine works from structure rather than from access to the raw values, the sensitive originals never have to leave their environment. This is what we call a non-access architecture, and it is the reason regulated teams can run synthesis on data that compliance would otherwise keep off the table.
What Structure-Preserving Synthesis actually does
Plain synthetic data generators sample from a learned distribution and stop there. That is fine for a demo and thin for training, because the relationships that carry signal, the way a fraud flag co-occurs with a transaction sequence or the way a lab value tracks a diagnosis, tend to wash out. Structure-Preserving Synthesis is DTS’s answer to that problem. The Transform step preserves the multivariate structure of the data: the correlations between columns, the conditional distributions, and the tail cases that a model has to see in order to generalize.
Two mechanisms do most of the work. The first is joint modeling, which learns columns together rather than one at a time, so a synthetic record is internally consistent instead of a bag of independently plausible values. The second is rare-pattern augmentation, which deliberately reproduces and, where useful, amplifies the low-frequency cases that matter most for classification but appear too seldom in the raw data to train on reliably.
Differential privacy is available as a technique inside the Transform step for teams that need a formal privacy guarantee on the output. It bounds how much any single source record can influence the synthetic result, which lets you tune the balance between privacy strength and how faithfully the rebuilt data tracks the original.
Transform versus plain synthetic data generation
The difference is easiest to see side by side. A generic generator optimizes for records that look real one at a time. The DTS Transform step optimizes for a dataset that behaves like the original when a model trains on it, which is a harder and more useful target.
How the Transform step runs, step by step
In practice a Transform run moves through a short, repeatable sequence. The engine reads the structural profile from Diagnose, fits a joint model to the source patterns, generates candidate synthetic records, and applies any privacy budget you set. It then checks the candidates against the recorded structure before handing them to the Rebuild stage for full validation.
Rare-pattern handling deserves a note here, and the lineage is long: SMOTE, the 2002 JAIR technique, established synthetic minority-class examples as the standard answer to class imbalance. If your fraud data carries positives at a fraction of a percent, a naive sample will hand your model almost none of them. The Transform step can hold those cases in view and rebuild them at a density the model can learn from, so the signal survives into training instead of being rounded away.
Is your dataset a candidate for the Transform step?
Run this quick check against the data blocking your project. If two or more of these are true, the Transform step is worth a trial.
- Regulation or contract keeps you from moving the raw records to where the model trains.
- The class you care about, such as a defect or a fraud case, is too rare to train on reliably.
- Column relationships carry the signal, so shuffled or masked data loses the point.
- You need a dataset you can share with a vendor or a partner without exposing customers.
- You want a formal privacy guarantee you can show an auditor, not just a promise.
Where it fits in the CUBIG operating layer
The Transform step is one stage of DTS, and DTS runs on the Syntitan platform, CUBIG’s AI-Ready Data Platform. The division of labor is clean: DTS rebuilds data that was restricted, scarce, or unusable into something a model can learn on, and the platform around it scores enterprise data for readiness and keeps the rebuilt output governable. Because the Transform step records how it produced each synthetic dataset, the output is not a one-off artifact you lose track of; it is a data state your team can point to when someone asks where a model’s training data came from. For high-risk systems in Europe that question carries legal force, since Article 10 of the EU AI Act expects training, validation, and testing data to sit under documented data-governance practices and to meet quality bars for relevance, representativeness, and completeness.
For teams comparing options, the honest framing is that Transform is a rebuild engine, not a masking tool. Masking removes values; Transform reconstructs the patterns those values carried so a model still has something to learn from. If you want the full picture of the engine, start with the pillar on what DTS is, then read how the Diagnose step feeds it and how DTS validation confirms the output is good enough to trust.
Try it on your data for free. Run a sample proof and see it on your own workflow.
