Comparative Benchmark Validation

batch: Second Iteration/Batch 04

aliases:
benchmark validation
reference standard comparison
gold-standard validation
baseline comparison validation
comparator-anchored validation
performance benchmarking validation
state-of-the-art comparison
predicate comparator validation

slug: validation

slug: calibration

slug: confounding

slug: randomization

slug: uncertainty

slug: decision

slug: trust

slug: overfitting

components:
Validation Claim Definition
Reference Standard or Comparator Set
Benchmark Task or Case Suite
Comparability Protocol
Acceptance Margin or Decision Threshold
Performance Measurement Bundle
Uncertainty and Error Analysis
Discrepancy Investigation Loop
Benchmark Relevance Review
Stratified Subgroup Benchmarks
Adversarial or Stress Benchmark
Expert-Adjudicated Reference Panel
Competitor or Status-Quo Baseline
Benchmark Refresh Cadence
Blinded Evaluator Assignment

mechanisms:
Gold-Standard Comparison Study
State-of-the-Art Baseline Study
Noninferiority Margin Protocol
Held-Out Benchmark Dataset
Benchmark Suite Coverage Matrix
Paired Comparison Experiment
Expert-Adjudicated Reference Panel
Benchmark Refresh Audit

essence_one_line: Validate a claim by comparing the system against explicit reference standards, gold standards, incumbent alternatives, competitors, or benchmark suites under conditions that make the comparison meaningful.

compression_statement: A comparator-anchored validation pattern that converts an isolated performance claim into a structured comparison: define what is being claimed, choose a legitimate benchmark or reference, align tasks/populations/conditions, measure both sides with equivalent procedures, quantify uncertainty and decision margins, investigate discrepancies, and decide whether the claim is supported, limited, revised, or rejected.

core_intuition: A result is hard to interpret by itself. Accuracy, speed, safety, usefulness, or quality only become decision-relevant when tied to a reference frame: what a competent existing method achieves, what a gold standard says, what the status quo delivers, or what a benchmark suite represents. The intervention works by replacing vague “good performance” with an auditable comparison whose comparator, conditions, thresholds, and uncertainty are visible.

canonical_formula: Benchmark validation ≈ claim definition + explicit comparator + matched measurement + acceptance margin + uncertainty analysis + discrepancy review + decision update.

structural_problem: A system, model, process, product, intervention, or claim is judged in isolation, against an implicit standard, or against a selectively chosen baseline. Without an explicit and legitimate comparator, stakeholders cannot tell whether the observed performance is adequate, superior, equivalent, misleadingly framed, or merely better than a weak alternative.

trigger_conditions: A party claims that a system is accurate, safe, robust, efficient, useful, compliant, equivalent, non-inferior, state-of-the-art, or ready to replace an incumbent.

trigger_conditions: A reference standard, gold standard, accepted incumbent, competitor baseline, benchmark dataset, case suite, or standard-of-care alternative exists or can be constructed.

trigger_conditions: The raw metric is uninterpretable without comparison because task difficulty, population mix, operating conditions, or measurement method affects the result.

trigger_conditions: Stakeholders must decide adoption, approval, deployment, publication, procurement, replacement, certification, or escalation.

trigger_conditions: Multiple alternatives are plausible, and the choice depends on relative rather than absolute performance.

trigger_conditions: Performance may vary across subgroups, regimes, scenarios, tasks, or use conditions, so a single undifferentiated score is insufficient.

trigger_conditions: Prior evaluation has relied on internal tests, convenience examples, self-selected metrics, or unverified claims.

trigger_conditions: The cost of false validation is high enough that an auditable external reference frame is needed.

symptoms: Reports say a result is “good,” “high,” “improved,” or “state of the art” without naming the comparator.

symptoms: Teams compare against a weak baseline while ignoring stronger available alternatives or the actual status quo.

symptoms: Benchmarks are selected after results are known, making the validation frame look better than it is.

symptoms: Different teams use different reference standards, so reported performance cannot be reconciled.

symptoms: A system performs well on a public benchmark but fails on real operating cases or protected subgroups.

symptoms: Stakeholders argue about whether a metric is enough because no pre-specified acceptance margin exists.

symptoms: Replacement decisions focus on novelty or headline scores rather than practical equivalence, safety, or robustness against incumbent options.

symptoms: Discrepancies between the new system and the reference are treated as errors by the new system or the reference without investigation.

root_tension: Validation needs a stable reference frame, but reference frames can be wrong, stale, gamed, selectively chosen, or mismatched to the actual decision. The intervention must make the comparator strong enough to discipline the claim without letting the benchmark become a misleading substitute for real-world judgment.

anti_signatures: No meaningful comparator, reference, baseline, or benchmark can yet be specified; exploratory discovery or concept formation is the real task.

anti_signatures: The issue is whether a pattern generalizes to unseen settings rather than whether it performs relative to a comparator; use generalization_validation as the nearer neighbor.

anti_signatures: The issue is whether a new theory or system recovers an older one in a known overlap regime; use correspondence_validation as the nearer neighbor.

anti_signatures: The problem is internal consistency of a story, model, or theory rather than external performance comparison.

anti_signatures: The benchmark is known to be irrelevant, leaked, heavily optimized against, or unrelated to the use context.

anti_signatures: A single compliance checklist or leaderboard ranking is being mistaken for validation without comparability, uncertainty, and discrepancy analysis.

anti_signatures: Safety, ethics, or regulatory approval requires multiple validation modes; benchmark comparison alone would create false assurance.

anti_signatures: The comparator would expose confidential, personal, or protected data without a legitimate need and safeguards.

structural_intervention: Install a comparator-anchored validation loop: specify the claim, select and justify the benchmark or reference standard, align comparison conditions, measure performance with equivalent protocols, interpret results through pre-specified margins and uncertainty, investigate mismatches, and translate the comparison into an adoption, revision, limitation, or rejection decision.

action_logic: State the validation claim precisely: what quality is claimed, for whom, under what conditions, and for what decision.

action_logic: Identify candidate comparators: gold standard, reference measurement, accepted standard, status quo, standard care, competitor, state-of-the-art baseline, benchmark suite, or adjudicated case panel.

action_logic: Justify comparator legitimacy by checking domain relevance, authority, recency, quality, measurement independence, and decision fit.

action_logic: Define the comparison frame: tasks, populations, cases, units, operating conditions, measurement timing, resources, constraints, and failure definitions.

action_logic: Pre-specify acceptance logic: superiority, noninferiority, equivalence, threshold satisfaction, safety margin, robustness margin, or decision-specific tradeoff.

action_logic: Measure the candidate and comparator using matched or explicitly normalized procedures so differences are not artifacts of test conditions.

action_logic: Quantify uncertainty, measurement error, sample representativeness, subgroup performance, and possible confounding in the comparison.

action_logic: Investigate discrepancies rather than automatically assuming either the candidate or reference is correct.

action_logic: Translate results into bounded conclusions: validated, conditionally validated, equivalent only in specified regimes, not yet validated, or invalidated.

action_logic: Record comparator choice, assumptions, data provenance, benchmark limitations, and update triggers so future users can audit or revise the validation frame.

decision_rules: Use the highest-authority reference standard only when it matches the practical target and its own uncertainty is understood.

decision_rules: Use the actual incumbent or status quo when the decision is replacement, procurement, adoption, or policy change.

decision_rules: Use strong competitor or state-of-the-art baselines when the claim is comparative superiority.

decision_rules: Use a benchmark suite rather than a single case when domain coverage, subgroup behavior, or failure-mode diversity matters.

decision_rules: Predefine margins before outcome inspection; post-hoc margins convert validation into rationalization.

decision_rules: Disaggregate results when aggregate benchmark success could hide subgroup, regime, or edge-case failure.

decision_rules: Reject a benchmark result as sufficient if the benchmark has been leaked, gamed, overfit, or rendered obsolete by domain shift.

decision_rules: Escalate to multiple validation modes when benchmark comparison is necessary but not sufficient for high-stakes deployment.

target_invariants: The comparator is explicit, justified, and decision-relevant.

target_invariants: The comparison conditions are equivalent or differences are openly normalized.

target_invariants: Acceptance thresholds and margins are pre-specified where possible.

target_invariants: Uncertainty, error, and benchmark limitations remain visible.

target_invariants: The validation conclusion is bounded to the tested conditions and comparator frame.

target_invariants: Subgroup, edge-case, and regime-specific failures are not hidden by aggregate scores.

target_invariants: Benchmark success does not substitute for ethical, safety, or real-world monitoring obligations.

target_invariants: The benchmark can be refreshed when standards, populations, tasks, or operating conditions change.

expected_outcomes: Performance claims become interpretable and auditable.

expected_outcomes: Weak, cherry-picked, or irrelevant baselines are exposed before adoption decisions.

expected_outcomes: Replacement and approval decisions can distinguish superiority, equivalence, noninferiority, and failure.

