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.

Essence

Collision-Free Mapping Design is the mapping-integrity pattern for preserving distinctions. It applies when a target value is treated as evidence of one source, but the system could accidentally map two distinct sources to that same value. The intervention is to make injectivity operational: define what counts as a distinct source, define the target namespace, install a unique-target guard, detect collisions, preserve preimage evidence, and route violations to repair or explicit merge review.

This is weaker than full bijection and stronger than ordinary mapping. Unused target values are fine. What is not fine is unreviewed collapse.

Compression statement

Collision-Free Mapping Design applies when a system maps many possible sources into target values but must preserve source distinctness. The intervention defines source identity boundaries, specifies the target namespace, writes an injective mapping rule, enforces unique-target constraints, detects collisions, quarantines or repairs violations, and governs target lifecycle so duplicates, accidental merges, double-bookings, alias collapse, and lossy encodings do not erase distinctions the system still needs.

Canonical formula: For a mapping f: A -> B, require that for all a1, a2 in A, if a1 != a2 then f(a1) != f(a2). Equivalently, if f(a1)=f(a2), then a1=a2. Unlike bijection, not every b in B must be reached.

Why this is distinct

The previous queue output lossless_bijective_mapping_design requires no collisions and no gaps, plus inverse behavior. injectivity is narrower: it only requires that distinct sources remain distinct after mapping. Many practical systems need this narrower invariant. A booking system does not need every room to be used; it needs no room-time slot to be double-booked. An ID registry does not need every possible ID to be used; it needs no active ID to refer to two different entities.

It is also different from pairwise_collision_risk_budgeting. Birthday-style budgeting estimates when collisions become likely in finite random spaces. Collision-Free Mapping Design governs the operational invariant and controls that prevent or detect actual collision in mappings.

Core intervention logic

1. Define source distinctness. State which inputs, entities, states, claims, or requests must remain distinguishable.
2. Define the target namespace. State where target values live, which values are active, reserved, retired, reusable, or invalid.
3. Specify the mapping rule. Describe how targets are generated, assigned, encoded, normalized, reserved, or imported.
4. Install a uniqueness guard. Prevent one target from being accepted for more than one distinct active source.
5. Detect existing collisions. Scan imports, legacy data, concurrent assignments, hashes, encodings, and normalized values.
6. Preserve preimage evidence. Keep enough source-to-target evidence to diagnose collisions.
7. Quarantine exceptions. Route collisions to retry, repair, disambiguation, explicit merge review, or namespace expansion.
8. Govern lifecycle. Define target retirement, reuse, reservation, and historical lookup rules.

Key components

Component	Description
Source Identity Boundary ↗	Injectivity cannot be checked until the system knows what counts as distinct. Two records, requests, people, resources, states, or claims may look similar but still need distinct targets.
Target Namespace Specification ↗	The namespace gives the uniqueness rule a boundary. A target may be unique per tenant, per day, per room, per table, per clinic, or globally. The scope must be explicit.
Unique Target Constraint ↗	The unique-target constraint is the practical injectivity guard. It prevents a shared target from being accepted unless a valid merge exception exists.
Collision Detection Guard ↗	Even strong systems need scans and tests. Imports, concurrency, legacy data, truncation, hashing, and normalization can bypass assumptions.
Preimage Evidence Record ↗	When a collision happens, maintainers need to know which sources led to the target. Without preimage evidence, a duplicate target may be visible but not repairable.

Mechanisms

Common mechanisms include unique database indexes, duplicate-target scans, namespace reservation tables, deterministic ID allocators, booking locks, hash collision checks, preimage audit logs, and collision quarantine queues. These are implementation mechanisms; the archetype is the broader design discipline that decides when injectivity is required and maintains it over time.

Boundary distinctions

• Lossless Bijective Mapping Design: use when every source and every target must be paired exactly once and inverse lookup must be total. Use this draft when unused targets are acceptable but target sharing is not.
• Pairwise Collision Risk Budgeting: use when the main problem is sizing a finite random namespace against collision probability. Use this draft when the main problem is mapping distinctness, enforcement, and repair.
• Alias-to-Authority Mapping: many aliases intentionally route to one authority. That is non-injective by design.
• Equivalence Normalization: equivalent forms intentionally collapse. This draft prevents unreviewed collapse of non-equivalent sources.

Examples

