Retrieval-Spaced Reinforcement

batch: First Iteration/Batch 41

slug: scheduling

slug: feedback

slug: conditioning

slug: metacognition

components:
Knowledge Item
Retrieval Prompt
Spacing Interval
Recall Performance Signal
Interval Adjustment Rule
Application Review
Decay Assumption
Item Priority Tier
Confidence Judgment
Interleaving Set
Content Freshness Check
Retirement Rule
Remediation Trigger

mechanisms:
Spaced Flashcard System
Retrieval Quiz
Refresher Training Protocol
Recurring Practice Prompt
Skill Maintenance Drill
Adaptive Review Scheduler
Knowledge Retention Dashboard
Scenario Recall Drill
Post-Training Recall Check

essence_one_line: Schedule repeated active retrieval over expanding or adaptive intervals so useful knowledge remains available after forgetting pressure.

compression_statement: When knowledge fades after initial learning, reinforce it through spaced retrieval attempts whose intervals expand, contract, or repeat based on recall strength, priority, and forgetting risk, then reconnect the retrieved knowledge to practical use.

core_intuition: Durable memory is strengthened by effortful retrieval separated by time, not by simply rereading or being reminded. The spacing interval creates enough forgetting pressure to make recall meaningful, while the performance signal tells the system when to wait longer, return sooner, repair an error, or retire an item.

canonical_formula: knowledge_item + retrieval_prompt + spacing_interval + recall_performance_signal + interval_adjustment_rule + application_review -> durable_available_knowledge

structural_problem: Learners, workers, or teams initially understand or can perform something, but later cannot retrieve it reliably because review is absent, massed, passive, poorly timed, or disconnected from use.

trigger_conditions: The target knowledge or procedure must remain available beyond the initial teaching, briefing, meeting, or training event.

trigger_conditions: The interval between learning and real use is long, irregular, or unpredictable.

trigger_conditions: A one-time assessment, workshop, onboarding module, or announcement creates temporary familiarity but not durable recall.

trigger_conditions: Forgetting creates safety, compliance, quality, customer, operational, or performance risk.

trigger_conditions: The population has many items to retain, making continuous rehearsal too costly and unprioritized review too unreliable.

trigger_conditions: The organization needs to detect which knowledge is stable, fragile, stale, or overdue for repair.

symptoms: People recognize the answer when shown it but cannot produce it when needed.

symptoms: Training scores look adequate immediately after instruction but drop sharply weeks or months later.

symptoms: Refresher sessions become broad, repetitive, and inefficient because no one knows which items actually need review.

symptoms: Rare but critical procedures are forgotten until an incident exposes the gap.

symptoms: Review is driven by calendar convenience rather than measured recall strength or risk.

symptoms: Teams rely on static job aids, archives, or search when the situation requires fluent recall or fast discrimination.

symptoms: Learners spend time rereading familiar material while weaker items remain hidden.

root_tension: The system needs knowledge to remain available over time, but attention is scarce and forgetting is uneven. Reviewing everything constantly wastes effort; reviewing too late allows decay. The intervention must impose enough spaced retrieval pressure to strengthen memory while using recall evidence to allocate review intelligently.

anti_signatures: The main problem is task support at the point of use rather than retained recall; use Temporary Scaffold and Fade, Progressive Disclosure, or a job aid mechanism instead.

anti_signatures: The main problem is deciding whether a learner may progress to dependent work; use Mastery-Gate Progression instead.

anti_signatures: The main problem is final accountability or credentialing; use Summative Certification instead.

anti_signatures: The main problem is general recurrence of a meeting, inspection, or operational process; use Cadence Design rather than retrieval-spaced reinforcement.

anti_signatures: The main problem is decay timing of a non-memory effect, such as freshness, residual load, pharmacologic effect, or resource recovery; use Half-Life-Based Timing or Recovery Interval Design instead.

anti_signatures: The intervention is only a flashcard deck, quiz, notification, LMS module, or study schedule with no active recall, spacing logic, performance signal, and adaptation rule.

structural_intervention: Select important retrievable units, encode them into prompts or practice tasks, schedule active recall after increasing or adaptive intervals, capture recall quality, adjust the next interval, repair weak items, and periodically reconnect the item to real application.

logic: Choose knowledge items, procedures, discriminations, or cues worth maintaining because future retrieval matters.

logic: Turn each target into a prompt or task that requires recall, reconstruction, recognition-plus-justification, or procedural execution without exposing the answer first.

logic: Place the first retrieval far enough from initial learning to create effortful recall, but soon enough to prevent unrecoverable loss.

logic: Record whether recall was accurate, fluent, delayed, partially correct, overconfident, guessed, or dependent on cues.

logic: Expand the next interval after strong recall, shorten or repeat it after weak recall, and treat high-risk items more conservatively.

logic: When recall fails, correct the misunderstanding, improve the cue or item granularity, and schedule a near-term retrieval rather than merely showing the answer.

logic: Mix items and connect recall to realistic decisions, cases, or practice so retention transfers beyond isolated cue-answer pairs.

logic: Retire stable low-risk items, refresh stale items when reality changes, and escalate repeatedly failed items into remediation or redesign.

decision_rules: Use active retrieval before passive review; seeing the answer should follow a retrieval attempt, not replace it.

decision_rules: Let demonstrated recall strength, item priority, and forgetting risk govern interval changes rather than using one fixed calendar for all items.

decision_rules: Increase interval length only when recall is accurate enough and fluent enough for the intended domain.

decision_rules: Shorten intervals, split the item, add cue refinement, or trigger remediation when repeated recall failures reveal unstable knowledge.

decision_rules: Use application-oriented retrieval for knowledge that must transfer into decisions, procedures, conversations, or real-time response.

decision_rules: Cull low-value items aggressively; the archetype fails when it tries to maintain everything.

decision_rules: Revalidate items when policies, tools, facts, or procedures change so reinforcement does not preserve obsolete knowledge.

target_invariants: Retrieval must be active: the learner must attempt recall or execution before receiving the answer.

target_invariants: Retrieval attempts must be separated by meaningful time intervals rather than compressed into a single massed session.

target_invariants: Intervals must respond to performance, item priority, or decay risk rather than functioning as arbitrary reminders.

target_invariants: The knowledge item must remain meaningful and connected to use, not reduced to brittle cue-answer trivia unless trivia-level recall is the actual need.

target_invariants: Mechanisms such as flashcards, quizzes, schedules, dashboards, and LMS workflows must remain subordinate to the timed retrieval-and-adaptation logic.

target_invariants: High-stakes items require conservative review, clear ownership, and validated content freshness.

expected_outcomes: More reliable long-term recall of important knowledge, procedures, cues, and discriminations.

expected_outcomes: Reduced forgetting between initial learning and real-world use.

expected_outcomes: More efficient refresher effort because review concentrates on items that are weak, risky, or decaying.

expected_outcomes: Earlier detection of fragile, overconfident, or stale knowledge.

expected_outcomes: Better skill maintenance for rare events and perishable capabilities.

expected_outcomes: Less dependence on broad retraining when targeted retrieval reinforcement is sufficient.

prose_essence:
Retrieval-Spaced Reinforcement is the pattern of keeping knowledge available after initial learning by asking for active recall at strategically spaced moments. The important move is not simply repeating material. It is asking the learner, worker, or team to retrieve a knowledge item after some forgetting pressure has accumulated, then using the quality of that retrieval to decide what happens next.

A healthy implementation has six recognizable pieces: a knowledge item worth preserving, a prompt that requires recall, a spacing interval, a recall-performance signal, an interval-adjustment rule, and some connection back to application. Without those pieces, the design usually collapses into passive rereading, a static study schedule, a quiz artifact, or a generic cadence.

prose_when_to_use:
Use this archetype when something has already been taught, explained, practiced, or documented, but it must remain available later. It is especially useful when real use is delayed or rare, when forgotten knowledge creates safety or quality risk, when a training event creates temporary familiarity but not durable recall, or when broad refresher training wastes time because only some items have actually decayed.

It is not the right first choice when the main problem is initial understanding, conceptual reconstruction, certification, point-of-use support, or general recurring work. Those point toward Active Knowledge Construction, Summative Certification, Temporary Scaffold and Fade, or Cadence Design respectively.

prose_structural_problem:
The structural problem is delayed unavailability. A person or group has encountered the material, but later cannot produce it when needed. Immediate recognition and short-term fluency create a false sense of durability. Over time, memory decays unevenly: some items remain stable, some become fragile, and some become obsolete.

The system therefore faces an allocation problem. Reviewing everything constantly is wasteful and annoying; reviewing too late permits forgetting; passive review can feel productive while failing to build recall. Retrieval-Spaced Reinforcement solves this by turning forgetting into a measurable signal and using that signal to schedule the next reinforcement.

prose_intervention_logic:
The intervention begins by choosing a limited set of knowledge items that genuinely need durable availability. Each item becomes a retrieval prompt or practice task. The first delayed recall attempt is scheduled after enough time has passed to make recall effortful. The learner attempts retrieval before seeing the answer. The system records recall quality: accuracy, fluency, latency, confidence, cue dependence, or application quality.

Strong recall expands the interval. Weak recall shortens it, repeats the item, repairs the prompt, or triggers remediation. High-risk items can remain on conservative schedules even after success. Applied items should periodically appear in scenarios, cases, or drills so recall transfers beyond the original cue.

prose_key_components:
### Knowledge Item

**slug:** `knowledge_item`

Defines the specific fact, concept, rule, cue, discrimination, procedure, or skill fragment that must remain retrievable over time. The item should be granular enough to retrieve and assess, but not so atomized that it loses meaning or transfer value.

### Retrieval Prompt

**slug:** `retrieval_prompt`