expected_outcomes: Discrepancies reveal whether the candidate, comparator, measurement process, or domain assumptions need revision.

expected_outcomes: Benchmark overfitting and false precision are easier to detect.

expected_outcomes: Stakeholders can communicate validation scope without overstating what was proven.

expected_outcomes: Future revalidation has clear triggers when comparators or domains drift.

prose_essence:
Comparative Benchmark Validation is the pattern of making a claim meaningful by anchoring it to an explicit comparator. A system may look impressive in isolation, but validation asks: compared with what, under which conditions, against which standard, and with what margin of uncertainty? The comparator may be a gold standard, a standard-care alternative, an incumbent process, a state-of-the-art method, a competitor, or a curated benchmark suite.

This archetype is not merely “run a benchmark.” It is the complete reasoning loop that makes benchmark evidence decision-worthy: define the claim, choose and justify the comparator, make conditions comparable, predefine acceptance logic, measure uncertainty, investigate discrepancies, and bound the conclusion.

prose_tradeoffs: Benchmark validation trades off relevance against comparability. A standardized benchmark allows clean comparisons but may poorly represent the actual use case. A deployment-like benchmark may be realistic but harder to reproduce. Stable benchmarks support longitudinal comparison, while refreshed benchmarks better track changing domains. Public benchmarks enable scrutiny but can become targets for optimization and leakage.

Gold-Standard Validation

short_definition: Validate a method, diagnosis, classifier, process, or claim by comparing it against the most authoritative available reference standard.

distinctive_feature: The comparator is treated as a high-authority reference rather than merely another baseline.

distinct_from_parent: The parent includes competitor, status-quo, reference-panel, and benchmark-suite comparisons; this variant specifically uses a privileged standard as the anchor.

still_same_parent_because: The intervention remains comparator-anchored validation: define the claim, choose the reference, align conditions, compare results, and interpret discrepancies.

use_when: A widely accepted reference standard exists or can be constructed through expert adjudication.

use_when: The new system claims accuracy, equivalence, or improvement against a known target.

use_when: Stakeholders need a non-circular anchor rather than internal self-assessment.

example_domains:
diagnostic medicine
laboratory measurement
forensic testing
model evaluation

domain: Diagnostics

example: A rapid test is evaluated against a clinician-adjudicated diagnosis or laboratory gold standard.

domain: Measurement

example: A field instrument is validated against a calibrated reference instrument.

failure_modes: The gold standard is itself noisy, biased, outdated, or misaligned with the practical decision.

name: Status-Quo or Standard-Care Benchmarking

short_definition: Validate a proposed replacement by comparing its outcomes against the current standard practice, standard care, incumbent process, or realistic no-change alternative.

distinctive_feature: The benchmark is the real existing alternative, so validation is tied to adoption or replacement decisions.

distinct_from_parent: The parent covers any explicit reference benchmark; this variant uses the incumbent option as the comparator.

still_same_parent_because: It still relies on a defined comparator, comparable measurement, acceptance margin, and discrepancy interpretation.

use_when: A new intervention is proposed as a practical replacement rather than an abstract improvement.

use_when: The relevant question is whether the alternative beats or matches what users actually have now.

use_when: A placebo, no-treatment, or idealized comparator would not answer the adoption decision.

example_domains:
clinical trials
education programs
operations improvement
public policy

domain: Clinical care

example: A new care pathway is compared with standard care on equivalent patients and endpoints.

domain: Operations

example: An automation workflow is compared against the existing manual workflow on speed, error, and rework.

failure_modes: The status quo is misrepresented, weakly measured, or selected to make the new option look better.

name: Competitor or State-of-the-Art Benchmarking

short_definition: Validate relative performance by comparing against leading alternatives, competitor baselines, or state-of-the-art methods under matched conditions.

distinctive_feature: The comparator is an active rival or best-known alternative, making validation relative and decision-oriented.

distinct_from_parent: The parent includes gold standards and status quo comparators; this variant emphasizes competitive alternatives and state-of-field baselines.

still_same_parent_because: The structure remains a benchmark-anchored validation loop with explicit comparator, matched measurement, and threshold interpretation.

use_when: Claims are comparative: better, faster, safer, cheaper, more accurate, or more robust than alternatives.

use_when: Users choose among competing systems rather than evaluating a system in isolation.

use_when: A field already has accepted baseline models, products, processes, or reference implementations.

example_domains:
machine learning
software tools
product testing
industrial process design

domain: Machine learning

example: A model is compared against strong baselines on the same held-out datasets and compute assumptions.

domain: Product testing

example: A battery is tested against market-leading alternatives under the same duty cycle.

failure_modes: Weak baselines, unreproduced competitor settings, or obsolete alternatives make the claim misleading.

name: Noninferiority or Equivalence Benchmark Validation

short_definition: Validate that a new option is close enough to an accepted comparator within a pre-specified margin rather than necessarily superior.

distinctive_feature: The decision threshold is a tolerated difference from the comparator, not simple superiority.

distinct_from_parent: The parent allows many pass/fail interpretations; this variant centers the acceptance margin.

still_same_parent_because: It depends on the same explicit comparator, matched measurement, and uncertainty-aware interpretation.

use_when: The new option offers secondary benefits such as lower cost, easier deployment, access, safety, speed, or convenience.

use_when: The central claim is “not meaningfully worse” or “practically equivalent.”

use_when: A clear margin can be justified before looking at outcomes.

example_domains:
clinical trials
medical devices
software migration
process replacement

domain: Clinical trial

example: A simpler treatment is accepted if outcomes are not worse than standard care beyond a justified margin.

domain: Software migration

example: A new storage system is accepted if reliability remains equivalent while maintenance cost falls.

failure_modes: Margins are chosen after the fact or set so wide that real harm is hidden.

Benchmark-Suite Validation

short_definition: Validate performance across a curated set of tasks, cases, scenarios, or datasets intended to represent the decision domain.

distinctive_feature: The comparator anchor is a structured suite rather than one reference case or one competitor.

distinct_from_parent: The parent includes single reference standards, direct competitor baselines, and status quo comparators; this variant emphasizes case-set construction and coverage.

still_same_parent_because: It still validates by comparing observed performance to an explicit reference frame under controlled comparability rules.

use_when: No single case or reference measurement represents the domain adequately.

use_when: Validation needs breadth across task types, conditions, populations, or failure modes.

use_when: A benchmark suite can be shielded from leakage, cherry-picking, and overfitting.

example_domains:
machine learning
education assessment
cybersecurity testing
simulation validation

example: A model is evaluated across a held-out suite of reasoning, robustness, and safety tasks.

domain: Cybersecurity

example: A detector is validated against a suite of known attack families and benign traffic cases.

failure_modes: The suite becomes stale, leaked, unrepresentative, or over-optimized.

near_names:
Benchmark Validation
Reference Standard Comparison
Gold Standard Comparison
Baseline Comparison Validation
State-of-the-Art Benchmarking
Predicate Comparator Validation


Compatibility Management

type: archetype

source: generated

batch: First Iteration/Batch 15/Wave 2

source_primes: versioning interoperability

related_primes: continuity coupling boundary indirection state_and_state_transition data_integrity constraint fault_tolerance accountability observability adaptation

slug: versioning

slug: interoperability

slug: continuity

slug: coupling

slug: boundary

slug: indirection

slug: constraint

slug: accountability

slug: observability

slug: adaptation

components:
Compatibility Rule
Version Relationship Matrix
Support Window
Migration Path
Deprecation Policy
Adapter or Translation Layer
Breaking Change Boundary
Compatibility Test Scope
Dependency Exposure Map
Fallback or Graceful Degradation Rule
Protocol Negotiation Rule
Exception and Waiver Path

mechanisms:
Backward Compatibility Policy
Semantic Versioning
API Versioning
Schema Migration
Protocol Negotiation
Rolling Upgrade
Migration Guide
Compatibility Matrix
Adapter Layer
Compatibility Test Suite
Support Lifecycle Schedule

essence_one_line: Manage how old and new versions interact so change does not break dependent systems or users.

compression_statement: When versions evolve at different speeds, manage compatibility windows, migration rules, and deprecation paths to preserve continuity during change.

core_intuition: Change becomes safer when the relation between versions is treated as a governed interface, not as an afterthought. Compatibility management accepts that different actors may legitimately occupy different versions for a while, then defines how they can interact, migrate, degrade safely, or stop interacting without surprise breakage.

canonical_formula: evolving_versions + active_dependencies + explicit compatibility relation + migration/deprecation governance -> continuity under change

structural_problem: Different actors, systems, or components use different versions, and unmanaged version differences create failure or fragmentation.

trigger_conditions: Old and new versions, rules, schemas, products, or workflows must coexist in the same ecosystem.

trigger_conditions: Dependents cannot all migrate at the same moment because of cost, timing, authority, risk, or unequal capacity.

