Associative Cue Redesign

batch: First Iteration/Batch 37/Wave 2

Trigger Redesign

notes: Plain-language near-name. Use when the concept is changing the trigger that activates an existing response.

Habit Redesign

notes: Useful when the target pattern is a routine or habit, but too narrow to replace the parent because cue redesign also applies to safety, workflow, interface, and procedural behavior.

Environmental Cue Change

notes: Usually a mechanism or implementation variant under the parent, not a standalone archetype.

Context Restructuring

notes: Often an implementation mechanism for changing the trigger field; it should not be drafted separately unless future review finds a distinct context-design archetype.

Prompt Redesign

notes: A digital, procedural, or communication mechanism when prompts are the cues being altered.

source_primes: conditioning feedback

slug: conditioning

slug: inertia

slug: ritual

slug: reactance

slug: observability

components:
Cue-Response Map
Trigger Context Inventory
Old Response Signature
Cue Removal or Substitution
Replacement Cue
Replacement Response
Reinforcement Support
Relapse Monitor
Autonomy and Consent Boundary
Unintended Substitution Check
Baseline Behavior Trace
Friction or Salience Adjustment
Stakeholder Legibility Review
Maintenance Cadence

mechanisms:
Habit Loop Mapping
Environmental Cue Change
Trigger Removal
Context Restructuring
Prompt Redesign
Behavior Substitution
Point-of-Action Prompting
Safety Cue Redesign
Friction or Salience Adjustment
Implementation Intention Script
Relapse Trigger Review

essence_one_line: Change the cues and contexts that trigger automatic responses so behavior can shift at the moment it happens.

compression_statement: When an unwanted or outdated response recurs because a learned cue activates it, map the cue-response association, remove or substitute the trigger, provide a replacement cue and response, add light reinforcement support, and monitor whether the old association returns or mutates.

core_intuition: People often act from the situation they are in before they consciously deliberate. Associative Cue Redesign works by changing the situation’s trigger field: make the old response harder to start, make the desired response easier to notice, and verify that the redesign supports agency rather than manipulating behavior covertly.

canonical_formula: old cue + old response + trigger context + cue removal/substitution + replacement cue + replacement response + light reinforcement + relapse monitor + autonomy boundary = redesigned association

structural_problem: A behavior, shortcut, omission, interpretation, or routine persists because the environment repeatedly cues it, even when intention, instruction, training, incentives, or explicit goals have changed.

trigger_conditions: The old response is fast, habitual, procedural, or automatic in a recurring context.

trigger_conditions: People can name the desired behavior but fail to enact it when the old cue appears.

trigger_conditions: Reminder campaigns, training, or downstream consequences have not changed behavior because the triggering context remains intact.

trigger_conditions: A physical object, interface prompt, workflow sequence, social moment, time of day, location, or sensory signal reliably precedes the unwanted response.

trigger_conditions: The desired replacement response must occur at a specific point of action, not merely as a general attitude or intention.

trigger_conditions: The behavior-change context is legitimate, transparent, and proportionate enough that cue redesign can be used without covert manipulation.

symptoms: People say they forgot or slipped even though they understand the rule, goal, or training.

symptoms: The unwanted response occurs in the same location, sequence, interface state, shift handoff, meeting rhythm, or social cue.

symptoms: A new policy is ignored because the old form, screen, button, path, or object placement still cues the old behavior.

symptoms: Posters, reminders, or incentives are added but the behavior remains anchored to the old context.

symptoms: When the cue disappears, the old response weakens; when the cue reappears, the old response returns.

symptoms: People create workarounds around the redesign because the replacement response is unclear, too costly, or unsupported.

root_tension: Behavior is partly chosen and partly cued. A design that respects agency must change trigger conditions enough to make the desired action easier, but not so covertly or forcefully that people are manipulated, surveilled, or trapped into behavior they would not endorse.

anti_signatures: The main problem is designing rewards, consequences, schedules, and feedback for a target behavior; use reinforcement_loop_design instead.

anti_signatures: The main problem is shifting shared expectations or legitimacy in a group; use norm_shaping or a related social-pattern archetype.

anti_signatures: The main problem is overcoming general inertia without a specific cue-response association; use inertia_harnessing or a change-design archetype.

anti_signatures: The main problem is reducing cognitive load or simplifying a task; use cognitive_load_reduction unless a learned cue-response trigger is central.

anti_signatures: The item is only a reminder, cue card, checklist, or prompt without mapping the old association, replacement response, and relapse monitoring.

anti_signatures: The context is clinical addiction, trauma response, or other medical/mental-health treatment; this archetype may inform environmental design but is not treatment guidance.

structural_intervention: Move behavior change upstream into the trigger context: identify the cue-response association, redesign the cue field, define the replacement response, provide enough support for the new association to stabilize, and monitor recurrence or misuse.

Map the current association

logic: Identify the cue, context, actor state, timing, old response, and consequence pattern that currently holds the unwanted behavior in place.

Locate the decisive trigger

logic: Distinguish the cue that actually starts the response from background conditions, explanations, training gaps, or downstream incentives.

Define the replacement response

logic: Specify what should happen instead when the context appears: action, pause, check, route, disclosure, safe behavior, or alternative routine.

name: Remove, weaken, move, or substitute the old cue

logic: Change the trigger context so the old response is no longer the easiest or most salient path.

name: Install a replacement cue at the point of action

logic: Make the desired response visible at the moment it can be performed, using a cue that is legible and proportionate.

Add light reinforcement support

logic: Use feedback, recognition, reduced friction, natural consequence, practice, or coaching only enough to help the new association stabilize.

name: Check autonomy, consent, and misuse boundaries

logic: Review whether the redesign is transparent, legitimate, reversible where appropriate, and not a dark pattern or covert manipulation.

name: Monitor relapse and substitution effects

logic: Watch for old cues returning, old responses moving elsewhere, replacement cues decaying, or new unwanted behaviors emerging.

Retune the cue environment

logic: Repair, simplify, remove, or refresh cues as evidence shows how the association changes over time.

rule: If the old behavior happens only when a specific cue or context appears, prioritize cue redesign over additional exhortation or training.

rule: If there is no viable replacement response, do not remove the old cue without creating a safe path for what should happen instead.

rule: If cue redesign requires hidden personalization, surveillance, or reduced choice, require explicit ethical review and a consent or legitimacy basis.

rule: If consequences and schedules are the main intervention rather than cue alteration, route the case to Reinforcement Loop Design.

rule: If the redesigned cue is ignored, check salience, timing, actionability, trust, and alert fatigue before adding more prompts.

rule: If old behavior returns after novelty fades, treat recurrence as evidence about trigger context rather than as simple lack of motivation.

invariant: Cue-response traceability

description: The redesign must remain traceable to a mapped cue-response association rather than a vague desire to influence behavior.

invariant: Replacement viability

description: The desired response must be clear and feasible at the moment the replacement cue appears.

invariant: Agency and consent protection

description: Cue redesign must preserve legitimate choice, transparency, proportionality, and dignity, especially where power is asymmetric.

invariant: No hidden harm transfer

description: Suppressing one cue must not merely push the unwanted behavior to another place, role, group, or time.

invariant: Retunability

description: Cues, prompts, friction, and replacement responses can be adjusted as evidence shows decay, confusion, or side effects.

outcome: Reduced activation of unwanted responses

description: The old behavior occurs less often because the trigger no longer starts it as reliably.

outcome: Improved point-of-action behavior

description: The desired response becomes easier to remember and perform exactly when it matters.

outcome: Lower dependence on willpower and generic reminders

description: The environment supports behavior change instead of asking people to resist the same cue repeatedly.

outcome: Better transfer from training or policy into action

description: Instruction becomes more effective because the cue context now supports the intended response.

outcome: Earlier detection of recurrence and workarounds

description: Relapse monitoring identifies when old cues, substitute triggers, or new unwanted behaviors appear.

prose_essence:
Associative Cue Redesign is the archetype for changing behavior by changing what triggers it. It applies when the problem is not ignorance, lack of stated intention, or absence of a goal, but a cue environment that keeps activating the old response. The intervention maps the current cue-response association, weakens or substitutes the old cue, installs a replacement cue and response, and monitors whether the old association returns.

This archetype is deliberately narrower than general behavior change. It does not mean “motivate people more” or “reward the behavior.” It means: find the signal that starts the old behavior, change the signal or its context, and make the desired response easier to initiate in that same moment.

prose_when_to_use:
Use this archetype when a repeated behavior appears automatically in a recurring context. Typical signs include slips after training, old workflow habits surviving a new policy, interface prompts that cue the wrong action, safety routines skipped at the same point in a process, or people saying they “know what to do” but fail when the old trigger appears.

It is especially useful when generic reminders have failed. A reminder sent far from the action moment often cannot compete with a cue embedded in the work, interface, room, social interaction, or routine sequence. Associative Cue Redesign moves the intervention to the point where the old response is activated.

Do not use it as a generic behavior-control label. If the intervention is mainly reward, penalty, schedule, or feedback design, use Reinforcement Loop Design. If the context is clinical treatment, addiction care, trauma response, or another health-sensitive domain, this archetype can only provide general design language and should not replace domain-qualified guidance.

prose_structural_problem:
The structural problem is a persistent cue-response association. A cue may be physical, temporal, social, procedural, digital, symbolic, or sensory. The response may be an action, omission, shortcut, interpretation, click, routine, or avoidance pattern. The behavior persists because the cue field keeps making the old response easy to start.

The common mistake is to address the actor’s intention while leaving the trigger untouched. Training, policies, posters, incentives, and after-the-fact feedback may all fail if the old cue still appears at the decision moment. The result is a mismatch between declared goals and situated behavior.