Creates the cue or task that forces active recall, reconstruction, decision, or execution before feedback is shown. A prompt may be a question, scenario, partial cue, oral challenge, simulated case, procedure start, or diagnostic discrimination.

### Spacing Interval

**slug:** `spacing_interval`

Separates retrieval attempts by enough time for forgetting pressure to appear, making successful recall strengthening rather than mere repetition. The interval can be fixed, expanding, adaptive, risk-weighted, or event-triggered, but it must be intentionally managed.

### Recall Performance Signal

**slug:** `recall_performance_signal`

Captures how well the learner or system recalled the item so future reinforcement can be targeted. Useful signals include accuracy, latency, confidence, cue dependence, error type, fluency, transfer to a case, or procedural execution quality.

### Interval Adjustment Rule

**slug:** `interval_adjustment_rule`

Determines whether the next retrieval should occur sooner, later, again immediately, or only after content repair. Without this rule, the pattern collapses into a static study calendar or recurring reminder.

### Application Review

**slug:** `application_review`

Reconnects recalled material to practical use so the reinforced item remains usable outside an isolated prompt. This component is especially important for decisions, procedures, safety responses, diagnostic reasoning, and job performance.

### Decay Assumption

**slug:** `decay_assumption`

States why the item is expected to fade, how quickly it might fade, and what risk arises if recall is unavailable. The assumption can be empirical, risk-based, experience-based, or adjusted from observed recall performance.

prose_common_mechanisms:
Mechanisms implement the archetype, but they are not the archetype itself. A flashcard, quiz, reminder, dashboard, or refresher course only counts when it participates in the full loop: active retrieval, spaced timing, recall evidence, interval adjustment, and repair.

### Spaced Flashcard System

**slug:** `spaced_flashcard_system`
**mechanism type:** `software_or_tool`

Implements active recall prompts with scheduled repetition and interval adjustment for facts, vocabulary, formulas, policies, or cue-answer items.

### Retrieval Quiz

**slug:** `retrieval_quiz`
**mechanism type:** `test_or_assessment`

Creates low-stakes recall attempts that reveal whether knowledge remains available after a delay.

### Refresher Training Protocol

**slug:** `refresher_training_protocol`
**mechanism type:** `procedure`

Uses scheduled recall checks and targeted repair to maintain important training outcomes after initial instruction.

### Recurring Practice Prompt

**slug:** `recurring_practice_prompt`
**mechanism type:** `ritual`

Prompts periodic recall or execution in meetings, shifts, huddles, coaching sessions, or learning workflows.

### Skill Maintenance Drill

**slug:** `skill_maintenance_drill`
**mechanism type:** `method`

Requires delayed practice of rare or perishable skills so procedural recall and decision cues stay available.

### Adaptive Review Scheduler

**slug:** `adaptive_review_scheduler`
**mechanism type:** `software_or_tool`

Calculates next review dates from recall outcomes, item priority, and configured decay assumptions.

### Knowledge Retention Dashboard

**slug:** `knowledge_retention_dashboard`
**mechanism type:** `metric_or_dashboard`

Aggregates recall signals across people, items, roles, or teams to reveal fragile knowledge and overdue reinforcement.

### Scenario Recall Drill

**slug:** `scenario_recall_drill`
**mechanism type:** `method`

Uses realistic scenarios to require retrieval of knowledge in the context where it must later be applied.

### Post-Training Recall Check

**slug:** `post_training_recall_check`
**mechanism type:** `test_or_assessment`

Samples delayed recall after a course, onboarding module, release training, or policy rollout to determine whether reinforcement is needed.

prose_failure_modes: Passive review masquerade occurs when the system shows answers again without requiring retrieval. Interval drift occurs when reviews become arbitrary or overdue. Over-itemization creates burdensome trivia. Easy-cue illusion happens when people learn the prompt rather than the underlying knowledge. Stale-knowledge reinforcement preserves outdated procedures. One-size interval failure ignores differences in item difficulty, learner performance, or risk. Notification fatigue turns a retention system into noise. Recall without application strengthens labels but not usable action.

prose_neighbor_distinctions:
Retrieval-Spaced Reinforcement is distinct from **Cadence Design** because recurrence is not enough; the recurrence must create active recall and adapt to recall performance. It is distinct from **Half-Life-Based Timing** because the decay being managed is durable memory or skill availability, not any decaying effect. It is distinct from **Recovery Interval Design** because the interval is for strengthening retrieval under forgetting pressure, not for biological, operational, or resource recovery.

It is distinct from **Memory Palace Retrieval Indexing** because a memory palace organizes cues spatially, while this archetype governs repeated retrieval over time. It is distinct from **Formative Feedback Loop** because feedback here primarily adjusts retention timing, though retrieval attempts can also provide formative information. It is distinct from **Mastery-Gate Progression** and **Summative Certification** because it maintains availability over time rather than controlling progression or certifying endpoint achievement.

prose_cross_domain_examples: In language learning, vocabulary items are recalled after increasing intervals, and failed items return sooner. In safety operations, rare emergency steps are recalled in scenario drills between real incidents. In software incident response, engineers retrieve rollback criteria, escalation paths, and triage questions between outages. In customer support, agents reinforce product limits and exception rules after product-release training. In organizational learning, lessons from postmortems become recurring prompts before similar projects begin.

prose_non_examples: A final exam is not this archetype; it is endpoint certification unless embedded in a longer reinforcement loop. A searchable knowledge base is not this archetype; it supports lookup rather than retained recall. A flashcard deck is not automatically this archetype if the learner merely rereads cards or reviews them without spacing and adjustment. A memory palace used once to memorize a speech is spatial retrieval indexing, not retrieval-spaced reinforcement. A recurring Friday study block is only a cadence unless it includes active delayed recall and performance-based timing.

prose_tradeoffs:
Retrieval-spaced reinforcement trades attention for durability. Done well, it reduces waste by targeting weak or important items. Done poorly, it becomes notification fatigue or rote trivia. It also trades simplicity for adaptation: fixed intervals are easier to administer, while adaptive schedules better match actual forgetting but require performance data, content ownership, and transparency.

Another tradeoff is recall fluency versus transfer. Simple prompts build availability, but realistic performance often requires interleaving, scenarios, and application review. High-stakes domains should not rely on memory alone when checklists, safeguards, or point-of-use supports are safer.

prose_invariants_to_preserve: The first invariant is active retrieval: the learner must attempt recall before seeing the answer. The second is meaningful spacing: attempts must be separated by enough time to expose forgetting pressure. The third is adaptation: interval decisions must be influenced by performance, risk, or decay assumptions rather than arbitrary recurrence. The fourth is meaning preservation: knowledge should remain tied to use, not merely memorized as isolated cue-answer pairs. The fifth is mechanism humility: flashcards, quizzes, LMS modules, reminders, and dashboards are implementation machinery, not the archetype.

prose_target_outcomes: A good implementation produces durable recall, more efficient refresher effort, earlier detection of fragile knowledge, better maintenance of rare-event skills, and lower risk that training decays before real use. In organizations, it also converts postmortem lessons, policy changes, and release knowledge from archive entries into recurring available memory.

prose_parameter_dimensions:
### Item Granularity

Items can be tiny facts, conceptual discriminations, decision rules, procedures, or scenario-based tasks. Too broad and recall becomes hard to diagnose; too narrow and reinforcement becomes trivia.

### Initial Interval

The first interval should be long enough to create effortful recall but short enough to prevent discouraging failure. New, hard, high-risk, or poorly encoded items usually need shorter initial intervals.

### Interval Expansion Rate

Intervals may expand quickly after fluent recall or slowly for fragile, high-stakes, or rarely used knowledge. Aggressive expansion reduces workload but risks hidden forgetting.

### Recall Criterion

The system needs a criterion for what counts as success. Exact recall, approximate recall, explanation, correct decision, or correct procedure may be appropriate depending on the domain.

### Cue Format

Prompts can be direct questions, partial cues, scenarios, oral prompts, practice tasks, or cases. Varied cue formats reduce cue dependency and support transfer.

### Priority and Risk Tier

Not every item deserves equal reinforcement. High-stakes, high-value, rarely used, or error-prone items should receive more conservative timing and stronger validation.

### Adaptation Aggressiveness

Some systems update intervals after every attempt; others use simpler tiers or fixed schedules. More adaptation can improve efficiency but requires better signals and governance.

### Retirement and Freshness Rules

Items should leave active reinforcement when stable, obsolete, low-value, or absorbed into routine practice. Items that change must be refreshed so the loop does not preserve stale knowledge.

prose_variants_and_near_names:
Recognized variants include **Adaptive Spaced Repetition**, where recall performance directly drives the next interval; **Fixed-Interval Retrieval Cadence**, where simplicity matters more than fine-grained adaptation; **High-Stakes Skill Maintenance**, where rare but critical knowledge is reinforced conservatively; and **Application-Integrated Retrieval**, where delayed recall appears inside realistic cases or work tasks.

Near names include spaced repetition, active recall schedule, forgetting-curve review, spaced review schedule, refresher cycle, and retention schedule. These should point here only when the design requires active retrieval and spacing. Flashcards, quizzes, study schedules, reminders, and dashboards should collapse into mechanisms unless they instantiate the full loop.

Memory Palace Retrieval Indexing remains a promotion candidate and neighbor: it may deserve its own draft because its core structure is spatial indexing for ordered recall rather than interval-based reinforcement.

Adaptive Spaced Repetition

short_definition: A subtype that calculates future retrieval intervals from observed recall performance rather than using a fixed schedule.

distinctive_feature: The key feature is the feedback-controlled interval adjustment rule.

distinct_from_parent: The parent can include fixed, expanding, or adaptive spacing; this variant emphasizes algorithmic or rule-based adaptation.

still_same_parent_because: The underlying intervention is still active retrieval over spaced intervals to preserve knowledge.