trigger_conditions: A proposed change may break existing integrations, obligations, records, workflows, expectations, or users.

trigger_conditions: Different actors interpret the same artifact through different version assumptions.

trigger_conditions: Support for older versions is costly but sudden removal would create unacceptable harm or disruption.

symptoms: Users or dependent systems break after a change that seemed local to the version owner.

symptoms: Teams cannot tell which version combinations are supported, tolerated, deprecated, or forbidden.

symptoms: Legacy users are stranded, while maintainers remain trapped by indefinite support obligations.

symptoms: Adapters, workarounds, and informal exceptions accumulate without a governing compatibility policy.

symptoms: Migration guidance exists, but no one knows when old behavior can safely be retired.

symptoms: New features are blocked because the ecosystem lacks a safe way to handle mixed-version operation.

root_tension: Evolution creates pressure to change, simplify, and improve, while dependency creates pressure to preserve old meanings, interfaces, records, and expectations. Compatibility management resolves the tension by designing an explicit relationship between versions rather than treating old and new states as isolated artifacts.

anti_signatures: There is only one version in use and no dependent actor, record, rule, or system needs to interact with another version.

anti_signatures: The main problem is simply documenting change history; use Versioned Evolution when interaction across active versions is not central.

anti_signatures: The main problem is recovering from a failed change; use Checkpoint and Rollback when the key intervention is returning to a known-good state.

anti_signatures: The main problem is parallel divergence and later recombination; use Branching and Merging when merge rules are central.

anti_signatures: The supposed compatibility issue is only a one-off conversion task with no recurring coexistence, support, or breakage-governance problem.

structural_intervention: Define compatibility rules, migration paths, deprecation policy, support windows, and translation or adapter behavior.

action_logic: Identify the active versions, dependents, interfaces, records, obligations, or workflows that may need to coexist.

action_logic: Map the compatibility relation: which pairings are supported, conditional, deprecated, unsupported, or unsafe.

action_logic: Expose breaking-change boundaries before releasing change, including hidden dependencies and semantic expectations.

action_logic: Define support windows and deprecation policy so continuity and end-of-support are both explicit.

action_logic: Provide migration paths, adapters, translation layers, negotiation rules, or fallback behavior where direct compatibility is not feasible.

action_logic: Test or review the version combinations that will actually coexist, not just the new version in isolation.

action_logic: Monitor adoption, exceptions, failures, and support debt, then revise the compatibility policy as the ecosystem evolves.

decision_rules: Promote to this archetype when the main risk is failure of interaction across active versions or dependent systems, not merely incomplete version records.

decision_rules: A version combination should be marked supported only when its semantics, obligations, and operational behavior are known enough to rely on.

decision_rules: A breaking change should require notice, migration path, compatibility test scope, and an explicit acceptance of residual breakage risk.

decision_rules: Support windows should be long enough for realistic migration but bounded enough to prevent indefinite hidden maintenance burden.

decision_rules: Adapters and translation layers should be used when they reduce ecosystem disruption without concealing semantic loss or creating an ungoverned second source of truth.

decision_rules: Deprecation should not be treated as complete until dependent exposure, exception paths, and retirement criteria have been reviewed.

target_invariants: Supported version combinations are explicit and discoverable.

target_invariants: Old and new versions do not interact under false assumptions about meaning, format, authority, safety, or obligation.

target_invariants: Users and dependent systems receive enough notice and migration support to avoid surprise breakage.

target_invariants: Compatibility commitments are bounded by clear scope, time, and evidence rather than informal promises.

target_invariants: Adapters, migrations, and translations preserve required meaning and integrity or surface where they cannot.

target_invariants: Deprecation and end-of-support are governed events, not accidental abandonment.

expected_outcomes: Fewer breaking changes and fewer stranded dependent actors.

expected_outcomes: Clearer tradeoffs between innovation, support burden, continuity, and ecosystem fragmentation.

expected_outcomes: Safer mixed-version operation during migrations, rollouts, policy changes, and standard revisions.

expected_outcomes: More predictable deprecation and retirement of old behavior.

expected_outcomes: Better evidence about which version combinations work, fail, or require special handling.

expected_outcomes: Reduced reliance on informal workarounds, hidden adapters, and unbounded legacy exceptions.

prose_essence:
Compatibility Management is the archetype for keeping change from breaking the ecosystem around it. It applies when old and new versions, rules, procedures, products, schemas, or interfaces must coexist long enough for dependent actors to keep functioning. The intervention is not simply to record that version A came before version B. It is to define whether A and B can interact, who is supported, how migration happens, what gets deprecated, and what counts as unacceptable breakage.

The core intuition is that versions are relational. A new version may be internally coherent and still fail because it collides with older clients, legacy records, prior obligations, or users who cannot migrate instantly. Compatibility management makes that relation explicit.

prose_when_to_use:
Use this archetype when a change creates mixed-version operation. This can happen when a technical platform changes an API, an institution updates policy, a product line introduces a new generation, a data team changes a schema, a curriculum updates requirements, or a legal template is revised while older commitments remain active.

The strongest signal is dependency mismatch: one part of the system changes faster than another part that relies on it. The archetype is especially useful when sudden cutover would strand users, corrupt data, invalidate obligations, break integrations, or destroy trust.

Do not use it merely because something has a version number. If the main need is lineage, provenance, or comparison over time, use **Versioned Evolution**. If the main need is recovery from a failed change, use **Checkpoint and Rollback**. If the main need is parallel divergence and recombination, use **Branching and Merging**.

prose_structural_problem:
The structural problem is unmanaged coexistence. Different actors, artifacts, or systems occupy different versions, but the relationship among those versions is implicit. One team may assume everyone has upgraded. Another may depend on old behavior. A third may use a transitional workaround that no one has tested. The system then fails not because any one version is incoherent, but because interaction across versions is underdesigned.

This creates several recurring symptoms: breaking changes appear as surprises, old versions become indefinite maintenance burdens, support commitments are unclear, migration is postponed until crisis, and adapters or workarounds accumulate outside governance.

prose_intervention_logic:
Compatibility Management intervenes by turning old-new interaction into an explicit design object. First, identify the active versions and the dependents attached to each. Then define which version pairings are supported, conditional, deprecated, or unsafe. Next, expose breaking-change boundaries and design support windows, migration paths, adapters, negotiation rules, or fallback behavior. Finally, verify the combinations that will actually coexist and revise the compatibility policy as adoption changes.

The intervention is successful when no one has to infer compatibility from hope, habit, or informal memory. Supported combinations are named. Unsupported combinations are named. Transition paths are visible. Retirement of old support is planned rather than accidental.

prose_key_components:
### Compatibility Rule

A compatibility rule states which versions, actors, interfaces, records, or procedures can safely interact. It may define full compatibility, partial compatibility, conditional compatibility, or explicit incompatibility. Without this rule, compatibility becomes a vague promise rather than a governed relationship.

### Version Relationship Matrix

The version relationship matrix maps old, current, future, and exceptional versions against each other. It need not always be a literal table, but the system needs a way to reason about combinations: v1 client with v2 server, old form with new eligibility rules, legacy product with new accessory, or previous contract term with current amendment.

### Support Window

A support window defines how long, or under what conditions, older versions remain supported. It protects dependents from sudden abandonment while preventing legacy support from becoming endless by default.

### Migration Path

A migration path explains how dependents move from one version to another. It may include conversion rules, phased rollout, training, communication, data transformation, or legal transition provisions. Migration path design is where compatibility becomes actionable.

### Deprecation Policy

Deprecation policy announces how old versions will lose support. It should include notice, alternatives, timelines, and exception handling. A deprecation policy is not simply a warning; it is the governance of safe retirement.

### Adapter or Translation Layer

An adapter or translation layer bridges incompatible versions. It might translate data formats, route old requests to new behavior, map old policy categories to new ones, or mediate between procedures. Adapters are useful, but they can also hide semantic loss, so they need ownership and tests.

### Breaking Change Boundary

A breaking change boundary identifies where a change invalidates existing assumptions. It surfaces hidden dependencies before they become failures. In legal, policy, or institutional settings, the boundary may involve rights, obligations, or interpretation rather than technical interfaces.

### Compatibility Test Scope

Compatibility test scope defines what must be verified before a compatibility claim is trusted. It should cover real coexistence cases, edge cases, and high-risk dependencies rather than only testing the new version in isolation.

prose_common_mechanisms:
**Backward compatibility policies** require newer versions to continue accepting older inputs, clients, records, or expectations for a defined period. They implement the archetype by protecting legacy dependents while migration proceeds.

**Semantic versioning** signals expected compatibility through version numbers. It is useful as a communication mechanism, but it is not the archetype itself because a version number cannot guarantee support, migration, or evidence.

**API versioning** exposes multiple interface versions so clients can move at different speeds. This is a domain-specific mechanism for the broader old-new interaction problem.

