Identifier Assignment

Version

v1 · 2026-08-24 · History

Prime #

905

Origin domain

History & Historiography

Subdomain

provenance and record keeping → History & Historiography

Core Idea

Identifier assignment is the act of minting a durable handle for an entity and binding that handle to the entity in a public, queryable record, so that future reference to the entity can route through the handle without re-describing it each time. The handle is deliberately opaque enough to remain stable under changes in the entity's description, and the binding is held by an authority that can answer "what does this identifier denote?" for as long as the system runs. The pattern is constituted by five commitments: an entity with persistent existence the system wants to track; an authority that mints handles and guarantees uniqueness within its namespace; a handle drawn from a defined shape and unique within that namespace; a binding record mapping handle to entity, held by the authority; and a dereference operation by which any party holding the handle can recover some agreed slice of what the entity is. The handle and the binding record together do the work that ad-hoc description cannot: they survive renames, transfers, and property changes, precisely because the handle was never about the entity's properties.

The structural force is the decoupling of reference from description. Without a managed handle, parties refer to entities by description, and description fails the moment it ceases to be unique, accurate, or known to the receiving party. Assigning an identifier installs a stable point of reference that absorbs all subsequent change in the entity, so that every downstream pointer can be the bare handle and description is consulted only on dereference. The pattern is administrative by nature — it presupposes a designed reference system with an authority and a resolution protocol — and it does not arise outside such systems: a thing is not assigned an identifier merely by being named informally, but only when an authority records a binding and stands ready to resolve it.

How would you explain it like I'm…

The Coat-Check Ticket

At a big coat check, instead of describing your coat every time ('the blue puffy one with a torn pocket'), they give you a numbered ticket. The ticket always means YOUR coat, even if your coat gets muddy or you forget what it looks like. Someone behind the counter promises to give you back exactly the coat your number points to. Giving out that ticket and keeping the matching list is what identifier assignment is.

A Name-Tag That Sticks

Identifier assignment is when someone in charge makes up a permanent name-tag for a thing and writes down, in a record everyone can check, which thing that tag points to. The tag is kept simple and meaningless on purpose, so it keeps working even when the thing changes — gets renamed, repainted, or moves. After that, instead of describing the thing every time, you just use its tag, and anyone holding the tag can ask the record 'what does this point to?' and get an answer. It needs an authority that guarantees no two things get the same tag, plus a way to look up the tag whenever you need to. This is why describing things ('the tall kid with red shoes') breaks down but a student ID number doesn't.

Handle Instead of Description

Identifier assignment is minting a durable handle for an entity and binding that handle to it in a public, queryable record, so future reference can route through the handle without re-describing the entity each time. The handle is deliberately opaque — kept independent of the entity's properties — so it stays stable when those properties change, and the binding is kept by an authority that can answer 'what does this identifier denote?' for as long as the system runs. Five pieces constitute it: an entity worth tracking, an authority that mints handles and guarantees uniqueness in its namespace, a handle of defined shape unique in that namespace, a binding record mapping handle to entity, and a dereference operation that recovers what the entity is. The structural force is decoupling reference from description: plain description fails the instant it stops being unique, accurate, or known to the receiver, whereas an assigned identifier installs a fixed reference point that absorbs all later change. It's administrative by nature — a thing isn't assigned an identifier just by being casually named, only when an authority records a binding and stands ready to resolve it.

 

Identifier assignment is the act of minting a durable handle for an entity and binding that handle to the entity in a public, queryable record, so that future reference to the entity can route through the handle without re-describing it each time. The handle is deliberately opaque enough to remain stable under changes in the entity's description, and the binding is held by an authority that can answer 'what does this identifier denote?' for as long as the system runs. Five commitments constitute the pattern: an entity with persistent existence the system wants to track; an authority that mints handles and guarantees uniqueness within its namespace; a handle drawn from a defined shape and unique within that namespace; a binding record mapping handle to entity, held by the authority; and a dereference operation by which any party holding the handle can recover some agreed slice of what the entity is. The handle and binding record together do the work ad-hoc description cannot — they survive renames, transfers, and property changes precisely because the handle was never about the entity's properties. The structural force is the decoupling of reference from description: without a managed handle, parties refer by description, which fails the moment it ceases to be unique, accurate, or known to the receiver; assigning an identifier installs a stable reference point that absorbs all subsequent change, so every downstream pointer can be the bare handle and description is consulted only on dereference. The pattern is administrative by nature, presupposing a designed reference system with an authority and resolution protocol; it does not arise outside such systems — a thing is not assigned an identifier merely by being named informally, but only when an authority records a binding and stands ready to resolve it.

