Orphan Target Scan¶
Test or assessment — instantiates Lossless Bijective Mapping Design
A scan that detects target members with no source member mapped to them under the intended bijection.
An orphan target scan sweeps the codomain and reports every target member that no source reaches — the empty slots, the unused states, the records that the mapping was supposed to cover but silently doesn't. Its defining move is that it works from the enumerated target set, not from the mapping: it starts with the full list of things that must be reached, subtracts everything the mapping actually hits, and returns the remainder. That is the surjectivity (onto) side of a bijection, and it is the property a collision check can never see — you can have zero duplicate targets and still have half the codomain orphaned. Where its collision-side counterpart asks "is any target claimed twice?", this scan asks "is any target claimed by nobody?" — and it can only answer if the codomain is genuinely closed and known in advance.
Example¶
A fulfilment warehouse is commissioning a new pick-face layout: every one of 4,200 storage bins is supposed to be assigned exactly one active SKU-lot, and every SKU-lot exactly one bin. The allocation job ran, reported "4,200 assignments made," and everyone relaxed. An orphan target scan disagrees. It loads the authoritative bin registry — the closed set of every commissioned bin — and walks it, marking each bin the allocation actually references. When it finishes, 63 bins have no SKU-lot pointing at them: they were superseded by a re-slotting pass that reassigned their lots elsewhere but never cleared the bins from the "available" pool.
Those 63 bins are orphans — physical shelf space the system believes is in use but that no product can be picked from. The scan writes each one into the mapping exception register with its aisle, level, and the lot that used to occupy it, so a slotting supervisor can either re-fill or decommission it. Without the scan, the orphans stay invisible until a picker is sent to an empty shelf, because the headline count of 4,200 was perfectly, misleadingly correct.
How it works¶
- Start from the codomain, not the map. It requires an explicit, closed list of every target that must be covered; a scan over "targets the mapping mentions" can never find an orphan by construction.
- Mark-and-sweep. Walk the mapping to mark reached targets, then walk the codomain and report the unmarked remainder — the orphans.
- Distinguish orphan from out-of-scope. A target legitimately outside the mapping's boundary is not an orphan; the scan applies the scope rule so it only flags targets that were supposed to be reached.
- Log, don't fix. Each orphan is written to the exception register with enough locating detail to be repaired or intentionally retired.
Tuning parameters¶
- Codomain freshness — how recently the target set was enumerated. A stale codomain hides orphans created since the last snapshot and invents orphans for targets already retired.
- Coverage definition — what counts as "reached" (any reference, an active reference, a validated reference). Loosening it hides orphans behind dead pointers; tightening it flags targets that are covered but weakly.
- In-scope filter — which targets are exempt as legitimately-unmapped. Too permissive and real orphans are excused; too strict and every reserved slot cries orphan.
- Cadence — one-shot at cutover versus scheduled after every allocation change. Determines whether new re-slotting silently reintroduces orphans.
When it helps, and when it misleads¶
Its strength is reaching the failure that aggregate counts and collision checks are both blind to: the target that exists, is expected, and is reached by nothing. It converts "coverage looks complete" into an enumerated, locatable list of exactly what is uncovered — the honest test of the surjective claim.[n1]
Its honest failure mode is that its verdict is only as complete as its codomain: if the target set it was handed is itself missing members, those members can never be reported as orphans because the scan never knew they should exist. The classic misuse is running it against the mapping's own target list rather than an independent registry, which guarantees a clean result and proves nothing. It is also a detector, not a repairer — it can list 63 empty bins but cannot decide which to re-fill and which to decommission. The guarding discipline is to source the codomain from an authority independent of the mapping, and to schedule the scan after every membership change rather than trusting a one-time cutover pass.
How it implements the components¶
surjectivity_coverage_guard— it is the onto-side check, enumerating every target the mapping fails to reach.codomain_set_specification— it consumes and depends on an explicit closed target set; without it the scan is meaningless, so specifying the codomain is intrinsic to running it.exception_register— each orphan is logged with locating detail so the gap is repairable rather than merely counted.
It does not implement injectivity_guard — the mirror-image collision check, and the property that separates it from a duplicate-side scan — nor round_trip_test_set, owned by its test-cluster twin Round-Trip Migration Test; it only finds gaps, never collisions or loss.
Related¶
- Instantiates: Lossless Bijective Mapping Design — it is the archetype's surjectivity (coverage) detector.
- Consumes: One-to-One Crosswalk Table or another authority supplies the enumerated codomain the scan walks.
- Sibling mechanisms: Bijection Test Suite · Round-Trip Migration Test · Mapping Exception Queue · Inverse Index · ID Mapping Register · One-to-One Crosswalk Table · Reversible Encoder–Decoder Pair · Unique-Constraint Pair
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Orphan Target Scan operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a scan that detects target members with no source member mapped to them under the intended bijection.
Independent corroboration: The frozen evidence defines Orphan Target Scan as 'A scan that detects target members with no source member mapped to them under the intended bijection', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Orphan Target Scan is most directly rooted in computer science and software engineering's formal and practical treatment of computation, interfaces, data, and reliable systems. The lineage fits its defining practice: A scan that detects target members with no source member mapped to them under the intended bijection.
Related originating lineages:
- Mathematics — Orphan Target Scan also draws materially on mathematics' axiomatic study of abstract structure, relations, and formal operations, which shaped this mechanism rather than merely adopting it as an application.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Independent reviewer agreement; medium confidence.
Notes¶
[n1] A function is surjective (onto) when every member of the codomain is the image of at least one member of the domain — i.e., nothing in the target set is left unmapped. An orphan is precisely a codomain member that violates this, so the scan is the operational test of the surjective claim. ↩