**Schema migration** transforms data or classifications from one version to another. It implements compatibility when records, analytics, or workflows need to survive structural change.

**Protocol negotiation** lets parties discover a mutually supported version or mode before interacting. It is valuable when compatibility cannot be assumed in advance.

**Rolling upgrades** gradually introduce change while old and new versions coexist. They depend on compatibility management because mixed-version states must be safe during rollout.

**Migration guides** help dependent actors move from old to new. They make the compatibility policy usable rather than merely declared.

**Compatibility matrices** display supported and unsupported combinations. They are representation artifacts, not the archetype itself.

**Adapter layers** mediate incompatible versions or formats. They are powerful but risky if they obscure meaning loss or become unmanaged sources of truth.

**Compatibility test suites** verify that the declared compatibility relation holds in practice.

prose_failure_modes:
A common failure mode is the **silent breaking change**, where hidden dependencies were never mapped and old users discover breakage only after release. Another is **infinite legacy support**, where old versions persist because no one defined retirement criteria. A third is the **false compatibility promise**, where versions are labeled compatible even though their semantics differ in important edge cases.

Adapters can drift into unmanaged infrastructure. Deprecation can happen too early and strand dependents. Compatibility can also become paralysis, blocking needed evolution because any change might break someone. The mitigation is explicit scope, support windows, migration evidence, breaking-change review, and honest classification of partial or conditional compatibility.

prose_neighbor_distinctions:
**Versioned Evolution** tracks and governs change lineage. Compatibility Management governs safe interaction across active versions. A changelog is not enough when old and new must coexist.

**Checkpoint and Rollback** prepares a return path after failure. Compatibility Management tries to prevent mixed-version breakage during normal evolution.

**Branching and Merging** governs parallel divergence and recombination. Compatibility Management governs interaction among versions, even when there is no branch to merge.

**Mapping Reconciliation** aligns different representations. Compatibility Management may use mapping reconciliation, but it adds support windows, deprecation, migration, and breakage governance.

**Decoupling via Interface** is a neighboring idea and a proposed prime-like concept in this draft. Compatibility Management may use interface decoupling, but it is specifically about cross-version coexistence and support.

prose_cross_domain_examples:
In software, an API provider can support old and new endpoints while publishing migration guides and compatibility tests. In data governance, a schema migration can preserve old fields during a support window while downstream dashboards migrate. In public policy, old and new eligibility rules can coexist through transitional provisions. In product operations, parts and accessories can be marked compatible or incompatible across generations. In education, old and new curriculum standards can be bridged so students are not stranded mid-program. In legal drafting, amendments can specify how prior obligations interact with revised clauses.

Across all examples, the common structure is not software-specific. A change creates multiple active versions, and the solution is to govern their relationship.

prose_non_examples: A simple changelog is not Compatibility Management if no old-new interaction must be supported. A one-time conversion script is not the archetype if there is no continuing coexistence or support policy. A rollback plan is not compatibility management if the response to failure is simply to return to a known-good state. A branch merge is not compatibility management if the core problem is recombining divergent work rather than supporting mixed-version interaction.

prose_tradeoffs:
The archetype trades simplicity for continuity. Supporting multiple versions increases maintenance burden, test scope, documentation needs, and decision complexity. It can also preserve harmful legacy assumptions if deprecation is too timid.

At the same time, refusing compatibility can shift the cost of change onto dependents who lack power or capacity. The art is to preserve enough continuity for legitimate dependence while making old support bounded, visible, and reviewable.

prose_invariants_to_preserve:
The central invariant is that supported interactions should not surprise participants. If a version combination is supported, it should preserve required meaning, safety, integrity, authority, and obligation. If it is unsupported, that fact should be visible before harm occurs.

Other invariants include discoverability of support status, boundedness of compatibility commitments, migration feasibility, accountability for adapters, and transparent deprecation. Compatibility management should preserve continuity without pretending that every old behavior deserves indefinite preservation.

prose_target_outcomes:
The desired outcomes are fewer breaking changes, safer migration, clearer support commitments, reduced legacy ambiguity, and more predictable evolution. Done well, compatibility management lets a system change without forcing every dependent actor to move at the exact same moment.

It also improves trust. Users, clients, institutions, and dependent teams can plan because they know what will keep working, what will stop working, and how to move.

prose_parameter_dimensions:
Compatibility management has several tunable dimensions. The **breadth of support** determines how many versions or combinations remain supported. The **duration of support** determines how long old versions persist. The **strictness of compatibility** determines whether compatibility means full equivalence, partial function, safe degradation, or merely non-corruption. The **migration burden** determines how much work is placed on maintainers versus dependents. The **adapter depth** determines whether compatibility is achieved through shallow translation, deep semantic mapping, or direct shared behavior. The **deprecation threshold** determines what evidence is needed before old support can end.

Tuning is not purely technical. Longer support windows can be more equitable but more expensive. Strict compatibility can preserve trust but delay necessary change. Fast deprecation can reduce maintenance burden but strand actors with less capacity to migrate.

prose_variants_and_near_names:
Important recognized variants include **Backward Compatibility Management**, which protects old dependents from new-version breakage; **Forward Compatibility Management**, which helps older versions tolerate future extensions; **Adapter-Mediated Compatibility**, which uses translation or wrapper layers; **Migration Window Compatibility**, which bounds compatibility to a transition period; and **Negotiated Protocol Compatibility**, which selects a mutually supported mode at interaction time.

Near names include compatibility governance, version compatibility management, mixed-version operation, breaking change management, backward compatibility, API version compatibility, and support lifecycle management. Most of these are aliases, domain names, or mechanism names rather than separate top-level archetypes.

Backward Compatibility Management

short_definition: Preserves older dependents by ensuring newer versions continue to accept, interpret, or respect older interfaces, records, terms, or expectations.

distinctive_feature: The compatibility direction primarily protects old dependents from new-version breakage.

distinct_from_parent: The parent governs mixed-version interaction generally; this variant specifically emphasizes newer versions remaining usable by older dependents.

still_same_parent_because: It uses the same compatibility rules, support windows, migration paths, and test scopes as the parent.

source_primes: versioning interoperability continuity

use_when: Existing users, clients, records, or workflows cannot all migrate at once.

use_when: A new version would otherwise break legitimate older dependencies.

use_when: Continuity matters more than immediate removal of old behavior.

example_domains:
software APIs
policy updates
legal amendments
curriculum revisions

failure_modes:
silent breakage of older dependents
excessive support burden
ambiguous deprecation timing

Forward Compatibility Management

short_definition: Allows older versions to tolerate or safely ignore future extensions, fields, terms, or procedures they do not yet fully understand.

distinctive_feature: The compatibility direction anticipates future evolution rather than only protecting past dependents.

distinct_from_parent: The parent governs all compatibility relations; this variant focuses on tolerance for later extensions and unknown future states.

still_same_parent_because: It still depends on compatibility rules, breaking-change boundaries, fallback rules, and supported interaction scopes.

source_primes: versioning interoperability adaptation

use_when: The system expects future extensions or partial upgrades.

use_when: Older actors need safe behavior when encountering newer information.

use_when: Unknown future features should not immediately corrupt or block operation.

example_domains:
data schemas
technical standards
institutional procedures
product ecosystems

failure_modes: unsafe tolerance of meaning-changing changes

failure_modes: future assumptions that never materialize

Adapter-Mediated Compatibility

short_definition: Uses an intermediary adapter, shim, crosswalk, translation layer, or compatibility wrapper to let incompatible versions interact.

distinctive_feature: Compatibility is implemented by indirection rather than by changing every participant to a common version.

distinct_from_parent: The parent includes rule, support, migration, and testing governance; this variant emphasizes adapter-based mediation.

still_same_parent_because: Adapters only work when governed by compatibility scope, semantics, support windows, and failure handling.

source_primes: interoperability indirection coupling

use_when: Direct compatibility would be too costly or impossible.

use_when: Different versions, standards, or groups must coexist for a transition period.

use_when: The translation boundary can be made explicit and governed.

example_domains:
software integration
legal rule crosswalks
data conversion
organizational process integration

failure_modes:
translation loss
adapter becoming hidden source of truth
excessive coupling to obsolete versions

Migration Window Compatibility

short_definition: Maintains compatibility for a bounded transition period while dependents move from an old version to a new one.

distinctive_feature: The compatibility promise is explicitly temporary and tied to migration completion.

distinct_from_parent: The parent can support indefinite or stable mixed-version operation; this variant uses a bounded migration window.

still_same_parent_because: It still uses compatibility rules, support windows, deprecation policy, migration path, and compatibility tests.

use_when: A change is necessary but immediate cutover would strand users or dependencies.

use_when: Old and new states must coexist temporarily.

use_when: Transition support should end once migration is feasible and verified.

example_domains:
product support lifecycles
policy rollouts
database migration
education standards transitions

failure_modes: unsupported laggards hidden from decision makers

Negotiated Protocol Compatibility

