The Identity MRO Never Had

In Case one the operator specified the part in full. Now watch what Ark does as they give it less — removing characteristics one at a time and re-checking.

Remove the two finest details — the physical size and the compliance standards. Seven characteristics remain. Ark re-checks, and returns eight candidates, grouped by verdict:

EXACT DUPLICATES (1)

UNCERTAIN (7)

The exact duplicate still stands — MAT-0100, caught on the same governed facts. But seven more records have surfaced, each marked UNCERTAIN. Four of them carry no description at all. The other three share the same core facts. With fewer characteristics to compare against, Ark will not certify any of these seven as a different part — so it refuses to wave them through. Creation stays blocked.

Remove more — the enclosure rating, then the mounting type. The result does not change: one exact, seven uncertain, blocked, at every step.

Now remove the last distinguishing characteristic — the terminal type — leaving only four coarse facts: type, contact configuration, voltage, current. Ark re-checks a final time:

EXACT DUPLICATES (8)

Every one of the eight is now an exact duplicate. The seven Ark could not rule out have become indistinguishable from the part being created — because the operator removed the very characteristics that told them apart. Here is the whole descent:

That is the point most tools get backwards. Enter less, and Ark widens the net — it does not narrow it. The fewer facts you give it, the more of the catalog it must treat as the same part, because you have removed what would tell them apart. You cannot under-specify your way past the gate.

Now consider why the obvious approach cannot do this.

Every way of searching a description is the same trick underneath: keyword or fuzzy, it looks at the text and measures how much one reads like another. That is silhouette matching — recognizing a shape by its outline. And an outline is exactly what abbreviation, blank fields, and formatting blur.

Ark does not match the silhouette. It takes the part’s fingerprint — its governed facts — and asks a different question entirely. Not “does this description look like that one?” but “is this the same part?” A resemblance is a probability. A fingerprint is a fact.

That is why the obvious fix — searching harder — cannot work. The instinct is to query: find records where voltage is 690 and current is 10 and terminal is screw. But a filter has exactly one move: exclude anything that doesn’t match. And a duplicate you have not found yet is, by definition, a record that differs somewhere — an abbreviation, a blank field, a value formatted a little differently. So the query throws away the very records you are hunting and hands you a confident “none found.”

You cannot find a near-match by filtering out everything that isn’t an exact one. Silhouettes are all these tools can see.

Ark inverts it. First it establishes what the part is — resolving a manufacturer part number, or a handful of entered facts, into governed identity. Then it compares on that identity, across the entire class, in full. Understand the part first. Compare second. Two capabilities, one primitive:

Identity Resolution — from a manufacturer part number, or even partial input, Ark builds the part’s governed facts. The identity MRO catalogs never had, established at the point of entry.

Duplicate Prevention — Ark compares those facts against every part in the class and flags the match before the record is created. Not on how the part was spelled. On what it is.

And Ark does not just surface the match. It can stop the duplicate at the door. Configurable by policy: warn the operator, or hard-block the creation outright. When it blocks, only a supervisor can override — a governed exception, logged, not a free pass. You decide where the gate sits and how hard it holds. Prevention that actually prevents.

Which is only safe because the verdict is not a guess. A fuzzy match gives you 87% sure. A fingerprint gives you a reason. Every line is explainable: this value equals that value, and here is the row that proves it. If you are going to block someone from creating a part — or let a supervisor wave it through — the reason has to stand up to an audit. It does.

Here is the honest part, and it is the part that matters most.

The comparison itself isn’t magic. Anyone could write the logic that checks whether two sets of facts agree. That was never the hard problem.

The hard problem is making it work on YOUR data — without a six-month implementation. Every other approach that matches on facts has to model your attribute schema first, map it, and customize its code for your specific catalog. A services project. Every client. Every deployment. Every time.

Ark doesn’t. It drops onto your existing master data as it stands — SAP, Maximo, Hexagon, or any other EAM — and works. No schema modeling. No per-client customization. No implementation phase. The same engine, out of the box, on anyone’s catalog.

That is the layer the incumbents cannot build. Not because the idea is a secret — it isn’t. Because building it to work everywhere, with no customization, requires a foundation they don’t have and cannot retrofit onto a relational model.

Fifteen years of MRO engineering went into making this look easy.

Ark manufactures part identity at the point of entry — and governs on what a part is, not on what someone typed.