ID Mapping Register¶
Artifact — instantiates Lossless Bijective Mapping Design
A governed register pairing old and new identifiers during migration, merge, split, or namespace transition.
An ID mapping register is a governed, versioned ledger of old_id ↔ new_id pairings, maintained through a transition rather than frozen at one moment. Its defining property is that it is a living record with an owner, a change history, and a place to record the messy cases — not a static lookup. A plain crosswalk table answers "what does A map to?"; the register answers "what does A map to, as of when, who changed it, and what happened to the pairings that didn't survive the transition cleanly?" It exists because real migrations are not instantaneous: identifiers get minted, merged, split, and renamed while both systems run in parallel, and the register is the single authority that keeps the correspondence honest across that span — propagating each change to downstream consumers and quarantining the pairings that break bijection into a visible exception list instead of pretending they don't exist.
Example¶
A logistics operator is switching telematics vendors across a 3,000-vehicle fleet. Each truck currently carries a device ID minted by the old vendor; the new vendor assigns its own. For eighteen months both platforms run in parallel — fuel logs still arrive under old IDs while dispatch already speaks new IDs — so a frozen crosswalk would be wrong the day after it was cut. Instead the team keeps an ID mapping register: every old_device_id ↔ new_device_id pairing, each stamped with an effective date and the change ticket that created it.
When a truck's unit is replaced mid-program, the register records the retirement of the old pairing and the new one, and a synchronization job pushes the delta to the fuel-card system, the maintenance database, and the insurance feed so none of them silently keep resolving a dead ID. Two trucks whose old IDs were transposed during a depot swap can't be paired cleanly — those land in the register's exception list for a fleet administrator to adjudicate rather than corrupting the mapping. At program end, the register's change history is the audit artifact that proves to the auditor every vehicle's telemetry is traceable end to end.
How it works¶
- Pairings are temporal, not static. Each
old ↔ newrow carries an effective date and provenance, so the register answers as-of questions, not just current-state ones. - Changes propagate outward. A synchronization rule turns every pairing change into a delta pushed to downstream consumers, so no system keeps resolving a retired identifier.
- Broken cases are quarantined, not hidden. Transpositions, splits, and ambiguous pairings that violate one-to-one are written to an exception list rather than forced into the clean table.
- History is the audit record. The append-only change log is itself the evidence that the correspondence was governed, not improvised.
Tuning parameters¶
- Propagation latency — synchronous push on every change versus batched nightly sync. Synchronous keeps consumers exact but couples them tightly; batched is looser but leaves a window where systems disagree.
- Exception tolerance — how aggressively imperfect pairings are diverted to the exception list versus auto-resolved. Strict routing protects bijection but grows the review backlog.
- History depth — full append-only lineage versus current-state-plus-recent. Deep history satisfies audit and rollback; shallow history is cheaper but forfeits provenance.
- Authority scope — whether the register is the system of record or a mirror of one. As the authority it can enforce; as a mirror it can only report drift.
- Retirement policy — how long a superseded pairing stays resolvable before it is fully retired, trading rollback safety against namespace cleanliness.
When it helps, and when it misleads¶
Its strength is governing a bijection over time: it keeps a correspondence exact while both sides are still changing, gives every downstream consumer one authority to sync against, and leaves an audit trail that makes the whole transition defensible. It is the natural home for the honesty rule that says a pairing which stops being one-to-one must be relabeled, not quietly overwritten. Treated as a system of record[n1] it is the difference between a migration you can audit and one you merely hope worked.
Its honest failure mode is drift: a register is only as exact as its most delinquent consumer, so a downstream system that skips a sync silently reintroduces the very ambiguity the register exists to prevent. The classic misuse is letting the register become write-only — pairings are added but retirements and exceptions are never worked, so the exception list grows into a graveyard and the "governed" ledger governs nothing. The guarding discipline is to make synchronization a checked obligation (consumers must acknowledge deltas) and to keep the exception list a worked queue with an owner, not an inbox.
How it implements the components¶
change_synchronization_rule— each pairing change becomes a delta propagated to downstream consumers, keeping the correspondence exact as membership evolves.exception_register— pairings that violate one-to-one (transpositions, splits, ambiguities) are diverted to a visible list for adjudication instead of corrupting the clean map.proof_or_audit_record— the append-only change history is the evidence that the correspondence was governed and every pairing is traceable.
It does not implement mapping_rule, domain_set_specification, or codomain_set_specification — the static structure of the pairing is owned by its artifact-cluster twin One-to-One Crosswalk Table; the register governs how that structure changes over time, it does not define the sets or the rule.
Related¶
- Instantiates: Lossless Bijective Mapping Design — it is the archetype's change-governance artifact, keeping a bijection exact through transition.
- Consumes: One-to-One Crosswalk Table supplies the current pairing structure the register versions and synchronizes.
- Sibling mechanisms: One-to-One Crosswalk Table · Mapping Exception Queue · Bijection Test Suite · Inverse Index · Orphan Target Scan · Round-Trip Migration Test · Reversible Encoder–Decoder Pair · Unique-Constraint Pair
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: ID Mapping Register operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it a governed register pairing old and new identifiers during migration, merge, split, or namespace transition
Independent corroboration: The frozen evidence defines ID Mapping Register as 'A governed register pairing old and new identifiers during migration, merge, split, or namespace transition', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Authoritative cross-system identifier mappings are a data-integration and enterprise-architecture mechanism.
Related originating lineages:
- Library & Information Science — Authority control and crosswalks independently developed durable correspondence between identifiers and controlled records.
Review resolution: Both reviewers independently assign computer_science as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The final form materially composes methods or concepts from more than one formative domain. It has established independent use across several domains, but that does not make it domain-free. The encyclopedia entry makes that composition explicit.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A system of record is the authoritative source for a given data element, the one place other systems are obliged to reconcile against. A mapping register earns its governing power only when it is treated as the system of record for the correspondence rather than one mirror among several. ↩