Identifier Assignment¶
Core Idea¶
Minting a durable handle for an entity and binding it to that entity in a public, queryable record, so future reference routes through the handle without re-describing the entity. The handle is deliberately opaque — never about the entity's properties — so it survives renames, transfers, and property changes; the structural force is the decoupling of reference from description.
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.
Broad Use¶
- Cultural heritage: accession numbers bound to physical objects across loans and reattribution.
- Law: chains of title anchored through deed numbers, vehicle identification numbers, and registrations.
- Healthcare: medical-record numbers, drug codes, and specimen accessions.
- Scholarly communication: persistent identifiers for works, authors, and institutions.
- Software and data: universally unique identifiers, database keys, commit hashes, container digests.
- Public administration: passport, license, taxpayer, and business-registration numbers.
- Incident histories: numbered policing incidents, support tickets, and bug reports.
Clarity¶
Supplies a checklist — who is the authority, what is the uniqueness scope, how is the binding kept, how does a third party resolve, and what happens on merge or transfer — and names the failure modes of collision, orphaning, and authority loss.
Manages Complexity¶
Bounds the description load on every reference: each pointer is the bare handle and full description is consulted only on dereference, so reference cost stays constant regardless of how rich the entity is.
Abstract Reasoning¶
Places a scheme on three axes — handle structure (opaque, descriptive, or hierarchical), authority reach (global, per-system, per-namespace), and dereference protocol — whose settings predict in advance how the system degrades under stress.
Knowledge Transfer¶
- Web → libraries: permanent-versus-temporary resolution and redirect-on-rename port to library migrations.
- Databases → customer records: stable keys decoupled from mutable attributes prevent the duplicates that wreck deduplication.
- Any registry: a watched authority failure teaches one to ask how every new system's bindings will outlive their creators.
Example¶
A database primary key is an opaque handle drawn from a fixed shape, so a row's name, address, or status can change while every foreign-key pointer survives — and using a natural key (an email) as the key is exactly the decoupling violation that breaks on rename.
Relationships to Other Primes¶
Parents (1) — more general patterns this builds on
- Identifier Assignment presupposes, typical Indirection — The file: 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. (Owner may prefer parentless / a managed-reference family.)
Path to root: Identifier Assignment → Indirection → Layering
Not to Be Confused With¶
- Identifier Assignment is not Idempotence because idempotence is a property an operation may have (a retry yields the same result) whereas assignment is the act of installing managed reference — authority, binding, and dereference.
- Identifier Assignment is not a Hierarchical Address because the canonical handle is deliberately opaque and maximally stable whereas a hierarchical address packs position into the token, buying queries at the cost of fragility under restructuring.
- Identifier Assignment is not a Naming Convention because a convention governs only the shape of a label whereas assignment additionally requires an authority that records a binding and resolves it.