Divergence Detection and Correction

batch: First Iteration/Batch 24

source_primes: convergence instability feedback

related_primes: observability controllability state_and_state_transition uncertainty damping threshold tolerance divergence_convergence robustness resilience

slug: instability

slug: observability

slug: controllability

slug: damping

slug: threshold

slug: tolerance

slug: resilience

components:
Target Distance Metric
Divergence Signal
Divergence Trend Window
Cause Diagnosis Frame
Correction Rule
Abort Condition
Monitoring Cadence
Recovery Target
Noise Filter
Rollback Point
Escalation Path
Independent Signal Check

mechanisms:
Model Training Divergence Monitor
Project Drift Correction Review
Process Control Alarm and Tuning
Negotiation Derailment Repair Protocol
Loss-Limit Correction Rule
Learning Remediation Loop
Policy Drift Review
Runbook-Based Course Correction

essence_one_line: Detect when a process is moving away from its target and correct course before divergence compounds.

compression_statement: When a system expected to converge begins moving away from its intended target, detect the divergence early, distinguish it from noise or legitimate exploration, diagnose the cause, and apply correction, rollback, escalation, or abort before the failure grows.

core_intuition: Convergence failure is often visible before final failure: distance from the target grows, corrections stop reducing the gap, or the process begins reinforcing the wrong path. The archetype turns those warning signs into a disciplined response rather than waiting for collapse or pushing harder blindly.

canonical_formula: target distance metric + divergence signal + trend window + cause diagnosis + correction rule + abort condition => bounded divergence and restored convergence path

structural_problem: A process intended to approach a target, stable state, or agreement instead moves farther away over time.

condition: Distance from target is increasing

description: Each update, decision, estimate, or action leaves the process farther from the intended state.

condition: Corrections are no longer corrective

description: Actions that should reduce the gap either fail, reverse progress, or create new deviation.

condition: Variation becomes directional drift

description: What began as ordinary fluctuation or exploration develops a persistent movement away from target.

condition: Compounding error appears

description: The longer the process continues, the harder, costlier, or riskier recovery becomes.

condition: Stakeholders disagree about whether the path is still viable

description: Some actors treat the divergence as adaptation while others see loss of target integrity.

symptom: Progress reports show activity but widening gap

interpretation: The process may be optimizing effort, throughput, or local milestones while losing the actual target.

symptom: Successive corrections need to be larger

interpretation: The path may be unstable, miscalibrated, or constrained by a wrong assumption.

symptom: The target is quietly redefined to fit current path

interpretation: Divergence is being hidden by moving the goal rather than correcting the route.

symptom: Feedback arrives too late to affect decisions

interpretation: Detection cadence may be slower than the divergence dynamics.

symptom: Local incentives pull actors away from global outcome

interpretation: The cause may be incentive misalignment rather than lack of effort.

symptom: A single bad update makes later updates worse

interpretation: The system may have path-dependent or compounding error.

root_tension: The process needs enough freedom to explore, adapt, and tolerate noise, but enough discipline to detect when movement has become harmful divergence rather than useful variation.

case: No defined target or reference state exists

why_not: Without a target or expected path, the issue is target clarification, sensemaking, or exploratory search rather than divergence detection.

case: The process is simply slow but still moving toward the target

why_not: Use Convergence Acceleration or Convergence Guidance when the problem is pace rather than movement away from target.

case: The problem is apparent stability that may be misleading

why_not: Use False Convergence Prevention when the danger is mistaken stability or premature agreement.

case: The system is volatile around a target but not directionally worsening

why_not: Use Instability Dampening or Oscillation Damping when volatility, not divergence, is primary.

case: The only question is when to stop

why_not: Use Convergence Criteria Design or Termination Condition Design when the path is converging and only closure criteria are missing.

structural_intervention: Instrument the expected convergence path so movement away from target becomes visible, confirm that the signal is persistent enough to matter, diagnose why divergence is occurring, and choose a correction, rollback, escalation, or abort action that restores a viable path or prevents further loss.

Name the converging object

purpose: Specify whether beliefs, estimates, designs, behaviors, decisions, workflows, negotiations, signals, or system states are expected to converge.

Define target distance

purpose: Create a meaningful way to tell whether the process is closer to or farther from the target.

Detect divergence trend

purpose: Use observation windows, thresholds, qualitative evidence, or comparative checks to distinguish true divergence from noise.

Diagnose the divergence cause

purpose: Classify whether the cause is target ambiguity, bad feedback, wrong assumptions, incentive conflict, capacity limit, external shock, excessive correction, or path dependence.

Apply a cause-matched correction

purpose: Adjust parameters, feedback, constraints, assumptions, sequence, participation, resources, or route according to the diagnosed cause.

name: Check for recovery or compounding failure

purpose: Look for evidence that the process has returned to a viable convergence path rather than merely hiding the divergence.

name: Escalate, rollback, or abort when needed

purpose: Stop the path when correction cannot responsibly restore convergence or when continued action compounds risk.

rule: Treat direction, not activity, as the key evidence

reason: High activity can coexist with movement away from the target.

rule: Confirm persistence before ordinary correction

reason: A single noisy observation should not trigger churn unless the domain is safety-critical.

rule: Use fast containment for compounding divergence

reason: When harm grows quickly, waiting for perfect diagnosis can be more dangerous than temporary halt or rollback.

rule: Correct the cause, not only the symptom

reason: Pushing harder along a bad path can deepen divergence.

rule: Abort if the target, path, or signal is invalid

reason: A process cannot be corrected responsibly if the reference point or evidence basis has failed.

rule: Re-evaluate the target explicitly if context changed

reason: Some apparent divergence is legitimate adaptation, but target revision should be visible rather than hidden.

Directionality Must Be Visible

description: The process must be able to tell whether movement is toward the target, away from it, or merely sideways.

Correction Must Match Cause

description: The response should address why divergence is happening, not just apply pressure toward the target.

Noise Must Not Drive Churn

description: Ordinary fluctuation should not trigger repeated corrections that destabilize the process.

Abort Must Remain Available

description: A path that cannot be restored should be stopped or replaced rather than endlessly corrected.

Target Integrity Must Be Preserved

description: The target may be revised explicitly, but it should not shift silently to make divergence appear solved.

prose_essence:
Divergence Detection and Correction is the archetype for situations where a process is supposed to converge but begins moving away from its target. It is not merely a warning system. The full pattern is: make distance from the target visible, recognize when the movement is truly divergent, diagnose why the movement is happening, and choose a correction, rollback, escalation, or abort action before the gap compounds.

The useful intuition is that convergence failure often becomes visible before final failure. A model’s fit worsens, a project drifts from its intended outcome, a negotiation hardens positions instead of finding common ground, or a policy implementation begins producing effects opposite to intent. This archetype catches that trajectory while recovery is still possible.

prose_when_to_use:
Use this archetype when there is a named object that should converge: an estimate, decision, design, workflow, negotiation, behavior, signal, implementation, or system state. The process must have some reference target or expected path, and there must be enough observation to tell whether updates are moving closer or farther away.

It is especially useful when delay makes the problem worse. A small divergence in an early model, implementation, or agreement process can later become expensive path dependence. The archetype is less appropriate during intentionally broad exploration, when disagreement and variation are useful, or when the target itself is still undefined.

prose_structural_problem:
The structural problem is directional failure. A process intended to approach a target instead increases its distance from that target. The process may still be active, busy, and apparently managed, but the direction of movement is wrong.

This can happen because the target is ambiguous, the feedback signal is misleading, the update rule is miscalibrated, local incentives pull actors away from the global outcome, external conditions changed, or a previous correction created new error. The danger is not only that the process fails, but that each additional cycle can make recovery harder.

prose_intervention_logic:
The intervention begins by naming what is supposed to converge. Without that, “divergence” is only a complaint. Next, the process needs a target distance metric or equivalent qualitative reference: what would count as closer or farther away? A divergence signal then marks when movement away from target is occurring.

The signal should be interpreted through a trend window so ordinary noise does not trigger needless churn. Once divergence is credible, the cause must be diagnosed. A correction that addresses metric error will differ from a correction for incentive conflict, capacity limits, target ambiguity, or excessive correction strength. Finally, the system checks whether correction restored a viable convergence path. If not, the path should be escalated, rolled back, redesigned, or aborted.

prose_key_components:
### Target Distance Metric

The target distance metric makes direction visible. It may be quantitative, such as error, loss, defect rate, or schedule variance, or qualitative, such as degree of agreement with a design intent or policy purpose. Its job is not to count activity; it is to show whether movement is closer to or farther from the intended state.

### Divergence Signal

The divergence signal is the warning that distance from the target is increasing. A good signal includes direction, magnitude, persistence, and context. Weak signals cause overreaction; delayed signals let divergence compound.

### Divergence Trend Window

The trend window defines how much evidence is needed before the signal is treated as real divergence. In a high-risk system, the window may be short. In a noisy learning or design process, it may need to be longer so that the process does not confuse useful variation with failure.

### Cause Diagnosis Frame

The cause diagnosis frame asks why divergence is happening. The same symptom can come from different causes: a bad metric, a wrong assumption, excessive correction strength, local incentive conflict, capacity overload, target instability, or a changed external environment. The diagnosis determines the correction.

### Correction Rule

The correction rule translates diagnosis into action. It might adjust parameters, change sequencing, revise assumptions, reset scope, add support, reallocate resources, alter incentives, or change participation. The correction should be traceable to the diagnosed cause.