prose_intervention_logic:
The intervention begins with diagnosis: map the old cue, context, response, and consequence pattern. Then locate the decisive trigger, not just the most visible reminder. The designer removes, weakens, moves, masks, or substitutes the old cue and installs a replacement cue that appears when the desired response can actually be performed.

The replacement cue must be paired with a replacement response. A cue that only says “don’t do that” leaves the actor without a new path. Light reinforcement support can help stabilize the new association, but the defining lever is the cue redesign itself. Finally, the design monitors recurrence: old cues may return, replacement cues may decay, and people may create workarounds if the new response is not viable.

prose_key_components:
### Cue-Response Map

**Component record:** `slug: cue_response_map` · `name: Cue-Response Map` · `role: Shows which cues, contexts, timings, actor states, or interface signals currently trigger which responses.`

This is the diagnostic map that prevents the intervention from guessing. It distinguishes the trigger from the response and records where the old association is strongest.

### Trigger Context Inventory

**Component record:** `slug: trigger_context_inventory` · `name: Trigger Context Inventory` · `role: Identifies the physical, temporal, social, procedural, digital, or symbolic contexts that make the old response likely.`

Cue redesign often fails because it changes only a visible prompt while leaving the wider triggering context intact. The inventory broadens the search for hidden triggers.

### Old Response Signature

**Component record:** `slug: old_response_signature` · `name: Old Response Signature` · `role: Defines the behavior, interpretation, shortcut, omission, or routine that the old cue currently evokes.`

The old response must be described concretely enough to detect whether it weakens, relocates, or reappears under a different cue.

### Cue Removal or Substitution

**Component record:** `slug: cue_removal_or_substitution` · `name: Cue Removal or Substitution` · `role: Removes, masks, moves, weakens, or replaces the cue that activates the old response.`

This is the decisive intervention lever. It changes the trigger conditions rather than asking people simply to remember, try harder, or resist the cue.

### Replacement Cue

**Component record:** `slug: replacement_cue` · `name: Replacement Cue` · `role: Provides a new or revised signal that makes the intended response easier to notice at the right moment.`

The replacement cue should be specific, timely, legible, and proportional. A vague reminder rarely substitutes for a cue embedded in the action context.

### Replacement Response

**Component record:** `slug: replacement_response` · `name: Replacement Response` · `role: Specifies the desired action, choice, pause, check, disclosure, or routine to perform when the replacement cue appears.`

A removed cue leaves a behavioral gap. The replacement response gives the actor a viable path so the old cue-response loop does not return by default.

### Reinforcement Support

**Component record:** `slug: reinforcement_support` · `name: Reinforcement Support` · `role: Adds enough feedback, consequence, recognition, or ease-of-action to help the new cue-response association stabilize.`

This support borrows from Reinforcement Loop Design but remains subordinate. The archetype is cue redesign; reinforcement is used only enough to keep the new association from decaying.

### Relapse Monitor

**Component record:** `slug: relapse_monitor` · `name: Relapse Monitor` · `role: Tracks whether the old response returns, whether old cues reappear, and whether new cues create unintended habits.`

Relapse here means return of the old association or emergence of a substitute cue-response pattern. In clinical contexts this draft should not be treated as treatment guidance.

### Autonomy and Consent Boundary

**Component record:** `slug: autonomy_and_consent_boundary` · `name: Autonomy and Consent Boundary` · `role: Defines ethical limits on cue manipulation, hidden prompts, personalization, monitoring, and behavior shaping.`

Cue redesign can easily become covert influence. This boundary requires transparency, proportionality, user agency, and special caution in workplaces, schools, public services, products, and vulnerable populations.

### Unintended Substitution Check

**Component record:** `slug: unintended_substitution_check` · `name: Unintended Substitution Check` · `role: Looks for new unwanted responses that appear when the old cue is removed or the replacement cue is introduced.`

Disrupting one association can shift behavior elsewhere, create avoidance, trigger workarounds, or reward a shallow substitute. The check protects against merely moving the problem.

prose_common_mechanisms:
The following mechanisms implement Associative Cue Redesign. They should not be confused with the archetype itself. A cue card, prompt, or environmental change is only a mechanism unless it participates in the full structure: cue-response mapping, trigger redesign, replacement response, support, monitoring, and autonomy safeguards.

### Habit Loop Mapping

**Mechanism record:** `slug: habit_loop_mapping` · `name: Habit Loop Mapping` · `mechanism_type: diagnostic_method` · `role: Maps cue, routine or response, and consequence to reveal the association that must be redesigned.`

This mechanism helps diagnose the cue-response pattern. It is not the archetype itself because mapping alone does not remove, substitute, test, or monitor cues.

### Environmental Cue Change

**Mechanism record:** `slug: environmental_cue_change` · `name: Environmental Cue Change` · `mechanism_type: context_intervention` · `role: Changes objects, placement, labels, lighting, paths, spatial layout, or visible affordances so the old trigger is less salient and the intended cue is more available.`

This is a common implementation in physical spaces, but the same archetype can be implemented in digital, procedural, social, or temporal contexts.

### Trigger Removal

**Mechanism record:** `slug: trigger_removal` · `name: Trigger Removal` · `mechanism_type: interruption_method` · `role: Removes, hides, blocks, delays, or decouples a cue that reliably starts an unwanted response.`

Removal works best when paired with a replacement response. Otherwise the actor may recreate the old cue or experience unnecessary friction.

### Context Restructuring

**Mechanism record:** `slug: context_restructuring` · `name: Context Restructuring` · `mechanism_type: environment_or_workflow_method` · `role: Rearranges the surrounding process, sequence, or setting so the old association is harder to activate and the new association is easier to enact.`

Use this when the trigger is embedded in a workflow rather than a single prompt, object, or sign.

### Prompt Redesign

**Mechanism record:** `slug: prompt_redesign` · `name: Prompt Redesign` · `mechanism_type: interface_or_message_method` · `role: Rewrites, repositions, retimes, or recodes prompts at the point of action so they cue the intended response rather than the old one.`

Prompt redesign is a mechanism, not a full archetype. It must be tied to cue-response mapping, replacement behavior, and safety boundaries to qualify as Associative Cue Redesign.

### Behavior Substitution

**Mechanism record:** `slug: behavior_substitution` · `name: Behavior Substitution` · `mechanism_type: replacement_method` · `role: Installs a safer or more useful response in the window where the old response used to occur.`

Substitution matters because suppressing a response without giving an alternative often makes the old loop return under stress or novelty loss.

### Point-of-Action Prompting

**Mechanism record:** `slug: point_of_action_prompting` · `name: Point-of-Action Prompting` · `mechanism_type: timed_prompt` · `role: Places a cue at the exact moment where the intended response can be taken.`

A prompt away from the action point often becomes generic communication. This mechanism works only when it changes the trigger at the decision or behavior moment.

### Safety Cue Redesign

**Mechanism record:** `slug: safety_cue_redesign` · `name: Safety Cue Redesign` · `mechanism_type: safety_practice_method` · `role: Repositions, clarifies, or substitutes safety cues so safe action is triggered before hazard exposure or procedural drift.`

Safety use requires special attention to reporting, false confidence, habituation, and not blaming individuals for poorly designed cue environments.

### Friction or Salience Adjustment

**Mechanism record:** `slug: friction_or_salience_adjustment` · `name: Friction or Salience Adjustment` · `mechanism_type: choice_architecture_method` · `role: Adds, removes, or rebalances friction and attention weight so the replacement response becomes easier than the old response.`

This can become manipulative if used to hide alternatives or exploit attention. The autonomy boundary must govern its use.

### Implementation Intention Script

**Mechanism record:** `slug: implementation_intention_script` · `name: Implementation Intention Script` · `mechanism_type: planning_script` · `role: Links a specific cue to a specific intended response in an if-this-then-that form.`

A script is useful when the actor participates in the cue redesign. It is weaker when the cue environment itself remains unchanged.

### Relapse Trigger Review

**Mechanism record:** `slug: relapse_trigger_review` · `name: Relapse Trigger Review` · `mechanism_type: review_procedure` · `role: Reviews episodes where the old response returned and identifies which cue, context, or substitution failure was responsible.`

This mechanism protects the archetype from one-time redesign. It converts recurrence into information for cue repair.

prose_failure_modes:
A common failure mode is targeting the wrong cue. Teams may change signage or messaging while the actual trigger is workflow timing, social pressure, or interface default. Another failure is removing the old cue without defining what people should do instead. The old response then returns under stress or is replaced by a different unwanted behavior.

Cue clutter is another risk. If the redesign adds prompts to a noisy environment, people may ignore all cues. In behavior-sensitive contexts, the most serious failure is manipulation: the design changes behavior by hiding choices, exploiting attention, or surveilling people in ways they would not accept.

prose_neighbor_distinctions:
**Reinforcement Loop Design** builds the full cue-response-consequence system for behavior learning. Associative Cue Redesign is narrower: it changes the trigger context for an existing response, while reinforcement is only support.

**Inertia Harnessing** uses default persistence or status quo tendencies. Associative Cue Redesign is specifically about learned cues that activate a response.

**Norm Shaping** changes shared expectations and social legitimacy. Associative Cue Redesign may involve social cues, but it does not require a norm to be the central mechanism.

**Cognitive Load Reduction** simplifies the task or representation. Associative Cue Redesign may reduce memory burden, but only because the old trigger is redesigned.

**Metacognitive Monitoring Loop** asks actors to regulate their own thinking. Associative Cue Redesign changes the action context so the desired response is cued without relying primarily on self-monitoring.

prose_cross_domain_examples:
In workplace safety, a team may move protective equipment and the inspection cue to the entrance of the hazardous area rather than reminding workers later. In software, a risky default prompt may be redesigned so the safe response is cued before irreversible action. In healthcare workflow, sanitizing supplies and visual cues may be placed exactly where patient contact begins. In operations, a handoff form may be resequenced so unresolved anomalies cue review before routine signoff. In cybersecurity, a verification cue may appear when a payment request contains changed account details.

