Every company that has built things for long enough is sitting on an archive. CAD files, drawings, requirement documents, test reports, supplier specifications, revision histories going back decades. Almost all of it is stored. Very little of it stays usable, because the knowledge is trapped inside the artifacts and the reasoning left with the people who wrote them.
Autonomous Evolution is our name for the harder of the two directions we work in. The companion piece, A product is not a collection of shapes, argues that generating geometry and reading old geometry fail for the same reason: neither has a representation of what the product actually is. This note is about the reading direction, and about what we have put forward as a research project to study it properly.
It is not an import problem
The instinct is to call this an import problem, and to reach for a better file parser. It is not, and it will not. Reading the bytes of a CAD file is understood and largely solved. What is missing when you finish reading is everything that was never written down formally.
The relationships were in the engineer's head, or in a review meeting, or implied by a dimension that only makes sense if you know what the part does. A seat labelled only "press fit" carries a tolerance that lived in shop practice. A hole that lines up with another part carries an intent that no single file records. Recovering all of that is inference, not parsing, and it is where the real work sits.
The question is not which shapes are in the file. It is what the file is asserting about the product.
The shape of the problem
The work breaks into four pieces. We list them in rough order of how well we understand them, which says more than the order they run in.
- A traceability graph. Relationships are stored as first-class objects with a type and a direction, not as metadata bolted on afterwards. If a requirement is satisfied by a part, that is a stored fact, not something re-derived by search every time somebody asks.
- A change-impact mechanism. Given a proposed change, it works out what the change reaches before anything is committed. The value is seeing the consequence in advance, especially in the places the person making the change is not looking.
- A reasoning component. It assembles the rest into one consistent product model and resolves the contradictions that appear whenever several sources describe the same thing. It proposes. A person confirms anything that changes state.
- A perception layer. It reads external artifacts and recognises what they contain at the level of engineering meaning, not file structure. This is the component we are building rather than extending, and the one we would bet on being harder than it looks.
Three of those four already run in our system, because generating products required them before interpreting anyone else's did. You cannot generate a change and not know what it touches. So the interpretation work does not start from nothing. It starts from a graph that already carries load, with one genuinely new component in front of it: perception.
What we expect to be hard
We expect the interesting failures to come from archives that contradict themselves, because real archives usually do. Two drawings of the same part disagree by a revision nobody propagated. A specification describes a variant that was never built. A dimension was corrected on the shop floor and never made it back to the sheet.
A system that cannot say "these two documents disagree" will quietly invent a product that never existed, and be confident about it. Refusing to answer, and pointing at the conflict instead, is not a limitation to engineer away here. It is the feature. The same honest refusal that stops our kernel returning a wrong volume is what stops interpretation returning a plausible fiction.
Why a feasibility study, and why in the open
We have scoped the interpretation half as a feasibility study rather than a finished product, because that is what it honestly is. What a feasibility study owes is findings, and findings can be published, including the ones that read "we tried this and it did not hold." Those are the posts we would most like to read from other people, and the ones we intend to write.
Scoping it this way keeps us disciplined. It forces a claim to be tested rather than shipped, and it means a negative result is a result, not a failure to be buried. We will report what the perception layer can and cannot recover from a real archive, and we will be specific about where it breaks.
If you work in this space
If you work on engineering data, on geometry kernels, or in the awkward space between them, we would like to hear from you. We are particularly interested in how other people handle archives that contradict themselves. We do not have a good answer yet, and we would rather compare notes than pretend we do.
Autonomous Evolution is co-funded by the European Union and supported by Samenwerkingsverband Noord-Nederland (SNN). Views and opinions expressed are those of the author only and do not necessarily reflect those of the European Union or SNN. Neither the European Union nor the granting authority can be held responsible for them.