### Abort Condition

The abort condition defines when continued correction becomes irresponsible. Some paths cannot be restored by pushing harder. The abort condition protects the system from escalation of commitment by specifying when to stop, roll back, escalate, or redesign.

### Monitoring Cadence

Monitoring cadence sets the rhythm of detection. Fast-compounding divergence needs frequent monitoring. Slow-moving processes can tolerate longer windows. The cadence should match the speed at which error, cost, conflict, or risk can grow.

### Recovery Target

The recovery target defines what “back on track” means after correction. It is usually not the final convergence state. It is the intermediate state where ordinary convergence guidance can resume.

prose_common_mechanisms:
### Model Training Divergence Monitor

A model training divergence monitor watches training or validation behavior to detect when repeated updates are worsening fit. This mechanism implements the archetype in a technical setting, but it is not the archetype itself. The transferable pattern is detection of movement away from target followed by cause-matched correction or abort.

### Project Drift Correction Review

A project drift correction review compares current work with the intended outcome, scope, and decision record. It helps identify whether a project is adapting appropriately or drifting into a different, less justified target.

### Process Control Alarm and Tuning

A process control alarm can detect movement away from an operating target. Tuning then adjusts parameters or restores a prior configuration. The alarm is only useful when connected to diagnosis and correction; otherwise it is just notification.

### Negotiation Derailment Repair Protocol

A negotiation derailment repair protocol detects when deliberation is widening disagreement, distrust, or positional rigidity. Repair may involve agenda reset, issue separation, caucus, reframing, evidence review, or escalation. The mechanism must preserve legitimate dissent rather than forcing false agreement.

### Loss-Limit Correction Rule

A loss-limit correction rule defines when accumulating deviation, loss, or exposure requires reducing risk or exiting the path. It is common in finance and operations, but the same logic applies whenever divergence compounds faster than ordinary review can handle.

### Learning Remediation Loop

A learning remediation loop detects when practice is reinforcing error instead of moving toward mastery. The correction changes explanation, practice sequence, feedback, or support before the wrong pattern becomes entrenched.

### Policy Drift Review

A policy drift review compares implementation behavior with policy intent. It is useful when field interpretation, incentives, or local constraints cause practice to move away from the intended outcome.

### Runbook-Based Course Correction

A runbook-based mechanism predefines triggers, diagnosis checks, and corrective actions for known divergence patterns. It increases response speed but should include escalation paths for unfamiliar cases.

prose_failure_modes:
The most common failure mode is noise-driven overcorrection, where normal fluctuation is mistaken for divergence. Another is late detection, where the signal arrives after recovery has become expensive. Symptom correction occurs when an indicator is pushed back into range while the underlying cause remains. Hidden target shift occurs when actors redefine success to avoid admitting divergence.

More severe failure modes include escalation of commitment, metric capture, and suppressed dissent. In social systems, “correction” can become pressure to conform, so divergence repair must not erase legitimate disagreement.

prose_neighbor_distinctions:
Convergence Guidance is the positive steering pattern; Divergence Detection and Correction is triggered when the process is moving away from target. Instability Dampening reduces volatility, while this archetype focuses on directional worsening. Adaptive Response Recalibration adjusts fit to changing conditions, while this archetype first establishes that the current path is departing from its target.

Objective Function Alignment is needed when the target or metric rewards the wrong behavior. Feedback Loop Redirection changes the feedback structure itself. Convergence Failure Review is a retrospective diagnostic companion when convergence has already failed repeatedly. False Convergence Prevention handles the opposite risk: apparent stability that hides unresolved variation.

prose_cross_domain_examples:
In machine learning, validation loss may increase across updates. The archetype detects persistent divergence, diagnoses causes such as learning rate or data mismatch, and corrects or aborts the training path.

In product delivery, a release may drift away from its intended user problem. A drift review compares the current work with the target outcome and resets scope or governance.

In negotiation, talks may harden positions rather than move toward agreement. A facilitator can detect derailment, separate issues, reframe the process, and escalate unresolved conflict.

In operations, a production process may move away from a target range after a parameter change. Control signals, diagnosis, and rollback restore the operating path.

In education, practice may reinforce a misconception. Assessment detects movement away from mastery and triggers remediation before the error pattern consolidates.

prose_non_examples: A dashboard that only reports status is not this archetype; it lacks diagnosis and correction. A team changing direction after discovering a better goal is explicit adaptation, not divergence correction. Slow convergence is not divergence. Exploratory brainstorming is not divergence merely because ideas differ. A noisy process centered around the target is an instability or damping problem rather than directional failure.

prose_tradeoffs:
Early warning trades off against false alarms. Fast correction trades off against diagnosis depth. Target integrity trades off against adaptation. Centralized correction trades off against local autonomy. Correcting a path trades off against aborting it.

The art is to tune the response to the speed and stakes of divergence. In safety-critical cases, temporary halt or rollback may be warranted before complete diagnosis. In creative or deliberative cases, premature correction can suppress useful exploration or dissent.

prose_invariants_to_preserve:
Directionality must remain visible. The process must be able to tell whether it is moving toward the target, away from it, or sideways. Correction must match cause; otherwise the intervention can deepen failure. Noise must not drive churn. Abort must remain available. Target integrity must be preserved, which means the target can be revised explicitly but should not move silently to hide divergence.

These invariants protect the archetype from becoming either blind persistence or reactive micromanagement.

prose_target_outcomes:
The primary outcome is early divergence visibility: harmful movement away from the target is noticed before it compounds. The second outcome is cause-matched correction, where action addresses the reason convergence is failing. A third outcome is restored convergence path: the process becomes viable enough for ordinary guidance, iteration, or deliberation to continue.

Other target outcomes include bounded loss or drift, cleaner escalation decisions, and responsible exit when the current path cannot be recovered.

prose_parameter_dimensions:
Signal sensitivity determines how much evidence is needed before divergence is suspected. High sensitivity catches problems early but creates false alarms; low sensitivity avoids churn but may detect too late.

Trend window length determines how long a pattern must persist before correction begins. Correction strength determines whether the response is incremental, decisive, reversible, or path-replacing. Diagnosis depth determines how much causal analysis is required before action. Abort threshold determines when correction stops and rollback, escalation, or redesign begins. Monitoring cadence determines whether detection is fast enough for the dynamics of the system.

prose_variants_and_near_names:
Project Drift Correction is a useful variant when the converging object is a project trajectory. Model Training Divergence Control applies to technical fitting or training processes. Negotiation Derailment Recovery applies when deliberation is moving away from agreement. Runaway Error Interception is a risk-focused variant for compounding divergence under time pressure.

Near names include drift correction, course-correction loop, divergence alarm, and runaway error control. Alarms, thresholds, dashboards, and stop-loss rules should usually be treated as mechanisms or components unless they include the full detection, diagnosis, correction, and abort logic.

Project Drift Correction

short_definition: Detects when project scope, decisions, schedule, or work products are moving away from the intended outcome and corrects the path before drift becomes embedded.

distinctive_feature: The converging object is a project trajectory or implementation path, with drift expressed through scope, schedule, decisions, or deliverables.

distinct_from_parent: The parent is domain-general; this variant emphasizes project baselines, scope boundaries, decision records, and coordination checkpoints.

still_same_parent_because: It still detects movement away from target, diagnoses cause, and applies correction or escalation.

source_primes: convergence feedback instability

use_when: The project has a defined target or commitment that current work is departing from.

use_when: Scope, timing, stakeholder interpretation, or design choices are drifting in a way that compounds future cost.

Target Distance Metric

role: Compares current project state with intended outcome.

Divergence Signal

role: Marks compounding scope, schedule, or decision drift.

Correction Rule

role: Defines reset, rescope, reprioritization, or escalation action.

Project Drift Correction Review

role: Structured course-correction workflow.

Decision Record Review

role: Checks whether local decisions still match the original target.

example_domains:
project management
product delivery
policy implementation
research programs

domain: product delivery

example: A release team detects that features are drifting from the intended user problem and resets scope before engineering work compounds.

domain: policy implementation

example: An implementation team notices local interpretations moving away from policy intent and revises field guidance.

failure_modes: Treats legitimate adaptation as drift and blocks useful local learning.

failure_modes: Uses the original plan as an unquestioned target even after context has changed.

Model Training Divergence Control

short_definition: Detects when an optimization, estimation, or training process is moving away from a useful fit and changes learning rate, data, objective, architecture, or stopping behavior.

distinctive_feature: The variant uses formal or semi-formal training signals, but the logic generalizes beyond one algorithm.

distinct_from_parent: The parent can apply to projects, negotiations, policies, and learning; this variant is specialized to iterative model or estimate fitting.

still_same_parent_because: The core intervention is still directional detection plus correction or abort, not a specific mathematical method.

use_when: Repeated updates should improve fit but loss, validation quality, or stability worsens.

use_when: Correction can be made through parameter adjustment, data review, objective repair, or path abort.

Target Distance Metric

role: Represents fit or error relative to a target.

Divergence Trend Window

role: Distinguishes noisy update behavior from sustained worsening.

Abort Condition

role: Stops a failing run or fitting path.

Model Training Divergence Monitor

role: Dashboard or check for worsening training behavior.

Learning Rate Adjustment

role: Parameter correction when step size causes divergence.

