Embeddings that know which revision they are
Semantic search over product data has a failure mode nobody warns you about: it keeps answering confidently about a design that no longer exists, and nothing in the answer tells you.
What it is, and what it is not
One of three search engines on one screen: structured attribute query for when you know the field, full text for when you remember a phrase, and semantic similarity for when you can describe the thing but not name it.
It is not a replacement for the other two. thread = M3 is an exact question with an exact answer, and asking a vector index is slower and worse. Semantic search earns its place on the questions the other engines cannot express.
It is also not a chat interface. It returns objects you can open, filter and act on — the same result set the other engines return, ranked differently. An answer in prose is what the assistant does, and it cites these results rather than replacing them.
The decision that could not be made later
Every embedding carries the revision of the object it was made from. When that revision supersedes, the embedding is invalidated rather than left to age.
This sounds like housekeeping and it is the single most consequential decision in the feature. An embedding with no revision on it cannot be distinguished from a current one. So the first time a part revises, similarity search begins returning a description of a design that no longer exists — fluently, ranked highly, with nothing in the result to signal it.
It could not have been added afterwards. Embeddings already written without a revision cannot be told apart retrospectively; the only remedy is to rebuild the entire index, and an organisation that has been running for two years by then has no way to know what was wrong in the interim.
The visible consequence is that a result can be marked historical rather than silently presented as current. A superseded description is sometimes exactly what you want — you are looking for the part that *used* to be specified — and knowing which you have is the whole point.
The failure it prevents
An engineer describes what they need: a captive fastener for a thin panel, stainless, low profile. Semantic search returns a part whose description matches closely.
The description is from revision B. At revision D the part changed material and the description was updated, but the embedding was written against B and nothing invalidated it. The engineer specifies a part that no longer has the property they selected it for.
Nobody catches it because the search worked — a plausible part with a matching description was returned. The error surfaces at first article inspection, and the diagnosis is that somebody chose the wrong part, which is both true and the wrong lesson.
How it meets the rest of the product
Filtering happens at query time, so a permission change takes effect immediately rather than waiting for a re-index. Attribute-level access control is the deciding reason: a rule whose unit is the field cannot be expressed as membership of an index partition whose unit is the document.
Results, totals and facet counts derive from one shared clause, so a semantic result set cannot reveal through a count what it correctly excludes from the rows.
Embeddings are computed and stored within the tenant, subject to the same predicate as every other query. They are not shared, pooled or used to improve anything outside the tenant that produced them.
The Parts Agent uses semantic similarity as one of three reuse signals, and requires agreement with attribute equality or a shared AML manufacturer part before surfacing a candidate. Similarity alone produces plausible nonsense, which is precisely why it is never used alone.
How it meets your ERP
Semantic search covers what Manufacturing PLM holds, including cached ERP context. Where a description or specification arrived from your ERP, it is embedded like any other content and carries the same as-of provenance the field does.
It does not federate live into your ERP. Searching happens against what has been synced, which keeps latency predictable and means a search never depends on a third-party system being available — a property that matters more the moment somebody builds a workflow on it.
Where an ERP-sourced description changes, the embedding is refreshed on the next sync of that field rather than drifting, for the same reason revisions invalidate: a stale embedding of somebody else's data is harder to notice than a stale copy of your own.
Where the boundary is
It does not read CAD geometry. Finding a part by shape is a question for the CAD system, and Manufacturing PLM works over text, attributes and document content rather than implying an ability it does not have.
Semantic ranking is also not explainable in the way an attribute filter is. A structured query returns rows because they match a stated condition; a similarity result is returned because a vector was close, and no honest interface can turn that into a reason. Where the distinction matters — a duplicate proposal, an agent citation — the object graph provides the reason and similarity only provides the candidates.
Facts
| Three engines | Structured · full text · semantic, on one screen |
| Every embedding | Carries the object revision it was made from |
| On supersede | Invalidated, not left to age |
| Could not be retrofitted | Old embeddings cannot be told apart afterwards |
| Historical results | Marked as such rather than presented as current |
| Filtering | Query time — a permission change applies immediately |
| Storage | Within the tenant; never pooled or shared |
| Not offered | Geometry search · explainable similarity ranking |
Frequently asked
Why do embeddings need a revision?
Because an embedding without one cannot be distinguished from a current one. The first time a part revises, similarity search starts returning a description of a design that no longer exists — fluently, ranked highly, with nothing in the result to signal that it is stale.
Could that have been added later?
No. Embeddings already written without a revision cannot be told apart retrospectively, so the only remedy is rebuilding the whole index — and an organisation running for two years by then has no way to know what was wrong during the interim period.
Does it replace attribute search?
No. Thread equals M3 is an exact question with an exact answer, and asking a vector index is both slower and worse. Semantic search earns its place on the questions the other two engines cannot express at all, which is a narrower and real set.
Can I find superseded designs deliberately?
Yes, and results are marked historical rather than silently presented as current. Sometimes a superseded description is exactly what you want — you are looking for what used to be specified — and knowing which of the two you have is the entire point.
Where are embeddings stored?
Within the tenant, subject to the same data-layer predicate as every other query. They are never shared, pooled across tenants, or used to improve anything outside the tenant that produced them, and a permission change applies immediately without any re-indexing.
Is similarity ranking explainable?
Not honestly. A structured query returns rows because they match a stated condition; a similarity result is returned because a vector was close, and no interface can turn that into a reason. Where a reason matters, the object graph provides it and similarity only supplies candidates.
Can it search our CAD geometry?
No. Finding a part by shape is a question for the CAD system, and Manufacturing PLM works over text, attributes and document content instead. Implying otherwise would be claiming an ability it does not have, and the gap would surface on somebody's first serious attempt.