Structural Signature

the entity to be tracked — the minting authority that guarantees uniqueness within a namespace — the opaque handle drawn from a defined shape — the binding record mapping handle to entity — the dereference operation recovering the entity from the handle — the decoupling of reference from description

The pattern is present when each of the following holds:

• An entity. Something with persistent existence is to be tracked across changes in its description, location, or ownership.
• An authority. A party mints handles and guarantees their uniqueness within its namespace, and stands ready to answer "what does this handle denote?" for as long as the system runs.
• A handle. A token drawn from a defined shape, unique within the namespace, deliberately opaque enough to stay stable when the entity's properties change — it was never about those properties.
• A binding record. A mapping from handle to entity, held by the authority and recorded at issuance.
• A dereference operation. Any party holding the handle can query the authority and recover an agreed slice of what the entity is, or an authoritative "not found."
• The reference/description decoupling invariant. Reference is separated from description so that every downstream pointer can be the bare handle; the handle absorbs all subsequent change in the entity, and description is consulted only on dereference. This is the load-bearing move, and it is why the handle survives renames, transfers, and property changes.

Each commitment has a determinate failure: handle collisions break uniqueness and silently merge entities; orphaned handles break dereference and leave dangling references; authority failure breaks durability and turns every outstanding handle into an unresolvable token. The pattern is administrative by nature — it presupposes a designed reference system with an authority and resolution protocol — and does not arise from merely naming a thing informally.

What It Is Not

• Not idempotence. Idempotence is the property that repeating an operation yields the same result as performing it once; identifier assignment is the minting and binding of a durable handle. A well-designed assignment may be idempotent (re-issuing returns the same handle), but idempotence is a property an operation may have, not the act of installing managed reference.
• Not a bare relation. A relation is any structured tie between relata; identifier assignment installs a specific administrative apparatus — authority, namespace, binding record, dereference — over a handle-to-entity mapping. The bare relation lacks the authority and resolution protocol that make the handle durable.
• Not indirection. Indirection inserts a resolvable level between reference and target; identifier assignment is what creates the handle that indirection later resolves. Dereference uses indirection, but minting and binding the handle is a prior, distinct act.
• Not versioning. Versioning attaches successive states to an entity over time; identifier assignment binds one durable handle that absorbs those state changes. A version chain rides on a stable identifier; it is not the assignment itself.
• Not a hierarchical_address. A hierarchical address encodes position into the handle and is fragile under restructuring; identifier assignment in its canonical opaque form deliberately encodes nothing, so the handle survives any change. The address is one (fragile) way to fill the handle slot, not the pattern.
• Not naming_convention. A naming convention is a shared rule for forming labels; identifier assignment additionally requires an authority that records a binding and resolves it. A convention can produce names that no one binds or resolves — that is informal naming, not assignment.
• Common misclassification. Believing a thing has a durable identifier because it has a name. The catch is the authority-and-binding test: if no party recorded a binding and stands ready to answer "what does this denote?", the token resolves only by shared memory — informal naming with the very fragility managed reference exists to eliminate.

Broad Use

The five commitments recur across record-keeping substrates with substrate-specific machinery filling the slots. Museum and cultural-heritage records bind accession numbers to physical objects across loans, conservation, and reattribution.^[1] Legal chains of title anchor claims through transfers and amendments using deed numbers, vehicle identification numbers, patent and trademark registrations, and docket numbers.^[2] Healthcare mints medical-record numbers, drug codes, clinical-trial registrations, and specimen accessions.^[3] Scholarly communication issues persistent identifiers for works, authors, and institutions. Software and data systems generate universally unique identifiers, database keys, commit hashes, network and hardware addresses, and container digests.^[4] Public administration assigns passport, license, taxpayer, and business-registration numbers.^[5] Incident and event histories number policing incidents, support tickets, change requests, and bug reports — anywhere a process must be referenced by parties who were not present at its creation. In each, the authority records the binding at issuance and resolves it on demand, and the handle's value lies precisely in its indifference to whatever the entity's description happens to be at the moment of reference.

Clarity