example_domains:
machine learning
statistical estimation
simulation calibration
forecast model tuning

domain: machine learning

example: A training run detects exploding loss and lowers step size, changes initialization, or aborts the run.

domain: forecast calibration

example: A forecasting workflow detects that updates increase out-of-sample error and revisits assumptions.

failure_modes: Optimizes the wrong metric and declares correction successful while real performance worsens.

failure_modes: Confuses exploration or early instability with true divergence.

Negotiation Derailment Recovery

short_definition: Detects when deliberation or negotiation is moving away from agreement and repairs the path through issue separation, reframing, evidence review, or process reset.

distinctive_feature: The converging object is agreement or coordinated commitment among actors.

distinct_from_parent: The parent does not require social actors; this variant adds disagreement handling, trust repair, and process legitimacy.

still_same_parent_because: It still begins with divergence detection and uses cause-matched correction to restore a convergence path.

source_primes: convergence feedback sensemaking

use_when: Actors need sufficient agreement but exchanges are increasing disagreement, mistrust, or positional rigidity.

use_when: The group can still recover through process repair rather than abandoning the negotiation.

Divergence Signal

role: Identifies escalation, rigid positions, or loss of shared frame.

Cause Diagnosis Frame

role: Distinguishes substantive conflict from process breakdown.

Escalation Path

role: Routes unresolved derailment to mediation or higher governance.

Negotiation Derailment Repair Protocol

role: Structured repair steps for derailed deliberation.

Agenda Reset

role: Reorders or reframes issues to restore constructive movement.

example_domains:
negotiation
community facilitation
standards committees
team decision-making

domain: standards committee

example: A facilitator detects that debate is hardening factions and separates technical, procedural, and value disagreements.

domain: labor negotiation

example: Mediators identify that talks are moving away from agreement and introduce caucus plus issue bundling.

failure_modes: Suppresses legitimate dissent in the name of restoring convergence.

failure_modes: Treats value conflict as a communication problem only.

Runaway Error Interception

short_definition: Intervenes when divergence is compounding quickly enough that ordinary correction may be too slow.

distinctive_feature: The key feature is compounding divergence under time pressure.

distinct_from_parent: The parent includes ordinary divergence correction; this variant emphasizes high-speed escalation, containment, and rollback.

still_same_parent_because: It still detects movement away from target and applies correction or abort; the difference is urgency and compounding risk.

source_primes: instability feedback convergence

use_when: Errors, losses, conflict, or deviation compound across cycles.

use_when: A fast halt, rollback, containment, or escalation may be safer than gradual correction.

Abort Condition

role: Triggers halt or rollback before harm compounds.

Monitoring Cadence

role: Must be fast enough for runaway dynamics.

Rollback Point

role: Provides a safe prior state.

Loss-Limit Correction Rule

role: Caps exposure before losses compound.

Runbook-Based Course Correction

role: Predefines urgent response steps.

example_domains:
operations safety
finance
incident response
public health response

domain: incident response

example: A service team halts deployment when error rates accelerate away from the recovery target.

domain: finance

example: A trading desk exits a position when losses cross a compounding risk rule.

failure_modes: Invokes emergency correction too often and creates organizational alarm fatigue.

failure_modes: Confuses temporary volatility with runaway divergence.

near_names:
Drift Correction
Course-Correction Loop
Divergence Alarm
Runaway Error Control
Negative Convergence Guidance


Diverse Functional Redundancy

type: archetype

source: generated

batch: First Iteration/Batch 16

aliases:
functional redundancy design
heterogeneous redundancy
diverse backups
alternate functional pathways
multi-path function preservation
function-preserving diversity

related_primes: robustness function equivalence_relation coupling variability uncertainty boundary resource_management network interoperability observability controllability unity_and_variety

slug: redundancy

slug: robustness

slug: function

slug: coupling

slug: variability

slug: uncertainty

slug: boundary

slug: network

slug: interoperability

components:
Function Definition
Alternative Pathway
Functional Equivalence Check
Diversity Requirement
Common-Mode Failure Map
Independence Check
Activation or Selection Rule
Coverage and Capacity Profile
Pathway Health Signal
Coordination Interface
Degradation Priority
Pathway Exercise Cadence
Cost and Complexity Guardrail
User Pathway Guidance

mechanisms:
Multi-Modal Transport Plan
Alternate Communication Channels
Cross-Training Program
Diverse Supplier Network
Independent Safety System
Diverse Data Source Triangulation
Heterogeneous Technology Stack
Manual Fallback Workflow
Mixed-Channel Service Delivery
Diverse Implementation Voting

essence_one_line: Provide multiple distinct ways to fulfill the same function so common-mode failure is less likely.

compression_statement: When duplicate components or a single pathway can fail together, design functionally equivalent but meaningfully different pathways so the same critical function can survive different disruptions, dependencies, and failure modes.

core_intuition: The important question is not whether there is “more than one” thing, but whether there is more than one way for the function to happen. Diverse Functional Redundancy works when alternatives are equivalent enough to preserve the function but different enough that one disruption is unlikely to defeat them all.

canonical_formula: critical function + alternative pathways + functional equivalence check + diversity requirement + common-mode failure map + activation rule -> function continuity under differentiated failure exposure

structural_problem: A critical function depends on one pathway, or on multiple pathways that are so similar or tightly coupled that a single upstream dependency, design flaw, environmental condition, authority failure, or operating assumption can disable them together.

condition: Critical function has correlated failure exposure

description: Multiple elements appear redundant, but they share a dependency, design principle, supply chain, operator, location, data source, or control path.

condition: Simple duplication is insufficient

description: A second copy of the same component does not adequately protect the function because the copies can fail for the same reason.

condition: Different means can deliver acceptable functional equivalence

description: There are plausible alternative ways to provide the same service, protective action, information, movement, supply, or decision function.

condition: Continuity matters more than optimization through uniformity

description: Uniform systems are efficient and easier to manage, but the cost of correlated collapse is high enough to justify heterogeneous pathways.

condition: Common-mode risk can be named and tested

description: The design can identify which shared hazards or dependencies the diverse pathways are meant to withstand.

symptom: False redundancy

meaning: The system has backups or alternates on paper, but all of them depend on the same platform, power source, credential, vendor, team, or location.

symptom: Single-channel fragility

meaning: A function such as communication, transport, intake, supply, or control flows through one dominant pathway even though alternate ways are possible.

symptom: Uniform design monoculture

meaning: The system standardizes on one technology, process, training model, supplier type, data source, or operating assumption so one flaw can propagate widely.

symptom: Backup fails during the same incident

meaning: The alternate path is discovered to rely on the same disrupted dependency as the primary path.

symptom: Substitutes exist but are not functionally equivalent

meaning: Alternatives can do something similar, but cannot meet the timing, scale, quality, safety, or authority requirements of the protected function.

symptom: Operators improvise alternate paths under stress

meaning: People repeatedly invent workarounds during disruption because no validated diverse pathways exist beforehand.

root_tension: Efficiency pushes systems toward uniformity, standardization, concentration, and single best paths. Resilience against correlated failure requires enough variety to keep the same function alive when the dominant path and its similar backups fail. The design problem is to maintain useful diversity without creating uncontrolled complexity, incompatible interfaces, or false equivalence.

anti_signatures: The main need is a duplicate of the same component, actor, supplier, or record; use redundant_backup_provisioning instead.

anti_signatures: The alternate capacity already exists and the problem is only when to switch to it; use failover or activation mechanisms.

anti_signatures: The function can simply stop safely on failure; use fail_safe_default or protective shutdown patterns.

anti_signatures: The system only needs a larger margin within the same design path; use robustness_margin_design.

anti_signatures: The alternatives are different but do not perform the same function; use portfolio or optionality patterns rather than functional redundancy.

anti_signatures: The supposed diversity cannot be maintained, accessed, governed, or validated in the real operating context.

structural_intervention: Define the critical function, create or maintain multiple alternative pathways that can satisfy that function, verify functional equivalence, impose a meaningful diversity requirement, test common-mode independence, and govern activation, coordination, and maintenance of the pathways.

step: Name the function, not the asset

logic: Start with what must continue: communication, mobility, care, supply, protection, identity verification, payment, decision-making, or another function. Avoid beginning with a favorite backup technology.

step: Map current and possible pathways

logic: List the primary path, nominal backups, workarounds, human routes, technical routes, institutional routes, and ecological or supply alternatives that might satisfy the same function.

step: Define functional equivalence

logic: Specify the minimum acceptable quality, time, scale, safety, authority, and user experience required for an alternate path to count as preserving the function.

step: Specify the required kinds of difference

logic: Decide which differences matter for the threat model: geography, vendor, technology, energy source, medium, organization, skill base, protocol, data source, or operating principle.

step: Map common-mode dependencies

logic: Look for hidden coupling that could defeat all paths at once, including shared credentials, platforms, policy permissions, staff, weather, fuel, data, or upstream suppliers.

step: Design activation and coordination rules

logic: Decide whether pathways run in parallel, standby, rotation, or context-specific use, and define how demand shifts when one pathway is impaired.

step: Exercise and monitor each pathway

logic: Run drills, test traffic, audits, supplier checks, data comparisons, or ecological monitoring so alternate paths remain real rather than ceremonial.

step: Review cost and complexity

logic: Retire pathways that add little independent value, and invest in those that materially reduce correlated failure of the critical function.

rule: Equivalence before diversity.

