The knowledge problem, from both directions
Engineering produces an enormous quantity of data. CAD files, drawings, requirement documents, test reports, supplier specifications, revision histories. Almost all of it gets stored. Very little of it stays usable.
The knowledge is trapped inside the artifacts. Below is a production drawing for a generator shaft, traced at General Electric in Schenectady in April 1910 and inspected that November. It is a good drawing. It is specific to a ten-thousandth of an inch, and it has outlived everyone who worked on it.
Look at what it records and what it leaves out. Written along the shaft, in the draughtsman's hand, are the words Comm. Fit., Spider Fit. and Cast Iron. Each marks a seat where another part mounts. Each is a relationship, and none of them carries a number. Whatever tolerance made those seats work lived in shop practice that everyone at Schenectady knew and nobody wrote on the sheet.
Read the dimensions literally and the sheet will mislead you. It calls for a hole reamed to 1.2599 inches, which reads as a requirement held to a ten-thousandth. Multiply by 25.4 and it is 32 millimetres. Four more do the same: 5.7087 is 145, 11.811 is 300, 8.8583 is 225, 2.1654 is 55. The journals, meanwhile, are 3.500 and 4.500 inches, round in inches and nothing in particular in millimetres. Two unit systems on one sheet, with nothing marking which digits carry intent and which are an artifact of conversion. The fitter knew. The drawing does not. When he moved on, the dimensions stayed and the reasoning left.
A second problem has appeared more recently. Machine learning systems can now generate geometry, and much of what they produce looks right. Sent to a 3D printer, it will often print. Placed in an assembly next to the parts it has to work with, it comes apart. Holes do not line up. Clearances are missing. The output is a shape, not a component.
One problem is about reading data that already exists. The other is about producing data that does not exist yet. They share a cause. In neither case is there a representation of what the product actually is.
What a product actually is
A closed manifold surface, usually called watertight, is a surface with no gaps and no holes, where every edge joins exactly two faces. It is what lets a 3D printer decide what is inside the object and what is outside. It is a real guarantee, and it is the bar most generated geometry is measured against.
It is also close to the weakest interesting guarantee available. It describes one object on its own, and says nothing about whether that object belongs in the machine.
Consider what has to be true before a part will assemble. Its mating face has to be flat enough, which is a tolerance and not a shape. Its bolt pattern has to agree with the pattern on the part it meets, which is a property of the pair and not of either one. It has to leave room for the tool that installs the fastener, and hold its fit across temperature and the accumulated variation of every part that positions it. Change one dimension and you change the answer to several of those at once, in places nobody is looking.
None of that lives in a shape. It lives in the relationships between shapes, and between shapes and the requirements that produced them. Parts that fit other parts within stated tolerances. Interfaces that carry load. Requirements that trace forward to the decisions satisfying them and the tests verifying them. Changes that propagate along those connections whether or not anyone follows them.
Geometry is one projection of that network. It is the most visible projection, which is why it gets mistaken for the whole thing.
Here is a case from our own work that shows how thin the line is. A shaft seated in the bore of a housing, running clear of it by two hundredths of a millimetre. The two parts share no material at all, because the shaft occupies a void inside the other part. But their bounding boxes, the rectangular volumes that enclose each part, nest almost perfectly.
radial gap exaggerated for clarity; the numbers below are exact
Our kernel proved the shared volume was empty, and then had no way to say so, because an empty result and a failed computation returned the same thing. The interference check saw a failure, fell back to comparing bounding boxes, and reported a serious collision on a fit that was entirely correct. A perfectly good clearance fit was indistinguishable from a part driven straight through another.
The arithmetic, if you want to check it
Not slightly off: it claims 85 per cent of the shaft is buried in solid metal.
The fix was conceptual rather than numerical. An empty result had to become a first-class answer in its own right, carrying a proof of why it is empty, and distinguishable from a computation that gave up. A fit is not an absence of geometry. It is a relationship, and the representation has to be able to hold it.
Interpretation: making sense of what already exists
We call this half of the work Autonomous Evolution. The goal is to take existing engineering data, in whatever state it arrives, and turn it into a coherent product model that can be edited, queried and traced.
The instinct is to call this an import problem. It is not. Reading the bytes of a CAD file is understood and largely solved. What is missing when you finish 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. Reconstructing them is inference, not parsing.
The problem breaks into four pieces. They are listed here in rough order of how well we understand them, which tells you more than the order they run in.
- A traceability graph. Records relationships as first-class objects with type and direction, rather than as metadata bolted on afterwards. If a requirement is satisfied by a part, that is a stored fact, not something re-derived by search whenever somebody asks.
- A change-impact mechanism. Given a proposed change, determines what it reaches before anything is committed. The value is seeing the consequence in advance, particularly in places the person making the change is not looking.
- A reasoning component. 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. Reads external artifacts and recognises what they contain, at the level of engineering meaning rather than file structure. The question is not which shapes are in the file, but what the file is asserting about the product. This is the one we are building rather than extending, and the one we would bet on being harder than it looks.
Three of those four already run, because generating products required them before interpreting anybody else's did. You cannot generate a change and not know what it touches. So the interpretation work starts from a graph that already carries load, with one genuinely new component in front of it.
Generation: geometry that has to survive the rest of the machine
The other half is a geometry kernel we wrote ourselves. A kernel is the component that represents and computes shape. It decides what a solid is, what it means to cut one solid with another, and whether the result is valid. Most CAD software licenses one from a small number of vendors. We built our own, which needs justifying, and the justification is representation.
Four commitments, all of which come back to that.
- Exact, not approximate. The kernel holds geometry as real surfaces and curves with their mathematical definitions, not as a mesh of triangles approximating them. Where correctness depends on getting a sign right, we compute that sign exactly rather than accepting whatever floating-point arithmetic produces near a boundary. That matters most where parts touch, which is where assemblies live.
- Inspectable. The kernel can be asked to prove its own output. A result is not accepted because the routine returned without error, but because it has been checked against the invariants a solid must satisfy. That is the difference between geometry that looks finished and geometry you can put a number on.
- Assembly-first. Interference between parts is measured as an actual volume, in cubic millimetres, not estimated from bounding boxes. Degrees of freedom are computed, including the redundant constraints that make a design overconstrained without anyone noticing. Tolerance chains are evaluated worst-case and statistically, because those answers differ and engineers need both.
- Honest refusal. When the kernel cannot do something correctly, it says so and stops, rather than returning an approximation that passes a visual check and fails on a machine.
The last one is the least glamorous and the one we argue about most. It is tempting to always return something. The cost is that nothing downstream can be relied on. The fit above settled the argument for us: the old behaviour did return an answer, and the answer was wrong by the size of the part. Refusing is also what separates autonomous engineering from automation. A system that only follows instructions has no grounds on which to stop.
What the two halves actually share
It would be neat to say interpretation and generation are the same activity. They are not, and the loose version of that claim falls apart on contact with either problem.
They do not share their difficulty. When you generate, you know the relationships, because you chose them. The hard part is producing exact geometry that honours all of them at once. When you interpret, the geometry is already there and costs nothing. The hard part is recovering relationships nobody ever wrote down. Those are different problems needing different techniques.
What they share is the target. Both have to arrive at the same structure: a product model where relationships are stored facts with type and direction, sitting alongside the geometry rather than being guessed from it.
That is a practical claim, not a philosophical one. Build the interpretation side on a representation that only holds shape, and you can read a thirty-year-old assembly perfectly and still not answer whether opening a bore breaks a fit. Build generation on the same thin representation and you produce parts that pass every check until they meet each other. The same missing thing causes both failures, which is why the representation is where the work goes.
Where we actually are
This is a proof of concept, and not in the modest sense people use when they mean nearly finished.
What works today is the generation side. The kernel produces exact geometry, validates its own output, and reasons about assemblies rather than isolated shapes. Traceability and change impact run against products our own system generated, where every relationship was recorded as it was created. That is the easy case: nothing had to be inferred, because nothing had been lost.
What does not work yet is the harder direction. Taking a folder of files from a company with thirty years of history and reconstructing relationships nobody wrote down is an open problem, and we are at the start of it. We expect the interesting failures to come from archives that contradict themselves, because real archives usually do. A system that cannot say "these two documents disagree" will quietly invent a product that never existed, and be confident about it.
The interpretation half is a project we have put forward for European regional funding, scoped as a feasibility study rather than a product. The reason to mention it at all is narrow: 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.
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.