source_primes: spaced_repetition feedback scheduling

use_when: Items vary in difficulty, risk, or stability.

use_when: The system can observe recall performance and adjust timing.

use_when: Review capacity is limited and should be allocated to weaker items.

example: Vocabulary items return sooner after failed recall and later after fluent recall.

domain: compliance

example: Critical policy exceptions are recalled more often for teams showing weak performance.

failure_modes: Over-trusting a noisy performance signal can over-review easy items or under-review fragile ones.

failure_modes: Algorithmic opacity may make learners feel controlled rather than supported.

Fixed-Interval Retrieval Cadence

short_definition: A subtype that uses pre-set review intervals for recall when adaptive evidence is unavailable or unnecessary.

distinctive_feature: The spacing plan is simple and pre-defined rather than dynamically adjusted after every recall.

distinct_from_parent: The parent includes both fixed and adaptive timing; this subtype is the low-complexity fixed-timing form.

still_same_parent_because: It still requires spaced active retrieval and delayed recall evidence.

use_when: The population or item set is too small for adaptive scheduling.

use_when: Simplicity and compliance matter more than precision.

use_when: Items are similarly difficult or risk-weighted.

domain: safety

example: Teams run a monthly recall drill for rare emergency steps and repeat missed steps next week.

failure_modes: The schedule becomes a generic cadence and ignores actual recall strength.

High-Stakes Skill Maintenance

short_definition: A risk-weighted variant that reinforces rare but critical knowledge or procedures before decay creates safety, compliance, or operational risk.

distinctive_feature: The timing and evidence standards are conservative because recall failure has meaningful consequences.

distinct_from_parent: The parent covers durable retention generally; this variant emphasizes risk tiering, governance, and safety validation.

still_same_parent_because: The core mechanism is still spaced active retrieval and interval adjustment.

use_when: Real events cannot be used as the only practice opportunity.

use_when: Recall must survive stress, delay, or unusual conditions.

example: A rare incident procedure is recalled and executed in short drills at intervals determined by error rates and risk tier.

failure_modes: A low-fidelity prompt creates false confidence for a high-stakes scenario.

failure_modes: The system becomes punitive rather than preventive and suppresses honest error signals.

Application-Integrated Retrieval

short_definition: A subtype that reinforces knowledge through delayed use in cases, simulations, decisions, or work tasks rather than isolated prompts.

distinctive_feature: Retrieval is embedded in an applied case or task, not a standalone recall item.

distinct_from_parent: The parent covers all timed retrieval; this variant prioritizes transfer and contextual execution.

still_same_parent_because: It still uses spaced retrieval and performance evidence to manage retention over time.

use_when: The target knowledge must transfer to action or judgment.

use_when: Cue-answer recall would be too brittle or artificial.

use_when: The domain values discrimination, timing, and contextual fit.

example: A delayed scenario asks engineers to choose a rollback criterion and explain it without looking at the runbook first.

failure_modes: Cases become too complex and obscure the specific item that needs reinforcement.

near_names:
Spaced Repetition
Active Recall Schedule
Forgetting-Curve Review
Spaced Review Schedule
Refresher Cycle
Retention Schedule


Return-Path Design

type: archetype

source: generated

batch: Batch 03

canonical_family: Channel Feedback & Return Paths

related_primes: backpressure optimal_stopping_rule flow feedback state_and_state_transition monitoring observability accountability recovery resilience constraint threshold buffering queueing transaction navigation controllability irreversibility reversibility_horizon coordination

slug: pipeline

slug: channel

slug: backtracking

slug: backpressure

slug: flow

slug: monitoring

slug: observability

slug: accountability

slug: recovery

slug: resilience

slug: constraint

slug: threshold

slug: buffering

slug: queueing

slug: transaction

slug: navigation

slug: controllability

slug: irreversibility

slug: coordination

components:
Forward Path Model
Return-Intent Catalog
Inverse Success Criteria
Backward Channel Boundary
Return Trigger Rule
State-Repair Model
Authority and Ownership Rule
Return Status Visibility
Capacity and Service-Level Budget
Loop-Closure Monitor
Appeal or Review Layer
Abuse and Fraud Guardrail
Time Window and Finality Rule
Round-Trip Test Case
Return-Reason Taxonomy
Substitute or Compensation Path

mechanisms:
Undo or Cancel Flow
Return Authorization Workflow
Reverse Logistics Channel
Appeal or Review Process
Rollback Runbook
Dead-Letter Queue and Replay
Refund or Reversal Protocol
De-Escalation Pathway
Resubmission with Preserved State
Return-Reason Dashboard
Unsubscribe or Exit Path
Round-Trip Journey Test

essence_one_line: For every forward path that moves people, work, goods, data, or decisions toward a goal, deliberately design the backward path that lets legitimate reversal, repair, appeal, return, or exit happen without improvisation.

compression_statement: A forward-flow pipeline optimizes for intake, progression, throughput, conversion, completion, or commitment. Real systems also need legitimate backward movement: mistakes must be undone, rejected work must be corrected, goods must be returned, decisions must be appealed, failed items must be repaired, overloaded stages must push back, and users must be able to exit without hostage friction. Return-Path Design makes that backward channel a separately designed subsystem rather than an afterthought. Its success criteria deliberately differ from the forward path: the return path values state integrity, accountability, evidence, fairness, capacity, dignity, containment, and closure, even when those criteria slow or partially invert the forward channel’s optimization.

core_intuition: A one-way system is rarely simpler in practice; it just hides the reverse flow in support tickets, exceptions, shadow work, resentment, abandoned items, and corrupted state. The backward path is not the forward path in reverse. It serves different users, moves different information, has different risk, and often needs different authority. Designing it explicitly turns trapped states into governable loops.

canonical_formula: forward_pipeline + legitimate_backward_intent + no_designed_return_channel -> stuck_state_or_shadow_return; forward_model + return_intents + inverse_success_criteria + backward_channel + state_repair + monitoring -> governed_return_loop

structural_problem: A system provides a clear way to enter, advance, submit, purchase, escalate, commit, or transform, but lacks an equally legible and governed way to reverse, revise, return, cancel, appeal, repair, de-escalate, or exit. The forward path becomes the only designed path, so backward movement is handled by improvisation, individual discretion, hidden exceptions, workarounds, or forced continuation.

trigger_conditions: A process has a directional forward path: intake to completion, source to receiver, application to approval, purchase to fulfillment, draft to publication, triage to treatment, deployment to production, or escalation to higher authority.

trigger_conditions: Participants can make mistakes, receive unsuitable outcomes, discover new evidence, experience changing constraints, or need to withdraw without destroying the larger system.

trigger_conditions: Forward progress changes state, custody, eligibility, obligation, money, material location, data lineage, reputation, authority, or access in ways that require governed reversal or correction.

trigger_conditions: The forward path has been optimized for speed, conversion, throughput, compliance, or queue clearing, while the backward path has been left informal, hidden, under-resourced, or punitive.

trigger_conditions: A legitimate return path would reduce stuck states, shadow labor, abandonment, disputes, unsafe continuation, data corruption, or unfair finality.

trigger_conditions: Some backward movement can be allowed without violating safety, law, privacy, evidence preservation, or legitimate finality constraints.

symptoms: Users can sign up, buy, apply, upload, escalate, or commit easily, but cancellation, return, appeal, deletion, de-escalation, or correction is obscure or manual.

symptoms: Support teams become the de facto return path, manually repairing cases that the designed workflow has no state for.

symptoms: Forward metrics look efficient while hidden queues of returns, appeals, failed submissions, rework, refunds, abandoned carts, dead-letter items, or unresolved exceptions accumulate elsewhere.

symptoms: People stay in unsafe, wrong, costly, or unwanted states because leaving is harder than entering.

symptoms: A process has an escalation ladder but no de-escalation, review, or return-to-local-control path.

symptoms: The system repeatedly asks users to start over instead of preserving state and allowing targeted correction.

symptoms: Goods, data, documents, or decisions move downstream faster than the organization can handle rejected, defective, misrouted, or recalled items.

symptoms: Local actors invent side channels, back doors, spreadsheets, email chains, refund hacks, or informal exceptions to move work backward.

root_tension: Forward paths reward momentum, commitment, legibility, and throughput. Backward paths require friction of a different kind: verification, diagnosis, traceability, consent, custody, restoration, and fair closure. The design challenge is to preserve legitimate reversibility without turning the return channel into an abuse path, a dark-pattern trap, or an unbounded operational sink.

anti_signatures: The problem is only downstream overload requiring upstream throttling; Backpressure may be the primary archetype.

anti_signatures: The problem is restoring a saved known-good technical state after risky change; Checkpoint and Rollback may be sufficient.

anti_signatures: The problem is a partial irreversible transaction requiring compensating action; Compensating Transaction may be the narrower archetype.

anti_signatures: The problem is restarting a suspended activity through monitored phases; Controlled Reentry may be the narrower archetype.

anti_signatures: The forward action is intentionally and legitimately final, and the right intervention is pre-commitment deliberation rather than backward path creation.

anti_signatures: The issue is only feedback about performance, not a path through which actors or artifacts can move backward, exit, repair, or appeal.

anti_signatures: A return channel would create unacceptable safety, privacy, fraud, legal, or accountability risk and no safer substitute can be defined.

structural_intervention: Model the forward pipeline and its state changes, enumerate legitimate backward intents, then build a separately governed return channel with its own triggers, permissions, evidence, capacity, state-repair logic, ownership, and monitoring. Optimize the backward channel for trustworthy closure and state integrity rather than simply mirroring the forward channel or maximizing forward conversion.

action_logic: Map the forward path, including stages, commitments, state changes, custody transfers, irreversible points, authorities, metrics, and user expectations.

