External identities

An operator never works alone. Around them, a manufacturer delivers a catalogue, a codification service assigns numbers, a design office hangs its analyses. Each one designates your objects with its own identifiers.

External identities are the correspondence table between yours and theirs.

What it changes, concretely

Without them, every import is a one-shot. A manufacturer’s first package creates a thousand references; the second package, six months later, recognises none of the ones it created itself, and produces a thousand duplicates.

The defect is invisible on the first package. That is exactly what makes it expensive: you discover it once there are already two catalogues.

Two screens

Administration › Identifier schemes (/admin/identifier-schemes) — the families of identifiers you accept: NATO codification, catalogue sequences, data module codes, manufacturer references. Seven are provided; add as many as your partners impose.

The “External identities” tab on an object — the values its partners give it. It currently sits on a part-number record; the same panel will plug in elsewhere unchanged.

Configuring a scheme

Normalisation happens on write, never on display

This is the rule that avoids the most expensive defect in the whole mechanism.

An NSN is written 5330-14-123-4567 or 5330141234567 depending on the source; a CSN- prefix is decoration. If cleaning only happens at display time, two different entries look identical on screen and diverge in the database. Nobody notices — until the first catalogue reconciliation, which then produces a stream of discrepancies on lines that are in fact identical.

Four rules are available: none, uppercase and trimmed, prefix removal, digits only.

Normalising is not validating

Two distinct acts, not to be confused:

• normalising always succeeds — it strips the decoration;
• validating can refuse — the pattern says whether the value is acceptable.

A twelve-digit NSN is refused, not completed. Partner data is never silently “repaired”: correcting it without saying so would amount to inventing.

Schemes with a dedicated column

Four schemes already have a home in the model: the NSN has its tab, the NCAGE its column on the partner, the CSN and ISN theirs on the breakdown. These are keys the application displays as its own.

They are marked “dedicated column”, and the application refuses to record a copy of them in external identities. Two places for the same value means two values that eventually differ — reconciliation reading one, the screen showing the other.

The registry still describes their normalisation rule: that is what applies before querying the original column.

Attaching an identity

Fields appear when they mean something:

• the context only shows for a hierarchical identifier. An item rank is only unique within its figure: two different figures legitimately carry the same rank, and without context the second entry would be wrongly refused;
• the partner only shows for a scheme that belongs to one. Asking who assigns an NSN would make no sense — that is a codification authority.

The primary identity is the one displayed when an object carries several from the same scheme. Only one at a time.

Supersede rather than delete

When a partner renumbers, supersede. The old identity leaves reconciliation but stays readable: an old package referring to it must remain legible, and its value becomes available for another object.

Deletion is reserved for mistyped entries. It erases a reconciliation trace: any old package referring to it becomes unreadable. The application asks for explicit confirmation, and the screen offers superseding first.

What this enables

This table is the first building block of the interoperability foundation. It reads and produces no format — but no format is viable without it.

The day a manufacturer’s package arrives, the question is no longer “how do I read this file” but “what does this line correspond to”: and that is exactly what external identities answer.