Why PLM search fails engineers — and what a semantic layer fixes

Ask an engineer to find something in your PLM system and watch what happens. They type a part number, get forty results, open six of them, and end up messaging a colleague who "worked on that program" because the search could not answer the question they actually had.

The question was never "find documents containing this string." It was something like: which released parts use this material above 120°C, and of those, which have failed warranty in the field? That is a normal engineering question. No keyword search will answer it, because keyword search does not know what a part is, what a material is, or what "above 120°C" means.

PLM stores documents; engineers think in objects

Product lifecycle and data management systems are, underneath, document stores with metadata. A CAD file, a spec, a test report, a BOM: each is an item with attributes and a full-text index. Search treats all of them as text.

But an engineer does not think about a part as a blob of text. They think about it as an object with a type, properties that carry units and tolerances, and relationships: this part implements that requirement, is made of this material, appears in these assemblies, was validated by that simulation, is built on this line, and has this field history. The meaning lives in the connections, not in any single document.

Keyword search flattens all of that. It can find the string "120" in a document. It cannot reason that a temperature attribute on a material, referenced by a part, referenced by a released assembly, exceeds a threshold. The structure an engineer reasons over is exactly the structure the search throws away.

The question that spans every silo

Take the warranty question again and look at where the data actually lives:

• The temperature requirement is in a requirements tool.
• The geometry is in CAD.
• The thermal margin came from a simulation result.
• The material assignment is in the BOM.
• "Released" status is in PLM.
• "Built on which line, when" is in MES.
• The field failures are in warranty and field-telemetry systems.

Seven systems, seven schemas, and no shared definition of "part" or "material" across them. A part number in CAD may be a different string in MES. The material called "AL-6061-T6" in one system is "6061 T6" in another. There is no join key and no shared vocabulary. This is why the answer today comes from a person who remembers, not from a query.

Why full-text search and vanilla RAG both fall short

The instinct in 2026 is to point a large language model at the documents: retrieval-augmented generation over the PLM corpus. It helps with "find me the document that discusses X." It does not answer the warranty question, for the same reason keyword search does not:

• No entity model. RAG retrieves passages. It has no concept of a part as a distinct object with identity across systems, so it cannot count parts, filter them, or join them to warranty records.
• No relationships. The digital thread, from requirement to CAD to simulation to BOM to build to field, is a graph. Chunk-and-embed discards the graph. You get semantically similar text, not connected facts.
• No units or tolerances. "Above 120°C" requires knowing that a field is a temperature, measured in Celsius, and comparing it numerically. Embeddings do not do unit-aware comparison. They match "120" and "temperature" as tokens.
• No traceability. When a model produces an answer from retrieved chunks, you get a paragraph. You cannot see which released part, which material record, or which warranty claim it came from, so an engineer cannot trust it enough to act.

Vanilla RAG makes the demo look good and the engineering answer stay wrong.

What a semantic layer actually adds

An engineering semantic layer, a data fabric, sits over the systems you already run and adds back the structure that search threw away:

• Typed entities. Part, Material, Requirement, Simulation, BOM line, Build, and Field event become first-class objects with stable identity, resolved across source systems so one part is one part no matter how each tool spells it.
• Relationships, the digital thread. The connections are modeled explicitly as a graph: implements, made-of, appears-in, validated-by, built-on, failed-in. The warranty question becomes a traversal, not a guess.
• Units-aware queries. Attributes carry units and tolerances, so "above 120°C" is a numeric comparison the system understands, not a string match.
• A decision trace on every answer. Each result shows the path it came from, these parts, this material property, these warranty claims, so an engineer can verify it before betting a design change on it.

Run this on-prem, over the tools you already have, and you get to ask the question you actually had instead of the question the search box will accept.

The practical difference

With a semantic layer, "which released parts use this material above 120°C and failed warranty in the field" is one query that returns a list of parts, each traceable back through requirement, material, build, and claim. Without it, that question is a week of someone's time and a lot of institutional memory that walks out the door when they change jobs.

This is the core of the engineering data fabric work we do at Curlscape, and it shows up differently in each industry: the entities and relationships that matter to an automotive supplier are not the ones that matter to a medical-device maker, but the failure of keyword search is the same everywhere.

Search treats your engineering data as a pile of documents. Your engineers treat it as a connected system. The gap between those two is where the answers get lost.