Correspondence Validation¶
Essence¶
Correspondence Validation is the intervention for replacing something without accidentally discarding what already worked. It asks: before a new model, system, rule, version, or theory replaces an old one, can the new candidate recover the old system's valid behavior in the domain where the old system was trusted?
The archetype is not nostalgia for legacy behavior. It allows real improvement, reform, and extension. Its key discipline is to separate three things that are often mixed together: behavior the new system must preserve, behavior it may intentionally change, and behavior that has not yet been validated. A replacement becomes safer when these distinctions are explicit before cutover.
Compression statement¶
When a new system supersedes an old one, Correspondence Validation defines the old domain of validity, compares new and old behavior in the overlap domain, classifies divergences, and uses the result to accept, revise, limit, or reject replacement.
Canonical formula: old_domain_boundary + legacy_behavior_baseline + new_candidate_representation + overlap_domain + correspondence_criterion + comparison_case_set + behavior_comparison + divergence_classification + acceptance_or_limitation_decision -> safe_replacement_or_scoped_transition
When to Use This Archetype¶
Use Correspondence Validation when a new version, model, process, policy, interface, or system is being introduced as a replacement or successor, and the older version still has a known valid domain. It is especially useful when existing users, downstream systems, legal obligations, safety guarantees, reports, or institutional expectations depend on old behavior.
It is also useful when a broader model claims to generalize an older one. The new model should be checked in the old model's limiting cases or known-success cases before its new reach is trusted. In operational settings, this often appears as parallel runs, regression suites, compatibility tests, migration acceptance tests, and exception reviews.
Do not use this archetype as a generic validation label. The defining feature is old-new overlap: there is a predecessor, a candidate replacement, and a domain in which both can be compared.
Structural Problem¶
The structural problem is replacement under incomplete continuity. A new system may be better overall, more modern, more general, or more efficient, yet still fail in cases where the old system was reliable. Because attention is often drawn toward the new capability, old-domain regressions may remain hidden until users, dependent systems, or high-stakes cases encounter them.
This problem is common when old systems are messy but valuable. They may contain tacit knowledge, edge-case handling, compatibility promises, historical conventions, or user expectations that were never fully documented. When the replacement is evaluated only on new goals, the hidden value of old behavior can disappear.
Intervention Logic¶
The intervention turns replacement into an overlap-domain test. First, state where the old system was valid. Then define the new candidate and identify cases where both old and new can be compared. Next, set a correspondence criterion: exact equality, bounded difference, preserved safety property, compatible interface, equivalent outcome, accepted approximation, or documented intentional divergence.
The comparison should examine behavior rather than labels. It may compare outputs, decisions, side effects, semantics, failure behavior, user consequences, preserved constraints, or downstream compatibility. Mismatches are then classified. Some are improvements, some are harmless changes, some are expected differences, some are unacceptable regressions, and some require more review.
The final step is to bind the evidence to a transition decision. The new system may be accepted, revised, limited to a validated scope, staged, run in parallel, or rejected. Correspondence Validation fails when it notices differences but does not govern adoption.
Key Components¶
Correspondence Validation structures replacement as an overlap-domain test rather than a blanket judgment of the new system. It begins by anchoring the predecessor: the Old Domain Boundary names where the old system was considered valid so teams cannot compare against an undefined past, and the Legacy Behavior Baseline captures what the old system actually did well enough to preserve — outputs, invariants, service guarantees, interface behaviors. The New Candidate Representation names the specific replacement under evaluation, and the Overlap Domain identifies the cases where old and new can be meaningfully compared. The Correspondence Criterion then states what counts as agreement — exact equality, bounded difference, preserved safety property, compatible interface, equivalent outcome, or documented intentional divergence — so the bar is set before any comparison occurs.
The comparison and decision components convert that setup into accountable continuity. The Comparison Case Set supplies ordinary, canonical, edge, historical, adversarial, and high-stakes cases, because a weak case set produces false confidence on happy paths while letting boundary regressions escape. The Behavior Comparison runs the candidates through those cases and examines outputs, semantics, side effects, failure behavior, and downstream consequences rather than only surface labels. The Divergence Classification then sorts the differences — acceptable extension, intended reform, harmless presentation change, tolerable approximation, unresolved anomaly, or unacceptable regression — keeping improvement and regression from being confused with each other. The Acceptance or Limitation Decision turns that classification into governance: proceed, revise, narrow scope, stage, run in parallel, or reject. Finally, the Transition Record documents where equivalence was demonstrated, which divergences remain, and where the new system should not yet be treated as equivalent, so later users inherit honest scope rather than rediscovering broken dependencies after cutover.
| Component | Description |
|---|---|
| Old Domain Boundary ↗ | defines where the predecessor was considered valid. This prevents teams from comparing against an undefined past or claiming old-domain success after the fact. |
| Legacy Behavior Baseline ↗ | captures what the old system actually did well enough to preserve, such as outputs, invariants, service guarantees, policy outcomes, or interface behavior. |
| New Candidate Representation ↗ | names the replacement being evaluated. The archetype applies to a specific successor, not to an abstract desire for improvement. |
| Overlap Domain ↗ | identifies the cases where old and new systems can be meaningfully compared. This is the testing ground for continuity. |
| Correspondence Criterion ↗ | states what counts as agreement. Some domains require exact preservation; others allow bounded or intentional difference. |
| Comparison Case Set ↗ | supplies ordinary, canonical, edge, historical, adversarial, and high-stakes cases for comparison. A weak case set produces false confidence. |
| Behavior Comparison ↗ | compares old and new behavior under the same cases. It should include semantics and consequences, not only numerical output. |
| Divergence Classification ↗ | classifies differences as acceptable, intentional, harmless, unresolved, or unacceptable. This keeps improvement and regression from being confused. |
| Acceptance or Limitation Decision ↗ | determines whether replacement proceeds, pauses, narrows, or is rejected. This component turns validation into governance. |
| Transition Record ↗ | records evidence, exceptions, limits, and accepted divergences so later users know where equivalence was demonstrated. |
Common Mechanisms¶
Backward compatibility tests implement the archetype in versioned systems. They check whether existing clients, workflows, contracts, and interfaces still behave as promised. They are mechanisms because they test one compatibility surface; they do not by themselves define the old domain, classify divergences, or decide migration scope.
Regression test suites encode previously working behavior as repeatable checks. They are excellent for executable systems, but they can become too narrow if they only preserve easy old cases. In this archetype, regression tests should be tied to the old-domain boundary and correspondence criterion.
Golden case benchmarks use trusted examples as reference anchors. They are useful when the old behavior cannot be fully formalized. Their risk is that they may preserve a small symbolic sample while missing the broader old-domain obligation.
Shadow runs or parallel runs operate old and new systems side by side before full replacement. They reveal differences under realistic conditions and are especially valuable for migrations, policy changes, data pipelines, and operational systems.
Protocol conformance tests verify that new implementations still satisfy old interface or format obligations. These implement the interoperability side of Correspondence Validation but should not be confused with Data Integrity Preservation or Source-of-Truth Assignment.
Model-limit validation checks whether a broader model recovers an older model under the older model's validity conditions. This is the closest transferable form of the correspondence-principle inspiration, but the archetype should remain an intervention pattern rather than a physics metaphor.
Migration acceptance tests and divergence review workflows connect comparison evidence to decisions. They keep validation from becoming ceremonial by deciding whether to proceed, limit, revise, or preserve a fallback.
Parameter / Tuning Dimensions¶
Important tuning dimensions include how broadly the old domain is defined, how strict the correspondence criterion is, how much tolerance is allowed, how representative the comparison case set is, and how much divergence can be accepted before rollout is limited.
Other parameters include the length of the parallel-run window, the severity classes for divergences, the retirement schedule for old behavior, the threshold for human review, the level of stakeholder involvement, and whether validation must cover semantics, downstream effects, and failure behavior in addition to direct outputs.
The stricter the tuning, the more continuity and safety the intervention preserves. The looser the tuning, the faster replacement can proceed but the more hidden regression risk remains.
Invariants to Preserve¶
The primary invariant is that known-valid old-domain behavior should not disappear unnoticed. In high-stakes settings, safety constraints, rights, compatibility promises, access guarantees, identity semantics, data definitions, appeal paths, and compliance obligations may need exact preservation unless a responsible process explicitly changes them.
Another invariant is scope honesty. Passing correspondence tests in the overlap domain does not prove the new system is valid everywhere. The draft should preserve the distinction between validated equivalence, intentional divergence, and untested extension.
Target Outcomes¶
A good Correspondence Validation intervention produces safer replacement decisions, fewer hidden regressions, clearer migration scope, stronger trust in upgrades, and better documentation of intentional changes. It allows useful innovation without forcing users to rediscover every old dependency after the cutover.
The target is not perfect sameness. The target is accountable continuity: the new system preserves what must be preserved, changes what is intentionally changed, and clearly limits what has not yet been validated.
Tradeoffs¶
The central tradeoff is continuity versus speed. Strong correspondence validation can slow upgrades, migrations, and model replacement. But skipping it can cause broken dependencies, lost rights, incorrect reports, unsafe decisions, or distrust.
A second tradeoff is exact matching versus improvement. If every divergence is treated as a failure, obsolete legacy behavior becomes frozen. If too many divergences are waved through as improvement, the replacement may destroy old-domain value. The solution is explicit divergence classification.
A third tradeoff is coverage versus cost. More cases, longer parallel runs, and deeper semantic checks provide better assurance but require more time and expertise.
Failure Modes¶
A common failure mode is narrow happy-path validation. The new system passes easy cases while failing boundary cases, legacy exceptions, or high-stakes scenarios. The mitigation is to include canonical, edge, adversarial, historical, and stakeholder-surfaced cases.
Another failure mode is compatibility theater. Tests exist, but the results do not control rollout. Correspondence Validation requires a decision rule: proceed, limit, revise, pause, or reject.
A third failure mode is frozen legacy behavior. The team preserves old behavior even when it was harmful or obsolete. The mitigation is to classify intentional reform separately from accidental regression.
A fourth failure mode is overgeneralized success. Passing old-domain tests is treated as proof that the new system works in new domains. The transition record should state the validated scope and require separate validation for extension.
Neighbor Distinctions¶
Correspondence Validation is distinct from Versioned Evolution: Versioned Evolution manages change across versions over time, while Correspondence Validation checks whether a particular replacement preserves old-domain behavior before adoption.
It is distinct from Compatibility Management: Compatibility Management may govern ongoing dependency and interoperability promises, while Correspondence Validation is the old-new overlap validation step. Because compatibility_management is not a canonical prime in the current prime list, this draft treats it as a neighbor and promotion candidate, not as a source prime.
It is distinct from Source-of-Truth Assignment: Source-of-Truth Assignment chooses authority among conflicting representations. Correspondence Validation compares predecessor and replacement behavior.
It is distinct from Data Integrity Preservation: Data integrity may be one invariant during migration, but Correspondence Validation asks whether the new system corresponds to the old system in the old valid domain.
It is distinct from Stationarity Validation: Stationarity Validation checks whether past patterns remain predictive. Correspondence Validation checks whether a new system recovers old valid behavior.
Variants and Near Names¶
Backward Compatibility Validation is the versioned-systems variant. It protects existing clients, contracts, protocols, and workflows during upgrades.
Model-Limit Correspondence is the model-transition variant. It checks whether a newer or broader model recovers the older model under limiting conditions or within the old domain of validity.
Migration Correspondence Validation is the cutover variant. It uses parallel runs, acceptance gates, and exception registers to protect continuity during data, process, policy, or platform migration.
Near names include correspondence check, old-new overlap validation, known-domain validation, replacement continuity validation, backward compatibility, regression testing, and compatibility testing. Regression tests and compatibility tests should remain mechanisms unless the surrounding governance pattern is explicitly drafted.
Cross-Domain Examples¶
In software, a new API version is validated against old clients and promised response semantics before the old API is retired. In data migration, old and new reporting systems run in parallel until key counts, definitions, cohorts, and exception cases correspond.
In policy, a new eligibility rule is run against historical cases so policymakers can distinguish intended reform from accidental exclusion. In scientific or analytic modeling, a new model is required to reproduce the older model's trusted results under the older model's limiting assumptions.
In product redesign, a new user flow is checked against previously supported accessibility, disclosure, payment, or safety behaviors. In operations, a new triage process is compared against past incidents to ensure that high-risk cases still escalate reliably.
Non-Examples¶
A brand-new system with no predecessor is not primarily a correspondence-validation case. It may need initial validation, risk assessment, usability testing, or safety review, but there is no old domain to match.
A corrupted database is not correspondence validation unless the corruption arises during old-new replacement. The primary pattern is Data Integrity Preservation or reconciliation.
A model that no longer works because the world changed is usually Stationarity Validation unless the problem is comparison with a replacement model.
A deliberately discontinuous reform may use correspondence validation to document what is being broken, but the target is not preservation of old-domain behavior.