Case-Based Mapping Test¶
Validation procedure — instantiates Schema Conflict Resolution
Runs a curated set of ordinary, edge, and high-consequence cases through a proposed mapping to expose the false equivalences and unresolved ambiguities that abstract agreement hides.
A crosswalk that everyone nodded at in a meeting can still fall apart on the first hard case. Case-Based Mapping Test is the empirical check that puts the proposed resolution under load: it assembles a deliberate set of real cases — the everyday ones, the ugly edge ones, and the false friends that look identical but aren't — and pushes each through the mapping to see where it breaks. Its defining idea is that agreement in the abstract is worthless until specific cases confirm it; the test's product is not the mapping but a verdict on the mapping, plus a logged residue of cases the mapping still cannot decide.
Example¶
Two auto insurers merge, and their claims systems must agree on a single severity classification. One uses a five-tier "impact" scale driven by estimated repair cost; the other uses a reserve tier driven by expected total payout including injury exposure. On paper the two scales look alignable — tier for tier. The mapping test pulls forty real closed claims spanning the range and runs each through the proposed correspondence. Most map cleanly. But a cluster of low-repair-cost, high-injury claims — a minor fender-bend with a serious whiplash claim behind it — lands in "moderate" under the repair-cost scale and "severe" under the reserve scale. That is a false equivalence the tier-for-tier table concealed. The test flags these as mismatch cases, records that the proposed mapping fails them, and logs the injury-exposure ambiguity as unresolved so a later rule can address it rather than pretending it is handled.
How it works¶
- Curate for coverage, not volume. The case set is chosen to span ordinary, boundary, and high-consequence situations, and to deliberately include suspected false friends — not a random sample.
- Run each case both ways. Classify each case under each schema independently, then check whether the proposed correspondence would have produced the same answer.
- Sort the failures. Disagreements become mismatch cases, tagged by whether they reveal a partial correspondence, a missing exception, or an outright non-equivalence.
- Log the residue. Cases the mapping cannot resolve are recorded as open ambiguities rather than force-fit, so the resolution's honest coverage is visible.
Tuning parameters¶
- Case-set breadth — how many and how varied the cases are. Wider coverage catches more false equivalences but costs curation effort; a partitioned set that samples each behavior class beats sheer count.
- Adversarial weighting — how deliberately the set hunts false friends versus confirming the easy majority. More adversarial sets are harsher and more informative.
- Pass criterion — what counts as failing: any divergence, or divergence above a consequence threshold. Stricter criteria catch more but can stall a workable mapping on rare cases.
- Residue tolerance — how many unresolved cases the resolution may carry forward, and to whom they are handed.
When it helps, and when it misleads¶
Its strength is that it converts "this mapping looks right" into "this mapping survived these specific hard cases," and it is the archetype's direct antidote to crosswalk theater — a table nobody ever tested. Using a set that partitions the space into equivalence classes and samples each is what makes a modest case count credible rather than anecdotal.[n1]
Its failure mode is coverage blindness: the test can only fail cases it thought to include, so a mapping that passes a weak set inherits false confidence. The classic misuse is stacking the set with easy, representative cases and skipping the awkward boundary ones — producing a green light that means only "we didn't look where it breaks." The guarding discipline is to build the set adversarially, weight high-consequence and false-friend cases heavily, and treat a clean pass on a thin set as untested, not validated.
How it implements the components¶
mismatch_case— each divergence surfaced by a run becomes a recorded mismatch case, tagged by the kind of correspondence failure it reveals.validation_case_set— the curated, coverage-spanning set of cases is the validation instrument, reusable whenever the mapping changes.residual_ambiguity_log— cases the mapping cannot resolve are logged as open ambiguities instead of being silently forced.
It does not itself test whether meaning survives a live technical exchange (exception_handling_path) — that is Semantic Interoperability Review — and it neither authors translation rules (translation_rule) nor assigns their upkeep (semantic_owner), which belong to Translation Register.
Related¶
- Instantiates: Schema Conflict Resolution — provides the empirical validation that a proposed correspondence actually holds against real cases.
- Consumes: Schema Crosswalk Table — supplies the proposed correspondence this test puts under load.
- Sibling mechanisms: Boundary-Spanner Review Session · Data Mapping Specification · Glossary Alignment Table · Ontology Mapping Workshop · Schema Crosswalk Table · Semantic Interoperability Review · Taxonomy Reconciliation Review · Translation Register
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Runs a curated set of ordinary, edge, and high-consequence cases through a proposed mapping to expose the false equivalences and unresolved ambiguities that abstract agreement hides, making its operative form a bounded trial, probe, simulation, or adversarial exercise that generates evidence from performance.
Independent corroboration: The frozen evidence defines Case-Based Mapping Test as 'Runs a curated set of ordinary, edge, and high-consequence cases through a proposed mapping to expose the false equivalences and unresolved ambiguities that abstract agreement hides', so its operative form is Experiment, Test & Rehearsal.
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: Software testing supplies equivalence classes, boundary cases, and representative case suites for validating a proposed mapping against concrete behavior.
Related originating lineages:
- Linguistics & Semiotics — Translation and semantic mapping supply false-equivalence and unresolved-ambiguity judgments.
- Statistics & Experimental Design — Sampling design contributes ordinary, edge, and high-consequence coverage without exhaustive testing.
Review resolution: Software testing is primary because the method validates a schema crosswalk with representative and boundary cases, equivalence classes, and expected outcomes. Statistics and linguistic or library classification supply sampling and semantic-mapping disciplines, so the artifact is a cross-disciplinary synthesis with multi-domain reach.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Equivalence partitioning is a software-testing technique that divides the input space into classes expected to behave alike, then tests one representative per class plus the boundaries between them — the logic behind curating a small case set for coverage rather than testing exhaustively. ↩