rationale: A different path is useful only if it can actually preserve the named function within the minimum acceptable bounds.

rule: Diversity must match the failure model.

rationale: Differences that do not reduce the relevant common-mode risk are decorative rather than protective.

rule: Independence claims require testing.

rationale: Hidden shared dependencies often remain invisible until exercises, audits, simulations, incidents, or dependency maps reveal them.

rule: Do not diversify every function equally.

rationale: The archetype is most valuable for functions whose correlated failure would create serious safety, continuity, mission, equity, or recovery harm.

rule: Coordinate distinct paths before stress.

rationale: Without routing, authority, interface, and reconciliation rules, diverse pathways may compete, duplicate work, fragment state, or confuse users.

rule: Prefer lived pathways over dormant symbols.

rationale: A path that is periodically used or tested is more reliable than a nominal alternate that no one can activate under pressure.

target_invariants: The named critical function remains available through at least one validated pathway when another pathway fails.

target_invariants: Alternative pathways are different in failure-relevant ways, not merely different labels for the same dependency chain.

target_invariants: Functional equivalence criteria remain explicit so substitutes do not silently lower service, safety, or fairness below acceptable bounds.

target_invariants: Common-mode dependencies are visible enough to be tested, monitored, and reduced over time.

target_invariants: Coordination across pathways preserves coherent state, accountability, user guidance, and recovery priorities.

expected_outcomes: Lower probability that one disruption disables all ways of providing a critical function.

expected_outcomes: Improved continuity across outages, supply disruptions, staffing shocks, communication failures, environmental stress, and design flaws.

expected_outcomes: Earlier discovery of false redundancy and hidden shared dependencies.

expected_outcomes: More flexible operation under regime change because the system has practiced multiple ways to satisfy the same need.

expected_outcomes: Reduced dependence on improvisation during crisis, while preserving enough variety for adaptation.

prose_essence:
Diverse Functional Redundancy is the pattern of protecting a function by keeping more than one real way to perform it. The central distinction is **functional equivalence plus failure-relevant difference**. A system does not become resilient merely because it has two copies of the same fragile thing. It becomes more resilient when the same function can move through paths that do not all share the same weak point.

The archetype is especially important when apparent redundancy hides common-mode failure. A city may have many digital communication tools, but if every tool depends on the same internet provider and authentication system, the warning function is still exposed. A hospital may have backup intake forms, but if nobody can authorize or reconcile them, the intake function is not truly preserved. The pattern asks: what function must continue, what paths can provide it, and why would those paths not fail together?

prose_when_to_use:
Use this archetype when a critical function is too important to depend on one pathway or on several nearly identical pathways. It fits disruptions where the danger is correlated failure: one vendor outage, one software defect, one supply shock, one staffing model, one communication medium, one geography, one authority bottleneck, or one environmental condition can defeat many nominal backups at once.

It is not necessary for every function. It is strongest where continuity, safety, equity, or mission performance would be harmed by losing the function, and where different ways of providing the function can be maintained without creating more complexity than they solve.

prose_structural_problem:
The structural problem is false variety. The system appears to have options, but those options are not independent enough or equivalent enough to protect the function. Similar copies share the same hidden dependency. Different tools perform related but not equivalent work. Alternate channels exist but are not usable by the people who need them. Backups are listed but untested.

The root tension is between efficient standardization and resilient variety. Standardization makes systems cheaper, cleaner, and easier to govern. It also creates monocultures: one assumption, platform, source, or rule can propagate failure everywhere. Diverse Functional Redundancy deliberately pays some complexity cost to avoid all paths breaking in the same way.

prose_intervention_logic:
The intervention starts by naming the function independently of its current delivery path. Then it identifies possible alternative pathways and checks whether each one can perform the function within acceptable bounds. After that, it imposes a diversity requirement: the pathways must differ in ways that matter for the expected hazards. Finally, the design tests common-mode exposure, defines activation or selection rules, monitors pathway health, and coordinates outputs so the alternatives remain one coherent function rather than a pile of disconnected workarounds.

This is not random diversification. Every alternate path must answer two questions: **Can it do the same job?** and **Why would it survive a different set of failures?**

prose_key_components:
### Function Definition

The function definition names what must continue: warning the public, moving supplies, registering patients, preserving identity verification, providing protective control, or delivering a public service. This prevents the design from protecting a tool instead of the work the tool performs.

### Alternative Pathway

An alternative pathway is one distinct way to provide the same function. It may differ by channel, technology, team, geography, supplier, authority route, data source, or biological pathway. The important test is whether the path is both usable and meaningfully different.

### Functional Equivalence Check

The functional equivalence check asks whether the alternate path really preserves the function. It defines acceptable quality, timing, scale, safety, authority, and fairness. Without this check, a system can claim redundancy through alternatives that do not actually meet the need.

### Diversity Requirement

The diversity requirement states what kind of difference matters. For one system, geographic diversity may matter; for another, vendor diversity, technology diversity, energy-source diversity, staffing diversity, channel diversity, or data-source diversity may matter. This is the main boundary from simple redundancy.

### Common-Mode Failure Map

The common-mode failure map identifies shared dependencies that can defeat apparently different paths. It asks what all paths still rely on: one provider, credential, control room, regulation, data feed, staff role, weather exposure, fuel source, or assumption.

### Independence Check

The independence check validates whether the pathways are independent enough for the named failure scenario. It does not require perfect independence. It requires enough separation to make correlated failure less likely for the function being protected.

### Activation or Selection Rule

The activation or selection rule says when each path is used. Some paths run in parallel, some rotate, some are standby, and some are selected by context. Without this rule, pathway diversity can become confusion during disruption.

### Coverage and Capacity Profile

The coverage profile states how much of the function each path can carry and for how long. An alternate path may preserve the function for priority users or for a limited period without covering full normal demand.

### Pathway Health Signal

A pathway health signal shows whether each path is still alive. It may be a drill, test transaction, supplier audit, staffing readiness check, data-source freshness measure, or ecological indicator. Diversity decays if it is not monitored.

### Coordination Interface

The coordination interface lets different paths converge. It handles routing, state reconciliation, message consistency, user guidance, safety constraints, and accountability.

prose_common_mechanisms:
### Multi-Modal Transport Plans

A multi-modal transport plan implements the archetype when the same movement function can shift across road, rail, air, water, walking, cycling, or emergency shuttle routes. The mechanism is not the archetype by itself; it is one way to create distinct pathways for movement.

### Alternate Communication Channels

Alternate communication channels preserve the message-delivery function through media with different failure exposures. SMS, radio, sirens, phone trees, in-person notice, and public signage can complement one another when the design checks reach, timing, message consistency, and activation authority.

### Cross-Training Programs

Cross-training creates human pathway diversity. Different people or teams can perform the same function when the primary role is absent, overloaded, or inaccessible. It works only if the alternate performer also has authority, access, practice, and accountability.

### Diverse Supplier Networks

A diverse supplier network protects an input function by using sources that differ in geography, logistics, ownership, production method, or upstream dependency. It is stronger than a backup supplier list when the suppliers are selected to avoid failing together.

### Independent Safety Systems

Independent safety systems implement diverse redundancy for protective control. Separate sensors, logic, power, or actuators can preserve the same safety function even when one protective path fails. These designs need conservative testing because false independence can be dangerous.

### Diverse Data Source Triangulation

Data-source triangulation preserves an informational function by using sources with different collection methods, biases, lags, and failure modes. It is useful when one data feed can be stale, manipulated, missing, or systematically biased.

### Heterogeneous Technology Stacks

A heterogeneous technology stack uses different technical implementations for critical capability. This can reduce dependence on one codebase, vendor platform, or design assumption, but it also raises maintenance and interface costs.

### Manual Fallback Workflows

A manual fallback workflow can be a genuinely different pathway when an automated system fails. It must still satisfy the function’s minimum timing, quality, authority, privacy, and reconciliation requirements.

### Mixed-Channel Service Delivery

Mixed-channel service delivery lets people access the same service online, by phone, in person, by mail, through partners, or through outreach teams. It can protect both continuity and accessibility, but only if the channels remain functionally equivalent enough.

### Diverse Implementation Voting

Diverse implementation voting compares outputs from independently built implementations. It can reduce the chance that one defect or assumption drives an irreversible action, though it requires rules for disagreement and escalation.

prose_failure_modes:
The most common failure mode is **false diversity**. The paths look different but share the same dependency. Another is **non-equivalent substitution**, where an alternate path exists but cannot satisfy the function at the needed quality or scale. **Coordination conflict** occurs when multiple paths produce inconsistent state or competing actions. **Dormant-path decay** happens when an alternate is never practiced and becomes unusable. **Complexity overload** occurs when too many pathways become harder to manage than the risk justifies.

A subtler failure mode is **diversity collapse over time**. Consolidation, standardization, procurement efficiency, and platform migration can gradually remove the differences that made the pathways protective.

prose_neighbor_distinctions:
Diverse Functional Redundancy is close to Redundant Backup Provisioning, but it is not the same. Backup provisioning asks whether substitute capacity exists; this archetype asks whether the substitutes are different enough to avoid failing together.

It is close to Fault-Tolerant Operation, but fault tolerance is about continuing operation despite partial failure using detection, isolation, masking, bypass, or compensation. Diverse Functional Redundancy may support fault tolerance, but it is specifically about function-preserving pathway diversity.