action_logic: Identify legitimate backward intents: undo, cancel, exit, return, refund, repair, revise, resubmit, appeal, de-escalate, reject, recall, quarantine, replay, restore, or return-to-owner.

action_logic: Classify which backward movements are safe, conditional, costly, prohibited, time-limited, evidence-dependent, or compensation-based.

action_logic: Define inverse success criteria for the return path. If the forward path optimizes speed or conversion, the backward path may optimize correctness, informed choice, fairness, fraud resistance, state integrity, traceability, containment, dignity, and final closure.

action_logic: Design the backward channel as a first-class route with visible entry points, eligibility rules, state preservation, ownership, service levels, user communication, and handoff protocols.

action_logic: Bind each return event to state-repair logic: what is restored, what is compensated, what remains changed, what evidence is retained, and who is accountable after the return.

action_logic: Provision capacity and observability so reverse flow does not become a hidden queue, a support-team dumping ground, or a privileged exception path.

action_logic: Add guardrails against abuse, gaming, privacy violation, dark-pattern obstruction, unsafe reversal, or infinite loop cycling.

action_logic: Test round trips, not just forward completion: enter and exit, submit and correct, buy and return, escalate and de-escalate, deploy and roll back, reject and resubmit.

action_logic: Monitor return-path load, failure reasons, time to closure, recurrence, abandoned returns, and upstream design defects revealed by repeated backward flow.

decision_rules: Design the return path before scaling any forward path that creates obligation, custody, money movement, eligibility, public consequence, production state, or user lock-in.

decision_rules: A return path is inadequate if it requires hidden knowledge, heroic staff, informal exceptions, total restart, excessive delay, or surrender of rights unrelated to the return.

decision_rules: Do not make the return path frictionless in the same way as the forward path; tune friction to evidence, safety, fraud, consent, and state-integrity requirements.

decision_rules: A backward channel must have an owner, capacity budget, status visibility, and closure definition; otherwise it is a wish rather than a designed path.

decision_rules: If backward movement cannot restore the prior state, switch from rollback logic to compensation, disclosure, mitigation, or finality governance.

decision_rules: Repeated use of the return path should feed upstream redesign; high reverse flow is often evidence that the forward path is mis-specified.

decision_rules: Return-path restrictions must be explainable by legitimate constraints, not by desire to trap users, suppress complaints, or hide quality defects.

target_invariants: Legitimate backward movement remains possible, legible, and accountable.

target_invariants: State integrity is preserved: the system knows what changed, what was restored, what remains changed, and why.

target_invariants: Users or downstream actors are not forced to continue merely because the forward path was easier to enter than to leave.

target_invariants: The backward channel has enough capacity and authority to resolve returns rather than merely acknowledge them.

target_invariants: The return path is not allowed to become an unbounded abuse channel, fraud vector, or accountability escape hatch.

target_invariants: Legal finality, safety constraints, privacy, evidence preservation, and consent requirements remain binding.

target_invariants: Learning from reverse flow is fed back into the forward-path design rather than treated only as operational nuisance.

expected_outcomes: Fewer stuck states, abandoned cases, shadow workflows, unresolved returns, and support-driven repairs.

expected_outcomes: Better trust because participants can correct, exit, appeal, or return through a known process.

expected_outcomes: Lower hidden operational cost from exceptions and manual rework.

expected_outcomes: Improved data integrity and custody tracking when items, decisions, money, or records move backward.

expected_outcomes: Clearer distinction between reversible, compensable, reviewable, and final actions.

expected_outcomes: Earlier detection of forward-path defects through observable reverse-flow patterns.

expected_outcomes: Reduced dark-pattern risk, unfair lock-in, and involuntary escalation.

prose_common_mechanisms: Common mechanisms include undo and cancel flows, reverse logistics channels, refund or reversal protocols, appeal and review processes, rollback runbooks, dead-letter queues with replay, de-escalation pathways, resubmission with preserved state, and round-trip journey tests. These are mechanisms, not the archetype itself. The archetype is the full return-loop design that gives mechanisms authority, state linkage, capacity, monitoring, and closure.

prose_failure_modes: The most common failure is symbolic return: a link or policy exists, but no authority, capacity, state-repair model, or closure rule sits behind it. Another failure is dark-pattern backward friction, where entry is easy and exit is deliberately hard. Reverse-flow sinkholes occur when returns and appeals accumulate in hidden queues. Unsafe reversal occurs when teams promise rollback after state has become irreversible. Infinite rework loops occur when items move backward without exit criteria.

prose_neighbor_distinctions: Backpressure sends a downstream capacity signal upstream; Return-Path Design builds a broader backward route for exit, repair, return, correction, appeal, or restoration. Checkpoint and Rollback restores a saved state; Return-Path Design includes rollback but also covers social, service, governance, logistics, and workflow return channels. Controlled Reentry manages staged return after suspension; Return-Path Design covers many backward movements that are not reentry. Tiered Escalation moves issues upward; this archetype also requires de-escalation and return-to-owner paths.

prose_non_examples: A complaint survey is not a return path if it cannot move a case backward. A generic support email is not a return path without state linkage and closure authority. A one-off exception is not a reusable channel. A downstream congestion signal is backpressure unless it also creates a governed backward route. A promise of undo after an irreversible action is a safety risk, not return-path design.

prose_invariants_to_preserve: Legitimate backward movement must remain possible and legible. State integrity must survive reversal or repair. Return-path restrictions must be justified by safety, evidence, law, privacy, or finality rather than by desire to trap participants. The return channel must have enough authority and capacity to close cases. Repeated backward flow should feed upstream redesign.

User-Interface Reversal Path

short_definition: Provide visible undo, cancel, back, edit, data-export, delete, or exit paths that preserve state and explain consequences.

distinctive_feature: The backward channel is part of the visible interaction surface and must preserve user agency, informed consent, and state clarity.

distinct_from_parent: It specializes the parent pattern to digital and interaction design, where the path is navigational and stateful.

still_same_parent_because: It still uses the same return-path logic: legitimate backward intents, inverse success criteria, state repair, ownership, and closure.

use_when: Users can take forward actions that create account, payment, publication, consent, data, or workflow state.

use_when: The interface can safely expose reversal or correction without corrupting records or enabling abuse.

use_when: The system should avoid trapping users behind hidden support channels or dark-pattern friction.

example: A user can cancel a subscription, export data, and see when access, billing, and retention states end.

example: A rejected form preserves entered data and highlights only the fields requiring correction.

failure_modes: The interface claims reversal exists but hides it behind support delay, repeated confirmation, or total restart.

Reverse Logistics Return Path

short_definition: Design the reverse movement of goods, devices, parts, documents, packaging, waste, or inventory after outbound fulfillment.

distinctive_feature: The backward path must handle physical custody, inspection, loss, restocking, refurbishment, disposal, and financial reconciliation.

distinct_from_parent: It specializes the return path around material flow and custody rather than user-interface state or governance review.

still_same_parent_because: The same architecture applies: reverse intent, backward channel, state/custody repair, capacity, status, and monitoring.

source_primes: return_path flow pipeline

use_when: Physical items can be rejected, defective, recalled, repaired, reused, recycled, restocked, or disposed.

use_when: Outbound flow is efficient but returns are costly, opaque, or unmanaged.

use_when: Custody, inspection, compensation, and disposition must be tracked.

domain: retail

example: Returned goods flow through authorization, shipping, inspection, refund, restock, refurbishment, or disposal.

example: A recalled device is traced back through custody, quarantined, inspected, and replaced.

failure_modes: Reverse flow can become a hidden loss sink if inspection, disposition, and compensation are not closed.

Governance Appeal Return Path

short_definition: Provide a route for a participant to challenge, revise, or reopen a forward decision while preserving evidence and authority boundaries.

distinctive_feature: The backward path carries claims, evidence, authority, and legitimacy rather than goods or interface state.

distinct_from_parent: It specializes the parent pattern for governance, due process, review, and contested decisions.

still_same_parent_because: It remains a return path because a forward decision creates a state that must be reviewable, correctable, or explicitly final.

source_primes: return_path accountability decision

use_when: A decision pipeline creates eligibility, punishment, approval, denial, ranking, placement, or allocation consequences.

use_when: Errors, new evidence, changed context, or procedural concerns may legitimately require review.

use_when: The organization must preserve fairness, record integrity, timeliness, and finality.

example: Applicants can correct missing evidence, appeal denial, track status, and preserve original filing date.

domain: education

example: A student can appeal placement or discipline through a documented review path with evidence and time limits.

failure_modes: An appeal path can become performative if the reviewing authority lacks independence or power to repair the decision.

Data-Pipeline Repair Return Path

short_definition: Route failed, invalid, delayed, or suspect data items into quarantine, correction, replay, or compensation rather than dropping or corrupting them.

distinctive_feature: The backward channel handles machine-readable state, lineage, replay, idempotency, and data integrity.

distinct_from_parent: It specializes the parent pattern to computational pipelines and failed message/item repair.

still_same_parent_because: The same return-path obligations apply: triggers, channel boundary, state repair, ownership, capacity, and closure monitoring.

use_when: A data or message pipeline has downstream validation, transformation, or delivery failures.

use_when: Failed items must be repaired, replayed, quarantined, audited, or compensated without contaminating the main path.

use_when: Forward throughput pressure risks hiding failed items or making manual repair unsafe.

example: Invalid records go to a dead-letter queue with reason codes, repair tools, and controlled replay.

domain: payments

example: Failed payment messages are reconciled and replayed idempotently instead of duplicated or dropped.

failure_modes: Dead-letter queues can become graveyards if ownership, service levels, and replay criteria are missing.

Workflow Rework Return Path

short_definition: Let work products move backward to the right prior stage for correction, clarification, resubmission, or re-approval without restarting the entire process.