short_definition: Uses a handshake, negotiation, or selection rule so interacting parties choose a mutually supported version or mode before proceeding.

distinctive_feature: Compatibility is resolved dynamically at interaction time rather than only by static policy.

distinct_from_parent: The parent includes static rules and support windows; this variant emphasizes runtime or encounter-time negotiation.

still_same_parent_because: Negotiation still relies on a declared compatibility scope, safe fallback behavior, and support policy.

use_when: Participants may support different sets of versions or modes.

use_when: Interaction should not proceed under an incompatible assumption.

use_when: Capability discovery can occur before full commitment.

example_domains:
communication protocols
cross-agency procedures
contract negotiation drafts
translation/interpreter services

failure_modes:
downgrade attacks or unsafe fallback
false capability claims
negotiation complexity exceeding value

near_names:
Compatibility Governance
Version Compatibility Management
Mixed-Version Operation
Breaking Change Management
Backward Compatibility
API Version Compatibility
Support Lifecycle Management


Compensating Transaction

related_primes: data_integrity accountability resilience fault_tolerance closure continuity constraint causality observability procedural_fairness

slug: transaction

slug: irreversibility

slug: resilience

slug: closure

slug: causality

components:
Compensation Rule
Irreversible Effect Map
Reconciliation Target
Compensation Trigger
Exception Owner
Compensating Action Sequence
Audit Trail
Residual Risk Acceptance
Reconciliation Verification
Notification Rule
Make-Whole Measure
Compensation Limit
Failure Learning Record

mechanisms:
Saga Pattern
Financial Reversal or Credit
Contract Cure Provision
Service Recovery Playbook
Remediation Plan
Corrective Action Request
Operational Reconciliation Workflow
Clinical Correction Protocol
Customer Make-Whole Credit
Incident Corrective Action Register

essence_one_line: When atomic rollback is impossible, apply compensating actions that restore an acceptable state after partial completion.

compression_statement: When a transaction cannot be simply undone, define compensating actions that counteract, cure, reconcile, or offset partial effects to restore consistency or acceptability.

core_intuition: Some effects cross a boundary where pretending they never happened is impossible: money posted, information disclosed, work consumed, goods shipped, trust damaged, or legal obligations triggered. A compensating transaction treats recovery as a designed counter-move rather than a failed attempt to rewind time.

canonical_formula: partial_or_irreversible_effect + exact_rollback_unavailable + compensation_rule + reconciliation_target + verification -> acceptable_repaired_state

structural_problem: A multi-step or grouped process can partially complete in ways that cannot be exactly reversed, leaving the system, parties, records, or obligations in an unacceptable intermediate state.

trigger_conditions: A process has local commits, external side effects, consumed resources, disclosed information, legal consequences, or human impacts that cannot be erased.

trigger_conditions: The system crosses organizational, technical, legal, temporal, or physical boundaries where one actor cannot centrally roll back every effect.

trigger_conditions: A later step can fail after an earlier step has already become visible, binding, recorded, or relied upon.

trigger_conditions: A saved-state rollback would lose legitimate subsequent work, violate obligations, or fail to repair the affected party.

trigger_conditions: Operational reality requires repair, cure, credit, reversal, reconciliation, or remediation rather than pure abort.

symptoms: Partial completion leaves accounts, records, inventory, obligations, or expectations out of balance.

symptoms: Teams say a failure was rolled back even though customers, counterparties, patients, or downstream systems still experience effects.

symptoms: Refunds, credits, manual fixes, apologies, amendments, or corrective actions are improvised with no consistent rule.

symptoms: Different parties disagree about whether repair is adequate because no reconciliation target was defined.

symptoms: Compensation is applied twice, not at all, or in the wrong order because triggers and ownership are unclear.

symptoms: Audit records cannot show what happened, what was compensated, who approved it, and whether closure was verified.

root_tension: Transactional design wants a clean all-or-nothing boundary, but real processes often produce irreversible or externally relied-upon effects before failure is known. The tension is resolved by shifting from exact reversal to governed counteraction and verifiable acceptability.

anti_signatures: The system can still abort all effects before they become visible, binding, consumed, or relied upon; use Transactional Atomicity instead.

anti_signatures: A known-good checkpoint can be restored exactly and that restoration is sufficient; use Checkpoint and Rollback instead.

anti_signatures: The main issue is preventing an invalid transition before it occurs; use Guarded State Transition instead.

anti_signatures: The main issue is retrying the same operation without duplicate side effects; use Idempotent Operation Design instead.

anti_signatures: The supposed compensation is only routine customer generosity or unrelated remediation, with no partial transaction, obligation, or irreversible effect being repaired.

structural_intervention: Define compensation steps, triggering conditions, ownership, reconciliation targets, audit trail, and verification for cases where exact rollback cannot repair partial or irreversible effects.

action_logic: Map the process steps and identify where each step creates irreversible, external, binding, or hard-to-reverse effects.

action_logic: Define the reconciliation target: what counts as acceptable repair after the original state cannot be restored exactly.

action_logic: Specify compensation triggers that distinguish retry, wait, rollback, escalation, and compensation.

action_logic: Attach a compensation rule or compensating action to each partial effect that could remain after failure.

action_logic: Assign owners and authorities for approving, executing, communicating, and verifying compensation.

action_logic: Order compensating actions so the cure does not create additional inconsistencies, duplicate repairs, or hidden obligations.

action_logic: Record the original effect, the trigger, the selected compensation, the evidence, and residual risks in an audit trail.

action_logic: Verify that compensation reached the reconciliation target and feed recurring failures back into prevention or redesign.

decision_rules: Use this archetype only after determining that exact rollback is impossible, unsafe, insufficient, or less fair than a designed counteraction.

decision_rules: Every irreversible or externally visible step in a long-running process should have an explicit compensation rule or an explicit statement that it cannot be compensated by ordinary means.

decision_rules: A compensation rule should be evaluated against the affected party or system state, not only against internal process closure.

decision_rules: Compensation should be proportional to the effect it repairs and should not create windfalls, double recovery, or new harms without explicit authority.

decision_rules: A compensation workflow is not complete until the reconciliation target has been verified or residual risk has been accepted by an accountable owner.

decision_rules: Repeated compensation for the same failure mode should trigger redesign, stronger guards, more atomic boundaries, or clearer user expectations.

target_invariants: Partial effects are not left invisible, orphaned, or unowned.

target_invariants: Every compensation action has a clear trigger, owner, authority, and closure criterion.

target_invariants: The repaired state is acceptable by domain-specific criteria even if it is not identical to the prior state.

target_invariants: The compensation does not duplicate the original effect, overcorrect the harm, or create a new inconsistent state.

target_invariants: Affected parties and records receive appropriate notice, correction, or traceability where required.

target_invariants: Residual risks and non-equivalent repairs are visible rather than hidden behind the word rollback.

expected_outcomes: Safer recovery from partial failure in long-running, distributed, irreversible, or human-facing processes.

expected_outcomes: Fewer dangling obligations, unbalanced records, unreconciled accounts, and unresolved customer or stakeholder harms.

expected_outcomes: More predictable handling of exceptions because compensation triggers and owners are defined in advance.

expected_outcomes: Better accountability because the original failure and compensation path are documented and verifiable.

expected_outcomes: Clearer boundaries between true atomic rollback, saved-state restoration, and compensating repair.

expected_outcomes: Improved learning from failures because recurring compensation events reveal where stronger design is needed.

prose_essence:
Compensating Transaction is the recovery archetype for cases where a clean all-or-nothing rollback is no longer possible. A step has already produced a real effect: money moved, information was disclosed, inventory changed, an obligation was triggered, a customer was harmed, a record was posted, or trust was damaged. The design problem is no longer “how do we pretend this never happened?” but “what counteraction restores an acceptable state?”

The archetype turns after-the-fact repair into a governed structure. It defines what counts as a compensable effect, when compensation begins, who owns it, what action is sufficient, how the action is recorded, and how closure is verified.

prose_when_to_use:
Use this archetype when a process can partially complete and some effects cannot be exactly undone. It is especially useful for long-running transactions, distributed workflows, contracts, service failures, healthcare corrections, financial postings, operational reconciliation, and public-service mistakes.

Do not use it merely because a failure occurred. If the system can still abort every effect before commit, use Transactional Atomicity. If a saved known-good state can be restored and that is sufficient, use Checkpoint and Rollback. Use Compensating Transaction when the repair must be a counteraction, cure, offset, or reconciliation rather than an exact rewind.

prose_structural_problem:
The structural problem is irreversible partial completion. A process crosses a boundary before the whole process succeeds. Once that boundary is crossed, a simple abort cannot remove all effects. Someone may have relied on the action, a record may need to remain traceable, a legal duty may have arisen, or a human experience may already have occurred.

This creates a residue: the system is neither simply successful nor cleanly failed. Without a compensating structure, that residue becomes manual cleanup, hidden support debt, dispute, unfairness, data inconsistency, or unresolved harm.