It is close to Failover, but failover is the switch. This archetype is the structure that gives the switch meaningfully different destinations.

It is close to Common-Mode Failure Analysis, but that is diagnostic. Diverse Functional Redundancy is the design intervention that responds to the diagnosis.

It is close to Graceful Degradation, but degradation accepts reduced function. Diverse Functional Redundancy tries to preserve the same function through another path, although the alternate path may have less capacity.

prose_cross_domain_examples: In emergency management, warnings can be sent through sirens, SMS, radio, door knocks, signage, and local partners. In supply chains, critical inputs can come from sources with different geographies and logistics. In healthcare, patient intake can continue through digital forms, paper forms, cross-trained staff, and manual verification. In public services, enrollment can be available online, by phone, through offices, through mail, and through community partners. In ecology, different species can preserve pollination or soil functions under different conditions. In software, independently implemented services can check one another before critical action.

prose_non_examples: Two identical servers in the same rack are not Diverse Functional Redundancy if they share one power, network, region, and code defect exposure. Extra inventory of the same item in one warehouse is buffering, not pathway diversity. A backup supplier using the same upstream manufacturer is only a nominal alternate. A safe shutdown is fail-safe behavior, not preservation of the same function. A portfolio of unrelated assets is diversification, but not functional redundancy unless the assets can fulfill the same critical function.

prose_tradeoffs:
Diverse Functional Redundancy trades efficiency for survivability. It may duplicate work, increase interface complexity, complicate procurement, require broader training, and make governance harder. It can also create inequity if some users are routed to weaker channels.

The answer is not endless variety. The best use of the archetype is selective: protect critical functions, choose differences that match real failure modes, test the pathways, and remove diversity that is expensive but not protective.

prose_invariants_to_preserve:
The core invariant is that the named critical function remains available through at least one validated path when another path fails. A second invariant is that the paths remain different in failure-relevant ways. A third is that substitutes remain functionally equivalent enough: an alternate route, team, supplier, or channel should not silently lower safety, fairness, legitimacy, or quality below the accepted floor.

The design should also preserve visibility of common-mode dependencies. Once hidden shared dependencies become invisible again, the system drifts back toward false redundancy.

prose_target_outcomes:
The desired outcome is reduced correlated failure. The system should be less likely to lose a function because one shared dependency breaks. It should discover false redundancy earlier, recover with less improvisation, route demand more intelligently, and support continuity across different disruption types.

A secondary outcome is adaptive flexibility. Practiced alternative pathways give people more ways to think and act when the operating regime changes.

prose_parameter_dimensions:
The main tuning dimension is **how much diversity is enough**. A design may need two pathways with strong independence or several pathways with partial independence. More pathways are not automatically better; each adds cost, complexity, training, coordination, and maintenance.

Other parameters include the functional equivalence threshold, tolerated degradation, pathway capacity, activation speed, independence standard, exercise cadence, user routing rule, interface strictness, and cost guardrail. Safety-critical systems usually need stricter independence and testing. Public-service systems often need stronger accessibility and fairness criteria. Ecological systems need attention to relationships among pathways, not just countable substitutes.

prose_variants_and_near_names:
The main variants are multi-modal pathway redundancy, cross-trained functional substitution, diverse supplier or input redundancy, biological degeneracy, and independent safety channel redundancy. Near names include functional redundancy design, heterogeneous redundancy, diverse backups, alternate pathways, multi-modal backup, and degeneracy.

Concrete items such as alternate communication channels, cross-trained teams, diverse supplier lists, independent safety systems, and diverse data sources should usually be treated as mechanisms or variants, not as separate top-level archetypes. Common-Mode Failure Analysis remains a close second-wave candidate because it has its own diagnostic logic.

Multi-Modal Pathway Redundancy

short_definition: Preserves a function through different physical, informational, or service channels rather than through multiple copies of the same channel.

distinctive_feature: The diversity comes from using different modes or channels, not merely different instances within the same mode.

distinct_from_parent: The parent covers any distinct means to fulfill the function; this variant focuses on channel or mode differences.

still_same_parent_because: Each mode remains an alternative pathway for the same protected function.

use_when: The same function can be delivered through different modes such as road and rail, online and in-person, or radio and phone.

use_when: A single channel is vulnerable to outage, congestion, exclusion, regulation, or environmental disruption.

use_when: Users or operators can be guided toward the pathway that remains available under current conditions.

Function Definition

role: Names the function that must be preserved across distinct pathways and states the minimum acceptable outcome that counts as the same function.

notes: The function definition prevents the design from confusing surface similarity with real substitutability. It should describe the job-to-be-done, users or beneficiaries, quality floor, timing needs, and unacceptable losses.

Alternative Pathway

role: Represents one distinct way to deliver the same named function through a different channel, actor, technology, process, resource, or ecological route.

notes: A pathway is not diverse merely because it has a different label. It should differ in some dependency, mechanism, environment, skill base, or failure exposure that matters under stress.

Functional Equivalence Check

role: Tests whether each alternative pathway can actually satisfy the protected function within defined quality, timing, safety, and scale limits.

notes: Different pathways often deliver different versions of a function. The equivalence check makes the accepted loss explicit and prevents decorative alternatives from being mistaken for real redundancy.

Diversity Requirement

role: Specifies the kinds of difference the pathways must have in order to reduce common-mode failure: vendor, medium, design principle, geography, skill base, energy source, authority path, or dependency chain.

notes: This component is the core distinction from simple redundancy. A second copy of the same thing may increase capacity, but a differently constituted pathway reduces correlated failure only when the relevant differences are real.

Activation or Selection Rule

role: Defines when different pathways are used, whether they operate simultaneously or in standby, and how the system shifts demand when one pathway degrades.

notes: Diverse pathways can create confusion unless selection rules are explicit. The rule may route by context, severity, availability, user need, risk level, cost, or evidence of primary-path failure.

Coordination Interface

role: Lets outputs from different pathways converge without conflict, duplicate harm, inconsistent state, or incompatible handoffs.

notes: Functional diversity can introduce mismatch. The interface coordinates routing, reconciliation, user guidance, state consistency, accountability, and escalation so multiple paths remain one coherent function.

Multi-Modal Transport Plan

mechanism_type: method

role: Uses different transport modes such as road, rail, air, water, walking, or cycling to preserve movement of people or goods when one mode is disrupted.

Alternate Communication Channels

mechanism_type: protocol

role: Maintains distinct channels such as SMS, radio, phone trees, email, in-person notice, or public posting so communication can continue when one medium fails.

Mixed-Channel Service Delivery

mechanism_type: workflow

role: Offers the same service through different channels such as online, phone, physical office, outreach worker, kiosk, or partner organization.

example_domains:
transportation
public service delivery
emergency communication
education access

domain: Emergency management

example: A city uses sirens, SMS alerts, radio, social media, door knocks, and public signage to communicate evacuation orders.

domain: Transport logistics

example: A supply chain can route critical goods by truck, rail, or air depending on which mode remains available.

failure_modes: All modes still depend on the same dispatch authority or data feed.

failure_modes: Users do not know which channel to use under stress.

failure_modes: The alternate mode works only at a scale too small for the protected function.

Cross-Trained Functional Substitution

short_definition: Builds overlapping functional capability across different people, teams, or roles so the same function can continue despite absence, overload, or role-specific failure.

distinctive_feature: The redundant pathways are human capability and role structures rather than machines, suppliers, or channels.

distinct_from_parent: The parent covers all function-preserving diversity; this variant focuses on people, training, authority, tacit knowledge, and coverage.

still_same_parent_because: The structural intervention remains multiple distinct ways to fulfill the same named function.

use_when: A critical function depends on one role, team, expert, or shift.

use_when: The alternate performer must use different knowledge, location, authority path, or team structure to reduce correlated failure.

use_when: The system can exercise the substitution without undermining accountability.

Pathway Health Signal

role: Provides observability into whether each pathway remains usable, degraded, overloaded, stale, or exposed to new shared risks.

notes: Diverse redundancy silently decays when an alternate channel is never exercised or monitored. Health signals can include drills, test traffic, supplier performance, staffing readiness, data-source freshness, or ecological indicators.

Cross-Training Program

role: Builds different people or teams with overlapping functional capability so the function can be performed through another skill base or role structure.

Manual Fallback Workflow

role: Preserves a function through a human or paper-based process when the digital, automated, or centralized path is unavailable.

example_domains:
healthcare staffing
public administration
education operations
field service

domain: Healthcare operations

example: Multiple staff categories are trained to perform essential intake tasks when the primary intake team is unavailable.

domain: Public administration

example: A permit function can be performed by a regional office or central surge team using different authority and staffing paths.

failure_modes: Cross-trained people lack real authority or access.

failure_modes: Training is too superficial for functional equivalence.

failure_modes: All substitute roles are exposed to the same staffing shortage or labor policy constraint.

Diverse Supplier or Input Redundancy

short_definition: Maintains different sources, inputs, or production routes that can satisfy the same supply or resource function under disruption.

distinctive_feature: The diversity criterion is applied to supply origins, input forms, and production routes.

distinct_from_parent: The parent is domain-general; this variant focuses on procurement, supply chains, and input continuity.

still_same_parent_because: Each supplier or input route is a distinct way to fulfill the same critical resource function.

use_when: A critical input has backups that may fail together because they share geography, logistics, ownership, technology, regulation, or upstream materials.

