UID Persistence Through Alias Mutation: Stable Identity Across Structural Change

Mechanism

The UID is assigned at object creation by the governing anchor of the scope into which the object is admitted. The assignment is a deterministic function of the lineage frontier: the UID is drawn from a per-lineage allocation register that the scope's anchors hold in consensus, and the allocation event is itself a lineage entry. Once assigned, the UID is bound to the object's lineage chain rather than to the alias path, the scope identifier, or the anchor that issued it. The alias is a separately maintained mapping that resolves a human- or machine-readable path to the UID; the UID is the canonical referent and the alias is a presentation layer over it.

When the index restructures, the UID travels with the object's lineage. A scope split that relocates the object to a child scope copies the lineage chain, including the UID, into the child scope's records and emits a structural-mutation entry that references the UID on both sides of the split. A scope merge that combines two scopes preserves the UIDs of all objects on both sides; collisions cannot occur because the allocation register that produced each UID guarantees uniqueness across the lineage namespace, not merely within a single scope. An alias rename emits a mutation entry that records the old alias, the new alias, and the unchanged UID, so that any consumer holding a cached alias can rebind to the current alias by querying the UID.

The non-reuse invariant is enforced at the allocation register itself. Each register maintains a high-water mark of issued UIDs and an explicit retirement set for UIDs whose objects have been deleted, retired, or absorbed by merge. The register's admission logic refuses to issue a UID drawn from either set; new allocations always advance the high-water mark or, in implementations that draw from a sparse identifier space, draw from the unused complement of the issued set. Retirement is itself a lineage event, so the act of removing a UID from active use is observable to auditors and to downstream caches that wish to invalidate references to retired objects.

Rotation is the controlled replacement of one UID with another for the same logical object. It is required when an identifier space must migrate — for example, when expanding from a 64-bit to a 128-bit register, or when transitioning from a randomly drawn identifier to a cryptographically signed identifier — and it must be performed without breaking external references. The rotation operation emits a lineage entry that links the old UID to the new UID, marks the old UID as rotated rather than retired, and instructs the resolution layer to accept either identifier and translate to the current one. Rotation is explicit, governed, and recorded; it is never inferred from context, and it never occurs as a side effect of structural mutation.

Resolution can proceed in two modes. Alias-based resolution traverses the namespace path stepwise through anchors and returns the UID at the leaf, suitable for human-facing reads. UID-based resolution skips the namespace traversal entirely and looks the object up directly through a UID-to-scope map maintained as a secondary index across the anchor mesh. Both modes reach the same object, and both are durable across structural change because the UID is stable.

The UID-to-scope secondary index is itself a lineage-bound structure. When an object's scope changes — through split, merge, or migration — the index emits a relocation event that records the prior scope, the new scope, the UID, and the structural mutation that caused the relocation. Stale cache entries can be reconciled by walking the relocation events forward from the cached scope until reaching the current location, an operation that takes time proportional to the number of relocations rather than to the size of the index. In practice, the cost is small because objects relocate rarely and because consumers can opportunistically refresh their caches by piggybacking on resolution responses, which carry the current relocation watermark alongside the resolved data.

The relationship between UID, alias, and lineage can be summarized as three orthogonal axes that meet at the object. The UID is the durable identity axis: it answers the question of what an object is and remains constant across the object's lifetime. The alias is the discovery axis: it answers the question of how to find the object today and may change as the namespace is reorganized. The lineage is the history axis: it answers the question of how the object came to be in its current form, including every mutation, relocation, and rotation it has experienced. The three axes are independently queryable and independently maintainable. A consumer that holds only a UID can recover the current alias by reverse-lookup, the lineage by chain traversal, and the object's data by resolution; a consumer that holds only an alias can recover the UID through forward resolution and proceed from there. The orthogonality is what makes the identity surface usable across long time horizons and across systems that join and leave the namespace at different points in its history.

Operating Parameters

The UID width is a per-namespace parameter that determines the size of the identifier space. A wider UID supports a larger object population and reduces the probability of collision under randomized allocation; a narrower UID reduces the storage cost of references at the expense of population ceiling. The allocation strategy is a per-namespace parameter as well: deterministic allocation from a sequential high-water mark is suitable for small namespaces with strong consistency, while randomized allocation from a sparse space is suitable for large, partitioned namespaces where global sequencing is impractical.

The retirement-set retention horizon governs how long a retired UID remains in the explicit retirement set before being archived to long-term storage. A longer horizon increases storage but reduces the operational risk of accidental reuse during register reconstruction; a shorter horizon reduces storage at the cost of requiring more careful register-rebuild procedures. The rotation policy specifies under what conditions rotation is permitted and what evidence — cryptographic, governance, or operational — must accompany a rotation request. A strict policy admits rotation only under explicit operator authorization; a permissive policy admits rotation whenever a configured key-aging or namespace-migration trigger fires.