The act is sharp at two points: issuance, where the authority records the binding, and resolution, where any holder of the handle queries the authority and recovers the binding or an authoritative "not found." Because the five commitments are explicit, the failure modes are immediately recognizable. Handle collisions — two entities sharing one handle — break uniqueness and silently merge distinct things. Orphaned handles — a handle whose binding no longer exists — break dereferencing and leave references dangling. Authority failure — no party keeping the binding alive — breaks durability and turns every outstanding handle into an unresolvable token. Naming the pattern thus supplies a checklist: who is the authority, what is the uniqueness scope, how is the binding kept, how does a third party resolve a handle, and what happens when the entity is destroyed, merged, renamed, or transferred. A system that cannot answer these is not assigning identifiers; it is naming things informally and inheriting the fragility that managed reference exists to eliminate.

Manages Complexity

Identifier assignment lets a system bound the description load on every downstream reference. Each reference becomes the bare handle, and the full description is consulted only when a dereference is actually needed. This is what allows catalogs, ledgers, legal systems, and distributed databases to scale: the cost of carrying a reference is constant regardless of how rich the underlying entity is, and the cost of changing the entity's description is borne once at the authority rather than at every site that points to it. The pattern composes with an entity's lifecycle — assign, bind, reference, resolve, and eventually retire — and with adjacent mechanisms that attach successive states to the handle, reconcile multiple handles discovered to denote one entity, or record who minted which handle when. By concentrating identity-bookkeeping at the authority and exporting only opaque, stable handles, the pattern keeps the combinatorial explosion of cross-references in any large system tractable: nothing downstream needs to know anything about an entity except how to name it and how to resolve the name.

Abstract Reasoning

Identifier assignment is the creation end of a reference lifecycle, and reasoning about a system's reference machinery begins by asking what kind of handle it mints and how that handle behaves across the lifecycle. The first axis is the handle's internal structure: opaque (no information, maximally stable), descriptive (carries meaning, fragile when the meaning changes), or hierarchical (encodes position, fragile when the structure changes). The second axis is the authority's reach: global, per-system, or per-namespace uniqueness, with delegation allowing sub-authorities to mint within carved-out scopes. The third is the dereference protocol — what a third party must do to resolve, and what guarantees the authority offers about availability. A reasoner who fixes these three can predict the system's behavior under stress: opaque handles survive restructuring but force lookups for any structural fact; descriptive handles save lookups but break on rename; authority centralization simplifies resolution but creates a single point of failure. The pattern thus turns "is this a good identifier scheme?" into a set of structural questions whose answers determine, in advance, how the system will degrade.

Knowledge Transfer

Once a reader holds the five commitments, the same diagnostic transfers across substrates that share no operational machinery, because the questions interrogate the structure of managed reference rather than any domain's implementation. Who is the authority for these handles? What is the uniqueness scope — global, per-system, per-namespace? How is the binding kept, and by whom? How does a third party resolve a handle? What is the policy when the entity is destroyed, merged, renamed, or transferred? A historian asking these of museum accession numbers, a clinician asking them of medical-record numbers, and an engineer asking them of universally unique identifiers are performing the identical diagnostic, and they surface the identical class of failure — collision, orphaning, authority loss — in each. The transfer is prescriptive as well as descriptive: the disciplines worked out in one substrate port directly to another. The web's hard-won practice of permanent versus temporary resolution, of preserving downstream references through redirects, and of avoiding resolution chains transfers to library-system migrations and to versioned-record management; the database practice of stable keys decoupled from mutable attributes transfers to customer-record design, where its absence produces the duplicate records that wreck deduplication and history.^[6] The deepest carry is the recognition that the authority and the dereference protocol are load-bearing: a handle is only as durable as the institution committed to keeping its binding resolvable, and a reasoner who has watched one authority fail — an abandoned registry, a deprecated key service — knows to ask of every new system how its bindings will outlive the parties that created them.

Examples

Formal/abstract

