Limiting-Case Test Suite¶
Test or assessment — instantiates Correspondence Violation Detection and Theory Refinement
An executable set of tests that runs the new formulation in the regimes where it should reduce to a trusted older one, and asserts the reduction holds within tolerance.
A Limiting-Case Test Suite is an executable set of tests that runs the new formulation in the specific regimes where it should collapse onto a trusted older or simpler formulation, and asserts that the reduction actually holds within tolerance. Its defining move is that it probes the frontier of correspondence by executing the new model in a limit — asking "does the new theory recover the old law where the old law is known to be right?" — rather than cataloguing expected cases or guarding known-good ones against regressions. Each test names a limit (a parameter going to zero or infinity, a special case, a low-order regime), the reduced-formulation reference it should match there, and a tolerance; a failure is a detected violation of the reduction expectation, precisely localized to the limit where it occurred.
Example¶
A new special-relativistic particle-dynamics solver must reduce to Newtonian mechanics at low velocity, v ≪ c. The Limiting-Case Test Suite runs the relativistic code at v = 0.001c, 0.01c, and 0.1c and asserts that kinetic energy, momentum, and trajectory match the Newtonian closed-form — tight (say 1e-6 relative) deep in the limit at 0.001c, with the tolerance deliberately widened at 0.1c because the ½mv² approximation is known to degrade there. It also checks the massless-particle limit and a low-field case. When a test at 0.1c shows relativistic kinetic energy departing from ½mv², that is not a bug: the tolerance schedule encodes the expected reduction envelope, so the suite reports that the code reproduces Newton where it must and departs where it should. A genuine failure — disagreement at 0.001c, where they must match — would point straight at a sign error or a units slip in the low-velocity path.
How it works¶
- Name each limit and its reference. For every correspondence limit, specify the reduced formulation it should recover and the parameter that carries the system into that limit.
- Schedule tolerances. Set a tolerance that may tighten deep in the limit and loosen near its edge, so the expected approximation error is not misread as a violation.
- Execute and assert. Run the new model at sampled points along the limit and assert |new − reduced| ≤ tolerance.
- Report failures as located violations. A failing assertion is tagged with its limit and parameter value, so the violation arrives already localized.
Tuning parameters¶
- Limit coverage — which reductions are tested. More limits give broader assurance but cost authoring and runtime.
- Tolerance schedule — fixed versus scaling with distance from the limit. A schedule tied to the known approximation order avoids both false passes and false alarms; a flat tolerance is simpler but blunter.
- Sampling density — how many points along each limit, and how close to its boundary. Sampling toward the boundary is where failures actually live; sampling only deep in the limit tests almost nothing.
- Grading — hard pass/fail versus a graded score of how cleanly the reduction holds.
When it helps, and when it misleads¶
Its strength is that it turns the correspondence principle — that a new theory must reproduce the old one in the old one's domain[1] — into an automated, standing gate, catching the class of error where a new formulation is subtly wrong exactly where it should have been safest.
Its failure mode is a tolerance set wrong in either direction: so loose that a genuinely broken limit still passes, or so tight that the expected approximation error at the edge of the limit trips the assertion and the suite cries wolf. The classic misuse is testing only deep in the limit, where nearly anything agrees, and never near the boundary where the reduction actually starts to fray — a suite that is all green and tells you nothing. The guarding discipline is to sample toward the boundary and to tie each tolerance to the known order of the approximation, so a pass means the reduction held where it was informative to check.
How it implements the components¶
The suite fills the execute-in-the-limit part of the machinery:
overlap_or_limit_regime_set— each test defines a limit or overlap regime where correspondence should hold, so the suite is an operational statement of that regime set.violation_detection_protocol— running the model and asserting the reduction is the detection procedure; a failed assertion is a recorded, localized violation.
It does not implement expected_correspondence_map or canonical_case_library — naming what-should-agree-with-what-and-why and curating the case corpus is the job of Overlap-Regime Benchmark Table. The benchmark table is the static catalog of expectations and tolerances; the suite is the executor that runs the reduction checks in the limiting regimes.
Related¶
- Instantiates: Correspondence Violation Detection and Theory Refinement — the suite is the frontier detector that turns correspondence-in-the-limit into runnable tests.
- Consumes: Overlap-Regime Benchmark Table — the expected-correspondence cases it turns into executable limit tests.
- Sibling mechanisms: Anomaly Triage Board · Assumption Audit Worksheet · Boundary Condition Memo · Expert Adjudication Panel · Failure Mode Annotation Card · Overlap-Regime Benchmark Table · Parameter Sweep Matrix · Regression Correspondence Harness · Residual Divergence Map
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Limiting-Case Test Suite operates as a bounded trial, probe, simulation, or rehearsal that generates evidence from performance because it an executable set of tests that runs the new formulation in the regimes where it should reduce to a trusted older one, and asserts the reduction holds within tolerance.
Independent corroboration: The frozen evidence defines Limiting-Case Test Suite as 'An executable set of tests that runs the new formulation in the regimes where it should reduce to a trusted older one, and asserts the reduction holds within tolerance', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Physics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: The substantive test descends from physics' correspondence principle: a new theory must recover the established one in the latter's valid limit.
Related originating lineages:
- Computer Science & Software Engineering — Executable regression suites materially turn that theoretical correspondence check into an automated artifact.
- Mathematics — Limit analysis supplies the formal reduction of a new formulation to a trusted special case.
Review resolution: Both independent reviews assign primary provenance to physics. The queued secondary differences (reported_ambiguity, alternate_origin_disagreement) are reconciled by retaining computer_science, mathematics only as formative or independently established lineage(s), not merely as application domains. origin_mode=cross_disciplinary_synthesis records the provenance relationship, while domain_reach=multi_domain separately records applicability breadth. confidence=high preserves the more cautious assessment, and encyclopedia_synthesis=true records whether either reviewer identified a corpus-specific synthesis.
Attribution caveat: The test-suite form is a software operationalization of a physics validation principle.
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.
References¶
[1] Bohr, N. The Theory of Spectra and Atomic Constitution: Three Essays. Cambridge University Press (1922). States the correspondence between quantum theory and classical electrodynamics in the limiting domain where the classical account applies. registry ↩