use_when: Different input forms or supplier categories can be made acceptable through qualification and interface rules.

use_when: The organization can manage cost, quality, and governance across multiple sources.

Common-Mode Failure Map

role: Identifies shared dependencies, correlated hazards, common assumptions, or single upstream causes that could make multiple pathways fail together.

notes: The map turns diversity from a vague virtue into an auditable claim. It asks what all pathways still depend on, including people, permissions, power, data, climate, policy, platform, supplier, or cultural assumptions.

Independence Check

role: Validates that the alternative pathways are independent enough for the specific failure mode the design is trying to survive.

notes: Perfect independence is usually impossible. The check asks whether the remaining coupling is acceptable for the named hazard and whether the pathways should be separated, diversified, or monitored further.

Coverage and Capacity Profile

role: Describes how much of the function each pathway can carry, for how long, at what quality level, and under which operating constraints.

notes: A pathway may be functionally equivalent for small loads but not full demand. The profile makes partial coverage explicit and supports graceful rationing or prioritization when diversity cannot preserve everything.

Diverse Supplier Network

mechanism_type: institution

role: Uses suppliers with different geographies, ownership, logistics, technologies, or input sources to reduce correlated supply failure.

example_domains:
manufacturing
food systems
healthcare supply chains
public procurement

domain: Manufacturing

example: A plant qualifies suppliers in different regions using different logistics routes for a critical material.

domain: Food systems

example: A cafeteria can source acceptable protein from local farms, distributors, and shelf-stable inventory when one channel fails.

failure_modes: All suppliers rely on the same upstream source.

failure_modes: Quality or compliance rules make the alternate input unusable.

failure_modes: Maintaining many suppliers creates administrative burden and weak relationships.

Biological Degeneracy

short_definition: Uses different structures or processes that can produce overlapping biological or ecological functions under different conditions.

distinctive_feature: The same function emerges from structurally different living pathways rather than engineered duplicate components.

distinct_from_parent: The parent is cross-domain; this variant preserves the established biological name and examples.

still_same_parent_because: It is still a case of distinct pathways fulfilling overlapping functions.

use_when: The domain is biological, ecological, or biomimetic.

use_when: Different organisms, tissues, pathways, or behaviors can sustain the same functional role.

use_when: The design goal is resilience of function rather than uniform replacement of parts.

Species Functional Group Mix

role: Maintains different species or ecological actors that can provide overlapping ecosystem functions under varying conditions.

Redundant Metabolic Pathways

role: Uses alternative biochemical routes that can produce needed function when one pathway is constrained.

example_domains:
ecology
biology
agriculture
biomimetic design

domain: Ecology

example: Different pollinator species sustain pollination when weather, disease, or seasonality affects one species.

domain: Agriculture

example: A mixed cropping system preserves soil or pest-control functions through different plant traits.

failure_modes: Species appear different but share the same vulnerability.

failure_modes: Functional overlap is assumed without ecological evidence.

failure_modes: Management simplifies the system until functional diversity disappears.

Independent Safety Channel Redundancy

short_definition: Uses independent protective channels with different sensing or action logic so a hazard can be controlled even if one safety path fails.

distinctive_feature: The function being redundantly preserved is protective control, not ordinary service delivery.

distinct_from_parent: The parent is broader; this variant highlights safety-critical independence and safe-state coordination.

still_same_parent_because: Multiple distinct channels still fulfill the same protective function.

use_when: Failure of a single protective channel could expose people, assets, or environment to unacceptable harm.

use_when: Independent sensing, power, control, or actuation can be maintained and tested.

use_when: The safety channels must converge on a coherent safe state rather than fight each other.

Independent Safety System

mechanism_type: other

role: Provides a separate safety path using different sensing, control, energy, or actuation logic so one design flaw or dependency is less likely to defeat all protection.

Diverse Implementation Voting

role: Compares outputs from independently designed implementations so one flawed implementation is less likely to determine the final result alone.

example_domains:
industrial safety
aviation
medical devices
critical infrastructure

domain: Industrial safety

example: A process plant uses independent pressure relief and automated shutdown channels to control the same hazard.

domain: Aviation

example: Different instruments and procedures provide overlapping flight-safety information when one source becomes unreliable.

failure_modes: Channels share one power or control dependency.

failure_modes: Protective paths trigger conflicting actions.

failure_modes: Maintenance disables multiple channels at once.

near_names:
Functional Redundancy Design
Diverse Backups
Heterogeneous Redundancy
Alternate Pathways
Degeneracy
Multi-Modal Backup
Alternate Communication Channels
Cross-Trained Teams
Independent Safety Systems


Domain–Codomain Delimitation

batch: First Iteration/Batch 08/Wave 2

Input–Output Scope Definition

notes: Plain-language expression of the same intervention when formal domain/codomain terms are too technical.

Applicability Boundary

notes: Often used when the concern is whether a model, rule, policy, or process may validly be applied.

Valid Range Specification

notes: Usually narrower and often numeric; retained as a near name rather than a full archetype.

Supported Use Boundary

notes: Useful for product, policy, or service contexts where supported and unsupported cases must be separated.

source_primes: function set_and_membership boundary closure

related_primes: constraint boundedness data_integrity fail_safe observability versioning accountability interoperability

slug: closure

slug: constraint

slug: boundedness

slug: versioning

slug: accountability

components:
Functional Unit Under Scope
Input Domain
Output Codomain
Membership Criteria
Unsupported Case Boundary
Safe Rejection or Deferral Path
Output Conformance Rule
Scope Stewardship
Precondition Statement
Conversion or Adaptation Rule
Edge Case Catalog
Test Cases and Counterexamples
Versioned Scope Notice
Exception Review Path

mechanisms:
Input Validation Gate
Output Schema
Output Validation
Type Signature
Eligibility Criteria
Service Scope Statement
Clinical Indication Criteria
Model Applicability Card
Contract Test Suite
Unsupported Case Triage Workflow
Scope Change Review

essence_one_line: Define valid inputs and valid outputs so a function or process does not receive, produce, or promise out-of-scope values.

compression_statement: When transformation fails because inputs, contexts, or output promises are poorly bounded, delimit the valid input domain and output codomain, specify unsupported cases, and provide safe rejection, conversion, deferral, or escalation paths to preserve validity and prevent unsupported use.

core_intuition: A function, process, model, role, or service does not become reliable merely because it has a name. It becomes safe to use when users know what it can accept, what it can return, what it cannot handle, and what happens at the boundary. Domain–Codomain Delimitation turns vague scope into operational membership tests and output promises.

canonical_formula: domain_codomain_delimitation = supported_input_set + promised_output_set + membership_tests + unsupported_case_path + output_conformance_rule + scope_stewardship

structural_problem: A function, policy, process, model, role, or service is applied to inputs it cannot validly handle, or is expected to produce outputs outside its intended range, because the input domain and output codomain are implicit, disputed, or stale.

description: Requests, cases, data, users, states, or preconditions outside the supported domain enter ordinary processing.

description: Users or downstream systems expect results, remedies, guarantees, decisions, formats, or categories the function is not designed or authorized to provide.

description: A once-bounded function gradually absorbs borderline cases without revising assumptions, staffing, tests, or safeguards.

description: A model, rule, policy, or procedure is used in contexts unlike those for which it was validated or authorized.

description: Out-of-domain cases fall through defaults, informal judgment, or silent failure rather than being rejected, converted, deferred, or escalated.

symptom: Different teams disagree over whether a case is in scope.

interpretation: The input domain is socially or technically under-specified.

symptom: Users treat an advisory score, checklist, or triage output as a stronger decision than intended.

interpretation: The output codomain and promise level are not explicit.

symptom: Validation rules reject malformed cases but still admit semantically unsupported cases.

interpretation: Mechanisms exist, but the real domain boundary has not been defined.

symptom: A process repeatedly escalates exceptions only after harm, delay, or rework occurs.

interpretation: Unsupported-case routing is missing from the boundary design.

symptom: Integrations, policies, or workflows break when a new input category appears.

interpretation: The domain boundary was assumed rather than maintained and versioned.

root_tension: The system needs a boundary strict enough to prevent invalid use and unsupported promises, while leaving enough adaptation room for borderline cases, changing conditions, and legitimate exceptions.

case: The whole behavior of a component is ambiguous, not just its valid input and output scope.

why_not: Use functional_specification when transformation rules, edge-case behavior, and verification criteria all need to be specified together.

case: The central issue is which relationships among entities are valid.

why_not: Use relation_constraint_enforcement when the problem is invalid association, cardinality, compatibility, or dependency relations rather than input/output scope.

case: The system must preserve invariants across operations after inputs are already admitted.

why_not: Use closure_preserving_operation or invariant_guarding when the central issue is maintaining valid state under transformation.

case: A simple validation check is sufficient and the scope is already clear.

why_not: Treat input_validation or output_validation as mechanisms rather than drafting this archetype.

case: The problem is broad organizational or product scope, not a bounded mapping from cases to outputs.

why_not: Use system_scope_definition or boundary_reframing when the unit of concern is the system boundary rather than a function-like input-output relation.

structural_intervention: Define the valid input space, valid output space, membership tests, unsupported-case handling, output conformance checks, and stewardship rules for a function-like element before it is used, integrated, promised, or governed.

logic: Name the process, model, service, role, policy, API, protocol, or workflow whose valid inputs and outputs must be bounded.