Across these cases, the common structure is not “add a reminder.” It is redesigning the cue that starts the old response and making the replacement response available at that moment.

prose_non_examples: A poster campaign away from the action point is not Associative Cue Redesign. A reward paid after the behavior is not this archetype unless the cue context is also redesigned. A checklist in a binder far from the work area is only an artifact. A dark pattern that hides cancellation or exploits attention violates the autonomy boundary. A clinical treatment plan for addiction or trauma requires specialized care and should not be treated as a generic design archetype.

prose_tradeoffs:
Associative Cue Redesign can reduce cognitive burden, but it can also reduce awareness if people become dependent on cues. It can make desired behavior easy, but powerful cue changes can become manipulative when hidden or coercive. It can simplify action, but changing one cue may disrupt legitimate routines that depended on the same signal.

The archetype therefore requires a balance: strong enough cue changes to matter, but transparent and proportional enough to preserve agency and trust.

prose_invariants_to_preserve:
The cue-response association must remain traceable. The redesign should always be connected to a specific old cue and old response rather than a vague intention to influence behavior.

The replacement response must be viable. If people cannot perform the desired response at the moment the replacement cue appears, the design will create frustration or workarounds.

Agency and consent must be protected. Cue redesign should help people enact legitimate goals or requirements, not exploit attention, hide alternatives, or manipulate choices covertly.

The design must not transfer harm. Removing a cue in one place should not merely push the unwanted behavior to another role, time, location, or group.

prose_target_outcomes:
The desired outcome is fewer activations of the old response and more reliable performance of the replacement response at the point of action. A successful redesign reduces reliance on willpower, makes training transfer into real contexts, and exposes recurrence early enough for repair.

A second outcome is better diagnosis of behavior failures. Instead of treating every recurrence as laziness or defiance, the archetype asks which cue reappeared, which response was missing, and how the cue environment needs to be retuned.

prose_parameter_dimensions:
**Cue specificity.** A cue may be broad, such as the beginning of a shift, or narrow, such as a warning that appears when a risky field is selected. Narrow cues are easier to connect to a response but may miss nearby contexts.

**Cue visibility and salience.** The replacement cue must be noticeable enough to trigger action, but not so loud that it becomes noise, alert fatigue, or coercive attention capture.

**Timing.** Cues work best when they appear before or during the action window. A cue after the action becomes feedback, not trigger redesign.

**Friction balance.** Adding friction to the old response and reducing friction for the replacement response can help, but hidden or coercive friction creates ethical risk.

**Replacement-response complexity.** The more complex the replacement behavior, the more support, practice, or reinforcement it will need.

**Transparency and consent.** Some cue changes are obvious and benign; others affect autonomy, privacy, power, or choice. Higher-stakes contexts require stronger disclosure, review, and consent or legitimacy.

**Maintenance cadence.** Cues decay, become invisible, or are bypassed. The design needs a cadence for review and repair.

prose_variants_and_near_names:
Recognized variants include environmental trigger redesign, interface prompt redesign, safety cue redesign, and relapse cue management. Near names include trigger redesign, habit redesign, cue-response redesign, environmental cue change, prompt redesign, and context restructuring.

The policy for variants is conservative. Keep a variant under this parent when it uses the same core logic: map old cue-response association, change the trigger, install a replacement cue or response, support the new association, and monitor recurrence. Collapse cue cards, reminders, prompts, habit-loop diagrams, and environmental tweaks into mechanisms unless they participate in the full archetype.

Environmental Trigger Redesign

short_definition: Changes physical or spatial cues so old automatic responses are less likely and intended responses are easier to initiate.

distinctive_feature: The decisive lever is physical or spatial context rather than reward, information, or self-reflection.

distinct_from_parent: The parent covers any learned cue-response redesign; this variant focuses on the material environment as the trigger field.

still_same_parent_because: It still uses cue-response mapping, cue removal or substitution, replacement response design, reinforcement support, and relapse monitoring.

use_when: The behavior is reliably triggered by objects, placement, paths, visibility, signage, or spatial sequence.

use_when: The actor intends or is legitimately expected to perform a different response, but the setting keeps cueing the old one.

use_when: The intervention can alter the environment without hiding important options or creating coercive friction.

Trigger Context Inventory

role: Identifies environmental triggers.

Replacement Cue

role: Creates a new spatial signal.

Environmental Cue Change

role: Changes placement or visibility.

Context Restructuring

role: Rearranges the trigger context.

domain: operations

example: A tool cart is rearranged so the calibration gauge is encountered before the part is installed.

example: A phone is kept out of the bedroom and a book is placed on the nightstand to change the bedtime cue field.

failure_modes: The cue change creates confusion because the replacement response is not clear.

failure_modes: The old cue reappears through workarounds or nearby substitutes.

Interface Prompt Redesign

short_definition: Changes digital or procedural prompts so an interface no longer cues the old response and instead supports the desired action.

distinctive_feature: The cue is an interface or procedure rather than a physical object or social context.

distinct_from_parent: The parent can redesign any trigger; this variant is tuned for digital and procedural prompt systems.

still_same_parent_because: It still maps the old cue-response association, replaces the cue, defines a replacement response, and monitors recurrence or workaround behavior.

use_when: The old response is triggered by button placement, notification timing, default wording, alert fatigue, or procedural prompts.

use_when: A prompt can be redesigned at the point of action without obscuring user choice.

Cue-Response Map

role: Finds which prompt triggers which action.

Autonomy and Consent Boundary

role: Prevents prompt redesign from becoming a dark pattern.

Prompt Redesign

role: Changes wording, timing, or placement.

Point-of-Action Prompting

role: Places the cue where action happens.

domain: software

example: A confusing confirmation prompt is rewritten and retimed so users pause before deleting shared data.

domain: healthcare

example: An order-entry prompt moves a safety check to the moment a risky dose is selected.

failure_modes: The prompt becomes another ignored alert.

failure_modes: The redesign hides a choice rather than helping a legitimate action.

Safety Cue Redesign

short_definition: Redesigns safety-related cues so safe behavior is triggered before exposure, drift, or normalization of deviance occurs.

distinctive_feature: The variant is governed by hazard timing, reporting protection, and false-safety risk.

distinct_from_parent: The parent is general; this variant is tuned for safety-critical or harm-sensitive contexts.

still_same_parent_because: It still redesigns cues and replacement responses while using feedback only as support.

source_primes: conditioning feedback fault_tolerance

use_when: Unsafe shortcuts are triggered by workflow pressure, ambiguous signals, missing visual cues, or normalized workarounds.

use_when: The desired safe response is known but not reliably cued at the hazardous moment.

Replacement Cue

role: Signals the safe action before risk exposure.

Unintended Substitution Check

role: Checks for unsafe workarounds.

Safety Cue Redesign

role: Places or clarifies cues near risk.

Relapse Trigger Review

role: Reviews recurrence of unsafe shortcuts.

domain: manufacturing

example: A machine guard inspection cue is placed before startup rather than in a distant checklist binder.

domain: cybersecurity

example: A high-risk link warning appears at click time and cues a safer verification path.

failure_modes: The cue creates a false sense of safety without changing the risky response.

failure_modes: People stop reporting near misses because the cue is treated as proof the system is safe.

Relapse Cue Management

short_definition: Identifies recurring contexts where old cue-response associations return and repairs the cue environment over time.

distinctive_feature: The variant emphasizes maintenance and recurrence rather than initial redesign.

distinct_from_parent: The parent includes a relapse monitor; this variant makes recurring trigger repair the center of attention.

still_same_parent_because: It still operates by mapping cues, detecting old responses, substituting cues, and supporting replacement responses.

use_when: A redesigned cue initially works but old behavior returns after stress, novelty loss, staff turnover, or context drift.

use_when: The old response is not gone; it is dormant until the old cue or a substitute cue appears.

Relapse Monitor

role: Tracks return of old associations.

Maintenance Cadence

role: Schedules cue review and repair.

Relapse Trigger Review

role: Analyzes recurrence episodes.

example: A team reviews why old checklist skipping returned after a schedule change and moves the cue into the new handoff rhythm.

failure_modes: Recurrence is framed as individual weakness instead of a cue-design failure.

failure_modes: The review becomes surveillance rather than cue repair.

near_names:
Habit Redesign
Trigger Redesign
Environmental Cue Change
Trigger Removal
Context Restructuring
Prompt Redesign
Behavior Substitution


Associative Transfer Warrant Audit

type: archetype

source: generated

batch: Batch 07

aliases:
Associative Property Transfer Audit
Association-as-Evidence Guardrail
Associative Attribution Audit
Associative Warrant Separation
Guilt-by-Association Guardrail
Halo and Taint Attribution Check
Contact-Based Property Transfer Review
Endorsement Scope Guardrail
Trust Transitivity Warrant Audit

source_primes: associative_property_transfer evidence causality correlation analogy trust reputation

related_primes: contagion emotional_contagion transferability_overclaim trusted_intermediary_compromise category classification stereotyping essentialism bias heuristic provenance signaling

slug: evidence

slug: causality

slug: correlation

slug: analogy

slug: trust

slug: reputation

slug: contagion

slug: category

slug: classification

slug: stereotyping

slug: essentialism

slug: bias

slug: heuristic

slug: provenance

slug: signaling

components:
Property Transfer Claim
Associative Link Record
Warrant Channel Separation
Transfer Function Hypothesis
Independence and Confounding Probe
Scope, Decay, and Distance Boundary
Harm and Stigma Check
Qualified Transfer Decision
Source-Target Role Map
Association Strength Indicator
Counterassociation Set

