Are These Two Pumps Actually the Same Pump?

Two plants send Botie a record named P7. Both display names say “Main pump.” If we merge on either field, the graph will connect inspections from two different physical machines.

Identity is the rule that tells us when records refer to the same thing. Before importing relationships, we need an identifier whose scope is clear and whose meaning survives a renamed label.

Two plants use the same local codes, while one plant sends a renamed record.

A display name can change, be misspelled or be shared. A source system’s local ID may be stable only inside that system. Use a documented application key, and retain the source ID used to resolve imports.

Database internal identifiers are implementation references, not a substitute for a durable cross-system business key. Avoid persisting assumptions about their reuse across deletion or export/import.

The question is which physical or logical thing this record refers to.

Treat system and external_id as a pair. Concatenating raw text with an unescaped delimiter can collide when either value contains that delimiter. A structured pair or a carefully encoded identifier preserves the boundary.

Our exercise serialises the pair as compact JSON text. That is a teaching key, not an attempt to choose the permanent identifier scheme for every production system.

east/P7 and west/P7 remain distinct even when their display names match.

import json
for system in ['east','west']:
    print(json.dumps([system,'P7'], separators=(',', ':')))

["east","P7"]
["west","P7"]

MERGE matches the pattern supplied. Including a mutable name in the identity pattern can create a new node after a rename. Match the stable key, then update the appropriate properties.

A uniqueness constraint backs the intended key under concurrent writers. MERGE by itself is not a general promise of global uniqueness. Resolve conflicting source records explicitly before applying updates.

A repeated import and a changed entity identity are different events.

MERGE (a:Asset {system:$system, external_id:$external_id})
SET a.name=$name
RETURN a.system, a.external_id, a.name

Entity resolution may propose that two vendor codes refer to the same equipment. Keep the proposed mapping and its evidence separate from a confirmed identity merge. A mistaken merge can redirect every attached relationship.

Define who approves ambiguous mappings and how a merge can be audited or reversed. Confidence scores are useful evidence, but they do not define identity by themselves.

Identity errors propagate through traversals even when the query syntax is correct.

Two rows with the same qualified key need a replay or conflict policy. A renamed display field may be a valid update, while differing immutable serial numbers may require review. The challenge only reports repeated keys so a later stage can decide.

Do not let dictionary overwrite order silently make that decision. Keep both source records available until the conflict has been interpreted.

A collision report identifies work for a policy; it does not prove the duplicate is fraudulent or incorrect.