prose_intervention_logic:
The intervention begins by mapping irreversible effects. For each step that can leave residue, the draft defines a compensation rule and a reconciliation target. The trigger decides when the system stops trying to wait, retry, or roll back and starts compensation. The owner has authority to execute or escalate the repair. The audit trail records what happened, and verification checks that the compensation actually reached the target.

The important move is conceptual: the goal is not always to restore the previous state. The goal is to restore an acceptable state under the domain’s standards of fairness, safety, balance, legality, trust, or operational consistency.

prose_key_components:
- **Compensation Rule (`compensation_rule`):** Defines what counteraction, cure, credit, reversal, remediation, or reconciliation step is required after a partial or irreversible effect. The compensation rule is the core component: it specifies the acceptable repairing action when true rollback is unavailable. It should state scope, timing, preconditions, limits, and whether compensation is exact, approximate, symbolic, financial, operational, or relational.
- **Irreversible Effect Map (`irreversible_effect_map`):** Identifies which parts of the process create effects that cannot be exactly undone once they occur. Compensation only makes sense when the design knows which effects are irreversible, externally visible, legally binding, consumed, disclosed, degraded, or otherwise not restorable to the prior state.
- **Reconciliation Target (`reconciliation_target`):** States the acceptable post-compensation condition the system should reach, even if it cannot return to its exact prior state. The target may be balance restored, harm mitigated, obligations cured, records corrected, trust repaired, patient safety restored, or parties made whole enough for the domain. It is not automatically the original state.
- **Compensation Trigger (`compensation_trigger`):** Specifies the conditions under which compensation should begin rather than waiting, retrying, escalating, or attempting exact rollback. Triggers may include partial completion, failed downstream step, missed obligation, duplicate charge, service outage, defective delivery, harmful disclosure, failed deployment after external effects, or manual exception review.
- **Exception Owner (`exception_owner`):** Assigns responsibility for choosing, approving, executing, and verifying compensation when the ordinary path fails. Without an owner, compensation often becomes an informal clean-up task. Ownership matters because compensation may require judgment, authority, customer contact, legal cure, clinical correction, or cross-team coordination.
- **Compensating Action Sequence (`compensating_action_sequence`):** Orders the corrective actions needed to neutralize, offset, or reconcile partial effects without creating additional inconsistency. Some compensation is a single action, but many cases require ordered steps: notify, freeze, reverse, credit, repair, amend record, reissue obligation, test, and close. Ordering prevents the cure from becoming another source of harm.
- **Audit Trail (`audit_trail`):** Records the original partial effect, compensation trigger, chosen action, authorizations, evidence, and final reconciliation result. The audit trail is especially important because compensation usually admits that a clean all-or-nothing transaction failed or was impossible. It supports accountability, learning, dispute resolution, and later verification.
- **Residual Risk Acceptance (`residual_risk_acceptance`):** Makes visible what harm, mismatch, uncertainty, or obligation remains after compensation and who accepts it. Compensation may restore acceptability rather than perfection. This component prevents premature closure by requiring explicit acknowledgment of residual loss, exposure, degraded trust, or non-equivalent repair.
- **Reconciliation Verification (`reconciliation_verification`):** Checks that the compensation actually reached the reconciliation target and did not create new inconsistent state. Verification may be a balance check, customer confirmation, legal sign-off, safety review, data integrity test, operational reconciliation, or independent audit.
- **Notification Rule (`notification_rule`):** Determines who must be informed that compensation is occurring, what they are told, and when disclosure is required. Important when affected parties, regulators, customers, patients, counterparties, or downstream operators need transparency before trust can be restored.
- **Make-Whole Measure (`make_whole_measure`):** Defines how sufficiency of repair is measured when exact reversal is impossible. The measure may be financial equivalence, restored access, corrected record state, service credit, clinical safety, contractual cure, reputational repair, or negotiated satisfaction.
- **Compensation Limit (`compensation_limit`):** Caps or constrains the allowed compensation so the cure does not create new unfairness, gaming, or unbounded liability. Limits should not erase legitimate obligations; they clarify escalation thresholds, proportionality, authority, and when ordinary compensation is inadequate.
- **Failure Learning Record (`failure_learning_record`):** Captures why compensation was needed so the underlying process can be redesigned, guarded, or made more atomic later. Compensation should not become a license for sloppy design. Recurring compensation events should feed prevention, guardrails, training, or redesign.

prose_common_mechanisms:
Mechanisms are implementations of the archetype, not substitutes for it. A refund, saga, remediation plan, or cure clause only instantiates Compensating Transaction when it repairs a partial or irreversible effect against a defined reconciliation target.

- **Saga Pattern (`saga_pattern`):** This workflow protocol implements the archetype when it implements long-running distributed work as a chain of local actions with defined compensating actions when later steps fail.
- **Financial Reversal or Credit (`financial_reversal_or_credit`):** This procedure implements the archetype when it uses refund, credit, chargeback, reversal, adjustment, or balancing entry to offset a completed financial effect that cannot simply vanish.
- **Contract Cure Provision (`contract_cure_provision`):** This legal clause implements the archetype when it defines how a party can repair a breach or incomplete performance through notice, correction, replacement, payment, or other cure.
- **Service Recovery Playbook (`service_recovery_playbook`):** This procedure implements the archetype when it guides apology, escalation, replacement, refund, credit, repair, and follow-up after a service failure has already affected someone.
- **Remediation Plan (`remediation_plan`):** This plan implements the archetype when it specifies corrective work, owners, deadlines, evidence, and acceptance criteria for restoring acceptable condition after harm or noncompliance.
- **Corrective Action Request (`corrective_action_request`):** This document implements the archetype when it creates a formal request to correct a defect, nonconformance, incident, or partial failure and to verify that the cure is complete.
- **Operational Reconciliation Workflow (`operational_reconciliation_workflow`):** This workflow implements the archetype when it compares expected and actual states after partial completion, then applies adjustments until records, obligations, inventory, or accounts balance acceptably.
- **Clinical Correction Protocol (`clinical_correction_protocol`):** This protocol implements the archetype when it coordinates disclosure, corrective care, monitoring, record amendment, and follow-up when a clinical action cannot be undone exactly.
- **Customer Make-Whole Credit (`customer_make_whole_credit`):** This policy implements the archetype when it offers replacement, account credit, restitution, or extra service to restore customer acceptability after a failed or incomplete transaction.
- **Incident Corrective Action Register (`incident_corrective_action_register`):** This artifact implements the archetype when it tracks compensating actions, residual risks, owners, due dates, evidence, and closure status across incidents.

prose_failure_modes: Common failure modes include non-equivalent compensation, duplicate compensation, missing compensation paths, unclear ownership, false closure, and moral hazard. A particularly dangerous failure is calling compensation “rollback,” because that hides the fact that the system did not return to the original state. Another common failure is designing compensation from the internal system’s perspective while ignoring the affected party’s real loss or risk.

prose_neighbor_distinctions: Compensating Transaction is distinct from **Transactional Atomicity** because atomicity prevents partial commit, while compensation repairs partial or irreversible effects after they occur. It is distinct from **Checkpoint and Rollback** because rollback restores a saved state, while compensation reaches an acceptable repaired state. It is distinct from **Guarded State Transition** because guards block invalid transitions before they occur. It is distinct from **Idempotent Operation Design** because idempotence makes repetition safe, while compensation repairs effects that should not simply repeat.

prose_cross_domain_examples: In software, an order workflow may compensate for a failed shipment after payment has already posted by refunding the customer and releasing inventory. In finance, posted transactions may require reversing or balancing entries rather than deletion. In contracts, a missed obligation may be cured through replacement performance, credit, and documented acceptance. In healthcare, an incorrect instruction may require disclosure, corrected records, follow-up care, and monitoring. In manufacturing, a shipped defect may require recall, replacement, credit, and corrective-action verification.

prose_non_examples: A database transaction that aborts before commit is not this archetype; it is transactional atomicity. A system image restored from a checkpoint is not this archetype unless later external effects also require repair. A release gate that prevents an unapproved change is guarded transition, not compensation. A generic goodwill discount with no failed obligation or partial transaction is not a compensating transaction.

prose_tradeoffs: Compensation makes distributed and irreversible processes workable, but it accepts that some effects cannot be erased. It increases design complexity and may create legal, financial, operational, or relational obligations. Standardized compensation improves speed and consistency, while individualized compensation may be fairer but slower and harder to govern. Overuse can normalize preventable failure.

prose_invariants_to_preserve: The draft preserves several invariants. Partial effects must not be orphaned or hidden. Every compensation path must have a trigger, owner, action rule, evidence record, and closure criterion. The repaired state must be acceptable by the relevant domain standard, not merely convenient for the actor that caused the failure. Compensation must not create duplicate repair, unbounded liability, or a new inconsistent state. Residual risk must remain visible.