mechanisms:
Association-to-Evidence Matrix
Guilt-by-Association Review
Halo and Taint Decomposition Table
Contact/Contagion Warrant Test
Endorsement Scope Checklist
Trust Transitivity Breakpoint Review
Category-Membership Attribution Audit
Associative Claim Red Team

essence_one_line: Do not let contact, co-membership, resemblance, endorsement, or proximity carry trust, blame, risk, quality, or credibility unless the link has a valid transfer warrant.

compression_statement: Associative Transfer Warrant Audit is the pattern of inspecting a property assignment that rides on an associative link. It identifies the property being transferred, names the link that is doing the transfer work, separates associative salience from causal, evidential, statistical, symbolic, and institutional warrant, tests the assumed transfer function, checks independence and confounding, scopes any valid transfer by distance and decay, and records a qualified decision. The result is not a ban on associative reasoning; it is a guardrail against converting association into evidence or responsibility without the channel that would make the transfer legitimate.

core_intuition: Association is useful because it directs attention. It is dangerous because attention can masquerade as warrant. The same link that makes one thing come to mind with another may or may not explain why a property should travel between them. This archetype keeps those two facts separate.

canonical_formula: property_claim + associative_link + transfer_function_test + warrant_channel_separation + scope_boundary + harm_check -> qualified_transfer_decision

structural_problem: A receiver assigns a property to a target because the target is linked to a source, category, event, symbol, platform, group, channel, person, or artifact, even though the link may not carry that property. The association may be real but the inference may be unwarranted.

condition: A property is being assigned through proximity, contact, co-membership, endorsement, dependency, analogy, or shared label.

notes: The link may be salient without being warrant-bearing.

condition: The property matters for trust, blame, risk, credibility, status, access, safety, responsibility, or quality.

notes: Low-stakes aesthetic associations may not need the full audit.

condition: The causal or evidential pathway is unclear, implicit, or disputed.

notes: The audit is most useful when the link is doing unstated inferential work.

condition: Downstream actors may reuse the transferred property as if it were a settled fact.

notes: A weak association can harden into a label once decisions, records, or reputations depend on it.

condition: The same link could either indicate a real channel or a misleading heuristic.

notes: Contact can be real contagion, an endorsement signal, a dependency risk, or mere co-presence.

symptoms: A decision memo says the target is risky, credible, contaminated, endorsed, suspect, high-quality, or low-quality because of who or what it is near.

symptoms: A single affiliation overwhelms direct evidence about the target.

symptoms: A category label is treated as if all members inherit the same property.

symptoms: The phrase “associated with” appears where a causal, evidential, or responsibility claim is needed.

symptoms: A trusted intermediary, sponsor, platform, citation, or brand relationship transfers more credibility than the channel actually supports.

symptoms: Reputation, blame, or stigma spreads farther than the underlying process, control, or evidence can justify.

root_tension: Associative links are excellent prompts for inquiry but poor substitutes for warrant. Systems need the attention value of association without allowing it to become automatic property assignment.

anti_signatures: The property is known to transmit through a tested causal channel; use diffusion, contagion, or causal mechanism tools instead.

anti_signatures: The task is merely to map associations or dependencies without evaluating a property transfer claim; use relation_mapping.

anti_signatures: The issue is valid analogical comparison with explicit scope; use literal_vs_figurative_boundary_preservation or transfer_scaffolding.

anti_signatures: The problem is emotion being treated as evidence without a specific associative link; use affect_evidence_separation.

anti_signatures: The target is being updated by direct evidence, not by association; use evidentiary_trace_warranting or knowledge_warrant_audit.

structural_intervention: Convert an implicit association-based property assignment into an explicit, reviewable transfer claim; then accept, narrow, relabel, or reject the transfer according to the warrant channel actually present.

logic: State exactly what property is alleged to move or be inherited.

logic: Identify the associative link and its type: contact, co-membership, analogy, endorsement, dependency, proximity, shared category, sequence, or visibility.

logic: Distinguish association from causality, evidence, correlation, symbolism, institutional authority, trust, and actual transmission.

logic: Ask what mechanism or rule would have to exist for the property to transfer through this link.

logic: Check for common causes, confounders, direct evidence, counterassociations, and category-base-rate errors.

logic: Limit any accepted transfer by distance, time, role, property type, channel integrity, and decision context.

logic: Mark the property assignment as warranted, unwarranted, hypothesis-only, narrowed, expired, or needing further evidence.

decision_rules: Treat association as a trigger for inquiry, not as sufficient warrant, unless a domain rule explicitly makes that link transfer-bearing.

decision_rules: Accept transfer only for the property type that the link can carry; endorsement may transfer credibility but not competence, and custody may transfer provenance but not blame.

decision_rules: Require stronger warrant when the transfer creates stigma, exclusion, punishment, or overtrust.

decision_rules: Use a contagion or propagation frame only when the property can actually transmit through the link.

decision_rules: When link strength and property relevance diverge, prioritize property relevance over salience.

decision_rules: If the transfer function cannot be stated, downgrade the claim to hypothesis or rhetorical association.

target_invariants: Associative links remain visible as possible clues.

target_invariants: Property claims stay tied to explicit warrant channels.

target_invariants: Evidence, causality, correlation, symbolism, endorsement, and trust are not conflated.

target_invariants: Scope, distance, decay, and decision-use limits travel with any accepted transfer.

target_invariants: People and groups are protected from unsupported stigma and collective blame.

target_invariants: Real transmission and dependency risk are not dismissed merely because association can be fallacious.

expected_outcomes: Fewer unwarranted guilt-by-association, halo, taint, and status-borrowing judgments.

expected_outcomes: Clearer distinction between attention cues and evidentiary support.

expected_outcomes: More precise trust and reputation transfer across intermediaries, sources, brands, and institutions.

expected_outcomes: Better handling of contact or contagion cases where the association sometimes is a real causal channel.

expected_outcomes: More auditable decisions in high-stakes attribution, moderation, hiring, risk, source evaluation, and public communication.

Guilt-by-Association Guardrail

short_definition: Prevents blame, risk, or disqualification from being assigned to a target solely because of contact, affiliation, or co-membership.

distinctive_feature: The transferred property is negative and may cause unfair exclusion or punishment.

distinct_from_parent: It is a high-harm variant focused on blame and disqualification rather than all property transfer.

still_same_parent_because: The core move remains the same: separate associative link from warrant-bearing channel.

use_when: A person, source, organization, or item is being evaluated through its associations.

use_when: The association may be salient but not causally or evidentially relevant to the property being assigned.

example_domains:
hiring
law
journalism
moderation
academic peer review

failure_modes: Treating affiliation as proof of endorsement.

failure_modes: Using a single network edge to justify broad reputational harm.

Halo and Taint Decomposition

short_definition: Separates positive or negative spillover from evidence about the specific property being evaluated.

distinctive_feature: The transfer happens through global evaluative glow or stain rather than a named argument.

distinct_from_parent: It focuses on affective and reputational spillover within the broader transfer-warrant pattern.

still_same_parent_because: The intervention still asks whether the associative link actually bears the claimed property.

use_when: A prestigious, attractive, disliked, or stigmatized association is influencing a judgment.

use_when: The transferred property is diffuse rather than explicitly argued.

example_domains:
brand evaluation
politics
performance review
art criticism

failure_modes: Letting likeability become competence evidence.

failure_modes: Letting contamination disgust become safety evidence without testing.

Endorsement Association Scope Guardrail

short_definition: Determines whether co-appearance, citation, sponsorship, platforming, or dependency actually transfers endorsement, credibility, or responsibility.

distinctive_feature: The transferred property is endorsement or credibility through public association.

distinct_from_parent: It focuses on communication and authority channels rather than all property-transfer contexts.

still_same_parent_because: It still uses association-to-warrant separation and scoped transfer decisions.

use_when: A source appears near another source or institution.

use_when: Receivers may infer endorsement, credibility, or shared responsibility from that association.

example_domains:
publishing
platform governance
sponsorship
supply chains

failure_modes: Assuming platform presence equals institutional approval.

Contagion Special-Case Warranting

short_definition: Tests when associative contact is actually a causal transmission channel and when it is only a symbolic or heuristic association.

distinctive_feature: It marks contagion as the warranted causal special case of associative transfer.

distinct_from_parent: It is narrower and often quantitative or epidemiological.

still_same_parent_because: It begins from a property-transfer claim along an association and asks whether a valid transmission function exists.

use_when: Contact, co-presence, or dependency is being treated as risk transmission.

use_when: The domain must distinguish actual spread from imagined contamination.

example_domains:
public health
financial risk
cybersecurity
social behavior

failure_modes: Overextending contagion metaphors to cases with no transmission path.

failure_modes: Ignoring real contact-mediated risk because the association seems merely symbolic.

near_names:
Associative Property Transfer Audit
Association-as-Evidence Guardrail
Associative Attribution Audit
Status Borrowing Review
Symbolic Contamination Check


batch: Batch 05

canonical_family: Finite Capacity & Contention

aliases:
Distributed Consensus Design
Fault-Tolerant Distributed Agreement
Consensus Under Partial Failure
Fault- and Timing-Aware Consensus
Safety–Liveness Consensus Design

related_primes: consistency consistency_model eventual_consistency network concurrency synchronization partition state_and_state_transition termination_condition randomization probability uncertainty threshold closure boundedness trade_offs observability redundancy authentication trust latency decision constraint algorithm robustness single_point_of_failure

slug: consensus

slug: coordination

slug: consistency

slug: network

slug: concurrency

slug: synchronization

slug: partition

slug: randomization

slug: probability

slug: uncertainty

slug: threshold

slug: closure

slug: boundedness

slug: redundancy

slug: authentication

slug: latency

