Lossless Bijective Mapping Design

Design mappings so nothing collides, nothing is left out, and every pairing can be traversed backward as well as forward.

Overview

Lossless Bijective Mapping Design is the intervention pattern for mappings that must be exact. It applies when a source collection and a target collection need a one-to-one-and-onto correspondence: every source gets exactly one target, every target is used exactly once, and the mapping can be traversed backward without losing the original member.

The target prime is 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.

Disposition check

The pre-draft check found no accepted archetype directly covering bijectivity. The closest accepted neighbors were correspondence_validation, mapping_reconciliation, equivalence_normalization, equivalence_class_consolidation, source_of_truth_assignment, and data_integrity_preservation. Those cover adjacent concerns, but none requires the full bijective invariant: no collisions, no gaps, inverse lookup, and round-trip preservation. The previous queue item, variant_access_point, was dispositioned as a component direction for many-to-one alias/authority routing, which is explicitly different from bijective mapping.

Why this is not just correspondence validation

Correspondence validation asks whether a new model, version, or system agrees with an old one inside an overlap domain. Lossless Bijective Mapping Design asks a stricter question: does every source member pair with exactly one target member, does every target member have exactly one source member, and can the mapping be traversed in reverse without loss? A correspondence can be partial or approximate; a bijection cannot.

Key components

Component	Description
Domain and Codomain Set Specifications ↗	A bijection cannot be checked unless both sides are explicitly bounded. The domain set defines what must be mapped from. The codomain set defines what must be covered. Ambiguous boundaries turn bijection into a slogan rather than an invariant.
Mapping Rule ↗	The mapping rule may be a table, transformation, matching rule, function, or crosswalk. It must be explicit enough that pairings can be inspected, regenerated, tested, and governed. Hidden heuristics are acceptable only if their outputs are recorded and audited as pairings.
Injectivity Guard ↗	The injectivity guard prevents two distinct source members from collapsing onto the same target. It protects identity, information, ownership, rights, counts, and accountability from accidental merging.
Surjectivity Coverage Guard ↗	The surjectivity guard checks the other side: every target inside scope must be reached. It prevents orphan target records, unused slots, missing target states, and false claims of complete coverage.
Inverse Lookup Path ↗	A practical bijection needs a reverse route. The inverse lookup path may be an index, inverse table, decoder, rollback map, or audit process, but it must reliably recover the source from the target inside scope.
Round-Trip Test Set ↗	Round-trip tests expose loss. Mapping source to target and back should return the source. Mapping target to source and back should return the target. Boundary cases, exceptions, and recently changed members should be included.

Common mechanisms

Common mechanisms include one-to-one crosswalk tables, bijection test suites, duplicate target scans, orphan target scans, inverse indexes, unique-constraint pairs, reversible encoder–decoder pairs, ID mapping registers, and mapping exception queues. These are mechanisms; the archetype is the larger design discipline that decides when bijection is required and maintains it through change.

Parameter dimensions

The main dimensions are mapping scope, membership volatility, identity granularity, exception tolerance, inverse strength, and failure cost. A small one-time crosswalk may only need spreadsheet checks. A regulated data migration, identity registry, safety system, or rights-bearing archive needs explicit evidence, inverse records, and repeated validation.

Invariants to preserve

A valid bijective mapping preserves source coverage, target coverage, uniqueness on both sides, inverse lookup, and round-trip identity. It also preserves honesty: if the relationship becomes partial, many-to-one, one-to-many, or lossy, the mapping should be relabeled instead of pretending to remain bijective.

Tradeoffs and failure modes

The core tradeoff is strictness versus practical coverage. Strict bijection protects reversibility but may exclude real cases that need partial, fuzzy, or probabilistic mapping. The main failure modes are hidden collisions, orphan targets, broken inverse paths, equal-count fallacies, stale mappings after membership changes, and forced bijections over naturally many-valued domains.

Neighbor distinctions

correspondence_validation checks old/new agreement in an overlap domain. mapping_reconciliation resolves conflicts between mappings. equivalence_normalization may intentionally collapse equivalent forms. equivalence_class_consolidation groups multiple items for shared treatment. source_of_truth_assignment assigns authority. Lossless Bijective Mapping Design is the stricter pattern for exact reversible pairings.

Examples and non-examples