distinctive_feature: The return path points to a specific earlier stage with preserved state and re-entry criteria.

distinct_from_parent: It specializes the parent pattern for staged workflow rework rather than exits, appeals, logistics, or data repair.

still_same_parent_because: The pattern still centers on a backward channel with trigger, state repair, authority, and closure.

source_primes: return_path pipeline backtracking

use_when: Sequential work can fail quality, readiness, evidence, or dependency checks at a later stage.

use_when: The right response is targeted rework rather than total rejection or forward exception.

use_when: The organization needs to preserve history, ownership, and partial progress.

domain: publishing

example: A review process sends a manuscript back to revision with exact conditions for resubmission.

domain: manufacturing

example: A failed inspection routes a part to the correct rework cell with defect codes and reinspection criteria.

failure_modes: Rework loops can become infinite if exit criteria, time limits, and escalation rules are absent.

near_names:
Backward Channel Design
Return Channel Design
Reverse Flow Design
Exit Path Design
Undo Path Design
Appeal Path Design
Reverse Path Architecture


Reusable Pattern Application

batch: Third Sweep Candidate Batch 02

aliases:
pattern fit and tailoring
context-aware pattern reuse
solution-pattern instantiation
pattern-guided implementation

related_primes: classification validation adaptation constraint invariance transfer feedback boundary trade_offs

slug: analogy

slug: classification

slug: validation

slug: adaptation

slug: invariance

slug: transfer

slug: feedback

slug: boundary

essence_one_line: After retrieving a known solution pattern, test its fit, map context and contraindications, preserve its invariant core, adapt and instantiate it locally, validate use, and return learning.

canonical_formula: problem_signature + candidate_pattern + fit_and_contraindication_test + context_constraints + invariant_core + adaptation_plan + local_instantiation + validation + use_record -> justified_pattern_reuse_with_cumulative_learning

structural_problem: Teams either reinvent recurring solutions from scratch or copy a familiar pattern because its label resembles the problem, without testing causal fit, adapting to context, protecting invariants, or learning from local use.

prose_essence:
Reusable Pattern Application is the disciplined movement from a known solution pattern to a justified local intervention. Pattern libraries and archetype indexes can help a team recognize that a problem resembles something solved before. That retrieval is only the beginning. The dangerous gap lies between familiarity and fit: teams either reinvent at great cost or copy the visible form of a successful example while ignoring the forces, preconditions, tradeoffs, and failure boundaries that made it work.

The archetype turns reuse into a governed lifecycle. It defines the current problem, retrieves a candidate pattern, tests fit and contraindications, maps contextual constraints, identifies invariant core, designs adaptations, instantiates local roles and artifacts, validates ordinary and boundary cases, provides exception and exit, records deviations and outcomes, and sends generalizable learning back to the pattern owner. Reuse is successful when causal structure survives while local form changes enough to work.

prose_when_to_use:
Use this archetype after a mature solution pattern has been retrieved and the real task is whether and how to apply it under present constraints. It is especially useful when reference cases differ in scale, law, users, capability, culture, incentives, interfaces, or risk, and when both rigid copying and unstructured improvisation are dangerous. Teams need access to the pattern's forces, invariants, consequences, failures, and examples, plus authority to tailor implementation and monitor outcomes.

Do not use it to discover a pattern, complete missing evidence, or organize a catalog. Do not proceed when contraindications dominate, overlap with reference contexts is too weak, or local conditions make the invariant core impossible to preserve. In those cases select another pattern, redesign the problem, or develop a new intervention. A familiar label and several analogous examples are insufficient authorization.

prose_structural_problem:
Reusable knowledge sits at two failure-prone extremes. Reinvention discards accumulated learning, repeats known mistakes, and consumes scarce design capacity. Cargo-cult reuse copies artifacts, vocabulary, or ceremonies detached from the structural problem and intervention mechanism. Both failures arise because retrieval, fit, adaptation, instantiation, and validation are treated as one informal leap.

Context matters, but not every difference justifies abandoning a pattern. Some features are conventional surface form; others alter causal forces, constraints, or failure risks. Without an invariant core, teams cannot know what must survive. Without adaptation trace, they cannot learn whether a departure was deliberate. Without local validation and an exit path, reference authority becomes lock-in. Without feedback, pattern libraries fossilize and each application repeats the same boundary work.

prose_intervention_logic:
Start from a problem signature with positive, negative, and boundary evidence. Retrieve one or more candidate patterns and read their complete forces, preconditions, components, mechanisms, consequences, and known anti-patterns. Test necessary fit and contraindications before investing in tailoring. Map local constraints and distinguish fixed conditions, change targets, and uncertain assumptions. State the invariant core and show how each invariant will be instantiated locally.

Design adaptations explicitly: what changes, why, who owns it, which consequence is expected, and what triggers review. Translate the adapted pattern into roles, workflows, rules, artifacts, resources, and interfaces. Pilot under ordinary and high-risk boundary conditions. Test both outcomes and invariant preservation, compare alternatives, and provide exception, escalation, rollback, or abandonment. Record the application and return validated adaptations and failures to the pattern library without promoting local accidents into universal rules.

prose_key_components:
### Recurring Problem Signature

States the structural problem class and evidence that the present case belongs to it.

Operationally, this component must be represented in a form that decision makers can inspect and update. Use positive, boundary, and counterexample features rather than matching on vocabulary alone. Its owner, evidence source, confidence, and update cadence should be explicit; otherwise the component becomes a decorative label rather than load-bearing structure.

The component connects to the archetype by establishing why pattern reuse is justified. It is required because a familiar solution is selected before the actual problem is classified Reviewers should test it with ordinary, boundary, missing-data, and adversarial cases instead of assuming that a plausible description will behave correctly in use.

### Candidate Pattern Reference

Identifies the known pattern, its source, prior uses, forces, consequences, and maturity.

Operationally, this component must be represented in a form that decision makers can inspect and update. Retrieve the complete pattern record rather than an attractive example or slogan. Its owner, evidence source, confidence, and update cadence should be explicit; otherwise the component becomes a decorative label rather than load-bearing structure.

The component connects to the archetype by providing the reusable intervention hypothesis. It is required because teams copy a visible artifact without understanding its structure Reviewers should test it with ordinary, boundary, missing-data, and adversarial cases instead of assuming that a plausible description will behave correctly in use.

### Fit Criteria

Defines which problem forces, preconditions, and desired consequences must be present for application.

Operationally, this component must be represented in a form that decision makers can inspect and update. Separate necessary from optional criteria and include negative evidence. Its owner, evidence source, confidence, and update cadence should be explicit; otherwise the component becomes a decorative label rather than load-bearing structure.

The component connects to the archetype by turning retrieval into a falsifiable application decision. It is required because fit becomes subjective resemblance Reviewers should test it with ordinary, boundary, missing-data, and adversarial cases instead of assuming that a plausible description will behave correctly in use.

### Context Constraint Map

Records local law, scale, capability, incentives, culture, resources, interfaces, and dependencies that shape adaptation.

Operationally, this component must be represented in a form that decision makers can inspect and update. Include constraints that cannot be changed and those the application is intended to change. Its owner, evidence source, confidence, and update cadence should be explicit; otherwise the component becomes a decorative label rather than load-bearing structure.

The component connects to the archetype by showing where canonical form needs tailoring. It is required because the pattern is transplanted as though context were noise Reviewers should test it with ordinary, boundary, missing-data, and adversarial cases instead of assuming that a plausible description will behave correctly in use.

### Contraindication and Anti-Pattern Check

Tests conditions under which the pattern is unsafe, ineffective, or likely to produce a known anti-pattern.

Operationally, this component must be represented in a form that decision makers can inspect and update. Use the pattern's failure history, not only success cases. Its owner, evidence source, confidence, and update cadence should be explicit; otherwise the component becomes a decorative label rather than load-bearing structure.

The component connects to the archetype by preventing forced reuse and predictable misuse. It is required because teams interpret every mismatch as an implementation problem Reviewers should test it with ordinary, boundary, missing-data, and adversarial cases instead of assuming that a plausible description will behave correctly in use.

### Invariant Core

Specifies the load-bearing relationships that must survive adaptation for the application to remain an instance of the pattern.

Operationally, this component must be represented in a form that decision makers can inspect and update. Distinguish principle and causal structure from conventional surface form. Its owner, evidence source, confidence, and update cadence should be explicit; otherwise the component becomes a decorative label rather than load-bearing structure.

The component connects to the archetype by protecting mechanism identity during tailoring. It is required because adaptation removes the structure that made the pattern work Reviewers should test it with ordinary, boundary, missing-data, and adversarial cases instead of assuming that a plausible description will behave correctly in use.

### Adaptation Plan

Maps each contextual difference to a justified change in components, sequence, mechanism, interface, or governance.

Operationally, this component must be represented in a form that decision makers can inspect and update. Record rationale, owner, uncertainty, and expected consequences for every material departure. Its owner, evidence source, confidence, and update cadence should be explicit; otherwise the component becomes a decorative label rather than load-bearing structure.

The component connects to the archetype by converting fit analysis into a locally viable design. It is required because tailoring becomes undocumented improvisation Reviewers should test it with ordinary, boundary, missing-data, and adversarial cases instead of assuming that a plausible description will behave correctly in use.

### Implementation Instantiation

Translates the adapted pattern into concrete roles, artifacts, workflows, rules, resources, and handoffs.

Operationally, this component must be represented in a form that decision makers can inspect and update. Make explicit which local objects implement each invariant and component. Its owner, evidence source, confidence, and update cadence should be explicit; otherwise the component becomes a decorative label rather than load-bearing structure.

The component connects to the archetype by bridging abstraction to executable practice. It is required because a pattern card is mistaken for an implemented intervention Reviewers should test it with ordinary, boundary, missing-data, and adversarial cases instead of assuming that a plausible description will behave correctly in use.

