B-REpresentation · Mechanical engineering · ai TRAINING
Data, Data, and More Data
Peter Glova · Valta Engineering s.r.o. — April 2026
Anyone building an AI model for a technical domain tends to talk about models. Which architecture, how many parameters, which fine-tuning method. That is the more interesting question, but rarely the decisive one. The decisive question is almost always the corpus.
And in engineering domains, the corpus does not exist. You cannot download it, you cannot license it, and you cannot assemble it from customer projects. So you have to build it. What follows is what we have learned building one, and why the method generalises well beyond the domain we happened to start with.
Why local models are especially hungry
We work with open models that run locally. That is not an ideological choice but a practical one: customer design data does not leave the building, and a domain capability that lives behind someone else's API is not a capability, it is a rental agreement.
The price is that you have to teach the domain yourself. A model with fourteen billion parameters has learned during pre-training how language works. It has not learned how a press brake works, how a milling cutter reaches into a pocket, or why a part has to release from a mould. With large proprietary models you can hope for diffuse world knowledge to carry some of that. With a compact local model, every piece of domain expertise comes from the training corpus or it does not exist at all.
That shifts the entire burden onto the data. And volume is only half the requirement.
Volume alone gets you nowhere
A corpus of parts that are all essentially the same part teaches a model exactly one part. You can vary angles and dimensions as much as you like: as long as the topology stays the same, the model keeps seeing the same structure.
Structural diversity means genuinely different construction trees, not different numbers on the same tree. In sheet metal that means a different count of bends, a different arrangement of panels relative to one another, different numbers and positions of openings, rounded corners next to sharp ones, a simple one-bend bracket next to a deep multi-bend enclosure. In a machining domain it would mean different pocket hierarchies and feature nesting; in a moulding domain, different parting geometry. The specifics change with the process. The requirement does not: only when the structure varies does the model learn the relationship between a description and a construction, rather than memorising a template.
This diversity requirement is also why real-world data alone will not do. A design archive is always unbalanced. It contains what that company built for those customers, with the habits of that engineering team. It is also unlabelled: for training you need not just the geometry but the machine-readable description that goes with it, and nobody is going to write those retroactively for an archive's worth of parts.
That leaves synthetic generation.
The catch with synthetic data
You can generate a great deal synthetically. The question is whether it is true.
A faulty sample teaches the model something false, and it does so invisibly. There is no error message. There is only a model that later proposes geometry no machine can produce, and nobody knows which twenty training examples caused it. So the real engineering work in a data generator is not the generation. It is the proof that every single delivered sample is correct.
Encode the process, not the shape
The move that makes automated generation possible is to stop generating geometry and start generating manufacturing histories.
Every manufacturing process comes with a grammar. It has a small set of operations a shop can actually perform, and a large set of rules about when those operations are admissible: reachable tool radii, minimum wall thicknesses, draft angles, overhang limits, minimum distances between features. Engineers carry this grammar in their heads and call it experience. A generator has to carry it in code.
If you do that, a useful thing happens. A generator free to emit arbitrary boundary representations will emit geometry nobody can make, and a model trained on that corpus learns to propose unmakeable parts. A generator restricted to the operations of a real process cannot. Manufacturability stops being something you check afterwards and hope for, and becomes a property of how the sample was constructed.
In sheet metal this looks concrete. A part grows through operations that correspond to shop-floor actions: cut a blank, extend a sheet edge into a new panel, fold that panel on a press brake, drill a through-hole, round a corner. Because every bend consumes one extension and adds one panel, n bends necessarily produce n+1 panels. The same discipline in a milling domain would build parts by removing material with tools that exist, in an additive domain by respecting what can be built without collapsing. The rule set differs completely. The principle transfers unchanged.
What is sampled, and what is looked up
The most important design decision in such a generator is the split between values drawn at random and values derived.
Free are the things that are genuinely free: which edge to extend, how far, through what angle, where a hole sits. Anything fixed by physics or by supply is not sampled at all. It is looked up.
Sheet thickness shows this well. Sample it continuously and you get values like 1.0016 mm, which is not a sheet anyone can buy. So the generator samples a thickness and rounds it up to the nearest stocked gauge. Rounding up rather than to the nearest value is the conservative direction: a part manufactured thicker than drawn is heavier than intended, whereas a thinner one may fail in service.
The inner bend radius is handled more strictly still, and never sampled at all. The radius a press brake produces follows from the punch and die, which in turn follow from material and gauge. So the generator consults a tooling table and draws a radius from the band real tooling can actually strike. No delivered part can carry a bend the workshop could not form.
Edge selection is bound the same way. A face is a valid extension target only if its narrow dimension equals the sheet thickness, because those faces are the sheet's edges; extending anything else merely thickens the plate. Very short faces have to be excluded as well, since they are slivers left over from the allowance region of an earlier bend, and folding them yields degenerate geometry.
The most instructive case was hole placement. Put every hole at the centre of its face and the geometry is impeccable, but the training data is poor: the model learns that holes are always centred. Positions therefore have to be distributed across the admissible area of the face, evenly by area rather than clustered toward the middle, and a candidate position is rejected unless the new bore clears every existing one by a margin. A separate guard counts the bores after each drilling operation, because two overlapping holes merge into a single opening. The part still loses material and remains a closed solid, so neither a volume test nor a closure test notices anything. Only the count reveals it.
That last one is worth generalising: a check that looks right is not the same as a check that is right. Which is the whole reason for the next section.
Independent checks, defined in advance
Validity has to rest on checks fixed before any result is measured, and they have to be independent in the strict sense, each catching a class of defect the others cannot observe. For folded sheet metal, three of them carry the load.
Closure. The part must be a sealed solid, with no gaps or free edges. Worth verifying after every single operation rather than once at the end, so the operation responsible for a defect is identified rather than inferred.
No self-intersection. The part must not pass through itself. This has to be its own criterion, because closure cannot detect it: a flange folded through another flange is still a perfectly sealed solid.
A valid flat pattern. The third is the least obvious and the most important. The first two examine the folded part, but the metadata, the training label itself, is produced from the unfolded one. The two can disagree. A part can be entirely sound when folded and, when flattened, produce a blank in which two panels occupy the same material. Such a part cannot be cut and bent from a single sheet, and no amount of inspecting the folded geometry will reveal it.
The lesson behind that third check is not specific to bending. Whenever the training label is derived from a different representation than the one you validated, you have to validate that representation too. In machining it would be the toolpath, in moulding the parting line. Somewhere in every domain there is a second view of the part that can be broken while the first one still looks fine.
How you respond to a failure deserves as much thought as the checks themselves, and the response should not be uniform. A single feature that fails locally can be undone and retried elsewhere, or dropped, leaving an otherwise sound part in the corpus. A failure that arises from how all the operations landed collectively cannot be attributed to any one feature, and the honest response is to discard the part and start again. The trade-off is real: strict all-or-nothing rejection burns computation rebuilding sound features to get past one unsound one, while local repair means a part may end up with fewer features than were asked for. Whichever you choose, the record has to say what was actually built rather than what was requested. A corpus that quietly disagrees with its own labels is worse than a smaller one.
Whoever checks must not be whoever built
The measurement procedure matters as much as the criteria.
Generation should be reproducible: a version-controlled settings file and an explicit random seed, so any batch can be rebuilt and any claim about it re-examined. Checking should then be deliberately separated from generation. Draw a random sample from the finished batch, reload each part from disk, and evaluate the criteria again from the file rather than from the generator's memory. The generator's own record serves as an index, never as evidence. A generator that validates its own output and reports success is testing its bookkeeping, not its geometry.
Two properties are worth watching beyond pass rates. One is agreement between what a file is named and what it actually contains, checked across the whole corpus rather than a sample, because a mislabelled part is a wrong training pair even when its geometry is flawless. The other is stationarity: independent seeds should produce statistically indistinguishable batches. When they do, batches can be treated as interchangeable samples instead of individual artefacts, and that is what lets you keep growing a corpus without re-characterising it every time.
What stays hard
Two problems do not go away, and it is worth being clear about them.
Validating the geometry is not the same as validating the label. Geometric checks confirm that the solid is sound; they say nothing about whether the description attached to it is a faithful account of that solid. Those are separate pieces of software solving separate problems, and a pipeline that only has the first one is shipping training pairs whose right-hand side nobody has audited. Label validation belongs in the same category of rigour as geometry validation, not in a follow-up ticket.
The second is model selection. Comparing candidate models by having a strong reference model write descriptions and then judging the outputs by eye gives a useful early signal, and we have used it. It is not a benchmark. One reviewer judging by impression cannot be repeated, "closest to the original" is undefined enough that two reviewers could reasonably disagree, small samples make any difference plausibly chance, and if every description comes from one model then candidates are being scored on that model's phrasing. The way out is to run cheap automatic checks first and human judgement last, and to reuse exactly the criteria the dataset itself has to pass. Then a model's output counts as valid precisely when it would have been accepted into the training data. Same bar, both directions.
Takeaway
From the outside, work on domain-specific AI looks like work on models. From the inside it looks like stock gauges, tooling tables and flat-pattern checks. Volume alone is not enough, diversity alone is not enough, and correctness is not a property you can inspect into a dataset after the fact. You have to build it in, by teaching the generator the rules of the process before you ever ask it for a part.
Data, data and more data. But the right data.