Skip to content

Versioned Map Registry

Versioned register — instantiates Context-Keyed Representation Switching

A catalogue that tracks every context-map by version and lineage, governs which version is current, and serves as the source of truth that distributed copies synchronize against.

A Versioned Map Registry is the authoritative index over all the context-maps: each map recorded with its versions, its provenance (who produced it, when, from what), its lifecycle status (draft, current, retired), and the rules for retiring a superseded version or merging two that have diverged. Its distinguishing job is governance across versions and across copies — it answers "which version of context X's map is current, where did it come from, and what supersedes it?" and it is the single source of truth every replica reconciles against. It governs the maps' history and distribution; it says nothing about the content of any one map.

Example

An autonomous-vehicle company maintains HD maps of road segments — each segment is a context-map. Survey crews and fleet-collected updates constantly produce new versions of the same segment. A Versioned Map Registry records every segment map's version, its source survey, and its validation status; enforces that a superseded version is retired so vehicles stop using it once its replacement is blessed; merges two crews' overlapping surveys of one segment under an explicit rule; and acts as the source of truth every vehicle pulls from, so the whole fleet converges on the same current maps. The payoff is that no vehicle ever drives on a silently outdated or forked segment map, and when a bad map is discovered, its provenance traces it straight back to the survey that produced it.

How it works

  • Register every context-map with a version, provenance/lineage, and lifecycle status.
  • Govern currency: exactly one blessed "current" version per context, with supersession retiring the old.
  • Apply retire/merge rules when versions diverge or two surveys of the same context overlap.
  • Act as the authoritative source that distributed copies pull from and reconcile against.

Tuning parameters

  • Versioning scheme — content-hash, semantic version, or monotonic counter. This shapes how supersession and comparison work.
  • Currency policy — a single blessed current version, or per-consumer pinning. Single maximizes consistency; pinning enables staged rollout.
  • Retire / merge rule — how conflicts and overlaps resolve — last-writer, validated-wins, or manual merge — setting the balance between safety and agility.
  • Sync consistency — strong (all copies identical before use) versus eventual (fast, tolerates lag), trading a freshness guarantee against availability.

When it helps, and when it misleads

Its strength is that it makes the whole portfolio of maps auditable and governed over time and across copies: you can always name the current version, trace where a map came from, retire the obsolete, and hold a distributed fleet in sync. It is the institutional memory that prevents silent version skew and forked maps. Its failure modes are matters of discipline and consistency: a registry is only as truthful as the rule that everything must go through it, so if updates can bypass it, it becomes an authoritative-looking index that is wrong — worse than none; strong synchronization can stall consumers waiting for consensus; and an auto-resolving merge rule can quietly bless the wrong survey. The classic misuse is treating registry presence as proof of quality — a well-catalogued map is not thereby a correct one.[1] The discipline is to make the registry the only path to publish or activate a map, and to keep "catalogued and current" strictly separate from "validated as correct," which is a different mechanism's job.

How it implements the components

Versioned Map Registry fills the governance-and-distribution subset — managing maps across versions and copies rather than within one:

  • version_and_provenance_trace — it records each map's version and full lineage (source, author, derivation), making any map traceable to its origin.
  • map_retirement_and_merge_rule — it enforces the lifecycle: superseded versions are retired, and divergent or overlapping maps are merged under an explicit rule.
  • distributed_map_synchronization — as the single source of truth, it is what distributed copies pull from and reconcile against, keeping every replica on the agreed current version.

It does not create the snapshots it versions (that's Per-Context Model Checkpoint), verify that a registered map is uncorrupted (that's Map Difference and Integrity Check), or restore an earlier version into service (that's Rollback to Prior Map Snapshot).

Notes

The registry governs maps across versions and copies and deliberately does not judge a single map's correctness (Map Difference and Integrity Check) or hold the raw snapshots themselves (Per-Context Model Checkpoint). It is the governance and lineage layer sitting on top of preserved snapshots — the reason a distributed system can agree on which map is real without agreeing, yet, that it is good.

References

[1] Single source of truth — the design principle that one authoritative store holds the canonical value everything else reconciles against, preventing divergent copies. Applied here to which version of each context-map is current across a distributed fleet. ↩