logic: Specify which values, cases, users, states, evidence, preconditions, contexts, or requests are supported.

logic: Specify which outputs, decisions, deliverables, result categories, formats, confidence levels, remedies, or promises may be produced.

logic: Convert the boundary into criteria, examples, counterexamples, thresholds, or tests that users and implementers can apply.

logic: Define what happens to out-of-domain, out-of-codomain, ambiguous, or borderline cases: rejection, conversion, deferral, escalation, referral, or safe fallback.

logic: Attach validation, contract tests, schema checks, review gates, or monitoring so boundary violations are detected rather than assumed away.

logic: Identify who may revise the boundary and how changes propagate to users, tests, documentation, dependent systems, and exception pathways.

description: State the boundary where another actor, system, or decision will rely on the function, not only inside internal documentation.

description: Distinguish inputs that are impossible or unsafe from inputs that are valid but not yet supported.

description: Every important exclusion should have an appropriate rejection, appeal, referral, escalation, or conversion path.

description: Format checks are not enough when semantic assumptions, populations, contexts, or promises define validity.

description: Boundary changes require notification and migration support when callers, users, tests, or downstream systems rely on the old scope.

description: Strict boundaries should be audited for unfair exclusion, unsafe denial, hidden proxies, or accountability avoidance.

description: Users and maintainers can determine whether a case belongs inside, outside, or at the edge of the supported domain.

description: The function produces or promises only outputs that fall inside the declared codomain and authority scope.

description: Out-of-domain or ambiguous cases do not silently flow through ordinary processing without safe handling.

description: Boundary violations, exceptions, and recurring edge cases are visible enough to govern and revise.

description: Changes to domain, codomain, or unsupported-case behavior are propagated to users and dependent systems.

description: Unsupported inputs are rejected, redirected, converted, or escalated before invalid processing occurs.

description: Users and systems stop expecting outputs, decisions, remedies, or guarantees outside the codomain.

description: Integrations and handoffs become more reliable because valid input and output expectations are explicit.

description: Borderline cases are routed through visible paths rather than being hidden in defaults or informal discretion.

description: Scope creep and validity drift are detected through stewardship, monitoring, and versioning.

prose_essence:
Domain–Codomain Delimitation bounds the valid use of a function-like unit. It asks two practical questions before the unit is relied on: **what may validly enter?** and **what may validly come out?** The answer can apply to a software function, public service, clinical protocol, data model, machine-learning system, organizational team, policy pathway, or any process that accepts cases and produces outputs.

The archetype is useful when a named function appears reliable but its scope is ambiguous. People send it unsupported cases, expect outputs it cannot legitimately produce, or treat boundary failures as ordinary exceptions. Delimitation makes the supported input domain, output codomain, unsupported cases, and safe routing visible enough to test, govern, and revise.

prose_when_to_use:
Use this archetype when invalid or unsupported use is the core failure. A service receives requests it was never designed to handle. A model is applied to populations outside its validation evidence. A policy pathway is expected to produce remedies it cannot authorize. A data pipeline accepts inputs that look well-formed but violate semantic assumptions. A team receives work that belongs elsewhere and quietly absorbs it until quality collapses.

It is especially strong when the boundary must be more than a disclaimer. The input domain and output codomain should affect intake, routing, validation, testing, user expectations, and revision authority. If the only needed action is to add a single field-level check, use an input-validation mechanism instead. If the whole behavioral contract is ambiguous, use Functional Specification.

prose_structural_problem:
The structural problem is a mismatch between a function-like unit and the cases or promises attached to it. The unit may have a name, owner, interface, workflow, or policy label, but its valid operating set is not explicit. As a result, out-of-domain inputs enter ordinary processing and out-of-codomain outputs are produced, inferred, or promised.

This creates several recurring symptoms: users disagree about what belongs in scope; downstream systems assume unsupported outputs; exception handling happens late and informally; validation checks superficial shape but not real applicability; and scope changes accumulate without stewardship. The deeper tension is that the system needs enough boundary precision to preserve validity while retaining humane and adaptive handling for legitimate edge cases.

prose_intervention_logic:
The intervention starts by naming the functional unit under scope. Then it defines the input domain: the supported values, requests, cases, users, states, evidence, preconditions, and contexts. It also defines the output codomain: the allowed result categories, decision types, formats, remedies, confidence levels, or promises.

The boundary becomes operational through membership criteria, examples, counterexamples, validation or review mechanisms, and unsupported-case paths. Out-of-domain cases should not disappear into silent failure. They should be rejected, converted, deferred, referred, escalated, appealed, or handled by a safe fallback according to the risk and domain. Finally, stewardship keeps the boundary from drifting as cases, technologies, laws, users, or downstream dependencies change.

prose_key_components:
- **Functional Unit Under Scope** identifies the process, model, service, policy, role, API, or workflow being bounded. Without this, the boundary becomes an unfocused scope statement.
- **Input Domain** defines what may validly enter: cases, data, users, states, requests, evidence, preconditions, or contexts.
- **Output Codomain** defines what may validly come out: result classes, response formats, decisions, remedies, deliverables, guarantees, or state changes.
- **Membership Criteria** translate the boundary into usable rules, thresholds, predicates, examples, and counterexamples.
- **Unsupported Case Boundary** distinguishes invalid, ambiguous, high-risk, unimplemented, or elsewhere-owned cases from ordinary work.
- **Safe Rejection or Deferral Path** defines where unsupported cases go and what users or systems can expect next.
- **Output Conformance Rule** prevents outputs from exceeding allowed formats, categories, authority, or promise levels.
- **Scope Stewardship** assigns responsibility for reviewing boundary violations, revising scope, versioning changes, and communicating them.

Optional components strengthen the pattern. A **Precondition Statement** captures assumptions that must hold before invocation. A **Conversion or Adaptation Rule** safely translates borderline inputs into supported form. An **Edge Case Catalog** records ambiguous cases for review. **Test Cases and Counterexamples** make the boundary teachable and testable. A **Versioned Scope Notice** helps dependent systems migrate when boundaries change. An **Exception Review Path** protects high-stakes or contested cases from automatic exclusion.

prose_common_mechanisms:
Common mechanisms implement the archetype but should not be confused with it. An **Input Validation Gate** checks whether an incoming case belongs in the input domain. An **Output Schema** bounds the structure of responses. **Output Validation** checks whether produced outputs remain inside the declared codomain before they are released, relied on, or sent downstream. A **Type Signature** expresses accepted inputs and returned outputs in technical systems. **Eligibility Criteria** and **Service Scope Statements** publish institutional boundaries for policies, services, and programs.

Clinical and model-governance contexts use more specialized mechanisms. **Clinical Indication Criteria** define conditions, contraindications, and escalation paths. A **Model Applicability Card** states intended use, excluded use, population boundaries, and output claims. A **Contract Test Suite** verifies that implementations respect the declared boundary. An **Unsupported Case Triage Workflow** routes out-of-scope or ambiguous cases instead of letting them fail silently. A **Scope Change Review** turns recurring exceptions and boundary violations into governance signals.

prose_failure_modes: A common failure mode is **boundary theater**: a document says what is supported, but intake, interface, training, testing, and triage do not enforce or reflect it. Another is **semantic failure behind formal validation**, where a request has the right shape but violates population, context, evidence, or authority assumptions. **Silent out-of-domain processing** occurs when unsupported inputs pass through defaults or informal judgment. **Codomain overclaiming** happens when technically valid outputs are interpreted as stronger guarantees or decisions than intended. **Unfair exclusion** occurs when a boundary denies service, opportunity, or recognition without legitimate criteria or appeal.

prose_neighbor_distinctions:
Domain–Codomain Delimitation is narrower than **Functional Specification**. Functional Specification defines the expected behavior of a unit across transformation rules, edge cases, and tests; this archetype focuses specifically on valid input and output scope.

It differs from **System Scope Definition**, which bounds an entire system, mission, or product. It differs from **Closure-Preserving Operation**, which preserves valid state under operations after the operation is already defined. It differs from **Relation Constraint Enforcement**, which governs valid relationships among entities. It differs from **Input Validation** and **Output Validation**, which are mechanisms for enforcing boundaries, not the intervention of defining and stewarding the boundary.

prose_cross_domain_examples: In software, an API defines accepted request schemas, authentication states, supported versions, response bodies, and error codes. In public services, a benefits program defines eligible households, required evidence, covered remedies, denial reasons, referrals, and appeals. In clinical care, a treatment protocol defines indications, contraindications, required measurements, allowed orders, and escalation for uncertain cases. In machine learning, a model is authorized only for a validated population and output claim. In organizational design, a team states which requests it accepts and which deliverables it can produce.

prose_non_examples: A field-level form check is not this archetype if the service scope is already clear. A general product mission statement is not this archetype because it does not delimit a function-like input-output relation. A foreign-key constraint is relation constraint enforcement, not domain/codomain delimitation. A full behavioral contract for every transformation rule and acceptance test is more likely Functional Specification. A disclaimer that says “use at your own risk” is not enough unless it changes input admission, output promises, unsupported-case routing, and stewardship.

prose_tradeoffs: The pattern trades openness for validity. Stronger boundaries improve safety, consistency, and interoperability, but they may exclude legitimate edge cases or slow service. More detailed codomains reduce overpromising, but they can frustrate users seeking broader outputs. More visible rejection and appeal paths improve fairness, but they add operational overhead. More automation reduces burden but risks brittle or unfair boundary enforcement.