prose_target_outcomes: Successful use of this archetype produces accountable recovery after partial failure. It reduces dangling obligations, unbalanced records, unresolved stakeholder harm, and improvised exception handling. It also clarifies when prevention should be strengthened: if compensation becomes frequent, the process probably needs better guards, more atomic boundaries, clearer expectations, or redesigned sequencing.

prose_parameter_dimensions:
- **Compensation exactness:** whether repair must be exact, approximate, symbolic, financial, operational, or relational.
- **Trigger sensitivity:** how quickly the system switches from retry or rollback to compensation.
- **Automation level:** whether compensation is automatic, operator-approved, or expert-judged.
- **Authority threshold:** who may approve compensation and what value, risk, or legal threshold requires escalation.
- **Reconciliation standard:** what evidence is enough to close the repair.
- **Affected-party participation:** whether the affected party must be notified, consulted, asked for consent, or given appeal rights.
- **Residual-risk tolerance:** what remaining mismatch can be accepted and who owns that acceptance.
- **Learning loop strength:** how aggressively repeated compensation events trigger redesign rather than more repair work.

prose_variants_and_near_names: Important variants include saga-based compensation, contractual cure compensation, service recovery compensation, and operational reconciliation compensation. Near names include compensating action, compensation workflow, corrective action, make-whole remedy, and rollback alternative. The name “saga pattern” should be retained for retrieval, but it is a mechanism under this archetype rather than the archetype itself.

Saga-Based Compensation

short_definition: Coordinate a distributed multi-step process through local commits paired with compensating actions for later failure.

distinctive_feature: The compensating actions are designed as part of a long-running distributed workflow rather than improvised after the fact.

distinct_from_parent: The parent is cross-domain compensation after irreversible or partial effects; this variant is the distributed-workflow implementation family often called saga.

still_same_parent_because: Its core logic remains counteraction and reconciliation after exact atomic rollback is unavailable.

use_when: A process spans multiple services, organizations, teams, or authorities that cannot participate in one atomic transaction.

use_when: Each step may commit locally before downstream failure is known.

use_when: A later failure needs defined counteractions rather than a single global rollback.

example_domains:
distributed software systems
inter-organizational workflows
operations coordination

domain: Software

example: An order workflow reserves stock, charges payment, and schedules shipment, then releases stock or credits the account if shipment fails.

example: A cross-vendor service process issues reverse work orders when one provider cannot complete a dependent step.

failure_modes: missing compensating action for one committed step

failure_modes: compensation order creates new inconsistency

failure_modes: workflow retries both original and compensation

Contractual Cure Compensation

short_definition: Use notice, cure periods, replacement performance, payment, amendment, or waiver to repair a breached or incomplete obligation.

distinctive_feature: The compensation rule is embedded in a legal or institutional obligation structure.

distinct_from_parent: This variant emphasizes notice, cure rights, contractual authority, and enforceable acceptance criteria.

still_same_parent_because: It still repairs partial or defective performance through defined counteraction rather than exact rollback.

source_primes: transaction accountability

use_when: An obligation has already been missed, partially performed, or performed defectively.

use_when: The prior condition cannot be restored exactly, but the relationship or obligation can be made acceptable.

use_when: Authority and evidence requirements matter for closure.

example_domains:
contracts
procurement
employment agreements
regulatory compliance

domain: Contracts

example: A vendor misses a delivery milestone and cures by expedited replacement plus credit under a notice-and-cure clause.

domain: Regulatory compliance

example: An institution remediates a filing defect through amended filing, disclosure, and documented corrective action.

failure_modes: cure does not match the breached obligation

Service Recovery Compensation

short_definition: Restore customer, client, patient, or participant acceptability after a service failure through apology, correction, credit, replacement, or follow-up.

distinctive_feature: The reconciliation target includes human satisfaction, trust repair, or fairness, not only technical state correction.

distinct_from_parent: The parent covers all compensating transactions; this variant highlights relational and service-experience repair.

still_same_parent_because: It is still a counteraction after partial or harmful effect rather than prevention or exact rollback.

use_when: The affected party has already experienced the failure or loss.

use_when: Trust, fairness, and perceived adequacy of repair are part of the outcome.

use_when: Exact restoration is unavailable or insufficient because the experience already occurred.

example_domains:
customer service
healthcare
education
public services

domain: Customer service

example: A hotel compensates a failed room guarantee with alternate lodging, transport, apology, and account credit.

domain: Public services

example: An agency corrects an erroneous denial with expedited review, retroactive benefit adjustment, and explanation.

failure_modes: repair metric ignores the affected party

Operational Reconciliation Compensation

short_definition: Compare expected and actual states after partial completion, then apply balancing or corrective entries until the process is acceptable.

distinctive_feature: The compensation is driven by reconciliation between recorded state and expected state.

distinct_from_parent: This variant emphasizes data or operational balancing as the repair pathway.

still_same_parent_because: It remains a compensation pattern because it repairs after partial state has been created.

use_when: Partial effects are already recorded in accounts, inventory, records, schedules, or obligations.

use_when: The repair must preserve traceable records rather than erase history.

use_when: Acceptable closure depends on balancing or matching actual state against expected state.

example_domains:
finance
inventory management
operations
data administration

domain: Finance

example: A settlement system applies correcting entries after one leg of a payment process posts and another fails.

domain: Inventory

example: A warehouse adjusts inventory records and issues a replacement after a shipment is partially fulfilled incorrectly.

failure_modes: records balance numerically but obligations remain unmet

near_names:
Compensating Action
Compensation Workflow
Corrective Action
Make-Whole Remedy
Saga Pattern
Rollback Alternative


Compensation-Aware Safeguard Design

batch: Batch 13

canonical_family: Staged Processes & Drift

slug: risk

slug: feedback

slug: monitoring

slug: boundedness

slug: externality

slug: homeostasis

slug: threshold

slug: controllability

slug: uncertainty

slug: governance

components:
Safeguard Change Map
Baseline Risk Behavior Profile
Perceived Failure-Cost Delta
Risk-Budget Reallocation Signal
Exposure Substitution Map
Offset Observability Channel
Compensation Friction Guardrail
Net Safety Gain Audit
Target-Risk Setpoint Hypothesis
Bystander Harm Sentinel
Protection Communication Boundary

mechanisms:
Risk Compensation Premortem
Before / After Behavior Monitor
Safety-Gain Offset Dashboard
Shared Downside or Deductible Rule
Use-Conditioned Protection Policy
Exposure Cap or Rate Limiter
Adaptive Safeguard Recalibration Gate
Post-Safeguard Incentive Audit

essence_one_line: Design safeguards so their apparent safety gains are not consumed by compensating increases in risky behavior, exposure, speed, leverage, or carelessness.

compression_statement: When protection lowers the perceived cost of failure, users may treat the freed margin as permission to increase exposure. This archetype designs the safeguard together with behavior baselines, offset monitoring, incentive alignment, exposure limits, communication boundaries, and net-safety audits so the intervention reduces total harm rather than merely moving the risk budget.

core_intuition: A safer car, backup, insurance policy, helmet, automated aid, or guardrail does not only change the machine. It changes what actors feel safe doing. The safeguard succeeds only if the new margin remains margin, instead of becoming fuel for faster, larger, more complex, or less careful action.

canonical_formula: NetSafetyGain = TechnicalRiskReduction - BehavioralOffset - DisplacedExposure - NewSystemicRisk; intervene when BehavioralOffset consumes the tolerated share of TechnicalRiskReduction.

structural_problem: A safeguard is introduced to reduce the cost, likelihood, or severity of failure. Because the protected actor experiences the action as safer, cheaper, reversible, insured, backed up, or less punishable, they may increase risky behavior until part of the intended gain disappears. The problem is not merely that actors are irrational or reckless. The safeguard changes the payoff surface and perceived failure boundary, and the system lacks controls for the behavioral response.

trigger_conditions: A protective measure, backup, insurance layer, safety device, automated aid, compliance shield, guarantee, or fail-safe reduces perceived downside for an actor who still controls exposure.

trigger_conditions: The actor can change behavior after protection is added: speed, leverage, load, volume, complexity, frequency, shortcutting, monitoring effort, or boundary pushing.

trigger_conditions: The post-safeguard behavior is not fully fixed by physical constraints, law, contract, or strong norms.

trigger_conditions: Safety success is measured locally, while offset behavior or displaced harm may appear in another population, channel, time period, or failure mode.

trigger_conditions: The protected actor receives the upside of taking more risk while some downside is transferred to others, pooled, delayed, hidden, or absorbed by the safeguard.

trigger_conditions: The safeguard is advertised or socially understood in a way that may create overconfidence, invulnerability, or reduced vigilance.

trigger_conditions: Leadership expects technical risk reduction to translate directly into net safety without monitoring the behavioral counter-move.

