How we work
The problems we solve and how we measure the outcome.
By default, we don’t publish client names, client data or project numbers. It’s not for lack of things to show: the confidentiality we promise covers results too, not just identities. Below, we describe the kinds of problems we solve in general terms, without tying anything to a specific project.
Problem patterns
The kinds of problem we are asked to solve most.
Described in general terms, drawn from several projects, not tied to any one client.
Retail · industrial packaging · catalog products
A product line that changes faster than you can rebuild the dataset.
The problem: a catalog, product set or parts list that changes so often that the real-photo dataset is out of date before the model is even retrained. Shooting in the field, reviewing and labeling takes weeks to months per update, and it all starts over at the next change.
imagens/cases/pattern-retail.jpg — parametric shelf/catalog scene, illustrative — 1200×210
How we approach it
- We rebuild the physical scene in 3D, with parameters: shelves, packaging, camera position
- We model each product or part as a swappable object, with the label independent of the object
- We generate detection or recognition datasets across the combinations that matter: lighting, occlusion, positioning
- We run the same pipeline at the next catalog change instead of photographing everything again
Why simulation helps
Once the parametric scene exists, updating the catalog just means changing an input, not organizing a field campaign. The dataset takes as long as rendering takes, not as long as scheduling a photo session, labeling and validating.
Agriculture · industrial defects · safety
A condition too rare, or too dangerous, to have been photographed yet.
The problem: the case that matters most (a disease at a specific stage, a defect that shows up once in thousands of parts, a near-miss) hasn’t appeared in real footage in large enough numbers to train on, and may never appear at the pace the project needs.
imagens/cases/pattern-rare-condition.jpg — parametric rare-condition scene, illustrative — 1200×210
How we approach it
- We build the object or scene with parameters, so the rare condition becomes a variable we can control
- We vary severity, scale, frequency and context independently
- We generate the condition on purpose, in whatever quantity the training plan calls for
- We compare against the real examples that exist, to check the synthetic data is a fair stand-in
Why simulation helps
Faster labeling can’t create a photo of a condition nobody recorded. Here, simulation isn’t a shortcut around collection: it’s the only source of the example.
Wondering if something similar applies to you? Worth a direct conversation: we’ll tell you how we’d approach your problem, within what other clients’ confidentiality allows.
Real vs. synthetic
The same scene, with the label coming from geometry.
Drag to compare. On the left, what a camera captures: noise, uneven light and no label. On the right, the simulation of the same scene, with every label coming from the 3D model itself.
Schematic illustration, not a client project.
How we measure
The validation set is the one thing we don’t simulate.
Numbers only mean something if you know what they were measured against. Ours are simple to explain.
01
Validation stays real
When labeled real data exists, that’s what we measure results on. Measuring performance on synthetic images would tell you nothing about production, so we don’t do it.
02
The same set for every strategy
When we compare training strategies (real only, synthetic only or mixed), all of them are scored on the same real validation set. Without that, the comparison is worthless.
03
We’d rather undersell than oversell
If your real data already covers most of the way, we’ll say so, even when a bigger synthetic project would be the easier sale. The right amount of synthetic data is sometimes none.
04
The method doesn’t depend on which model you use
Measuring on the same set and testing under controlled conditions works the same way, whether the model is one we helped train from scratch or a foundation model you fine-tuned. How we measure doesn’t depend on how the model was built.
Working on something similar?
Tell us your field and where your model gets it wrong today. We’ll say whether simulation is worth testing on it.