### Local Validation Plan

Tests ordinary, boundary, failure, and counterexample cases before and during use.

Operationally, this component must be represented in a form that decision makers can inspect and update. Validate both outcome and fidelity to invariant core; hold out evidence when possible. Its owner, evidence source, confidence, and update cadence should be explicit; otherwise the component becomes a decorative label rather than load-bearing structure.

The component connects to the archetype by checking that the adapted instance works here. It is required because prior success is treated as proof under new constraints Reviewers should test it with ordinary, boundary, missing-data, and adversarial cases instead of assuming that a plausible description will behave correctly in use.

### Exception and Exit Path

Defines when to deviate, escalate, combine patterns, roll back, or abandon the application.

Operationally, this component must be represented in a form that decision makers can inspect and update. Protect users from conformance pressure and make failure to fit actionable. Its owner, evidence source, confidence, and update cadence should be explicit; otherwise the component becomes a decorative label rather than load-bearing structure.

The component connects to the archetype by preventing pattern lock-in. It is required because teams persist because abandoning a standard pattern appears illegitimate Reviewers should test it with ordinary, boundary, missing-data, and adversarial cases instead of assuming that a plausible description will behave correctly in use.

### Pattern-Use Record

Documents problem signature, selected pattern, fit evidence, adaptations, deviations, outcomes, and lessons.

Operationally, this component must be represented in a form that decision makers can inspect and update. Keep enough traceability to compare applications without exposing sensitive detail unnecessarily. Its owner, evidence source, confidence, and update cadence should be explicit; otherwise the component becomes a decorative label rather than load-bearing structure.

The component connects to the archetype by making application auditable and learnable. It is required because successful and failed tailoring disappear into local memory Reviewers should test it with ordinary, boundary, missing-data, and adversarial cases instead of assuming that a plausible description will behave correctly in use.

### Feedback to Pattern Library

Returns validated adaptations, contraindications, examples, and failure evidence to the source pattern owner.

Operationally, this component must be represented in a form that decision makers can inspect and update. Separate local exception from generalizable extension and require review before changing the canonical pattern. Its owner, evidence source, confidence, and update cadence should be explicit; otherwise the component becomes a decorative label rather than load-bearing structure.

The component connects to the archetype by closing reuse into cumulative pattern learning. It is required because the library remains static while users repeatedly rediscover the same boundary Reviewers should test it with ordinary, boundary, missing-data, and adversarial cases instead of assuming that a plausible description will behave correctly in use.

prose_common_mechanisms:
### Pattern-Fit Checklist

Tests required problem forces, preconditions, boundaries, and contraindications against the current case.

Use it when a known pattern has been retrieved and must be accepted or rejected Implementation should expose inputs, thresholds or transformation rules, expected outputs, responsible actors, and evidence of performance. Require evidence and counterexamples; do not let checklist completion substitute for judgment.

This mechanism is not the archetype by itself. It instantiates the broader intervention only when connected to the complete component set, monitoring, exception handling, and revision logic. The checklist supports fit analysis but does not adapt and instantiate the pattern.

### Forces-Consequences Matrix

Compares the forces balanced by the pattern with local priorities, constraints, tradeoffs, and expected consequences.

Use it when surface resemblance hides materially different causal pressures Implementation should expose inputs, thresholds or transformation rules, expected outputs, responsible actors, and evidence of performance. Include negative and delayed consequences from prior applications.

This mechanism is not the archetype by itself. It instantiates the broader intervention only when connected to the complete component set, monitoring, exception handling, and revision logic. The matrix is a reasoning mechanism inside the application lifecycle.

### Context-Mapping Workshop

Brings domain experts, implementers, and affected users together to map differences between reference and local contexts.

Use it when relevant constraints and tacit practice are distributed across actors Implementation should expose inputs, thresholds or transformation rules, expected outputs, responsible actors, and evidence of performance. Prevent dominant stakeholders from defining context alone and document unresolved disagreement.

This mechanism is not the archetype by itself. It instantiates the broader intervention only when connected to the complete component set, monitoring, exception handling, and revision logic. A workshop gathers evidence; it does not authorize a pattern or guarantee fit.

### Invariant-to-Instantiation Table

Maps each canonical invariant and component to the local role, artifact, rule, interface, or behavior that implements it.

Use it when the pattern is abstract and adaptation risks losing its load-bearing core Implementation should expose inputs, thresholds or transformation rules, expected outputs, responsible actors, and evidence of performance. Flag missing or ambiguous mappings and avoid cosmetic one-to-one compliance.

This mechanism is not the archetype by itself. It instantiates the broader intervention only when connected to the complete component set, monitoring, exception handling, and revision logic. The table traces fidelity but is not the whole intervention.

### Tailoring Decision Log

Records every material adaptation, its constraint, rationale, evidence, owner, and review trigger.

Use it when local deviations are necessary and will evolve Implementation should expose inputs, thresholds or transformation rules, expected outputs, responsible actors, and evidence of performance. Keep the log decision-relevant and protect it from becoming bureaucratic exhaust.

This mechanism is not the archetype by itself. It instantiates the broader intervention only when connected to the complete component set, monitoring, exception handling, and revision logic. Logging provides traceability; validation determines whether tailoring works.

### Reference-Implementation Comparison

Compares the local instance with one or more mature implementations to expose hidden obligations and differences.

Use it when pattern prose under-specifies practical interfaces or sequencing Implementation should expose inputs, thresholds or transformation rules, expected outputs, responsible actors, and evidence of performance. Treat references as evidence, not templates, and select more than one when context varies.

This mechanism is not the archetype by itself. It instantiates the broader intervention only when connected to the complete component set, monitoring, exception handling, and revision logic. Reference comparison informs design but does not justify copying.

### Bounded Pilot Application

Tests the adapted pattern in a limited setting with monitoring, exit, and learning rules.

Use it when fit is plausible but consequential uncertainty remains Implementation should expose inputs, thresholds or transformation rules, expected outputs, responsible actors, and evidence of performance. Choose a pilot representative of critical boundary conditions and protect participants.

This mechanism is not the archetype by itself. It instantiates the broader intervention only when connected to the complete component set, monitoring, exception handling, and revision logic. Piloting is one validation mechanism within the full application lifecycle.

### Conformance and Outcome Test

Checks both preservation of pattern invariants and achievement of local outcomes.

Use it when successful outcomes could arise despite a broken pattern or faithful application could still fail locally Implementation should expose inputs, thresholds or transformation rules, expected outputs, responsible actors, and evidence of performance. Avoid binary conformance scores and investigate causal contribution.

This mechanism is not the archetype by itself. It instantiates the broader intervention only when connected to the complete component set, monitoring, exception handling, and revision logic. Testing validates an instance; it does not define fit or adaptation.

### Anti-Pattern Pre-Mortem

Uses known failure patterns and local constraints to imagine how the application could fail or be gamed.

Use it when the pattern has common misuse paths or local incentives encourage shortcuts Implementation should expose inputs, thresholds or transformation rules, expected outputs, responsible actors, and evidence of performance. Include affected users and operational edge cases, then connect findings to design changes.

This mechanism is not the archetype by itself. It instantiates the broader intervention only when connected to the complete component set, monitoring, exception handling, and revision logic. A pre-mortem is a failure-analysis mechanism, not a pattern application by itself.

### Pattern-Use Registry

Stores searchable records of applications, adaptations, outcomes, exceptions, and confidence.

Use it when an organization reuses patterns across many teams and contexts Implementation should expose inputs, thresholds or transformation rules, expected outputs, responsible actors, and evidence of performance. Govern quality, privacy, ownership, and promotion of local lessons.

This mechanism is not the archetype by itself. It instantiates the broader intervention only when connected to the complete component set, monitoring, exception handling, and revision logic. The registry supports organizational learning; the archetype governs each fit-to-application cycle.

prose_failure_modes:
### Surface-Resemblance Overmatch

Shared vocabulary is mistaken for shared causal structure. Detect it through required forces or preconditions are absent Respond by reject the pattern and reopen problem classification

### Contraindication Suppression

Teams hide negative fit because a standard pattern is institutionally favored. Detect it through exception cases and dissent are omitted from review Respond by independent challenge, stop authority, and alternative comparison

### Invariant Erosion

Tailoring removes load-bearing relationships while retaining the pattern label. Detect it through invariant-to-instantiation mappings are missing or fail tests Respond by restore the structure, rename as a different intervention, or abandon use

### Context Underfitting

Legal, cultural, scale, capability, or interface constraints are treated as implementation noise. Detect it through failures cluster at local boundaries absent from references Respond by expand context map and redesign adaptations and validation

### Reference Lock-In

One famous implementation becomes the only accepted form. Detect it through alternatives and local evidence are rejected without causal analysis Respond by compare multiple references and restate invariant core

### No Library Feedback

Outcome and boundary learning remain local and the canonical pattern never improves. Detect it through repeated teams encounter the same undocumented adaptation Respond by create pattern-use records, owner review, and evidence-based extension policy

prose_neighbor_distinctions:
### Archetype Pattern Indexing

Organizes known patterns for recognition and retrieval.

Boundary rule: Use indexing to find a candidate pattern; use Reusable Pattern Application after retrieval to test fit, map context, preserve invariants, adapt, instantiate, validate, document, and feed outcomes back.

Hybrid cases should assign each design obligation to its proper owner rather than using Reusable Pattern Application as an umbrella for all adjacent work.

### Cautious Pattern Completion

Infers missing portions of an incomplete observation from a known pattern while representing uncertainty.

Boundary rule: Use it to complete evidence or representation; use Reusable Pattern Application to intervene in a real problem using a known solution structure.

Hybrid cases should assign each design obligation to its proper owner rather than using Reusable Pattern Application as an umbrella for all adjacent work.

