Lineage and Evolution

Test Data Workbench is the third generation of a test-data tooling idea. Each generation kept the goal, realistic relational test data on demand, and changed the fundamental approach. The most interesting decision in the current generation is a reversal of the one that defined the first two.

Three generations

Generation	Approach	Defining trait
First (fixed schema)	A hand-built e-commerce schema (users, products, orders, reviews) with one generator per table.	Rich, domain-aware output, for exactly one schema.
Second (AI-assisted)	The same fixed schema, plus a language-model layer for contextual value synthesis.	More believable values, still bound to the built-in schema.
Third (schema-adaptive)	No built-in schema. Reflects whatever database it is given and generates the generators.	Works on schemas it has never seen.

The reversal

The first two generations answered “what data should we produce?” by shipping the answer inside the tool. The schema was part of the product. That made the output good and the reach narrow: the tool could only populate the one shape of database it already knew.

The third generation inverts the relationship between tool and schema. The schema is now an input, discovered at runtime through reflection, and the generators are an output, written to fit it. The tool stopped being an e-commerce data generator that happens to be configurable and became a generator of generators for any relational schema.

This is why the current codebase shares no modules with its predecessors. It is not a refactor of the earlier generations; it is a different kind of program that inherited only the goal. The earlier fixed-schema generators are the thing this generation replaced with a factory.

What was gained and what it cost

Gained: reach. The tool now works against databases nobody anticipated when it was written. That is the whole point of a schema-adaptive design.

Cost: certainty. A fixed-schema generator knows precisely what an orders table means because someone told it. A schema-adaptive one infers meaning from names and structure, and inference is fallible. Two design choices exist specifically to pay down that cost:

• The The Fallback Ladder guarantees that uncertain classification degrades output quality gracefully instead of failing.

• Design Principles makes generated code the product, so a misclassification is a one-line fix rather than a defect you route around.

In other words, the current generation accepts that it will sometimes be wrong about a schema, and is built so that being wrong is cheap.

Where the earlier work still lives

The build history is preserved rather than hidden. The specification prompt that seeded the schema-adaptive rewrite, and the architecture notes from its early form, are kept under docs/history/ in the repository. The system was built with AI acceleration and human-owned architecture, and the record of that is part of the artifact.