slug: decision

slug: constraint

slug: algorithm

slug: robustness

components:
Agreement Value Contract
Participant and Membership Model
Fault Model
Failure, Timeout, and Partition Model
Safety–Liveness Contract
Validity Rule
Coordination Protocol Selection Rule
Quorum or Voting Rule
Round, Epoch, and Leadership State
State Consistency Guard
Decision Certificate
Failure Detector
Stall and Partition Policy
Recovery Policy
Observability and Audit Trace
Termination Condition
Identity or Credential Signal
Redundancy Pool
Assumption Register
Event Log
Decision Authority Boundary
Operator Override Protocol
Post-Agreement Review
Commitment Boundary

mechanisms: Byzantine Fault-Tolerant Quorum Protocol

compression_statement: When independent agents must decide one value but messages may be delayed, lost, reordered, partitioned, or adversarial and participants may crash, recover, or equivocate, do not promise unconditional agreement, validity, and termination. Define the decision and membership epoch; state the fault and communication model; choose a safety–liveness contract; derive intersecting quorums and protocol rules; make tentative, locked, certified, and committed states distinct; require durable decision evidence; expose stalls rather than fabricating finality; and recover or reconfigure without erasing prior commitments.

canonical_formula: Given participants P in membership epoch e, admissible values V, fault budget F, communication model C, safety properties S, and liveness conditions L: choose protocol Π and certificate rule Q such that under F and C, no two correct participants decide different v ∈ V (agreement), every decided v satisfies the validity rule, and termination is claimed only when L holds. If Q cannot be obtained, preserve S and expose nontermination rather than inventing a decision.

structural_problem: Several independently controlled participants must expose one authoritative decision or ordered state even though they do not share instantaneous knowledge and some participants or communication paths may fail, recover, delay, partition, or behave adversarially. Each participant can see only a local and potentially stale slice of the system, so an apparently sufficient set of responses may coexist with a conflicting set elsewhere unless membership, fault bounds, rounds, and decision evidence are designed to intersect safely.

trigger_conditions: Two or more independently failing participants must agree on one value, leader, order, configuration, lock owner, or state transition.

trigger_conditions: A conflicting pair of decisions would be materially worse than temporary unavailability or delay.

trigger_conditions: Messages can be delayed, lost, duplicated, reordered, or partitioned, so silence is ambiguous.

trigger_conditions: Participants may crash, restart, lose volatile state, or, in stronger threat models, equivocate or collude.

trigger_conditions: No single permanently trusted participant can safely decide every instance without becoming an unacceptable failure or capture point.

trigger_conditions: The system needs a checkable notion of finality that recovering or lagging participants can verify.

trigger_conditions: Membership or leadership can change over time and stale authorities must be prevented from continuing to decide.

trigger_conditions: The application can define an admissible value domain and a validity predicate before agreement is attempted.

trigger_conditions: The system can state a finite fault budget or trust assumption rather than treating all failures as unbounded.

trigger_conditions: Operators need to distinguish a safe stall from a safety violation, and need recovery procedures for both.

symptoms: Two healthy subsets report different leaders, lock owners, configurations, balances, or committed commands.

symptoms: A node treats a timeout as proof that another node is dead and creates a second authority.

symptoms: A recovered participant forgets an earlier vote or lock and supports a conflicting value.

symptoms: A protocol claims high availability but quietly weakens finality during a network partition.

symptoms: Majority counts are based on changing or inconsistent membership views.

symptoms: A leader announces commitment without a certificate that other participants can verify.

symptoms: The system blocks indefinitely because progress assumptions were never stated or monitored.

symptoms: Repeated leader changes occur because timeout policy is unstable relative to actual latency.

symptoms: Nominally independent replicas fail together because they share one region, operator, software image, or credential root.

symptoms: An invalid or unauthorized proposal is committed because agreement was checked but validity was not.

symptoms: External side effects occur on tentative state and cannot be undone after leadership changes.

symptoms: A two-phase transaction coordinator is assumed to provide nonblocking consensus under coordinator failure.

root_tension: Agreement requires enough overlap and persistence that conflicting evidence cannot both become valid, while termination requires enough timely communication and available correct participants to collect that evidence. Under full asynchrony with faults, delay is indistinguishable from failure, so a deterministic protocol cannot guarantee both unbroken progress and safety without adding timing, randomness, failure-detector, trust, or availability assumptions.

anti_signatures: The problem is deliberative alignment, legitimacy, or shared understanding among people; use Consensus Convergence, Structured Expert Judgment Iteration, or a governance pattern.

anti_signatures: Temporary divergence is acceptable and deterministic merge after updates stop is the intended behavior; use a branching, reconciliation, or eventual-consistency direction rather than one-value finality.

anti_signatures: One trusted authority can legitimately decide and its failure is handled by ordinary failover; use Source-of-Truth Assignment or Fault-Tolerant Operation.

anti_signatures: The primary problem is atomic completion or compensation across transaction participants; use Transactional Atomicity or Nested and Distributed Transaction Coordination.

anti_signatures: Concurrent operations can be serialized or made commutative without tolerating participant or communication faults; use Concurrency Control or Order-Independent Processing.

anti_signatures: The system does not require one shared decided value and local autonomy is preferable.

anti_signatures: The value-validity rule is fundamentally contested or undefined; protocol agreement would only automate an unresolved governance problem.

anti_signatures: The task is to explain an impossibility theorem or a named protocol, not to design a reusable intervention pattern.

anti_signatures: Failure and adversary behavior are truly unbounded, so no finite quorum or trust model can justify a decision.

structural_intervention: Replace implicit, unconditional consensus expectations with an explicit agreement contract and evidence-preserving protocol: bind each decision to a membership epoch and value-validity rule; declare fault and timing assumptions; separate safety from liveness; derive quorum intersection and monotone round state; certify finality; expose stalls and partitions; and recover or reconfigure through transitions that preserve all prior safety-relevant commitments.

action_logic: Define the decision instance, admissible values, proposal authority, and externally meaningful finality boundary.

action_logic: Freeze or version the participant set and identity model for the instance; define how membership changes can become valid.

action_logic: State the participant and channel fault model, including correlated failure domains and the maximum tolerated fault budget.

action_logic: State the communication and timing model, distinguishing full asynchrony, partial synchrony, bounded delay, and clock or lease assumptions.

action_logic: Write a safety–liveness contract that names agreement, integrity, validity, durability, termination, and availability separately.

action_logic: Choose which guarantees are non-negotiable when partitions or uncertainty prevent all of them from holding simultaneously.

action_logic: Select a protocol family and derive quorum thresholds, intersection, locking, and certificate rules from the model rather than convention.

action_logic: Use monotone rounds, terms, views, or epochs so stale leaders and messages cannot acquire current authority.

action_logic: Persist votes, promises, locks, accepted values, and commit evidence before acknowledging actions that depend on them.

action_logic: Require a verifiable decision certificate before reporting commitment or triggering irreversible side effects.

action_logic: Treat failure detection as suspicion; route timeouts into safe retries, leader/view changes, pause, or reconfiguration rather than contradictory decisions.

action_logic: Expose no-quorum and undecided states explicitly, with bounded read-only or degraded behavior if that behavior preserves the declared invariants.

action_logic: Recover and reconfigure through overlapping membership or proof-carrying transfer so prior commitments remain visible.

action_logic: Test safety and liveness separately under message reordering, partitions, crash/recovery, disk loss, stale leadership, and adversarial behavior inside the declared model.

action_logic: Review assumptions and fault-domain independence after incidents, topology changes, software changes, and key rotation.

decision_rules: If two correct participants committing different values would cause irreversible harm, preserve agreement even when that means refusing progress.

decision_rules: If local availability during partition is more important than one-value finality and later merge is acceptable, choose a weaker consistency model instead of disguising divergence as consensus.

decision_rules: If arbitrary equivocation is plausible, require authenticated identities, evidence of conflicting statements, and a Byzantine-appropriate participant and quorum threshold.

decision_rules: If only crash or omission faults are in scope, use the simpler protocol only after verifying that identity compromise and stale durable state are genuinely excluded.

decision_rules: If the system is fully asynchronous, do not claim deterministic guaranteed termination; add an eventual-synchrony assumption, randomized progress mechanism, stronger failure detector, or explicit possibility of indefinite waiting.

decision_rules: If membership changes, require an overlap or joint configuration that prevents old and new electorates from certifying conflicting values.

decision_rules: If votes share a region, operator, software stack, or credential root, count that correlation in the fault model rather than treating every replica as independent.

decision_rules: If a value cannot be validated locally or by attached proof, agreement alone is insufficient; repair the validity rule before proceeding.

decision_rules: If a manual override is necessary, enter it as a governed epoch change or recovery action and eliminate competing technical authority.

decision_rules: If an external side effect is irreversible, delay it until the decision certificate and commitment boundary are satisfied.

decision_rules: If a participant cannot recover its highest promise, lock, vote, or committed prefix, keep it out of the voting set until state transfer proves safety.

decision_rules: If liveness incidents exceed the expected timing model while safety remains intact, tune timeouts or topology; do not weaken quorum intersection as an operational shortcut.

target_invariants: Agreement: no two correct participants commit different values for the same decision instance and membership lineage.

target_invariants: Integrity: each correct participant decides at most once per instance and does not acknowledge mutually inconsistent safety-relevant states.

target_invariants: Validity: every committed value satisfies the declared admissibility, provenance, authorization, and application constraints.

target_invariants: Quorum intersection: any two sets capable of producing conflicting progress evidence intersect in enough correct or accountable participants to prevent both certificates.

target_invariants: Round monotonicity: authority, promises, locks, and accepted state move only forward across ballots, terms, views, or epochs.