### Archetype Overmatching Guardrail

Prevents premature or forced assignment of cases to familiar archetypes.

Boundary rule: Use it as a diagnostic safeguard; use Reusable Pattern Application when a candidate pattern survives matching and must be tailored and deployed.

Hybrid cases should assign each design obligation to its proper owner rather than using Reusable Pattern Application as an umbrella for all adjacent work.

### Pattern Detection with Validation

Discovers and validates recurring regularity in data or cases.

Boundary rule: Use it when the pattern is not yet established; use Reusable Pattern Application when a mature solution pattern is already known and the task is fit and adaptation.

Hybrid cases should assign each design obligation to its proper owner rather than using Reusable Pattern Application as an umbrella for all adjacent work.

### Representation Fit Selection

Chooses a representational form appropriate to task and audience.

Boundary rule: Use it when the artifact or encoding is the design object; use Reusable Pattern Application when a full intervention structure is being instantiated.

Hybrid cases should assign each design obligation to its proper owner rather than using Reusable Pattern Application as an umbrella for all adjacent work.

### Standardization and Simplification

Reduces variation by establishing common forms and practices.

Boundary rule: Use it when uniformity is the intervention; reusable pattern application permits contextual tailoring while protecting only invariant structure.

Hybrid cases should assign each design obligation to its proper owner rather than using Reusable Pattern Application as an umbrella for all adjacent work.

prose_cross_domain_examples:
### Software Architecture

A team retrieves a circuit-breaker pattern, tests whether cascading remote-call failure is the actual problem, maps latency and availability constraints, adapts thresholds and fallbacks, pilots under load, and records outcomes.

Why it fits: a known intervention is selected only after fit and then tailored while preserving isolation, state, and recovery invariants The design is evaluated by failure containment, false trips, recovery, interface fidelity, and documented deviations

### Clinical Operations

A hospital adapts an early-deterioration response pathway to local staffing, patient mix, escalation authority, and diagnostic access while preserving surveillance and response invariants.

Why it fits: the pathway is mature but cannot be transplanted without context and contraindication work The design is evaluated by sensitivity, workload, response time, equity, override use, and patient outcomes

### Emergency Management

A municipality applies an incident-command pattern, mapping legal authority, volunteer organizations, communication infrastructure, and community trust before exercises and deployment.

Why it fits: a recognized coordination solution requires local role and interface instantiation The design is evaluated by role clarity, handoff, exercise failures, authority legitimacy, and recovery

### Education

Teachers adapt worked-example fading to learner prior knowledge, subject matter, class size, accessibility needs, and assessment while preserving modeling-to-responsibility progression.

Why it fits: the instructional pattern is known but fit and adaptation determine whether it transfers The design is evaluated by learning gain, cognitive load, participation, transfer, and fade timing

### Public Governance

An agency applies a citizen-review-board pattern, tailoring appointment, information access, remedy authority, confidentiality, and anti-capture safeguards to local law.

Why it fits: the governance pattern's invariant accountability function must survive contextual legal design The design is evaluated by independence, access, remedy completion, representation, and capture indicators

### Service Design

A benefits office adapts a one-stop intake pattern to multilingual access, eligibility complexity, privacy, disability accommodation, and referral partners.

Why it fits: a known service pattern needs local fit, interface, and exception governance The design is evaluated by completion, error, access equity, handoff loss, and user burden

prose_non_examples:
### Catalog Search

A designer queries tags and retrieves three possible patterns. It fails the archetype boundary because retrieval stops before fit, adaptation, instantiation, and validation Route the case to Archetype Pattern Indexing when that is the actual design object.

### Novel Pattern Discovery

Analysts infer a recurring structure from a new case collection. It fails the archetype boundary because the pattern is not yet established for reuse Route the case to Pattern Detection with Validation when that is the actual design object.

### Template Copy

A team copies a reference checklist and changes its logo. It fails the archetype boundary because no forces, constraints, invariant core, or local validation are addressed Route the case to document templating or standard operating procedure when that is the actual design object.

### Uniform Standardization

Management mandates identical practice everywhere to reduce variation. It fails the archetype boundary because contextual tailoring is prohibited and uniformity is the intervention Route the case to Standardization and Simplification when that is the actual design object.

prose_tradeoffs:
### Speed versus Fit

Reuse can accelerate design, but shallow assessment carries the wrong solution into implementation. The design should not pretend this tension disappears. Use risk-tiered fit checks, early contraindication review, and reversible pilots and make the selected position visible to affected actors.

### Fidelity versus Adaptation

Strong fidelity protects mechanism while rigid form ignores local constraints. The design should not pretend this tension disappears. Use separate invariant core from adaptable shell and test both conformance and outcomes and make the selected position visible to affected actors.

### Consistency versus Autonomy

Shared patterns aid coordination while local teams need authority to respond to real differences. The design should not pretend this tension disappears. Use declare adaptation bands, escalation paths, and pattern-owner review and make the selected position visible to affected actors.

### Learning versus Burden

Detailed use records improve the library but can slow implementation and expose sensitive context. The design should not pretend this tension disappears. Use minimum sufficient records, structured fields, privacy controls, and value-based feedback thresholds and make the selected position visible to affected actors.

prose_invariants_to_preserve:
### Problem Before Pattern

Application begins from a verified problem signature, not attachment to a familiar pattern. Preserve it by requiring fit evidence and counterexamples before authorization A violation is indicated by the pattern name appears before the problem is described

### Contraindications Count

Negative fit and unsafe conditions can stop application. Preserve it by publishing stop criteria and independent challenge A violation is indicated by every mismatch is reframed as implementation failure

### Invariant Core Preserved

Contextual tailoring retains the relationships that make the pattern causal. Preserve it by mapping each invariant to a local instantiation and test A violation is indicated by surface artifacts remain while load-bearing structure disappears

### Adaptation Traceable

Material changes have explicit constraints, rationale, owners, and review triggers. Preserve it by maintaining a tailoring decision log A violation is indicated by local drift cannot be distinguished from deliberate design

### Local Evidence Governs

Prior success is a hypothesis, not proof of present fit. Preserve it by piloting ordinary and boundary cases with outcomes and alternatives A violation is indicated by reference authority overrides contradictory local evidence

### Reuse Produces Learning

Applications return validated examples, failures, adaptations, and contraindications. Preserve it by maintaining use records and pattern-owner review A violation is indicated by each team repeats the same tailoring work without cumulative improvement

prose_target_outcomes:
The immediate outcome is faster solution design without sacrificing causal fit. Teams can explain why the problem belongs to the pattern class, which constraints require adaptation, which relationships must remain invariant, how the pattern is instantiated, and what evidence could falsify the application. Implementation burden falls because mature knowledge is reused, while avoidable failure falls because contraindications and boundary cases are explicit.

Longer-term outcomes include comparable but not artificially uniform implementations, clearer exception governance, fewer cargo-cult rituals, more honest abandonment of poor fits, and a pattern library enriched by actual applications. Organizations gain cumulative learning: each use record adds evidence about contexts, adaptations, consequences, and anti-patterns, allowing future teams to search and tailor with better boundaries.

prose_parameter_dimensions:
### Fit Threshold

Sets how much evidence of matching forces and preconditions is required. Low settings create weak matches are accepted; high settings create useful reuse is rejected under impossible proof demands. Tune against failure cost, reversibility, pattern maturity, and counterexamples and record the rationale.

### Adaptation Latitude

Sets how much local form may change while the pattern identity is retained. Low settings create the reference is copied rigidly; high settings create invariant structure is lost. Tune against invariant mapping, local constraints, and outcome evidence and record the rationale.

### Pilot Scope

Sets breadth, duration, and boundary coverage before wider use. Low settings create critical context and failure modes remain untested; high settings create learning is slow and participants bear unnecessary experiment burden. Tune against uncertainty, reversibility, heterogeneity, and harm and record the rationale.

### Conformance Depth

Sets how thoroughly implementation is checked against invariant core. Low settings create cargo-cult instances pass; high settings create bureaucratic compliance displaces outcomes. Tune against causal importance of each invariant and monitoring cost and record the rationale.

### Library Feedback Threshold

Sets what local learning is promoted into canonical pattern knowledge. Low settings create generalizable boundaries are lost; high settings create local accidents clutter the pattern. Tune against replication, causal explanation, and review by pattern owners and record the rationale.

prose_variants_and_near_names:
### Design-Pattern Application

Adapts a known architecture or design pattern to a technical system.

Its load-bearing distinction is interfaces, quality attributes, and implementation consequences dominate fit Preserve it as a named variant when that difference changes design or failure analysis. Collapse it when the work merely retrieves or documents the pattern

### Clinical-Pathway Application

Adapts an evidence-informed care pattern to local population, staffing, resources, and safety constraints.

Its load-bearing distinction is contraindications, professional judgment, and outcome monitoring are load-bearing Preserve it as a named variant when that difference changes design or failure analysis. Collapse it when the pathway is copied without local fit or exception governance

### Governance-Pattern Application

Instantiates known accountability, participation, delegation, or oversight structures in a local institution.

Its load-bearing distinction is authority, legitimacy, remedy, and capture risks dominate tailoring Preserve it as a named variant when that difference changes design or failure analysis. Collapse it when the intervention is only a generic template

### Instructional-Pattern Application

Adapts a learning design pattern to learners, content, setting, and assessment.

Its load-bearing distinction is learner variability and transfer evidence dominate validation Preserve it as a named variant when that difference changes design or failure analysis. Collapse it when the pattern name is used as a lesson-plan label without invariant mapping

raw_bundle_path: solution_archetypes/_Batches2/Third Sweep Candidate Batch 02/reusable_pattern_application_solution_archetype_output_bundle.zip


name: Revealed Preference Validation Against Indifference Curves