The resolution-mode mix is a workload parameter rather than a configuration parameter, but operators can bias it by tuning cache placement. Deployments that favor UID-based resolution maintain the UID-to-scope secondary index close to consumers; deployments that favor alias-based resolution keep the alias trees warm and accept the longer traversal path for the benefit of human-readable references in the critical path.

Alternative Embodiments

The mechanism admits several alternative embodiments. In the sequential-allocation embodiment, the allocation register is a monotonically increasing counter held in consensus across the scope's anchors; this embodiment is simple and produces small, dense UIDs but requires global ordering at the scope. In the randomized-allocation embodiment, UIDs are drawn from a large random space and validated against the issued and retired sets; this embodiment scales to many concurrent allocators without coordination but produces wider identifiers.

In the content-addressed embodiment, the UID is derived from a cryptographic hash of the object's lineage-genesis record; this embodiment produces self-verifying identifiers that downstream consumers can validate without trusting the issuing anchor, at the cost of forbidding any identifier change short of full rotation. In the credentialed-allocation embodiment, the UID is a signed token produced by an authority anchor; this embodiment supports federation across trust domains, where each domain's authority issues UIDs in its own subspace and cross-domain references carry the issuing-domain credential.

In the eager-rotation embodiment, rotation is scheduled proactively on a fixed cadence to limit the lifetime of any single identifier; this embodiment is suitable for deployments where identifier compromise must be bounded in time. In the lazy-rotation embodiment, rotation occurs only on demand, when an event such as suspected key compromise or a namespace migration requires it; this embodiment minimizes operational overhead and is the default for deployments where identifier compromise is not a primary concern.

Composition With Other Subsystems

UID persistence composes with the topology subsystem by absorbing the structural changes that the topology subsystem generates. Splits and merges, routing rebalances, and anchor-group resizings are all transparent to UID-bearing references because the UID is invariant under them. Composition with the lineage subsystem is direct: every UID allocation, retirement, and rotation is a lineage event, and the lineage chain provides the authoritative answer to questions about an object's identity history.

Composition with the alias subsystem treats the alias as a derived view over the UID rather than a parallel identity. Alias renames update the alias-to-UID map; UID-to-alias reverse lookup is maintained as an auxiliary index for use by consumers that received references through alias paths and need to recover the canonical UID. Composition with the confidence-governance layer allows downstream consumers to weight references by the freshness and stability of the UID's lineage; a UID whose object has rotated recently or whose scope has just been merged carries a slightly lower structural confidence until the next verification cycle confirms continuity.

Prior-Art Distinction

Conventional database systems use surrogate keys that are stable within a single table but are tied to the schema and storage layout of that table; reorganizing the schema or migrating across stores typically forces key reassignment, and the systems do not record reassignments as auditable identity events. Filesystem inodes are stable within a single filesystem but are reused after deletion and are not portable across mounts or replicas. Distributed-object identifiers in modern object stores are typically immutable but are also not rotatable; the only way to retire a compromised identifier is to delete the object and copy its content to a new identifier, which loses lineage continuity.

The mechanism described here differs by binding identity to lineage rather than to schema, storage, or filesystem; by forbidding reuse explicitly through a retirement set rather than implicitly through allocator state; and by treating rotation as a first-class, governed, lineage-recorded operation rather than as a destructive copy. The combination of lineage binding, explicit non-reuse, and explicit rotation is the structural distinction that makes the UID safe to embed in long-lived external references.

Disclosure Scope

The disclosure covers UID allocation under lineage binding, the non-reuse invariant enforced through an explicit retirement set, the rotation operation as a governed lineage event, and the dual resolution modes that allow alias-based and UID-based access to converge on the same object. It covers the parameter surface that governs UID width, allocation strategy, retirement-set retention, and rotation policy at the namespace level, and it covers the alternative embodiments in which the allocation register is sequential, randomized, content-addressed, or credentialed.

The disclosure does not depend on a specific identifier width, a specific cryptographic primitive, or a specific transport for the secondary index. Any width sufficient for the population, any primitive that produces collision-resistant identifiers when randomized allocation is used, and any transport that delivers the UID-to-scope map with bounded staleness may be substituted without departing from the disclosed mechanism. The structural contribution is the persistence of identity across mutation, the prohibition on reuse, and the explicit, governed treatment of rotation — not the choice of components within the allocation and resolution machinery.