The same pump, in four systems, with four different names

#The ingestion problem

An industrial site does not have one system of record. It has a maintenance system with an asset register, a historian with tag names, a set of engineering drawings, and usually a spreadsheet that one person maintains and everybody trusts. The same centrifugal pump appears in all four under a different identifier, and at least one of those identifiers has a typo that has been there since 2011.

If identity is generated at insert time, ingesting a second source creates a second node. You then need a matching pass, a merge operation, a way to un-merge when the matching was wrong, and a policy for edges pointing at the node you merged away. I have written that system. It is a lot of code and it is never finished.

#Deriving identity instead

A node's identifier is a deterministic hash of tenant, kind and normalised external identifier. Identity is computed from what the thing is rather than allocated when it first appears [4].

1// Same tuple in, same id out, from any source, on any replay.
2id := kgkit.NodeID(tenant, "equipment", "P-101")
Copy

Three consequences follow. Ingestion is idempotent, so re-running an import changes nothing and a failed import can simply be re-run. Sources converge, because the historian and the maintenance system both normalise to the same key and contribute different attributes to one node. Import order stops mattering, because an edge can reference a node that does not exist yet, which means four sources can be imported in parallel with no coordination.

#Where it breaks

All of that depends on the normalisation function, and that is where the difficulty now lives. Whether P-101, P101, P-0101 and PUMP-101 denote the same pump is site specific.

The two errors are not symmetric. Too strict gives two nodes for one asset, which an operator sees and reports. Too permissive gives one node for two assets, which is silent: attributes from two pumps merge, nothing looks broken, and traversals return confidently wrong neighbourhoods.

A hash is only as good as the tuple you feed it. All I have done is move the hard problem somewhere I can see it and write tests against it.

The asymmetry argues for strictness by default. It also helps that normalisation is a pure function with no dependencies, so a site's rules become a table of inputs and expected outputs. An operator saying two identifiers are the same asset becomes a test case rather than a migration.

#The case I do not have a good answer for

A source system that reuses an identifier over time. A tag referring to one pump until a 2019 replacement and a different one afterwards. Content-addressed identity has no temporal component, so both map to one node.

Currently the ontology allows a supersedes edge and the resolver prefers the most recent node, which is a workaround wearing a schema. A principled version would put a validity interval in the hashed tuple, and the obstacle is that the interval is unknown at ingest time for exactly the sources that need it.

#Why a graph and not a hierarchy

ISA-95 gives a useful equipment hierarchy [3] and real plants are not trees. A header serves units in several areas, a utility crosses the site, a shared spare belongs to two systems. Forcing that into a hierarchy produces either duplicate nodes or a structure that lies about connectivity.

Keeping the hierarchy as one edge type inside a graph preserves both, which is the representational argument the knowledge graph literature makes generally [1] [2].