batch: Second Iteration/Batch 06

aliases: Choice-Based Indifference Curve Inference

alias_records: Choice-Based Indifference Curve Inference

slug: optimization

essence_one_line: Use what actors actually choose under constraints to infer their trade-off curves, then test whether those inferred curves are coherent enough to guide decisions.

compression_statement: Revealed Preference Validation Against Indifference Curves treats observed choices as evidence about a decision maker’s implicit substitution rates. It reconstructs candidate indifference contours from choice data, checks them against budget, feasibility, dominance, and consistency constraints, and flags where observed behavior contradicts the claimed preference model.

core_intuition: People often say one trade-off matters, but their choices reveal another. The archetype turns behavior into a check on stated preference and on theoretical utility maps.

canonical_formula: valid_preference_surface = observed_choice_set × feasible_budget_set × inferred_substitution_rates × consistency_tests × anomaly_explanation_boundary

structural_problem: A system must reason about preferences, trade-offs, or utility contours, but stated preferences, assumed indifference curves, or model-implied trade-offs may not match the choices people actually make under constraint.

trigger_conditions: A decision maker claims to value two goods, goals, benefits, risks, or outcomes in a certain ratio, but observed choices may reveal different substitution rates.

trigger_conditions: A product, policy, compensation, or conservation decision depends on estimating trade-offs that cannot be observed directly.

trigger_conditions: A team has survey or stated-preference data but also has behavioral records that may validate or contradict it.

trigger_conditions: The same actor makes repeated choices under different price, budget, risk, or bundle conditions.

trigger_conditions: Observed selections appear inconsistent, dominated, cyclic, path-dependent, or sensitive to framing.

trigger_conditions: The project needs to distinguish stable preference from noise, manipulation, constraint artifacts, habit, or limited attention.

symptoms: Stated willingness-to-pay diverges from purchase, uptake, or opt-out behavior.

symptoms: A model assumes smooth trade-offs, but observed choices create discontinuities or kinks.

symptoms: Actors accept a bundle that seems worse than an available alternative under the stated objective.

symptoms: Preference estimates change sharply when options are reframed, reordered, bundled, or priced differently.

symptoms: Policy makers infer public values from one kind of evidence while actual behavior suggests another.

symptoms: Design teams debate whether a choice reflects true preference, constraint, confusion, inertia, or incentive distortion.

symptoms: A utility or satisfaction model predicts a selection that people reliably reject.

root_tension: Preferences are internal and context-sensitive, while the available evidence is external behavior shaped by budgets, prices, defaults, information, habits, social pressure, and constraints.

anti_signatures: The task is simply to map possible trade-offs before behavior is observed; use broader tradeoff-surface or multiobjective mapping patterns.

anti_signatures: The issue is assigning explicit weights to objectives through a deliberative process; use Objective Weighting Governance.

anti_signatures: The issue is designing incentives so truthful information is revealed; use Incentive-Compatible Rule Design or mechanism-design neighbors.

anti_signatures: The issue is estimating risk tolerance rather than trade-off contours among bundles; use Risk Aversion Calibration.

anti_signatures: The issue is optimizing a known utility function rather than validating it from behavior.

anti_signatures: Observed choices are unavailable, irrelevant, coerced, or so constrained that they cannot meaningfully reveal preference.

structural_intervention: Collect comparable choice observations, define the feasible option set behind each choice, infer candidate indifference contours, test them for revealed-preference consistency, and separate genuine preference signals from constraint, framing, or data artifacts.

action_logic: Define the decision domain, goods or attributes, actor unit, time horizon, and constraints that make choices comparable.

action_logic: Record observed choices together with the feasible alternatives that were actually available at the time of choice.

action_logic: Normalize bundles, prices, benefits, risks, and contextual variables so trade-offs can be compared across choice occasions.

action_logic: Infer local substitution rates from choices at the margins and assemble candidate indifference contours or preference regions.

action_logic: Run consistency checks for dominance, reversals, cyclic preference, budget violations, and incompatible revealed preference relations.

action_logic: Compare inferred contours against stated preferences, survey responses, policy claims, or model-assumed utility functions.

action_logic: Investigate anomalies as potential evidence of framing, defaults, constraints, misinformation, fatigue, strategic behavior, or unstable preference.

action_logic: Set confidence boundaries around the inferred curves and mark where extrapolation would exceed the evidence.

action_logic: Use the validated preference map to revise product bundles, policy options, compensation menus, pricing, or welfare analysis.

decision_rules: Treat a choice as preference evidence only when the actor plausibly understood the options and could choose among them.

decision_rules: Always model the feasible set; a rejected option reveals little if it was unavailable, unaffordable, inaccessible, or hidden.

decision_rules: Do not infer a smooth indifference curve from sparse, discontinuous, or heavily constrained choices without uncertainty bounds.

decision_rules: Flag dominated choices as diagnostic events rather than automatically dismissing them as irrational.

decision_rules: Separate preference inconsistency from data error, framing effects, inertia, status quo bias, and strategic misrepresentation.

decision_rules: Use repeated or varied choice contexts before claiming stable substitution rates.

decision_rules: Treat revealed preference as stronger for actual high-stakes choices than for hypothetical or low-consequence tasks.

decision_rules: Escalate to ethical review when inferred preferences might be used to manipulate, exploit, or price-discriminate against actors.

target_invariants: Observed choices remain linked to the feasible alternatives available at the time.

target_invariants: Inferred curves are not treated as direct facts; they remain model-backed interpretations of behavior.

target_invariants: Consistency failures are preserved as evidence rather than hidden by overfitting.

target_invariants: Constraints, defaults, information quality, and choice architecture are documented.

target_invariants: Stated preferences and revealed preferences are compared without assuming either is automatically superior.

target_invariants: Use of inferred preferences remains bounded by privacy, consent, fairness, and non-exploitation constraints.

expected_outcomes: More realistic estimates of trade-off rates, willingness-to-pay, benefit preferences, or policy substitution patterns.

expected_outcomes: Detection of inconsistencies between stated values, assumed models, and actual behavior.

expected_outcomes: Better option design because bundles reflect observed substitution behavior rather than only declared priorities.

expected_outcomes: Clearer identification of dominated, coerced, or constrained choices that should not be overinterpreted.

expected_outcomes: More transparent welfare, pricing, or allocation analysis with explicit confidence boundaries.

expected_outcomes: Reduced risk that a theoretical utility model silently substitutes for empirical behavior.

Consumer Choice Consistency Audit

short_definition: Uses purchasing, substitution, and basket data to infer whether consumer choices support stable trade-off contours.

distinctive_feature: The revealed evidence comes from actual purchasing or uptake behavior under changing option conditions.

distinct_from_parent: It specializes the parent to market and consumer-choice settings.

still_same_parent_because: It still reconstructs and validates indifference contours from observed choices.

use_when: Retail, subscription, or marketplace choices are observed repeatedly.

use_when: Prices, bundles, or attributes vary enough to expose substitution behavior.

use_when: The task is to validate actual preference rather than only predict sales.

example_domains:
retail
subscription pricing
consumer product design

domain: consumer research

example: Basket substitutions under promotions reveal whether consumers treat two goods as close substitutes.

failure_modes: Inferring preference from purchases when availability, stockouts, or search friction dominate.

Policy Revealed Trade-Off Inference

short_definition: Infers social or institutional trade-offs from policy choices, votes, budgets, or implementation decisions.

distinctive_feature: The revealed behavior is collective, institutional, or policy enactment rather than private purchase.

distinct_from_parent: It adds legitimacy, aggregation, and representation concerns to the base inference problem.

still_same_parent_because: It remains an observed-choice validation of trade-off contours.

use_when: Public values are claimed but actual policy choices allocate resources differently.

use_when: Budget, voting, land-use, or regulatory behavior can be observed.

use_when: The analyst must distinguish declared value from enacted trade-off.

example_domains:
environmental policy
municipal budgeting
public-choice analysis

domain: conservation policy

example: Actual land-use approvals reveal a trade-off between habitat protection and development that differs from survey statements.

failure_modes: Treating institutional compromise as if it reveals individual citizen preference directly.

Benefits Menu Trade-Off Validation

short_definition: Uses selections among salary, leave, flexibility, insurance, training, and other benefits to infer employee trade-off contours.

distinctive_feature: The feasible option set is a designed menu with explicit internal budget or value constraints.

distinct_from_parent: It specializes the parent to compensation and benefits design.

still_same_parent_because: It still validates indifference contours from observed bundle choices.

use_when: A benefits or compensation menu forces real trade-offs.

use_when: Different groups choose different bundles.

use_when: Designers need to validate which benefits are substitutes or complements.

example_domains:
human resources
benefits administration
workforce planning

domain: employee compensation

example: Selections reveal that one group values flexible scheduling more than a small salary increase.

failure_modes: Treating a constrained benefits menu as a complete representation of employee preference.

Revealed Preference Anomaly Review

short_definition: Focuses on choices that violate inferred indifference contours and diagnoses whether the violation reflects preference change, constraint, framing, or data error.

distinctive_feature: The main object is the inconsistency rather than the ordinary curve reconstruction.

distinct_from_parent: It is a diagnostic subtype centered on failed validation.

still_same_parent_because: The anomaly is meaningful only relative to the revealed-preference validation procedure.

use_when: Dominated, cyclic, or unstable choices appear.

use_when: The analyst must decide whether to revise the curve or explain the anomaly.

use_when: Choice architecture or information quality may have distorted the signal.

example_domains:
behavioral economics
consumer protection
digital choice architecture

domain: digital product design

example: A dominated plan is selected because the cheaper equivalent option was hidden below the fold.

failure_modes: Pathologizing every inconsistent choice instead of investigating constraints and framing.

near_names: Choice-Based Indifference Curve Inference