A database primary-key scheme with a resolution endpoint is the pattern in its most controllable, fully specified form. The entity is a row representing some real-world thing (a customer, an order) with persistent existence the system tracks across changes to its attributes. The authority is the database's key-generation mechanism — a sequence generator or UUID source — which guarantees uniqueness within the table's namespace and stands ready to resolve any key.^[4] The handle is the primary key itself, drawn from a defined shape (a 64-bit integer or a 128-bit UUID) and deliberately opaque: it is not derived from the entity's mutable attributes, so it survives a name change, an address change, or a status change.^[7] The binding record is the row itself, mapping key to the entity's current attributes, recorded at insertion. The dereference operation is a lookup by key returning the row, or an authoritative "not found." The reference/description decoupling invariant is the load-bearing design rule that distinguishes a robust schema from a fragile one: every foreign key elsewhere in the database points by the bare opaque handle, so the entity's description can change freely while every pointer to it remains valid. The three named failures are concrete bugs. Handle collision — two distinct entities issued the same key — silently merges them, the classic catastrophe a uniqueness constraint exists to prevent. Orphaned handle — a foreign key whose target row was deleted — leaves a dangling reference, which referential-integrity constraints are designed to catch. Authority failure — the key service or the table is lost — turns every outstanding reference into an unresolvable token. The well-known anti-pattern of using a natural key (an email address, a phone number) as the primary key is exactly a violation of the decoupling invariant: a descriptive handle that breaks on rename.^[7]

Mapped back: The primary-key scheme instantiates all five commitments — entity, key-generating authority, opaque handle, binding row, lookup dereference — and the reference/description decoupling is precisely what lets the row's attributes change while every foreign-key pointer survives.

Applied/industry

Two record-keeping cases run the identical five-commitment structure on substrates a database shares no machinery with. In museum collection management, an accession number is the handle bound to a physical object at acquisition.^[1] The authority is the registrar who mints the number and guarantees its uniqueness within the institution's namespace; the binding record is the accession ledger entry; the dereference operation is a catalog lookup returning the object's current record. The handle's value is its indifference to description: across loans, conservation treatments, reattribution to a different artist, and even retitling, the accession number remains the stable point of reference, and every internal and external citation routes through it.^[1] The predicted failure of orphaned handle appears concretely when an object is deaccessioned without retiring its references; authority failure is the abandoned-registry scenario that turns historical citations into unresolvable tokens. In healthcare, a medical-record number is the handle bound to a patient.^[3] The reference/description decoupling is clinically load-bearing: the MRN must remain stable across the patient's name change, address change, and insurance change, so that every lab result, prescription, and encounter aggregates against one identity. The signature failure is the handle collision in reverse — duplicate MRNs for one patient — which fragments the chart and is exactly the failure that managed reference exists to eliminate; the prime's checklist (who is the authority, what is the uniqueness scope, how is the binding kept, how does a third party resolve, what happens on merge or transfer) is the same diagnostic a registrar applies to accession numbers and an engineer applies to UUIDs.

Mapped back: Accession numbers and medical-record numbers span cultural heritage and healthcare; in each, an authority binds an opaque, description-independent handle to an entity and resolves it on demand, and the same collision, orphaning, and authority-loss failures the prime names recur in identical form.

Structural Tensions

T1 — Opaque versus Descriptive Handle (sign/direction). Opacity is the prime's load-bearing virtue — a handle that carries no description survives renames — but opaque handles force a lookup for any fact and reveal nothing on inspection. Descriptive or hierarchical handles save lookups but break the moment the encoded meaning changes. The failure mode is using a natural key (an email, a phone number) as the handle, so the identity shatters when the description it embedded changes. Diagnostic: ask whether the handle is derived from any mutable attribute of the entity; if it is, the decoupling invariant is violated and the handle is description wearing an identifier's costume.

T2 — Handle Durability versus Authority Lifespan (temporal). A handle is only as durable as the authority committed to resolving it — but authorities outlive entities far less reliably than the handles they mint imply. Registries are abandoned, key services deprecated, institutions dissolved. The failure mode is minting "permanent" identifiers whose binding becomes unresolvable when the authority disappears, turning every outstanding reference into a dead token. Diagnostic: ask how the binding will outlive the party that created it — succession, escrow, federation; an identifier scheme with no continuity plan for its authority is promising a durability it cannot back.

T3 — One Handle versus Many for One Entity (coupling). The pattern presumes one handle per entity, but reality produces several — duplicate medical-record numbers, multiple registrations, independently minted keys later found to denote the same thing. The decoupling that makes handles cheap also makes accidental duplicates easy. The failure mode is a fragmented identity, where an entity's history scatters across handles no one has reconciled. Diagnostic: ask what detects and merges co-referring handles; a system that can mint freely but cannot reconcile will accumulate duplicates that wreck aggregation and deduplication.