A legacy-to-new ID crosswalk is a good example when every old ID maps to one new ID and every new ID maps back to one old ID. A reversible encoding is a good example when every valid source state has exactly one representation and every valid representation decodes to one source state. A room-to-exam assignment is a good example within a time block when every exam gets one room and every room is used by one exam.

A synonym table is not a bijection when many names point to one authority. A category split is not a bijection when one old category maps to several new categories. Lossy compression is not a bijection because the inverse cannot recover the original. Equal counts alone do not prove bijection because pairings can still be wrong.

Quality note

This draft is recommended for use with ordinary review. The main future boundary issue is the relation to upcoming zero-coverage targets canonical_form, injectivity, and any later surjectivity-like target; those may become components, variants, or separate narrower archetypes depending on their disposition checks.

Common Mechanisms

• Bijection Test Suite
• Duplicate Target Scan
• ID Mapping Register
• Inverse Index
• Mapping Exception Queue
• One-to-One Crosswalk Table
• Orphan Target Scan
• Reversible Encoder–Decoder Pair
• Round-Trip Migration Test
• Unique-Constraint Pair

Compression statement

Lossless Bijective Mapping Design applies when a system needs a reversible one-to-one-and-onto correspondence between two collections. The intervention defines both sets, states the mapping rule, checks cardinality, prevents collisions, detects gaps, maintains inverse lookup, tests round trips, records exceptions, and governs changes so information, identity, rights, counts, or obligations are not lost when moving across representations.

Canonical formula: For sets A and B, design f: A -> B such that for every a in A there is exactly one f(a), for every b in B there exists exactly one a with f(a)=b, and inverse f^-1 is well-defined throughout the governed scope.

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)

• 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.
• Cardinality: Size of sets.
• Function (Mapping): Relates inputs to outputs.
• Injectivity: A distinctness-preserving mapping in which distinct inputs never collide on one output.
• Isomorphism: Structure-preserving mapping.
• Preimage: The set of all inputs that map to a given output under some mapping.
• Surjectivity: A coverage-guaranteeing mapping in which every element of the target is hit by some input, leaving no gap in the codomain.

Also references 13 related abstractions

• Closure: Ensures operations remain within a set.
• Constraint: Limits possibilities to guide outcomes.
• Correspondence Principle: New theories match old limits.
• Data Integrity: Accuracy and consistency preserved.
• Equivalence Relation: Groups elements into equivalence classes.
• 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.
• Interoperability: Systems function together.
• Relation: Describes associations or dependencies.
• Representation: Model complex ideas.

▸ Show 3 more

Variants

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

Identifier Crosswalk Bijection · domain variant · recognized

Maintain a one-to-one crosswalk between old and new identifiers during migration or namespace transition.

• Distinct from parent: The parent covers all bijective mappings; this variant applies specifically to identifiers, registries, and durable namespace changes.
• Use when: Old identifiers must remain traceable to exactly one new identifier; Rollback, audit, or historical references require inverse lookup; A namespace transition must not merge distinct entities or strand new identifiers.
• Typical domains: data migration, registry management, software package renaming
• Common mechanisms: id mapping register, one to one crosswalk table, bijection test suite

Reversible Encoding Mapping · mechanism family variant · recognized

Encode each source state into a target representation that can be decoded back without information loss within the governed state space.

• Distinct from parent: The parent covers set mappings broadly; this variant covers reversible representation transformations.
• Use when: Serialization, exchange, or format conversion must preserve exact recoverability; Round-trip behavior is a core acceptance criterion; The representable target states can be bounded and checked.
• Typical domains: serialization, data exchange, file format conversion
• Common mechanisms: reversible encoder decoder pair, round trip migration test, bijection test suite

Allocation Pairing Bijection · domain variant · candidate

Pair agents, tasks, resources, seats, slots, or obligations so every source and every target is used exactly once within a defined block.

• Distinct from parent: The parent is mapping-general; this variant emphasizes resource assignment, capacity, and operational exceptions.
• Use when: A matching or assignment must avoid both double-booking and unused slots; Every participant or resource should receive exactly one counterpart; The assignment boundary is fixed enough that exact coverage can be checked.
• Typical domains: scheduling, staffing, inventory assignment, matching markets
• Common mechanisms: one to one crosswalk table, duplicate target scan, orphan target scan

Near names: One-to-One Mapping Design, Reversible Crosswalk Design, Exact Correspondence Mapping, Lossless ID Mapping, Bijection Governance.