We built Twynvex because ML teams kept telling us the same thing.

Lars Bergstrom spent several years building ML pipelines for fraud detection and supply chain optimization. The work was the same everywhere: write the feature engineering, tune the model, watch it fail in production on the minority class. The fraud rate in the transaction data was 0.3%. After SMOTE, the training set had enough positive examples to train on — but they were interpolations between the same 40 real fraud rows, not genuine coverage. The model learned to generalize those 40 examples, not actual fraud patterns.

Priya Anand was building data platform infrastructure for the same organization. The pipeline side of the problem: even if you could generate better training data, you needed it in the format your training loop expected, with the same schema, the same column types, the same referential constraints. A script that dumped rows that broke foreign key relationships was useless.

Together they built the first version of what became Twynvex: a statistical modeling layer over a schema that generated constraint-satisfying synthetic rows with configurable class ratios. The fraud model improved. Then they took on a healthcare analytics contract. Same problem, different reason: patient records couldn't leave the hospital's on-premises environment, so model development was blocked waiting on a compliance process. They ran Twynvex schema-defined — no real records at all — and unblocked the project.

That was the pattern. Coverage problem or privacy problem. Both solvable from a schema. They started Twynvex in Pittsburgh in 2025 to make that internal tool available to every ML team that hits the same wall.

We build one thing: a generation engine for tabular and text training data. We do not make claims about model training broadly, data labeling workflows generally, or the future of synthetic data as a field. We solve a specific problem — distribution tail coverage and privacy-blocked dataset development — and we solve it well.