T4 — Stable Handle versus Entity Lifecycle Events (scopal). The handle is supposed to absorb all change in the entity, but some lifecycle events — destruction, merger, split, transfer — strain the one-handle-one-entity binding itself. When two entities merge, which handle survives, and what happens to references to the retired one? The failure mode is an unhandled merge or split that leaves orphaned handles or silently redirects without a record. Diagnostic: ask what the policy is for destroy, merge, split, and transfer; a scheme that specifies issuance and resolution but is silent on these events will improvise them inconsistently when they occur.

T5 — Constant Reference Cost versus Resolution Availability (scalar). The prime makes every downstream reference a cheap constant-size handle, exporting all the cost to dereference time — which is fine until resolution is unavailable, at scale, or offline. The cheapness of holding a reference is paid back as a dependency on the authority being reachable whenever meaning is actually needed. The failure mode is a system flooded with bare handles it cannot resolve because the authority is a bottleneck or single point of failure. Diagnostic: ask what a holder can do with a handle when the authority is unreachable; if the answer is "nothing," the constant reference cost concealed a resolution-availability liability.

T6 — Managed Reference versus Informal Naming (scopal). The prime applies only inside a designed reference system with an authority and a resolution protocol; it does not arise from merely naming a thing. The boundary is where the institutional machinery stops. The failure mode is believing a thing has a durable identifier because it has a name, when no authority records a binding or stands ready to resolve it — so the "identifier" resolves only by shared memory. Diagnostic: ask who recorded the binding and who will answer "what does this denote?"; if no party owns the binding, this is informal naming with the fragility managed reference exists to eliminate, not identifier assignment.

Structural–Framed Character

Identifier assignment sits in the mixed-framed band of the structural–framed spectrum, at an aggregate of 0.6. There is a real relational core — the decoupling of reference from description, so a stable handle absorbs all subsequent change in the entity — but the act is administrative infrastructure that does not exist outside designed reference systems, and two diagnostics hit the full mark.

The framing pressure is concentrated in institutional_origin (1.0) and human_practice_bound (1.0). The prime's five commitments — an entity, an authority that mints and guarantees uniqueness within a namespace, a handle, a binding record held by the authority, and a dereference operation — describe a governed bookkeeping system. The prime is explicit that a thing is not assigned an identifier merely by being named informally: assignment requires an authority that records a binding and stands ready to resolve it. There is no such act in indifferent physical substrates; its home cases — museum accession numbers, legal title numbers, medical record numbers, scholarly identifiers, software UUIDs, public-administration IDs — are all administrative artifacts, which is exactly why both criteria max out.

The remaining marks hold the grade inside the mixed-framed band rather than deeper. vocab_travels is 0.5: terms like namespace, authority, dereference, and binding carry an infrastructural idiom that partly travels, but the underlying reference-from-description decoupling can be stated neutrally. import_vs_recognize is 0.5 because invoking the prime partly imports the registry frame and partly recognizes a real managed-reference structure. And evaluative_weight is 0: minting a handle is a value-neutral act. The mixed-framed label is correct — this is administrative infrastructure tied to designed reference systems — but the genuine structural decoupling at its core is what keeps it at 0.6.

Substrate Independence

Identifier assignment is a moderately substrate-independent prime — composite 3 / 5 on the substrate-independence scale. Its structural core — the decoupling of reference from description, so a stable opaque handle absorbs all subsequent change in the entity — can be stated over five substrate-free commitments (entity, authority, handle, binding record, dereference), which earns the middle structural-abstraction mark. The domain breadth is real but bounded: the five commitments recur in museum accession numbers, legal title and vehicle and patent registrations, medical-record numbers and clinical-trial registrations, scholarly persistent identifiers, software UUIDs and database keys and commit hashes, public-administration IDs, and incident and ticket numbers. Transfer evidence is the strongest component at 4 — a database primary key, a museum accession number, and a medical-record number share the same five commitments and the same collision, orphaning, and authority-loss failure modes, and the disciplines worked out in one substrate (stable opaque keys, redirect-on-rename) port directly to another. What caps the composite at 3 is that the act is administrative infrastructure: every instance presupposes a designed reference system with an authority and a resolution protocol, and a thing is not assigned an identifier merely by being named informally, so the pattern has no instance in indifferent physical substrates and stays confined to record-keeping practice.

