Reverse Mapping Table¶
Reference artifact — instantiates Structural Inversion Design
Tabulates a finite forward mapping and its reverse so every target value is labelled a unique preimage, an ambiguous set, or none — turning enumeration into an honest inverse relation.
When a mapping is finite or categorical rather than continuous, its inverse cannot be solved for — but it can be enumerated. Reverse Mapping Table takes the complete forward mapping, inverts it row by row, and produces a lookup relation in which each target value points back at every source that produced it. The defining move is what happens when that pointer is not one-to-one: instead of quietly picking a favourite, the table labels every target as one of three kinds — a unique preimage, an ambiguous set of two or more, or none at all (a value the forward map never produces). It is a static reference artifact, not a running procedure: you read it, you don't execute it. And because two labels can be spelled the same but mean different things, each row also carries the semantic correspondence that makes the reverse lookup a real inverse and not a coincidence of strings.
Example¶
A company is migrating a twenty-year-old CRM into a new platform, and the two systems disagree about what an account's status means. The legacy system had five codes — active, dormant, suspended, closed, pending — while the new one recognizes only three: active, inactive, archived. The forward migration is easy and lossy: dormant, suspended, and closed all collapse into inactive. The trouble comes later, when a report needs to run the mapping backward to reconstruct legacy status for an audit.
Building the reverse mapping table makes the situation legible. The row for active has a unique preimage — clean. The row for inactive is ambiguous: it points back at the set {dormant, suspended, closed}, and the table refuses to guess which one any given record was. The row for archived has no legacy preimage at all — it is a new concept the old system never expressed, so reversing it yields nothing to reconstruct. The table also records a semantic footnote: legacy pending mapped forward to active, but the two do not mean the same thing, so a naïve reverse lookup that treated active as recovering pending would be wrong. The artifact turns a migration that "looks reversible" into an explicit map of what actually is.
How it works¶
- Enumerate the forward mapping in full. List every source value and the target it maps to; the reverse table is the transpose of this relation, so completeness of the forward list is what makes the inverse trustworthy.
- Group by target and label. For each target value, collect all sources that reach it and tag the row
unique,ambiguous {…}, ornone. - Attach the semantic correspondence. Record what each side means, not just its symbol, so that equal labels with unequal meaning are flagged and unequal labels with equal meaning are unified.
- Keep it read-only and versioned. The table is consulted, never computed on the fly; when the forward mapping changes, the table is regenerated rather than patched.
Tuning parameters¶
- Granularity — one row per raw value, or per equivalence class of values. Coarser rows shrink the table but can hide a distinction the reverse consumer needs.
- Ambiguity presentation — list the full preimage set, or attach prior weights to its members. Weights help a downstream chooser but tempt readers to treat the most likely source as the source.
- Coverage stance — whether unmapped targets are stored as explicit
nonerows or simply omitted. Explicitnonerows distinguish "no preimage" from "not yet entered," which omission blurs. - Semantic strictness — whether rows must match on meaning or only on symbol. Strict matching catches label collisions; loose matching is faster to build but ships false equivalences.
When it helps, and when it misleads¶
Its strength is exhaustive honesty over a finite domain: because every target is visited, the table cannot hide an ambiguous or empty preimage the way a solved formula or a convenient default can. It is the reference other mechanisms consult when they need to know, definitively, whether a value can be reversed at all.
Its failure mode is arbitrary preimage selection creeping in at the consumer: a reader glances at an ambiguous row, takes the first entry, and treats a set-valued inverse as single-valued.[n1] A subtler misuse is matching rows by symbol when the two systems assign the same token different meanings, producing a table that round-trips characters while corrupting semantics. The guarding discipline is to keep the three labels visible all the way to the point of use — an ambiguous row must reach the consumer as a set — and to build the table on semantic correspondence rather than string identity.
How it implements the components¶
Reverse Mapping Table fills the finite-relation components — the ones an enumerated artifact can hold:
source_structure_map— the forward mapping is captured completely as an explicit relation, which is the substrate the reverse table transposes.invertibility_and_ambiguity_classification— every target row is labelled unique, ambiguous (with its preimage set), or none, classifying invertibility per value.interpretation_and_semantic_mapping— each row carries the meaning of both sides, so a reverse lookup recovers sense, not just a matching symbol.
It does not derive a closed-form operator or restrict a continuous domain (inversion_operator, domain_and_codomain_boundary) — that is Algebraic Inverse Construction, the symbolic twin; and it does not infer candidates for outputs absent from the table (information_loss_and_recoverability_profile, round_trip_validation_rule), which is Backward-Chaining Reconstruction.
Related¶
- Instantiates: Structural Inversion Design — supplies the enumerated inverse relation with per-value ambiguity made explicit.
- Sibling mechanisms: Algebraic Inverse Construction · Backward-Chaining Reconstruction · Round-Trip Property Test · Reverse-Order Workflow Walkthrough · Inside-Out / Outside-In Reframing Matrix · Role and Control Reversal Simulation · Reversible Transformation Sandbox · Polarity or Orientation Flip Probe · Inversion Failure-Mode Review
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Reverse Mapping Table operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it tabulates a finite forward mapping and its reverse so every target value is labelled a unique preimage, an ambiguous set, or none — turning enumeration into an honest inverse relation.
Independent corroboration: The frozen evidence defines Reverse Mapping Table as 'Tabulates a finite forward mapping and its reverse so every target value is labelled a unique preimage, an ambiguous set, or none — turning enumeration into an honest inverse relation', so its operative form is Representation, Specification & Plan.
Nearest alternative: Record, Log & Register — Reverse Mapping Table includes features of a persistent ledger, log, register, or case record that preserves history and traceability, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Mathematics
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Enumerating inverse images of a mapping is elementary function and relation theory in mathematics.
Related originating lineages:
- Computer Science & Software Engineering — Lookup tables and invertibility checks materially operationalize finite reverse mappings.
Review resolution: Both blind reviewers agree that mathematics is the primary historical origin. Explicit reconciliation of domain reach disagreement, encyclopedia synthesis disagreement starts from reviewer_a’s mechanism-specific evidence: Enumerating inverse images of a mapping is elementary function and relation theory in mathematics. Reviewer A proposed alternates=computer_science, origin_mode=single_lineage, domain_reach=universal, and encyclopedia_synthesis=false; reviewer B proposed alternates=computer_science, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=true. The final record retains every independently supported alternate from either review (computer_science) without an arbitrary cap, selects origin_mode=single_lineage to represent the combined lineage evidence, and keeps domain_reach=universal and encyclopedia_synthesis=false from the more mechanism-specific assessment. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] The preimage of a value under a mapping is the set of all inputs that produce it. For a non-injective (many-to-one) map that set has more than one member, so the "inverse" is a relation, not a function — which is exactly what an ambiguous table row records and a careless reader collapses. ↩