target_invariants: Durable memory: crash and recovery cannot erase a vote, promise, lock, or commitment needed by the safety proof.

target_invariants: Membership coherence: a decision certificate identifies the membership epoch and cannot be replayed as authority in an incompatible configuration.

target_invariants: Certificate verifiability: lagging, recovering, or external verifiers can distinguish committed state from tentative state.

target_invariants: Explicit nontermination: absence of sufficient evidence remains undecided rather than being coerced into finality.

target_invariants: Fault-budget honesty: guarantees are claimed only while the number and correlation of faults remain within the declared model.

target_invariants: Side-effect ordering: irreversible application effects do not precede the protocol state that authorizes them.

target_invariants: Liveness conditionality: progress claims state the timing, randomness, failure-detector, availability, and correct-participant conditions they require.

expected_outcomes: One auditable committed value or ordered log despite the tolerated participant and communication faults.

expected_outcomes: Reduced split-brain, double-ownership, conflicting-leader, and contradictory-configuration risk.

expected_outcomes: A clean distinction between safe unavailability and actual safety violation.

expected_outcomes: Recovery and membership change without forgetting prior commitments.

expected_outcomes: Protocol selection aligned to real fault, trust, latency, and durability conditions.

expected_outcomes: Transparent finality evidence for clients and dependent systems.

expected_outcomes: Faster diagnosis of liveness stalls because timing assumptions and failure detectors are observable.

expected_outcomes: Fewer false guarantees caused by majority folklore, timeout assumptions, or protocol-name cargo culting.

expected_outcomes: Controlled trade-offs among latency, availability, fault tolerance, geographic diversity, and verification cost.

expected_outcomes: A testable safety case that can be revalidated as topology, software, membership, and threat models change.

prose_essence:
Make distributed agreement achievable by declaring the fault, timing, membership, and validity model, preserving safety when progress is uncertain, and using only decision evidence that is valid under those assumptions.

Consensus failures usually come from hidden assumptions, not from a missing vote. A timeout cannot tell whether a node is dead or merely delayed, and a local majority can be unsafe if another membership view can form a conflicting majority. The intervention works by turning assumptions into explicit design inputs and making every advancement carry enough evidence to preserve a monotone safety invariant. Progress is then conditional and honest: the system moves when its liveness assumptions hold, and it remains visibly undecided when they do not.

The decisive move is not “take a vote.” It is to make the assumptions behind any vote explicit, then require evidence that remains safe across delay, crash, recovery, leader change, and membership change. When the evidence cannot be assembled, the correct output may be **undecided** rather than a guessed winner.

prose_tradeoffs:
- Safety versus availability: preserving one value during partition often requires refusing writes on subsets that cannot form the required certificate.
- Fault tolerance versus latency and communication: larger or more diverse quorums survive more faults but take longer and consume more bandwidth.
- Crash-fault simplicity versus Byzantine robustness: stronger adversary models require authentication, more participants, more messages, and more complex recovery.
- Stable-leader efficiency versus failover responsiveness: long leader tenures reduce coordination overhead, while aggressive leader change can thrash under variable latency.
- Deterministic operation versus randomized progress: randomness can restore probabilistic liveness under asynchronous scheduling but adds entropy, verification, and communication assumptions.
- Membership flexibility versus safety proof simplicity: frequent joins, removals, and key changes increase the risk of non-overlapping electorates.
- Geographic diversity versus quorum latency: spreading replicas reduces common-mode risk but makes timely quorum formation harder.
- Durable vote state versus throughput: synchronous persistence protects safety after crash but increases write latency and storage burden.
- Compact certificates versus audit richness: aggregated signatures reduce size but may complicate attribution, debugging, and key recovery.
- Automatic recovery versus operator control: automation reduces downtime but can propagate a flawed fault diagnosis; manual control adds delay and dual-authority risk.
- Strong validity checks versus proposal throughput: application proof and authorization prevent bad values but can dominate consensus cost.
- Protocol observability versus attack surface and privacy: rich traces improve diagnosis but may expose identities, topology, timing, or sensitive proposals.

Crash-Fault Majority Agreement

short_definition: Preserves one decided value when a bounded number of participants stop, restart, or omit work but do not deliberately equivocate.

distinctive_feature: The fault model excludes arbitrary conflicting messages, allowing smaller quorums and simpler evidence than Byzantine protocols.

distinct_from_parent: The parent is fault-model neutral; this variant narrows the design to crash-stop or crash-recovery behavior.

still_same_parent_because: It still resolves one-value agreement by making timing and fault assumptions explicit and protecting safety when progress is uncertain.

use_when: Participant identities are controlled and malicious equivocation is outside the primary threat model.

use_when: A majority or equivalent intersecting quorum remains reachable after the tolerated crash budget.

use_when: Safety-relevant promises and votes can be durably recovered.

example: Five replicas commit a configuration entry after three durable votes and pause writes when no majority is reachable.

example: A lock service elects one term-bounded leader and commits leases only after a majority log entry.

failure_modes: A network partition is misclassified as a dead minority.

Byzantine Fault-Tolerant Agreement

short_definition: Preserves agreement and validity when a bounded number of participants may lie, equivocate, collude, or send inconsistent messages.

distinctive_feature: Safety is designed against arbitrary participant behavior rather than only omission or crash.

distinct_from_parent: This variant strengthens the fault model and therefore changes quorum thresholds, evidence, locking, view-change, and key-governance requirements.

still_same_parent_because: The structural intervention remains assumption-bounded agreement with explicit safety, validity, and liveness conditions.

use_when: Participants span trust or administrative boundaries or compromise is plausible.

use_when: Votes can be authenticated and conflicting statements can be attributed.

use_when: The system can afford the larger participant, communication, and verification burden required by the threat model.

example: Seven independently governed validators require a five-signature certificate to tolerate two Byzantine participants.

example: A command is accepted only with authenticated, intersecting endorsements from controllers in independent fault domains.

failure_modes: Key compromise is omitted from the fault count.

failure_modes: Nominally independent validators share one operator.

failure_modes: Evidence verification becomes the throughput bottleneck.

short_definition: Preserves safety during arbitrary delay but guarantees progress only after communication and processing become timely enough for one leader or view to remain effective.

distinctive_feature: Liveness is conditional on eventual timing stability while safety remains independent of timeout accuracy.

distinct_from_parent: The parent permits several progress assumptions; this variant selects eventual synchrony and leader/view change.

still_same_parent_because: It handles the same impossibility by making the missing progress assumption explicit rather than weakening agreement silently.

use_when: The system may be asynchronous for long periods but is expected eventually to enter a sufficiently stable timing regime.

use_when: Stable-leader operation is materially cheaper than fully leaderless coordination.

use_when: Timeouts can adapt without being used as proof of safety.

example: A cluster can change leaders repeatedly during instability but commits only after a stable term reaches quorum.

example: Cross-region replicas pause minority writes during a partition and resume once a majority can communicate reliably.

failure_modes: Timeouts are too aggressive and leadership thrashes.

failure_modes: Operators claim unconditional termination.

failure_modes: A stale leader can still produce externally visible side effects.

Randomized Asynchronous Agreement

short_definition: Uses randomness to obtain probabilistic termination in an asynchronous environment while preserving deterministic safety conditions.

distinctive_feature: Progress comes from unpredictable shared choices rather than a deterministic timing bound.

distinct_from_parent: The parent is neutral about the liveness mechanism; this variant explicitly accepts probabilistic termination.

still_same_parent_because: The same agreement, validity, fault-budget, certificate, and finality structure remains.

source_primes: consensus_problem consensus randomization probability uncertainty

use_when: A deterministic scheduler could indefinitely prevent progress.

use_when: Randomness can be generated or verified without one faulty actor controlling the outcome.

use_when: Probabilistic liveness is acceptable and can be monitored.

example: Validators use a verifiable common coin to escape rounds in which an adversarial message schedule prevents deterministic convergence.

failure_modes: Expected termination is reported as a hard deadline.

failure_modes: Coin generation becomes a new centralized dependency.

Replicated-Log Consensus

short_definition: Repeats the agreement instance to create one durable ordered log of state transitions rather than deciding only one isolated value.

distinctive_feature: Agreement is extended across indexed log positions with prefix and ordering invariants.

distinct_from_parent: The parent covers one-value agreement generally; this variant adds repeated decisions, log matching, replay, compaction, and state-machine application.

still_same_parent_because: Each committed log position still depends on assumption-bounded distributed agreement.

source_primes: consensus state_and_state_transition consistency concurrency

use_when: A service must agree on a continuing sequence of commands or records.

use_when: The order of committed operations affects state.

use_when: Snapshots, compaction, lag recovery, and application determinism can be governed.

example: Replicas apply only the longest certified prefix of configuration changes in identical order.

failure_modes: Application handlers are nondeterministic.

failure_modes: Snapshot installation loses committed-prefix evidence.

failure_modes: External side effects occur before log commitment.

near_names:
Consensus Problem
Distributed Consensus Design
Fault-Tolerant Distributed Agreement
Consensus Under Partial Failure
Safety–Liveness Consensus Design
Byzantine Generals Problem
FLP Impossibility


Assumption-Light Inference

batch: First Iteration/Batch 30/Wave 2

slug: approximation

slug: variability

slug: stationarity

slug: parsimony

slug: overfitting

components:
Assumption Audit
Consequential Assumption Boundary
Assumption-Light Method Choice
Evidence Scale Alignment
Sensitivity Comparison
Interpretation Limit
Rank or Distribution-Free Rule
Outlier-Robust Summary
Resampling or Permutation Plan
Power or Information-Loss Note
Assumption Review Trigger

mechanisms:
Nonparametric Tests
Rank-Based Methods
Permutation Tests
Bootstrap-Like Checks
Robust Statistics
Median-Based Summaries
Assumption Audit Checklist
Sensitivity Analysis Protocol
Diagnostic Plot Review
Model Comparison Table