• Composite substrate independence — 3 / 5
• Domain breadth — 3 / 5
• Structural abstraction — 3 / 5
• Transfer evidence — 4 / 5

Relationships to Other Abstractions

Current abstraction Identifier Assignment Prime

Parents (2) — more general patterns this builds on

• Identifier Assignment is a kind of Appellation Prime

  Identifier assignment is the managed-reference species of appellation, adding namespace uniqueness, a durable binding record, and a dereference protocol to authoritative token-to-entity binding.

• Identifier Assignment presupposes, typical Indirection Prime

  Identifier_assignment CREATES the handle that indirection later resolves (dereference uses indirection); minting+binding is a prior distinct act that presupposes the indirection-resolution machinery.

Children (9) — more specific cases that build on this

• Acct URI scheme Domain-specific is a kind of Identifier Assignment

  The proposed strict upward parent is prime:identifier_assignment.

• Bort number Domain-specific is a kind of Identifier Assignment

  The proposed strict upward parent is prime:identifier_assignment.

• European Case Law Identifier Domain-specific is a kind of Identifier Assignment

  ECLI strictly instantiates Identifier Assignment by assigning one governed, parseable handle to a judicial decision within a federated namespace.

▸ Show 6 more

Hierarchy paths (4) — routes to 4 parentless roots

• Identifier Assignment → Appellation

Show alternative paths (3)

Neighborhood in Abstraction Space

Identifier Assignment sits among the more crowded primes in the catalog (39^th percentile for distinctiveness): several abstractions describe nearly the same structure, so a description that fits it will tend to fit its neighbors too — transporting it usually means disambiguating within this family rather than landing on it exactly.

Family — Naming, Reference & Identifiers (8 primes)

Nearest neighbors

• Persistent Identifier — 0.77
• Appellation — 0.73
• Idempotence — 0.73
• Alias-to-Authority Mapping — 0.72
• Identity-Providing Kind — 0.71

Computed from structural-signature embeddings · 2026-09-10

Not to Be Confused With

The embedding-nearest neighbor, idempotence (similarity 0.86), is a confusion driven by a real but narrow overlap: well-designed assignment is often idempotent. Idempotence is a property of an operation — applying it repeatedly produces the same result as applying it once, so a retried request leaves the system in the state a single request would have. Identifier assignment is not an operation-property but an act of installing managed reference: minting a handle, recording a binding in an authority, and standing ready to dereference it. The two intersect because robust assignment protocols are usually built to be idempotent — re-issuing for an entity that already has a handle should return the existing handle rather than mint a duplicate, which is exactly the defense against the "many handles for one entity" failure of tension T3. But idempotence is a desirable property the assignment operation may have, not what assignment is; one can have idempotent operations that assign nothing, and one can (badly) assign identifiers non-idempotently. Conflating them leads a designer to think that making a mint endpoint idempotent has solved identity management, when the load-bearing parts — the durable authority, the binding record, the resolution protocol — are entirely separate concerns idempotence does not touch.

A second confusion, structurally important, is with the hierarchical_address. Both produce a token that stands for an entity, and both live in designed reference systems. The difference is whether the token encodes information about the entity. The canonical identifier-assignment handle is deliberately opaque: it carries no description and no position, which is precisely the decoupling-of-reference-from-description that lets it survive renames, transfers, and restructuring untouched. The hierarchical address does the opposite — it packs the entity's tree position into the token to buy free structural queries, and pays for it with fragility under restructuring. They are the two poles of the handle-design trade-off the prime's "Abstract Reasoning" section lays out: opaque handles maximize stability and force lookups for any fact; structured (descriptive or hierarchical) handles save lookups but break when the encoded meaning or structure changes. A practitioner who fuses them imports the address's restructuring fragility into a setting that wanted opaque stability, or expects free ancestry-queries from a handle that, being opaque, can offer none. The hierarchical address is one (informative, fragile) way to fill the handle slot; identifier assignment is the general pattern, which is most robust precisely when the handle carries nothing.