symptoms: After a safety improvement, users operate faster, closer to limits, with less caution, or at higher throughput than before.

symptoms: The protected failure mode decreases, but total harm, near misses, tail events, or bystander exposure do not improve as expected.

symptoms: People treat backup, insurance, redundancy, automation, or compliance approval as a license to expand scope or risk appetite.

symptoms: The organization celebrates the safeguard adoption rate while ignoring exposure growth that uses up the new margin.

symptoms: A rule designed to prevent one class of failure creates new pressure to push a different boundary.

symptoms: Risk controls are removed or relaxed because a new protection is presumed to make them unnecessary.

symptoms: Post-incident review discovers that users knew the safeguard existed but misunderstood its limits or failure modes.

root_tension: The archetype manages the tension between protection and behavioral adaptation. Protection should reduce harm, but it also changes incentives and perceived constraints. The design challenge is to make the technical margin survive contact with actors who optimize around the new margin.

anti_signatures: The safeguard fails because of a technical defect while user behavior remains unchanged; use reliability, fail-safe, or robustness patterns instead.

anti_signatures: The primary issue is hidden action in a contractual principal-agent setting, not safeguard-induced behavioral offset; use moral_hazard_mitigation as the narrower parent/neighbor.

anti_signatures: The actor is forced by physical design to remain within safe limits, leaving no meaningful room for compensating behavior.

anti_signatures: The main problem is excessive caution or avoidance, not re-spending a safety margin; use risk_aversion_calibration or approach-avoidance patterns.

anti_signatures: The system is simply adding a safety buffer without a behavioral response channel; use safety_margin_design or robustness_margin_design.

anti_signatures: The intervention is a pure training, awareness, or compliance campaign with no changed failure-cost surface.

anti_signatures: Observed risk growth is due to external demand growth or environmental change rather than actor response to protection.

structural_intervention: Pair the safeguard with a compensation-control layer: map the perceived cost shift, establish behavioral baselines, monitor offset signals and displaced exposure, preserve some accountability or friction, communicate limits, and recalibrate the protection when net safety gain is being consumed.

action_logic: Define the safeguard and the specific harm, failure mode, or cost it is supposed to reduce.

action_logic: Identify who perceives the protection, who can change behavior because of it, who gains from increased risk-taking, and who may bear displaced harm.

action_logic: Record the baseline risk behavior profile before deployment, including exposure quantity, intensity, caution practices, near misses, and distribution of harm.

action_logic: Estimate the perceived failure-cost delta: what now feels cheaper, safer, reversible, insured, backed up, or less sanctionable?

action_logic: Generate plausible compensation pathways: faster operation, higher leverage, weaker monitoring, expanded scope, less maintenance, more complexity, closer spacing, or risk transfer to outsiders.

action_logic: Install offset observability channels before or alongside the safeguard so changes in behavior can be measured without relying only on final harm rates.

action_logic: Add compensation friction guardrails: rate limits, co-risk, deductibles, usage conditions, training, communication boundaries, exposure caps, or override reviews.

action_logic: Measure net safety gain after deployment using technical failure reduction, behavior change, displaced exposure, and distributional effects rather than one local success metric.

action_logic: Recalibrate the safeguard, incentives, communication, or constraints when behavioral offset exceeds the tolerated share of the intended gain.

action_logic: Treat persistent compensation as information about the system’s risk appetite and redesign the surrounding rules rather than blaming users alone.

decision_rules: Do not count technical risk reduction as safety gain until post-safeguard behavior and exposure have been measured.

decision_rules: If the actor can increase exposure after protection, design compensation monitoring before the safeguard is scaled.

decision_rules: If the protected actor captures upside while others bear downside, add accountability, co-risk, externality internalization, or approval constraints.

decision_rules: If offset behavior is likely but benign within limits, set a tolerated offset band and monitor for threshold crossing instead of forbidding all adaptation.

decision_rules: If the safeguard creates overconfidence, revise communication to state limits, failure modes, and residual responsibilities without hiding the protection.

decision_rules: If displaced harm increases for bystanders or tail cases, evaluate the safeguard by total and distributional harm rather than protected-user outcomes only.

decision_rules: If compensation repeatedly consumes most of the gain, redesign the surrounding incentive structure rather than adding more technical protection alone.

decision_rules: If the domain is safety-critical or rights-sensitive, require independent review before relaxing other controls because of the new safeguard.

target_invariants: The intended protective function remains available to users who need it.

target_invariants: The new safety margin is not silently converted into increased exposure, speed, leverage, or carelessness.

target_invariants: Behavioral offset is measured close enough to the action point to allow correction before harm accumulates.

target_invariants: The success metric includes net harm and displaced exposure, not only the failure mode the safeguard was designed to reduce.

target_invariants: Actors retain appropriate responsibility for controllable behavior even when protection reduces catastrophic downside.

target_invariants: Communication accurately describes both the protection and the residual risk boundary.

target_invariants: Guardrails are proportionate: they constrain compensation without eliminating the benefits of the safeguard.

expected_outcomes: Greater preservation of the safety, resilience, or reliability gain expected from the safeguard.

expected_outcomes: Earlier detection of compensating behavior before it becomes normalized.

expected_outcomes: Reduced risk transfer from protected actors to bystanders, insurers, pooled resources, or future maintainers.

expected_outcomes: More disciplined decisions about when to relax older controls after new protection is introduced.

expected_outcomes: Better separation between useful confidence and reckless overconfidence.

expected_outcomes: Improved accountability for safeguards that otherwise make failure feel costless.

expected_outcomes: Clearer learning about the system’s actual risk appetite and behavioral response to protection.

prose_tradeoffs: The main tradeoff is between useful confidence and harmful overconfidence. Good safeguards should let people act with less fear, but not with unlimited exposure. Monitoring improves learning, but can become intrusive. Shared downside can preserve care, but may punish those who need protection. Exposure limits preserve safety gain, but can reduce autonomy or throughput. Communication must be honest without becoming alarmist.

Risk-Homeostasis Setpoint Management

short_definition: Treats compensation as movement toward a tolerated risk setpoint and manages the setpoint, feedback, and friction rather than only the technical safeguard.

distinctive_feature: Foregrounds a behavioral risk setpoint and feedback loop.

distinct_from_parent: The parent covers all safeguard-induced offset; this variant uses homeostasis/setpoint reasoning.

still_same_parent_because: It still preserves net safety gain by controlling risk compensation after protection changes.

source_primes: peltzman_effect homeostasis risk

use_when: Behavior repeatedly returns to a similar perceived risk level after safeguards change.

use_when: The actor receives feedback about risk and can adjust exposure continuously.

use_when: The system needs to change the risk target or action boundary, not just add protection.

example: After better helmets are introduced, monitor and constrain impact intensity if players compensate by hitting harder.

failure_modes: Overstating a psychological setpoint when behavior is actually driven by incentives or demand.

failure_modes: Treating all adaptation as bad rather than distinguishing useful confidence from harmful offset.

Insurance Moral-Hazard Compensation

short_definition: Controls increased risk-taking that follows insurance, guarantees, pooled protection, bailout expectations, or liability shielding.

distinctive_feature: The safeguard is a financial, contractual, or pooled-risk shield.

distinct_from_parent: The parent covers all safeguards; this variant is the insurance/guarantee subtype and strongly overlaps moral_hazard_mitigation.

still_same_parent_because: The same behavioral offset and net-gain preservation loop applies.

use_when: Coverage or guarantee shifts downside away from the actor.

use_when: The actor can change care level, exposure, leverage, or maintenance after protection begins.

use_when: Contract, monitoring, or shared-risk rules can preserve some accountability.

example_domains: insurance finance public_backstops warranties

domain: insurance

example: Require deductibles and safety standards so coverage does not reduce maintenance or care.

failure_modes: Monitoring hidden action invasively or unfairly.

Automation Overtrust Compensation

short_definition: Manages reduced vigilance or expanded task risk after automation, decision support, or recovery systems make failure feel less likely or less costly.

distinctive_feature: The protection is an automated aid or recovery system that changes vigilance and responsibility.

distinct_from_parent: The parent is technology-neutral; this variant covers automation trust and misuse.

still_same_parent_because: The intervention still detects and limits compensating behavior after perceived protection increases.

source_primes: peltzman_effect feedback monitoring

use_when: Automation changes the user’s perceived responsibility or failure boundary.

use_when: Users can stop monitoring, increase complexity, or push use beyond intended conditions.

use_when: The system can provide capability boundaries, attention checks, and misuse monitoring.

domain: cybersecurity

example: Automatic rollback is paired with deployment-rate limits and review triggers so teams do not ship riskier changes merely because rollback exists.

failure_modes: Blaming operators for predictable overtrust.

failure_modes: Using attention checks that become ceremonial.

near_names:
Risk Compensation
Risk Homeostasis
Peltzman Effect Control
Behavioral Offset Control
Safety-Gain Preservation
Safeguard Offset Management