Every grown structure carries an implicit categorisation.
Nobody declared it, no system holds it — and yet it decides every day what counts as the same thing in your company and what does not. Semantic examination makes it visible and testable.
Every analysis is blind to its own foundation.
A report on variant proliferation counts what is registered as a variant. Where part of that is in truth the same thing recorded twice, it counts it too. The result is precisely computed and wrong all the same — and the report cannot notice. It is not missing a record; it is missing a criterion for when two entries mean the same thing.
That criterion is not an arithmetic operation. It is a statement about meaning, and no query can produce one out of itself. Which is why semantic examination is not downstream of analysis but prior to it: it establishes what every analysis silently relies upon.
A finding is a statement about your company — not a list of defects.
Every design decision, every exception, every rushed call of the past years has left a trace in your systems. Those traces are not random: they follow rules that hold in your company without ever having been written down. Semantic examination surfaces exactly those rules — the categorisation your company actually works by, as distinct from the one it believes it has.
That is the yield of semantic examination: information about your company, not a list of defects. Where a substantial share of your assemblies mean the same thing, that is not a data error — it is a statement about how design work happens in your house. Where production orders keep losing their link to the customer order at the same point, that is not a mishap but a property of your process. Statements like these about one's own company cannot be obtained by asking. They are in the data or nowhere.
Not whether the data is valid. Whether it means the same.
What is examined is the complete holdings of your systems of record — not by sampling, not on an extract. And what is examined is not whether fields are populated and formally valid: that is data quality, and your systems handle it themselves.
- Is the field populated?
- Does the value have the right format?
- Does the foreign key resolve?
- Do these two objects mean the same thing?
- Does this production order really belong to this customer order?
- Are these two bills of material different — or the same one twice?
Your system answers the left column itself, every night. It never answers the right one — that requires knowing what your business means by these objects. That is where we start.
Meaning is not similarity. It is type, identity, and relation.
Two designations can look almost alike and mean different things; two entirely different numbers can denote the same thing. Similarity therefore carries no statement. Meaning is captured in a model through three definitions:
What an object is — part, assembly, sales order line, production order — regardless of what it is called or which field it sits in. The type determines which statements about the object are meaningful at all.
Which attributes make an object this particular one. Where the identity-bearing attributes of two entries agree, they are the same — even under different numbers, different designations, different creation dates.
Which relationships must hold: consists of, is a variant of, supersedes, supplies. A relation the model requires and the data cannot produce is itself a finding.
Only these three definitions make the implicit categorisation testable: they state what to look for in the first place. Without them every hit stays an anomaly open to argument — with them it becomes a statement you have to refute or accept.
Type, identity, and relation are not in the data.
No ERP or PLM system holds these three definitions for your business. They have to come from the business itself: which attributes identify a part, when two assemblies count as the same, what relationship must hold between a customer order and a production order. Examine without them and you are examining similarity — and, in the worst case, doing damage, because a wrongly merged record becomes a real missing part on the floor.
Providing such a typed model of the company is the subject of Tactical Enterprise Management and its artefact Company Cubing. That is why semantic examination does not work as a tool alone: the tool computes, but only the model can decide.
Data is the key to sound semantic integrity. Establishing it inside the original system makes the finding complete and traceable — so that structuring and planning rest on meaning that holds.
Technical integrity is not semantic integrity.
Your systems of record are technically sound: keys resolve, relations are valid, the database reports no error. That is precisely why the real damage goes unnoticed. When the same physical part runs under three numbers, every one of them is technically correct — and the meaning is destroyed all the same.
Semantic Integrity describes whether that meaning is intact: whether an object in the system means what it means on the floor, whether equivalent matters are represented equivalently, and whether relationships hold across assemblies, sales order lines, and master data. A system can run faultlessly and have been semantically unusable for years.
The principles behind the tools.
The tools do not rest on heuristics but on established principles: graph analysis over structure trees, similarity measures across designations and attributes, distribution and variance analysis over quantities and times, time-series analysis over order data, and reference-model comparison against the typed enterprise architecture.
These principles decide nothing. They produce candidates — places where
something might be the same, or where a required relation is missing. Whether that becomes a
finding is decided by the model of type, identity, and relation alone. The separation matters:
computing is one thing, meaning another. Together with the unaltered raw layer,
that makes a finding a statement of condition rather than an opinion.
Three tools, one condition.
A statement of position. Not an audit.
Nothing is compared against a standard and nothing is graded — no traffic lights, no target values, no scores. The comparison runs against the phases of your own flow: where do the quantities stand right now, and how has that shifted since the last run.
That separation is what makes a finding negotiable inside the company rather than an occasion for defence. It names what is, and where it came from; it hands out no grades and assigns no blame.
Eleven symptoms. Do you recognise yours?
If you know your symptom, you do not need the route via the tools. Both routes lead to the same finding.
So that every finding keeps its provenance.
A semantic statement is worth only as much as its provability. Beneath the analysis therefore sits an architecture that preserves the origin of every value — the precondition of the offering, not the offering itself.
A 1:1 image of the source system. Untouchable, without a single added index — so it stays provable at any time that nothing was altered.
Where data is condensed, resolved, and pre-computed. The layer in which mirrored data becomes a statement that holds.
What the customer sees, separated per tenant. Every viewer reads here and nowhere else — which is why it is fast.
Because raw is an unaltered mirror without a single added index, any finding can
be tied back to the source row it came from. That is the opposite of the
customary approach — pour everything into a shared data lake and hope afterwards that
provenance is still legible. Dispute a finding, and you get the row, not an explanation.
Two properties that are rare.
The report header names what is not covered, and why. A report that conceals its gaps becomes a trap for its reader — who takes conclusions to be covered that are not.
Every run persists its metrics before any presentation is produced. Only then does comparison over time exist — retrofit it later and every earlier run is irrecoverably gone.
Semantic Integrity is established at Analysis. Where the loop is not yet running, that is also the way in: without a sound finding there is nothing to structure or plan against.