A third confusion is with naming_convention. A naming convention is a shared rule for forming labels — a syntax, a vocabulary, a pattern that makes names well-formed and human-legible. It is tempting to think that having a good naming convention means one has assigned identifiers. But a convention governs only the shape of the token; identifier assignment additionally requires the institutional machinery the convention lacks — an authority that records a binding and a protocol that resolves the handle to the entity. A perfectly disciplined naming convention can still produce names that no authority binds and no party can resolve, which is exactly the informal-naming failure of tension T6: the names look like identifiers and resolve only by shared memory. Confusing the two leads an organization to invest in beautiful, consistent names while neglecting the binding record and resolution authority that are what actually make reference durable.

These distinctions matter because each protects a different load-bearing commitment. Holding identifier assignment apart from idempotence keeps the durable authority, binding, and dereference in view as the substance, rather than mistaking a retry-safety property for identity management. Holding it apart from the hierarchical_address keeps the opacity that gives the handle its stability, and frames structured handles as one fragile point on a trade-off curve. And holding it apart from naming_convention keeps the authority-plus-resolution machinery central, so that well-formed names are never mistaken for managed, resolvable reference.

Solution Archetypes

Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.

Built directly on this prime (2)

• Durable Identifier Binding: Create a durable handle for a referent, bind it in an authoritative record, and maintain enough lookup, lifecycle, and audit rules that later references can rely on the handle without re-describing the entity.
  ▸ Mechanisms (11)
• Registry-Mediated Discovery: Put a maintained discovery registry between agents and changing counterparts so stable names resolve to current locations, interfaces, or contact records instead of hard-coded references.
  ▸ Mechanisms (10)

Also a related prime in 5 archetypes

• Collision-Free Mapping Design: Protect source distinctions by ensuring that no two distinct inputs map to the same target unless an explicit, reviewed merge is intended.
• Evidence-Bound Authentication: Grant trust, access, or evidential weight only after an asserted identity or origin is bound to admissible evidence and returned as a scoped authentication verdict.
• Lossless Bijective Mapping Design: Design mappings so nothing collides, nothing is left out, and every pairing can be traversed backward as well as forward.
• Open Reuse Publication Infrastructure: Make an artifact reusable by strangers by publishing it as a stable, openly accessible, license-clear, machine-readable, versioned, and maintained public dependency rather than as a private handoff.
• Persistent Identifier Stewardship: Keep references usable over time by assigning a durable identifier and maintaining the resolver, metadata, and stewardship rules that make the identifier continue to reach the same intended entity.

References

[1] Collections Trust. Spectrum 5.0: The UK Collections Management Standard. Collections Trust, 2017. Specifies accessioning and object-numbering procedures: an authority (the registrar) binds an accession number to a physical object at acquisition and resolves it across loans, conservation, and reattribution. registry ↩a ↩b ↩c

[2] International Organization for Standardization. ISO 3779:2009 — Road Vehicles: Vehicle Identification Number (VIN) — Content and Structure. Geneva: ISO, 2009. Defines the VIN as a uniquely-issued durable handle bound to a vehicle, representative of legal title/registration identifier schemes anchoring claims across transfers. registry ↩

[3] Health Level Seven International. HL7 Version 3 Standard: Patient Administration; Patient Registry. Ann Arbor, MI: HL7. Defines patient-identity management and the medical-record-number role as a durable handle bound to a patient, kept stable across name, address, and insurance changes. registry ↩a ↩b

[4] Leach, Paul, Michael Mealling, and Rich Salz. A Universally Unique IDentifier (UUID) URN Namespace. RFC 4122, IETF, 2005. Specifies UUID generation guaranteeing uniqueness within a namespace without a central registry — the opaque-handle minting authority for software and data systems (analogous to a DB sequence/UUID source). registry ↩a ↩b

[5] International Civil Aviation Organization. Doc 9303: Machine Readable Travel Documents, 8^th ed. Montréal: ICAO, 2021. Governs passport-number issuance, representative of public-administration identifier assignment (passport, license, taxpayer, business-registration numbers) by a minting authority. registry ↩

[6] Berners-Lee, Tim. Cool URIs Don't Change. W3C Style guide, 1998. States the web discipline of permanent versus temporary identifiers, preserving downstream references through redirects and avoiding resolution chains — the practice ported to library migrations and versioned-record management. registry ↩

[7] Date, C. J. An Introduction to Database Systems, 8^th ed. Boston: Addison-Wesley, 2003. Standard text establishing surrogate (opaque) primary keys decoupled from mutable attributes and referential integrity, and the anti-pattern of using a natural key (email, phone) that breaks on change. registry ↩a ↩b