essence_one_line: Use inference methods that require fewer fragile assumptions when strong assumptions are unjustified.

compression_statement: When a conclusion depends on distributional, model-form, independence, stationarity, or measurement assumptions that the evidence does not justify, shift the inference frame toward robust, rank-based, resampling, or otherwise assumption-light methods; compare sensitivity against stronger assumptions; and state the limits of interpretation.

core_intuition: Inference is only as trustworthy as the assumptions that make it run. When those assumptions are stronger than the situation warrants, the right move is not to pretend the method is assumption-free; it is to expose the assumptions, relax the most fragile ones, and make the resulting claim more modest but less brittle.

canonical_formula: fragile_assumptions + evidence_need + assumption_audit + weaker_assumption_method + sensitivity_comparison + interpretation_limit -> robust_but_qualified_inference

structural_problem: A decision, claim, or comparison is being inferred from evidence through assumptions that may not hold. The procedure may look precise because it uses a formal model, but the conclusion is fragile if the data are small, skewed, outlier-heavy, nonstationary, ordinal, dependent, censored, or otherwise mismatched to the assumed form.

trigger_conditions: The data-generating process is poorly understood, changing, or too heterogeneous for a strong parametric model to be trusted.

trigger_conditions: The sample is small, skewed, heavy-tailed, ordinal, censored, clustered, dependent, or visibly affected by outliers.

trigger_conditions: A formal result changes substantially when distributional assumptions, independence assumptions, or outlier handling are varied.

trigger_conditions: Decision-makers need an inference, comparison, or uncertainty statement but cannot justify the usual model requirements.

trigger_conditions: The domain has high consequences for overclaiming, and a modest but robust conclusion is preferable to a precise but brittle one.

trigger_conditions: A default method is being applied because it is familiar rather than because its assumptions match the evidence.

trigger_conditions: Exploratory work has found a pattern, but confirmation under a strong model would create false confidence.

symptoms: Results depend on means and standard errors even though the data contain extreme values or asymmetric tails.

symptoms: A model output is reported with narrow precision while diagnostics show assumption violations.

symptoms: Different reasonable analysts choose different transformations, exclusions, or model forms and get different answers.

symptoms: The evidence is ordinal or ranked, but the analysis treats distances between values as if they were exact and equal.

symptoms: Stakeholders argue over whether the model is “valid” without separating consequential assumptions from harmless simplifications.

symptoms: A conclusion survives one formula but not a simpler rank, permutation, robust, or resampling check.

symptoms: The method choice is described by software default rather than by the claim and evidence structure.

root_tension: Inference needs structure to generalize beyond raw observations, but too much unverified structure can manufacture certainty. This archetype resolves the tension by lowering assumption burden while preserving enough structure to make a useful, qualified claim.

anti_signatures: The relevant assumptions are directly validated, stable, and central to the theory being tested rather than merely convenient defaults.

anti_signatures: The task is purely descriptive and does not require inference, comparison, uncertainty, or generalization.

anti_signatures: The evidence is so weak, biased, or malformed that no assumption-light method can make the claim responsible.

anti_signatures: A mechanistic or domain model is required for safety, legality, or causal interpretation and cannot be replaced by distribution-light reasoning.

anti_signatures: The decision requires maximum detection power under a well-supported model, and robustness checks have already shown low fragility.

anti_signatures: The proposed method only hides assumptions under a different name, such as unexamined resampling, arbitrary ranks, or untested exchangeability.

structural_intervention: Turn assumption dependence into an explicit design variable: inventory the assumptions behind the planned inference, identify which assumptions are consequential and weakly justified, choose a less assumption-dependent procedure or representation, compare the result with stronger-model alternatives, and communicate the claim only within validated interpretive limits.

action_logic: Name the claim, comparison, decision, or uncertainty statement that the inference is supposed to support.

action_logic: List the model, measurement, sampling, independence, stationarity, distributional, and outlier assumptions that the proposed inference relies on.

action_logic: Classify assumptions by consequence: which ones would change the answer, which ones are merely convenience assumptions, and which ones are unavoidable domain commitments.

action_logic: Choose an assumption-light method or evidence representation that preserves the information needed for the claim while relaxing unsupported assumptions.

action_logic: Compare the assumption-light result with the stronger-assumption result and investigate meaningful divergence.

action_logic: Use sensitivity, resampling, diagnostic, or holdout checks to see whether the inference is stable under plausible assumption changes.

action_logic: State the interpretation limit: what the result supports, what it does not support, and what additional evidence would strengthen the claim.

decision_rules: Use this archetype when the credibility of a conclusion depends more on unverified assumptions than on observed evidence.

decision_rules: Treat a weaker-assumption method as better only when it still preserves the information required by the decision.

decision_rules: Do not describe any method as assumption-free; name the remaining assumptions such as exchangeability, independence, measurement validity, or sampling adequacy.

decision_rules: If stronger-model and assumption-light results diverge, downgrade certainty, collect more evidence, or make the assumption dependence explicit before acting.

decision_rules: If an assumption-light method loses too much sensitivity to detect an effect worth acting on, pair the result with a power or information-loss note.

decision_rules: Prefer domain-grounded causal, mechanistic, or experimental design when causal identification is the main problem rather than distributional fragility.

target_invariants: Assumptions remain explicit, inspectable, and linked to the claim they enable.

target_invariants: Method choice is justified by evidence structure and decision need, not by habit or software default.

target_invariants: The intervention lowers unsupported assumption burden without pretending that inference is assumption-free.

target_invariants: Information loss from ranks, robust summaries, aggregation, or resampling is documented rather than hidden.

target_invariants: Interpretive limits are stated with the result, especially when robustness comes at the cost of specificity, power, or causal detail.

target_invariants: Concrete statistical tests remain mechanisms under the archetype rather than being promoted to the archetype itself.

expected_outcomes: Conclusions become less brittle under outliers, skew, non-normality, small samples, or uncertain model form.

expected_outcomes: False precision decreases because results are framed around defensible evidence rather than convenient assumptions.

expected_outcomes: Analysts can see which assumptions drive the conclusion and which methods merely change presentation.

expected_outcomes: Stakeholders receive more honest claims: sometimes weaker, often more robust, and easier to audit.

expected_outcomes: Future data collection is targeted toward the assumptions that matter most for decision quality.

expected_outcomes: Disagreements about methods become more productive because they are mapped to assumption burden and information preservation.

prose_essence:
Assumption-Light Inference is the pattern of making a conclusion less dependent on assumptions that the situation does not justify. It does not mean “assumption-free.” It means the assumption burden is audited, weakened where possible, compared against stronger-model alternatives, and carried into the interpretation of the result.

The archetype is useful whenever a formal inference looks more certain than the evidence allows. The goal is not to avoid models; it is to stop unvalidated model form, scale assumptions, independence assumptions, stationarity assumptions, or outlier-sensitive summaries from doing hidden argumentative work.

prose_when_to_use:
Use this archetype when a claim, comparison, or uncertainty statement must be made from evidence whose usual assumptions are doubtful. It is especially relevant with small samples, ordinal measures, skewed distributions, heavy tails, clustered observations, outliers, changing regimes, or field data that do not behave like the textbook case.

It is also useful when two reasonable analysts might disagree less about the data than about the assumptions imposed on the data. In that situation, the productive move is to surface the assumptions and choose a method or representation that asks less of the evidence.

Do not use it as a shortcut around deeper validity problems. If the data are unrepresentative, missing for meaningful reasons, causally confounded, or poorly measured, those problems still require their own archetypes.

prose_structural_problem:
A conclusion depends on more structure than the evidence can responsibly carry. A parametric model, ordinary mean comparison, default test, or standard interval may assume a distribution, independence pattern, measurement scale, or stable process that is not actually established.

The structural danger is false security. The result can look precise because the method is formal, while the inference is actually fragile because a hidden assumption is carrying the conclusion. The system then mistakes methodological familiarity for evidential strength.

prose_intervention_logic:
The intervention begins by naming the claim. Then it audits the assumptions that make the claim possible, separates consequential assumptions from minor simplifications, and chooses a lower-assumption method or representation that still preserves the information needed by the decision.

A responsible use of this archetype then compares results across assumption frames. If the strong model and the assumption-light frame agree, confidence may increase. If they diverge, the divergence becomes a finding: the conclusion depends on assumptions and should be softened, bounded, or investigated.

The final step is the interpretation limit. The result should travel with a statement of what it supports, what it does not support, and which assumptions remain.

prose_key_components:
### Assumption Audit

The **Assumption Audit** lists the assumptions behind the proposed inference. This includes distributional form, independence, stationarity, measurement scale, sampling, missingness, outlier treatment, and any domain assumptions needed for the claim. Without this component, method selection becomes a ritual.

### Consequential Assumption Boundary

The **Consequential Assumption Boundary** distinguishes assumptions that matter from assumptions that are harmless or already justified. The archetype does not try to remove every assumption. It focuses on assumptions whose failure would change the conclusion, action, or risk judgment.

### Assumption-Light Method Choice

The **Assumption-Light Method Choice** selects a procedure or representation that relaxes unsupported assumptions while preserving decision-relevant information. This might involve rank-based, robust, permutation, resampling, median-based, or distribution-free approaches, but the method is not the archetype.

### Evidence Scale Alignment

**Evidence Scale Alignment** keeps the method honest about what the data can express. Ordinal data should not be treated as precise interval measurements without justification. Skewed or censored data should not automatically be summarized as if means and symmetric errors were stable.

### Sensitivity Comparison

The **Sensitivity Comparison** asks whether the conclusion changes under plausible assumption changes or under stronger versus weaker methods. It prevents the new method from becoming a new unexamined default.