A customer registry blocks two customer records from receiving the same active customer ID. A room-booking system prevents two meetings from reserving the same room-time slot. A log encoder is tested so two event states do not collapse into the same emitted code. A token generator checks active and quarantined tokens before issuance. An asset registry blocks duplicate active tag numbers and records retirements before reuse.

Failure modes

The most common failure modes are hidden many-to-one collapse, concurrent double-assignment, unsafe target reuse, intentional merges disguised as ordinary mappings, probabilistic collision surprise, and overconstrained uniqueness. The repair pattern is the same: make the scope explicit, detect collisions early, preserve source evidence, and separate intentional merging from accidental collision.

Common Mechanisms

• Booking Lock
• Collision Quarantine Queue
• Deterministic ID Allocator
• Duplicate Target Scan
• Hash Collision Check
• Namespace Reservation Table
• Preimage Audit Log
• Unique Index Constraint

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (7)

• Cardinality: Size of sets.
• Data Integrity: Accuracy and consistency preserved.
• Function (Mapping): Relates inputs to outputs.
• Hashing: Deterministically reducing any object to a short fixed-size token used as its handle.
• Injectivity: A distinctness-preserving mapping in which distinct inputs never collide on one output.
• Preimage: The set of all inputs that map to a given output under some mapping.
• Set and Membership: Groups and categorizes elements.

Also references 10 related abstractions

• Aliasing: Sampling a signal below the rate its information content demands folds distinct high-frequency states onto identical low-frequency ones, fabricating false structure that masquerades as real signal.
• Bijectivity: A correspondence that is exactly one-to-one and onto — no collisions, no gaps — so it is reversible and the two collections have equal size and information content.
• Birthday Problem: Pairwise collisions in a finite namespace become likely at the square root of its size, not half of it.
• Complete Enumeration: A programmatic commitment to map every unit of a defined population, where completeness itself is the load-bearing property that unlocks inferences sampling cannot.
• Coverage / Reachability: A completeness claim in the surjective direction: every required target in a target set is reachable from at least one of the system's inputs, pathways, or mechanisms.
• Disjointness: Two or more populated collections share no element.
• Identifier Assignment: Mint a durable handle for an entity and bind it to that entity in a public, queryable record, so future reference can route through the handle without re-describing the entity.
• Identity-Providing Kind: A category whose membership fixes what it takes for an instance to remain the same instance over time, supplying persistence criteria rather than a temporary description.
• Persistent Identifier: A designed token committed to keep resolving to its entity across changes in the entity's location, representation, custodian, or version, via a separately maintained resolver.
• Surjectivity: A coverage-guaranteeing mapping in which every element of the target is hit by some input, leaving no gap in the codomain.

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Unique Identifier Assignment · domain variant · recognized

Assign identifiers so no two active entities share the same identifier inside a governed namespace.

• Distinct from parent: The parent covers any distinctness-preserving mapping; this variant focuses on identifiers as durable operational values.
• Use when: IDs carry identity, rights, history, ownership, audit, or access consequences; Unused identifiers are acceptable, but shared identifiers are not; The namespace changes over time and needs reservation, retirement, and reuse rules.
• Typical domains: customer records, asset registries, software package names
• Common mechanisms: unique index constraint, namespace reservation table, duplicate target scan

Injective Encoding Mapping · mechanism family variant · recognized

Encode source states so distinct source states never collapse to the same encoded value inside the represented domain.

• Distinct from parent: The parent is mapping-general; this variant focuses on representation and encoding.
• Use when: The system may not need to cover every possible encoded value; Losing source distinctions would corrupt interpretation, audit, replay, or reconstruction; Decoder behavior may be partial but collision prevention is mandatory.
• Typical domains: serialization, logging, machine learning feature encoding
• Common mechanisms: encoder distinctness test, round trip sample test, hash collision check

Injective Allocation / No-Double-Booking · domain variant · candidate

Assign tasks, users, bookings, claims, or obligations to target slots so no target is assigned to more than one active source.

• Distinct from parent: The parent is mapping-general; this variant emphasizes operational allocation and double-booking avoidance.
• Use when: Double-use of a target creates conflict, overbooking, liability, or resource contention; Not every target slot needs to be used; The main invariant is at-most-one source per target, not complete coverage.
• Typical domains: scheduling, inventory reservation, case assignment
• Common mechanisms: booking lock, reservation ledger, duplicate assignment scan

Near names: Distinctness-Preserving Mapping, One-to-One Mapping Design, Uniqueness Preservation, Duplicate Target Prevention, Collision-Free Assignment.