prose_invariants_to_preserve:
The input membership boundary must remain clear enough that users and maintainers can distinguish in-domain, out-of-domain, and borderline cases. The output promise boundary must remain honest: the unit should not produce or imply outputs outside its declared codomain or authority.

Unsupported cases must remain safe. They should not be hidden in defaults, ignored by automation, or handled through unaccountable discretion. Boundary changes must remain observable and versioned when others rely on the old scope. In high-stakes settings, the boundary must remain contestable enough to avoid unfair exclusion.

prose_target_outcomes: A successful domain–codomain delimitation reduces invalid invocations, unsupported promises, integration failures, and late exception surprises. It improves users’ ability to know what a function can and cannot do. It gives implementers testable criteria. It helps stewards detect drift and recurring edge cases. It also reduces hidden accountability gaps by forcing out-of-scope cases into explicit routing rather than informal improvisation.

prose_parameter_dimensions:
The main tuning dimension is **boundary strictness**. Strict boundaries reduce invalid use but increase false rejection and escalation burden. Softer boundaries permit adaptation but risk scope creep and unsupported processing.

Other parameters include the granularity of the input domain, the breadth of the output codomain, the threshold for escalation, the level of automation in boundary enforcement, the cost of false acceptance versus false rejection, the visibility of rejection reasons, the ease of appeal, the cadence of boundary review, and the versioning burden imposed on downstream systems.

prose_variants_and_near_names:
Recognized variants include **Strict Input Domain Boundary**, **Output Promise Boundary**, **Eligibility Scope Delimitation**, **Model Applicability Boundary**, and **Type Signature Delimitation**. Near names include input-output scope definition, applicability boundary, valid range specification, supported use boundary, type contract, and eligibility boundary.

The draft collapses input validation, output validation, type signatures, service scope statements, and partial-function fallback into mechanisms or subpatterns unless they carry the broader intervention logic. Model applicability and eligibility boundaries are retained as promotion-watch variants because they may deserve future standalone treatment in model-governance or procedural-fairness contexts.

Strict Input Domain Boundary

variant_type: subtype

short_definition: A domain–codomain delimitation variant that sharply rejects or escalates inputs outside an explicitly admitted input set.

distinctive_feature: The input boundary is deliberately strict and operationally enforced before the transformation proceeds.

distinct_from_parent: The parent may also delimit output promises; this variant concentrates on admission to the input side of the mapping.

still_same_parent_because: It is still an input-output scope intervention rather than a full behavioral specification or a generic validation mechanism.

source_primes: function set_and_membership boundary constraint

use_when: Invalid inputs can create safety, integrity, legal, or downstream processing failures.

use_when: The system can cheaply test whether an input is inside the valid domain before acting.

use_when: False acceptance is more dangerous than false rejection or human review.

Input Domain

role: Defines admitted values, cases, users, states, or requests.

Membership Criteria

role: Tests whether an input belongs inside the supported domain.

Safe Rejection or Deferral Path

role: Routes unsupported inputs without silent failure.

Input Validation Gate

mechanism_type: procedure

role: Checks admissibility before the function is invoked.

Type Signature

mechanism_type: interface

role: Declares accepted input shapes or types.

example: An API rejects requests whose fields, authentication state, or version fall outside the supported domain.

example: A treatment protocol defines inclusion and exclusion criteria before a therapy may be offered.

failure_modes: The boundary becomes so strict that legitimate borderline cases are rejected without review.

failure_modes: The validation gate checks superficial format while ignoring substantive domain assumptions.

Output Promise Boundary

short_definition: A variant that defines what outputs, results, recommendations, decisions, or service states the function is allowed to produce or promise.

distinctive_feature: The crucial boundary is around the codomain: the result set, decision set, guarantee set, or service promise.

distinct_from_parent: The parent covers both input and output scope; this variant concentrates on the promises made on the output side.

still_same_parent_because: It still prevents out-of-scope mapping by bounding outputs and output claims.

source_primes: function boundary data_integrity accountability

use_when: Users or downstream systems overinterpret what the process can deliver.

use_when: The system sometimes returns unsupported categories, confidence levels, guarantees, or remedies.

use_when: Accountability depends on distinguishing promised outputs from aspirational, advisory, or impossible outputs.

Output Codomain

role: Defines allowed outputs, result classes, decision types, or promise categories.

Output Conformance Rule

role: Checks whether an output belongs to the allowed codomain.

Scope Stewardship

role: Maintains and revises codomain commitments.

Output Schema

mechanism_type: artifact

role: Constrains output format, categories, and permitted fields.

Service-Level Catalog

mechanism_type: document

role: Publishes what outcomes the service does and does not provide.

example: A classifier is authorized to return only screened risk bands, not clinical diagnoses.

example: A support workflow specifies which remedies agents may promise and which must be escalated.

failure_modes: The codomain is stated in technical terms but users still infer broader promises.

failure_modes: Outputs are artificially narrowed to avoid accountability rather than to preserve validity.

Eligibility Scope Delimitation

short_definition: Defines who or what is eligible for a service, benefit, intervention, rule, or pathway, and what happens to ineligible or uncertain cases.

distinctive_feature: The input domain is expressed as eligibility for a social, institutional, clinical, educational, or administrative pathway.

distinct_from_parent: The parent is domain-general; this variant highlights membership, rights, due process, and routing concerns in eligibility decisions.

still_same_parent_because: It still bounds the valid input set and allowed downstream handling for a defined process.

use_when: A policy, program, workflow, or service must decide which cases are inside its remit.

use_when: Ambiguous eligibility creates inconsistent treatment, queue leakage, or unsupported promises.

use_when: Fairness and accountability require explicit inclusion, exclusion, and appeal paths.

Membership Criteria

role: Defines eligible cases.

Unsupported Case Boundary

role: Separates ineligible or uncertain cases from ordinary processing.

Exception Review Path

role: Provides review for borderline, contested, or high-stakes cases.

Eligibility Criteria

role: Operationalizes inclusion and exclusion rules.

Intake Triage Form

mechanism_type: template

role: Collects evidence needed to apply eligibility criteria.

example: A benefits office defines eligible household conditions, required evidence, denial reasons, and appeal routing.

domain: education

example: A program defines prerequisite skills, age bands, and referral options for students outside scope.

failure_modes: Eligibility criteria encode unfair exclusions or hidden proxies.

failure_modes: A rigid boundary denies service while offering no safe alternative or appeal.

Model Applicability Boundary

short_definition: Defines the inputs, populations, conditions, and output claims for which a model, analysis, simulation, or forecast is valid enough to use.

distinctive_feature: The domain and codomain include empirical validity assumptions, uncertainty limits, and decision-use constraints.

distinct_from_parent: The parent can delimit any process; this variant adds model-specific validity, training, sampling, and uncertainty concerns.

still_same_parent_because: The structural move remains bounding supported inputs and allowed outputs before use.

source_primes: function representation uncertainty observability

use_when: A model is being applied beyond its training data, assumptions, measurement conditions, or validation evidence.

use_when: Users need to know when model outputs should be accepted, caveated, rejected, or escalated.

use_when: Decision risk depends on model validity boundaries rather than only on model accuracy.

Precondition Statement

role: States data, population, measurement, and context assumptions.

Input Domain

role: Identifies populations, cases, or feature ranges for which the model applies.

Output Codomain

role: Restricts whether outputs are forecasts, risk bands, labels, scores, or recommendations.

Model Card Applicability Section

role: Publishes intended use, excluded uses, and validity boundaries.

Out-of-Distribution Detector

role: Flags inputs likely outside validated domain.

example: A triage model is bounded to adult emergency visits from validated sites and cannot output diagnoses.

domain: forecasting

example: A demand model declares seasonal, geographic, and product categories for which forecasts are valid.

failure_modes: Model users treat boundary statements as disclaimers rather than operational constraints.

failure_modes: The boundary is not instrumented, so out-of-domain inputs are never detected.

Type Signature Delimitation

short_definition: Uses type declarations, parameter shapes, return types, or schema signatures to bound allowable inputs and outputs.

distinctive_feature: The delimitation is expressed through formal type, schema, signature, or interface machinery.

distinct_from_parent: The parent is the intervention; the type signature is a common way to implement it in technical systems.

still_same_parent_because: A type signature alone does not define unsupported-case behavior, domain assumptions, or promise scope unless embedded in the broader archetype.

source_primes: function representation constraint

use_when: The function or interface is technical enough for type-like boundary declarations.

use_when: Callers need a compact contract for admissible inputs and returned outputs.

use_when: Compile-time, runtime, or contract tests can enforce boundary adherence.

Input Domain

role: Captured as input types or parameter schemas.

Output Codomain

role: Captured as return types, output schemas, or response contracts.

Output Conformance Rule

role: Checks that implementations produce the declared outputs.

Type Signature

role: Declares input and output shapes.

Contract Test Suite

role: Checks that implementation behavior respects the declared signature.

example: A service endpoint defines accepted request types and response bodies before integration.

example: A transformation declares accepted source schemas and produced table schemas.

failure_modes: The signature captures shape but not semantic validity.

failure_modes: Callers infer more behavioral guarantees than the signature actually provides.

near_names:
Input–Output Scope Definition
Applicability Boundary
Valid Range Specification
Supported Use Boundary
Type Contract
Eligibility Boundary