Why geometry is not engineering knowledge

A CAD file is extraordinarily good at preserving geometric intent. It can tell a kernel where a face lies, how an edge is trimmed and which transform places an instance in an assembly. Those facts are necessary, but an engineering decision usually asks a different question.

Is this cylinder an M3 clearance hole, a bearing seat or a decorative recess? Is the repeated object a purchased fastener, a printed part or a stock profile cut to length? Which members does the bolt clamp, and is its grip length appropriate? Geometry contains evidence for these answers, but not the answers themselves.

Engineering work needs typed facts

WorldIR compiles source geometry into layered Engineering IR. L0 retains normalized geometry. L1 adds recovered features. L2 represents interfaces and assembly relationships. Catalogue identity, provenance and confidence remain explicit rather than being flattened into a generated description.

That distinction matters for agents. A language model looking at a mesh or a list of file names is tempted to complete a plausible story. A tool reading typed entities can instead query exact dimensions, follow evidence and abstain when the compiler has not established a fact.

Unknown is an engineering result

WorldIR publishes abstention rather than hiding it. A component known only by an informal name is not silently converted into a purchasable identity. It enters a review queue or remains unresolved. That may look less impressive than a complete generated BOM, but it is more useful to the person who must approve a design or place an order.

The long-term knowledge asset is therefore not a warehouse of geometry. It is a graph of stable identity, typed relationships, source evidence and accepted human decisions. Geometry begins the compilation; engineering understanding is the output.