### Interpretation Limit

The **Interpretation Limit** is the claim boundary attached to the result. It says what the evidence supports, what remains uncertain, and what further evidence or assumptions would be needed for stronger claims.

### Optional Components

The **Rank or Distribution-Free Rule** is helpful when order is more defensible than distance. The **Outlier-Robust Summary** reduces undue influence from extremes while preserving awareness of tail risk. The **Resampling or Permutation Plan** makes empirical reference procedures explicit. The **Power or Information-Loss Note** records what the weaker assumption frame may have sacrificed. The **Assumption Review Trigger** reopens the audit when the domain, data, or failure evidence changes.

prose_common_mechanisms:
**Nonparametric tests** implement the archetype when they compare groups or distributions without relying on a full parametric model. They are mechanisms, not the archetype, because they only help when chosen in response to a named assumption threat.

**Rank-based methods** use order instead of metric distance. They are useful when ordinal structure is credible but exact distances are not. They should not be used to hide magnitude when magnitude is decision-relevant.

**Permutation tests** create a reference distribution by rearranging labels under an exchangeability assumption. They reduce some parametric assumptions but introduce their own assumptions, so they require explicit interpretation limits.

**Bootstrap-like checks** assess stability by resampling observed data. They can be useful, but they do not fix unrepresentative samples or missingness mechanisms.

**Robust statistics** and **median-based summaries** reduce sensitivity to outliers and heavy tails. They should be paired with tail reporting when rare events represent meaningful harm or risk.

**Assumption audit checklists**, **diagnostic plot reviews**, **sensitivity analysis protocols**, and **model comparison tables** make the reasoning visible. These artifacts help operationalize the archetype, but the archetype remains the full intervention: audit, method choice, comparison, and bounded interpretation.

prose_failure_modes:
The most common failure mode is the **assumption-free illusion**: describing nonparametric, robust, or resampling methods as if they have no assumptions. The mitigation is to name remaining assumptions explicitly.

Another failure mode is **information discard**, where a safer method throws away information the decision needs. This requires an information-loss note and sensitivity comparison.

A third is **mechanism ritualization**, where a named test is chosen because it is familiar. The fix is to require the assumption audit before mechanism selection.

A fourth is **robustness as hiding**, where outliers or rare cases are downweighted despite being ethically or operationally important. Robust summaries should be paired with tail reporting and domain review.

Finally, assumption-light inference can be misapplied to problems of causal identification, missingness, or representativeness. Those require neighboring archetypes, not merely weaker distributional assumptions.

prose_neighbor_distinctions:
**Bounded Approximation** simplifies calculation while bounding error. Assumption-Light Inference changes the inferential frame so conclusions depend less on unsupported assumptions.

**Sensitivity Analysis** tests how results vary when inputs or assumptions change. Assumption-Light Inference uses sensitivity as one component, but also includes method choice and interpretation limits.

**Hypothesis Testing Frame** defines claims, defaults, thresholds, and error risks. Assumption-Light Inference helps select the evidence procedure when the usual testing assumptions are fragile.

**Representative Sampling Design** governs who or what is observed. Assumption-Light Inference governs how a given body of evidence is interpreted, and it does not repair a biased sampling frame.

**Confounder Control** protects causal claims from hidden third variables. Assumption-Light Inference does not create causal identification by itself.

**Robustness Margin Design** builds systems that keep functioning across variation. Assumption-Light Inference builds claims that remain credible under weaker assumptions.

prose_cross_domain_examples:
In **healthcare**, skewed recovery times may be compared with medians, quantiles, and rank-based methods rather than a fragile mean-based model.

In **product analytics**, a small beta cohort may support bootstrap-like stability checks and median usage changes, while avoiding overprecise average-effect claims.

In **environmental monitoring**, censored and skewed pollutant readings may call for distribution-free comparisons and explicit interpretation limits.

In **education**, ordinal rubric scores may be compared as ordered evidence rather than treated as precise interval values.

In **operations**, robust downtime summaries can prevent rare outages from dominating typical-performance claims while still reporting the tail events separately.

prose_non_examples:
Running a named nonparametric test without an assumption audit is not this archetype. It is just a mechanism used by habit.

Using robust regression to make a causal claim from confounded observational data is not this archetype. The distributional method does not fix causal distortion.

Switching from means to medians because it makes performance look better is not this archetype. That is selective reporting.

Rejecting all parametric models on principle is also not this archetype. The point is justified assumption burden, not avoidance of models.

prose_tradeoffs:
Assumption-light methods can be less powerful, less precise, or less informative under a well-specified model. Rank methods may protect against questionable scale assumptions but discard magnitude. Robust summaries may prevent outlier domination but can also hide tail risk.

The archetype therefore favors credibility over maximal precision. That is valuable when assumptions are weak, but costly when strong models are justified and decision-relevant.

prose_invariants_to_preserve:
Assumptions must remain explicit. Method choice must be tied to the claim and evidence structure. Lowering assumption burden must not become an excuse to ignore sampling bias, confounding, missingness, or measurement validity.

The result must preserve enough information for the decision. Robustness should not erase rare harms or practically important magnitudes. Every result should include an interpretation limit that travels with the claim.

prose_target_outcomes:
The main outcome is a conclusion that is less brittle under plausible assumption failure. The draft should reduce false precision, expose assumption dependence, and make method disagreements easier to resolve.

A good application also improves learning. It shows which assumptions are worth testing, which data would strengthen the claim, and which conclusions are robust enough for action despite imperfect evidence.

prose_parameter_dimensions:
The first tuning dimension is **assumption strength**: how much structure the method asks the evidence to support. The second is **information preservation**: what the lower-assumption method keeps or discards. The third is **robustness versus power**: safer assumptions may reduce sensitivity to real effects.

Other parameters include the measurement scale, sample size, outlier treatment, dependence or clustering structure, stationarity of the process, interpretability needs, decision stakes, and the depth of sensitivity comparison required before action.

prose_variants_and_near_names:
**Rank-Based Inference** is a recognized variant for ordinal, skewed, or outlier-heavy evidence where order is more defensible than distance.

**Permutation-Based Inference** is a candidate variant that trades parametric distribution assumptions for explicit exchangeability or randomization assumptions.

**Outlier-Robust Inference** is a recognized variant focused on reducing undue influence from extreme observations while still respecting tail risk.

Near names include robust inference, distribution-free analysis, nonparametric method selection, and assumption-reduced inference. Specific tests, bootstrap checks, diagnostic plots, and robust estimators should be treated as mechanisms unless a later review finds distinct cross-domain intervention logic.

Rank-Based Inference

short_definition: Uses order information rather than metric distance when ranks are more defensible than interval-scale assumptions.

distinctive_feature: It preserves comparative order while deliberately discarding questionable magnitude information.

distinct_from_parent: The parent covers many ways to lower assumption burden; this variant specifically lowers scale assumptions by using ranks.

still_same_parent_because: It remains an implementation family for assumption-light inference rather than a standalone intervention logic.

source_primes: nonparametric_methods order robustness

use_when: Distance between values is not as trustworthy as ordering.

use_when: Outliers would dominate metric summaries.

Evidence Scale Alignment

role: Aligns method with ordinal evidence.

notes: Used to avoid overinterpreting numeric distance.

Interpretation Limit

role: Bounds the resulting claim.

notes: Ranks may not support magnitude claims.

Rank-Based Methods

mechanism_type: method

role: Converts values to ranks for comparison.

domain: education

example: Compare rubric-ranked growth without treating rubric intervals as exact distances.

failure_modes: Discarding magnitude information that is actually decision-relevant.

Permutation-Based Inference

short_definition: Uses label rearrangement or randomization logic to build a comparison reference without a parametric sampling distribution.

distinctive_feature: It trades parametric assumptions for an explicit exchangeability or randomization assumption.

distinct_from_parent: The parent may use several lower-assumption approaches; this variant relies specifically on permutation logic.

still_same_parent_because: Permutation is a concrete mechanism family under assumption-light inference.

use_when: Exchangeability or random assignment is defensible.

use_when: Parametric reference distributions are not trusted.

use_when: The comparison question can be represented by label rearrangement.

Resampling or Permutation Plan

role: Defines rearrangement rules.

notes: Clarifies exchangeability assumptions.

Interpretation Limit

role: Bounds claim strength.

notes: Prevents treating permutation output as assumption-free.

Permutation Tests

role: Implements reference distribution through rearrangement.

failure_modes: Using permutation when units are not exchangeable.

failure_modes: Ignoring dependence, clustering, or hidden assignment structure.

Outlier-Robust Inference

short_definition: Uses summaries, comparisons, or estimators that reduce undue dependence on extreme observations while still respecting meaningful extremes.

distinctive_feature: The central fragility is extreme-case influence rather than distributional form in general.

distinct_from_parent: The parent addresses assumption burden broadly; this variant targets outlier sensitivity specifically.

still_same_parent_because: It is still a method-choice and interpretation-limit variant inside assumption-light inference.

source_primes: robustness variability uncertainty

use_when: Means or ordinary least-squares-like summaries are unstable.

use_when: The decision needs central tendency or comparison without letting a few cases dominate.

Outlier-Robust Summary

role: Reduces outlier dominance.

notes: Must not erase meaningful tail risk.

Sensitivity Comparison

role: Compares with ordinary summaries.

notes: Shows whether extremes drive the conclusion.

Robust Statistics

role: Uses robust estimators.

Median-Based Summaries

role: Uses medians and quantiles.

example_domains: finance healthcare operations

failure_modes: Treating extreme but important cases as noise.

failure_modes: Using robust summaries to hide inequity, risk, or rare harm.

near_names:
Nonparametric Methods
Distribution-Free Analysis
Robust Statistics
Rank-Based Method