name: Heuristic vs. Algorithm Tradeoff and Selection

aliases:
decision method selection
heuristic-algorithm boundary design
computational rigor selection
fast-vs-slow decision pathway
method-of-decision selection

source_primes: heuristic algorithm decision

Heuristic

slug: heuristic

role: Represents fast, experience-based, simplified, or rule-of-thumb judgment methods that trade completeness for speed and usability.

Algorithm

slug: algorithm

role: Represents explicit, repeatable, rule-governed procedures that can produce consistent decisions when inputs, logic, and constraints are specified.

Decision

role: Provides the focal object: a commitment, selection, classification, triage, or action that must be made under constraints.

Optimization

slug: optimization

Calibration

slug: calibration

Observability

slug: observability

Fairness

slug: fairness

components: Accountability and Explainability Requirement

mechanisms:
Decision Method Triage Matrix
Stakes–Latency–Error Scorecard
Heuristic Boundary Checklist
Algorithmic Escalation Protocol
Shadow-Mode Method Comparison
Override and Exception Log
Retrospective Error Calibration Review
Model or Rule Card

essence_one_line: Choose the decision method, not just the decision: use heuristics where speed and bounded cost dominate, algorithms where rigor and consistency are worth the burden, and hybrids where staged escalation is safest.

compression_statement: When a decision must be made under bounded rationality, time pressure, incomplete information, and unequal error costs, this archetype explicitly selects the method of decision. It profiles stakes, reversibility, uncertainty, latency, data availability, error asymmetry, explainability, and accountability, then assigns the case to a heuristic, algorithm, approximation, formal review, or staged hybrid path with feedback for recalibration.

core_intuition: The wrong method can fail even when the people and goals are reasonable. A quick rule can be lifesaving in routine time-critical cases and disastrous in novel high-stakes cases; a rigorous algorithm can be reliable at scale and useless when it arrives too late or hides contestable assumptions. The archetype makes method choice a designed boundary rather than a habit.

canonical_formula: decision context + constraints + error profile -> method class + escalation threshold + feedback calibration

structural_problem: Decision-makers often default to either intuition and rule-of-thumb shortcuts or formal algorithmic analysis without testing which method fits the context. The resulting mismatch creates preventable errors: slow overanalysis of routine choices, brittle shortcut use in high-stakes cases, opaque automation where contestability is needed, or inconsistent human judgment where repeatability matters.

trigger_conditions: A decision recurs often enough that method choice can be standardized or improved.

trigger_conditions: The cost of delay, computation, data collection, or deliberation competes with the cost of being wrong.

trigger_conditions: Errors are asymmetric: a false positive, false negative, missed opportunity, or delayed action has materially different consequences.

trigger_conditions: A heuristic is being used outside the domain where it was learned or validated.

trigger_conditions: An algorithm or model is available but may be too opaque, slow, data-hungry, brittle, or socially contested for the use case.

trigger_conditions: Routine cases and exceptional cases are mixed together, causing either under-escalation or over-escalation.

trigger_conditions: Stakeholders need to understand why one decision path is automated, another is manually reviewed, and another is handled by a simple rule.

symptoms: Teams debate whether a choice was too hasty or overengineered after the fact.

symptoms: Analysts run expensive models for low-stakes routine decisions while urgent high-stakes cases wait.

symptoms: Experienced staff rely on tacit shortcuts that are not teachable, auditable, or calibrated.

symptoms: A model or algorithm is deployed because it exists, not because it improves the actual decision under constraints.

symptoms: Edge cases break the default rule but there is no escalation threshold or override record.

symptoms: Decision quality varies widely across people, teams, shifts, or locations.

symptoms: Users lose trust because they cannot tell when the system is applying judgment, rules, optimization, or black-box prediction.

root_tension: The system needs speed, usability, and low cognitive burden, but it also needs accuracy, consistency, fairness, robustness, and accountability. The more rigor a method adds, the more it may cost in time, data, explanation, and flexibility; the more simplicity a heuristic adds, the more it may hide bias, drift, or unhandled complexity.

anti_signatures: The task is a purely mechanical calculation with an already accepted method and no meaningful decision-method choice.

anti_signatures: Legal, safety, or contractual rules mandate one specific method regardless of local tradeoffs.

anti_signatures: The primary problem is resolving disagreement among stakeholders rather than selecting a method for reaching a decision.

anti_signatures: The system lacks any ability to observe outcomes, making calibration impossible; a temporary rule may still be needed, but this archetype will be weak.

anti_signatures: The issue is only about making an algorithm faster after algorithmic treatment has already been chosen.

anti_signatures: The supposed heuristic is being used to justify arbitrary preference or bias without validity boundaries.

structural_intervention: Install an explicit decision-method selection layer that profiles the decision context, compares candidate method classes, assigns default treatment, defines escalation or override thresholds, documents accountability requirements, and recalibrates boundaries using observed performance.

logic: Name the decision type, recurrence, stakes, reversibility, time window, available data, affected parties, and domain familiarity.

logic: Distinguish speed loss, false positives, false negatives, inconsistency, opacity, unfairness, and opportunity cost rather than speaking vaguely about accuracy.

logic: Compare unaided judgment, explicit heuristic rules, checklists, satisficing thresholds, approximate algorithms, exact algorithms, model-assisted review, and hybrid pathways.

logic: Select the least burdensome method that meets the decision’s risk, robustness, accountability, and performance requirements.

logic: Specify when the default method applies, when exceptions escalate, when human override is valid, and when additional analysis is mandatory.

logic: Make method choice reviewable: who chose it, why it fits, what it assumes, who can challenge it, and what evidence would change it.

logic: Track outcomes, error rates, overrides, disagreements, and drift so thresholds and method assignments improve over time.

description: Use the simplest method that satisfies the stakes, error, fairness, and accountability requirements of the decision.

description: Move from heuristic treatment to formal analysis or review when errors are severe, irreversible, novel, or broadly consequential.

description: Use a bounded heuristic when fast action is valuable, the domain is familiar, errors are tolerable or reversible, and feedback can reveal drift.

description: Use algorithmic treatment when cases are numerous, inputs are stable enough, repeatability matters, and data or formal rules are available.

description: Use screening, escalation, or human-algorithm handoff when routine cases need speed but exceptional cases need rigor or judgment.

description: Require interpretable methods, documentation, review, or appeal when affected parties need to understand or contest the decision.

description: If errors, overrides, or edge cases cluster, revise the method boundary rather than treating exceptions as isolated.

description: The selected method must fit the decision’s stakes, time budget, data quality, uncertainty, and reversibility.

description: Heuristics must have explicit validity boundaries and escalation conditions.

description: Formal algorithms or models must justify their data, latency, complexity, and explainability costs.

description: False-positive, false-negative, delay, and opacity risks must be visible before method choice.

description: Exceptions and human overrides must be allowed where needed but recorded well enough to prevent arbitrary drift.

description: Observed performance must be able to update thresholds, boundaries, and method assignments.

description: Routine, low-risk, or reversible choices are handled without unnecessary analytical burden.

description: Consequential or unfamiliar decisions trigger deeper analysis, review, or algorithmic support before harm accumulates.

description: The system avoids both brittle shortcut use and performative overengineering.

description: Similar cases receive similar method treatment, reducing individual and local variation.

description: Stakeholders can see why a case was routed to a rule, model, expert, or hybrid pathway.

description: Outcome feedback turns method choice into a calibratable portfolio rather than a frozen policy.

prose_essence:
Heuristic vs. Algorithm Tradeoff and Selection makes the method of decision explicit. It asks: should this case be handled by a fast rule, experienced judgment, a checklist, an approximate model, an exact algorithm, a human review path, or a staged combination?

The archetype works by profiling the decision context, separating error types, defining time and resource budgets, then assigning a method class with validity boundaries and escalation thresholds. Its core promise is not that heuristics are better or algorithms are better. Its promise is fit: the method should match the stakes, urgency, uncertainty, data quality, reversibility, and accountability needs of the decision.

prose_when_to_use:
Use it when a system repeatedly faces decisions where speed and rigor are in tension. It is especially useful when routine cases and exceptional cases are mixed together, when quick judgment sometimes works but sometimes fails, or when a formal algorithm is available but not always justified.

It also applies when stakeholders need to understand why some decisions are automated, some use human judgment, some require expert review, and some move through a hybrid path. In high-impact domains, the archetype should include explainability, appeal, and fairness constraints rather than treating method choice as a purely technical efficiency question.

prose_structural_problem:
The structural problem is method mismatch. A shortcut can become a hidden bias when it escapes the domain where it was learned. A formal model can become false precision when data are poor or assumptions are unstable. A full optimization process can waste scarce time on low-stakes routine choices. A simple rule can miss rare but severe cases.

The system needs a way to choose the method before it chooses the answer. Without that layer, method selection happens by habit, status, tooling availability, or local preference.

prose_intervention_logic:
The intervention installs a decision-method selection layer.

First, profile the decision context: recurrence, stakes, reversibility, urgency, data quality, affected parties, and domain familiarity. Second, separate error consequences: false positives, false negatives, delay, inconsistency, opacity, unfairness, and missed opportunity. Third, define the candidate methods, including unaided heuristic, explicit rule, checklist, approximate algorithm, exact algorithm, model-assisted review, and hybrid pathway.

Then select the least burdensome method that satisfies the decision’s risk and accountability requirements. Define boundaries for ordinary cases, escalation thresholds for exceptional cases, and feedback loops for recalibration. The method should be revisable when performance, environment, or error patterns change.

prose_key_components:
### Decision Context Profile

This captures what kind of decision is being made and under what constraints. It prevents teams from treating an urgent, reversible, low-stakes choice the same way they treat a rare, irreversible, high-stakes decision.

### Method Option Set

This keeps the archetype from becoming a false binary. The practical choice is often not “heuristic or algorithm” but “which mixture of heuristic, rule, approximation, algorithm, review, and escalation is sufficient?”

### Error Consequence Profile

Different methods fail differently. A fast heuristic may increase inconsistency; a model may create opacity; a slow algorithm may cause opportunity cost. The error profile makes those risks explicit.

### Time and Resource Budget

A rigorous method is only useful if it can operate inside the decision window. This component accounts for latency, data collection, computation, human attention, and explanation cost.

### Heuristic Validity Boundary

A heuristic should state where it is trusted: which domain, which case type, which stakes, which feedback regime, and which warning signs require escalation.

### Algorithmic Escalation Threshold

This component defines when a case moves from fast treatment to formal analysis, optimization, model review, expert review, or a higher-accountability process.

### Accountability and Explainability Requirement

High-impact decisions need more than performance. They may require reasons, appeal, reviewability, documentation, and a human accountable owner.

### Calibration Feedback Loop

Outcome review turns method selection into a learning system. If overrides, complaints, errors, or edge cases cluster, the method boundary should be revised.

prose_common_mechanisms:
A **decision method triage matrix** classifies cases by stakes, urgency, reversibility, uncertainty, and accountability needs. A **stakes-latency-error scorecard** makes the core tradeoff visible. A **heuristic boundary checklist** tests whether a shortcut is valid in the current context.

An **algorithmic escalation protocol** routes cases above threshold to formal analysis or review. A **shadow-mode method comparison** tests a candidate method before it receives operational authority. An **override and exception log** records when people depart from the default method and why. A **retrospective error calibration review** periodically tunes thresholds and method assignments. A **model or rule card** documents intended use, limits, failure modes, and review ownership.

prose_failure_modes:
**Heuristic overreach** occurs when a useful shortcut is applied outside its domain. Mitigate it with validity boundaries and escalation rules.

**Algorithmic overkill** occurs when formal analysis is applied to low-stakes routine cases. Mitigate it with lowest-sufficient-rigor rules.

**False precision** occurs when a formal model hides poor data or fragile assumptions. Mitigate it by documenting uncertainty and validation limits.

**Automation bias** occurs when humans rubber-stamp model outputs. Mitigate it with override criteria, review training, and exception analysis.

**Threshold gaming** occurs when actors classify cases to avoid escalation. Mitigate it with audit sampling and accountable routing rationales.

**Feedback blindness** occurs when method assignments are never checked against outcomes. Mitigate it with calibration reviews.

**Fairness drift** occurs when simplified rules or models affect groups differently. Mitigate it with subgroup error monitoring, fairness review, and appeal routes for high-impact decisions.

prose_neighbor_distinctions: This archetype is distinct from `bias_specific_decision_audit`, which checks whether biases distort judgment. It is distinct from `proceduralization`, which codifies an already-chosen process. It is distinct from `complexity_scaling_assessment`, which estimates tractability. It is distinct from `decision_load_management`, which manages the volume and fatigue of decisions. It is distinct from `bounded_search_pruning`, which is a technique inside a search process. It is distinct from `robust_solution_selection`, which selects options under uncertainty rather than selecting the method used to decide.

prose_cross_domain_examples:
In medical diagnosis, a triage rule can handle urgent routing while red flags trigger comprehensive workup. In online recommendations, a lightweight filter may generate candidates in real time while a deeper model ranks or audits them. In supply chain management, routine replenishment can use simple rules while major sourcing decisions trigger optimization and scenario review.

In incident response, a known alert may follow a runbook while novel cascading failures escalate to expert diagnosis. In public administration, clear eligibility cases may be processed by rule while ambiguous or adverse decisions require human review, explanation, and appeal.

prose_non_examples: A mandated formula with no real method choice is not this archetype. A political dispute over goals is not this archetype unless the practical issue is how to make a decision under defined method constraints. A complex model used solely because it is available is a failure of this archetype, not an example. A heuristic applied to high-stakes cases without boundaries, appeal, or feedback is also a failure, not an example.

prose_tradeoffs:
The main tradeoff is speed versus rigor. Heuristics reduce latency but may miss edge cases. Algorithms increase repeatability but may require data, assumptions, computation, and maintenance. Hybrid paths improve fit but add routing complexity.

Other tradeoffs include simplicity versus coverage, consistency versus context sensitivity, accuracy versus explainability, automation scale versus contestability, and calibration cost versus boundary quality.

prose_invariants_to_preserve: Preserve context-method fit: the selected method must match the decision’s stakes and constraints. Preserve bounded heuristic use: shortcuts need explicit validity limits. Preserve algorithmic burden justification: formal methods should justify their latency, data, and complexity costs. Preserve error asymmetry visibility: the system should know which mistakes matter most. Preserve accountable override: people must be able to challenge or override methods where appropriate, but exceptions must be recorded. Preserve feedback recalibration: observed outcomes should update the method boundary.

prose_target_outcomes:
The target outcomes are faster routine decisions, better high-stakes rigor, fewer method mismatches, more consistent decision quality, clearer accountability, and a decision-method portfolio that learns over time.

When the archetype works, teams stop asking only “what should we decide?” and also ask “what kind of decision method does this situation deserve?”

prose_parameter_dimensions:
Important tuning dimensions include decision stakes, reversibility, time budget, data quality, recurrence rate, novelty, error asymmetry, explainability requirement, affected-party contestability, cost of computation, human expertise, and calibration frequency.

Set thresholds carefully. If thresholds are too low, every case escalates and the system becomes slow. If thresholds are too high, high-consequence edge cases stay trapped in quick treatment. If feedback is weak, thresholds should be conservative because method performance cannot be reliably learned.

prose_variants_and_near_names:
Recognized variants include **Fast-and-Frugal Heuristic Selection**, **Algorithmic Escalation Selection**, **Hybrid Screen-Then-Solve Selection**, and **Human–Algorithmic Handoff Selection**.

Near names include decision method selection, heuristic-algorithm boundary design, computational rigor selection, and fast-vs-slow decision pathway. Future drafting should keep **Heuristic Calibration and Confidence Judgment** distinct if it focuses on calibrating the performance and confidence of a heuristic after method selection has already occurred.

Fast-and-Frugal Heuristic Selection

variant_type: subtype

short_definition: A variant that deliberately chooses a simple rule or small decision tree because speed, interpretability, or scarce information matters more than exhaustive optimization.

distinctive_feature: It treats simplicity as a chosen design property rather than as a failure to be rigorous.

distinct_from_parent: The parent includes all method-selection choices; this variant specifically legitimizes bounded heuristic treatment.

still_same_parent_because: It still depends on the same context, error, and threshold logic that governs when heuristics are acceptable.

source_primes: heuristic bounded_rationality decision

use_when: The domain is familiar or feedback-rich.

use_when: The decision is reversible or low to moderate stakes.

use_when: The cost of delay exceeds the value of marginal accuracy.

use_when: Human users need a rule they can remember and apply consistently.

example_domains:
triage
incident response
teaching
customer support

domain: medical triage

example: A nurse uses a validated triage rule for immediate routing while escalating unusual or severe cases.

failure_modes: Rule persists after the environment changes

failure_modes: Low-stakes rule is reused in high-stakes cases

Algorithmic Escalation Selection

short_definition: A variant that starts with lightweight treatment but escalates to formal algorithmic analysis when thresholds for stakes, novelty, scale, or error risk are crossed.

distinctive_feature: It uses trigger thresholds to preserve speed for routine decisions while reserving rigor for risky ones.

distinct_from_parent: The parent may select any method directly; this variant emphasizes thresholded escalation between levels of rigor.

still_same_parent_because: Escalation still depends on the parent tradeoff among speed, accuracy, cost, and accountability.

source_primes: algorithm decision threshold

use_when: Most cases are routine but some cases carry high consequence.

use_when: Formal analysis is costly but available.

use_when: There are defensible escalation thresholds.

use_when: Decision-makers need consistency without overburdening routine cases.

example_domains:
supply chain
credit review
safety engineering
legal review

domain: supply chain

example: Routine reorder points use a rule, but large sourcing changes trigger optimization and risk review.

failure_modes: Thresholds are set too high and miss serious cases

failure_modes: Everything escalates and the pathway becomes a bottleneck

Hybrid Screen-Then-Solve Selection

short_definition: A variant that uses a heuristic or screening rule to narrow cases before applying a more expensive algorithm or expert review.

distinctive_feature: It deliberately composes heuristic and algorithmic methods rather than choosing only one.

distinct_from_parent: The parent governs method choice; this variant specifies a staged combination.

still_same_parent_because: The key design question remains how much rigor to apply to which cases under resource and error constraints.

source_primes: screening algorithm heuristic

use_when: A cheap first pass can safely eliminate many cases.

use_when: False exclusions are detectable or bounded.

use_when: Formal analysis should focus on ambiguous or high-value cases.

example_domains:
diagnosis
content moderation
portfolio screening
procurement

domain: online recommendations

example: A lightweight filter creates candidate items in real time before a richer model ranks the shortlist.

failure_modes: First-pass heuristic filters out rare but important cases

failure_modes: Later algorithm inherits biased screening boundaries

failure_modes: No one monitors disagreement between stages

Human–Algorithmic Handoff Selection

short_definition: A variant that assigns which parts of a decision remain with humans, which parts are algorithm-assisted, and when handoff or override occurs.

distinctive_feature: It focuses on division of decision labor between human judgment and algorithmic processing.

distinct_from_parent: The parent chooses among method classes; this variant tunes handoff boundaries inside a hybrid human-machine method.

still_same_parent_because: It remains a method-selection boundary problem rather than a general AI governance archetype.

use_when: Automated support is useful but moral, contextual, or contestability requirements remain.

use_when: Users must understand when to trust or challenge a model.

example_domains:
clinical decision support
loan review
moderation escalation
maintenance diagnostics

domain: clinical decision support

example: A risk model suggests cases for review, while clinicians retain authority for exceptions and patient-specific context.

failure_modes:
Automation bias
Rubber-stamp human review
Unclear responsibility for errors

near_names:
Decision Method Selection
Heuristic–Algorithm Boundary Design
Computational Rigor Selection
Fast-vs-Slow Decision Pathway


Hidden Path Discovery

type: archetype

source: generated

batch: First Iteration/Batch 20

aliases:
Hidden Route Discovery
Alternative Pathway Discovery
Barrier Bypass Search
Non-Obvious Route Discovery
Feasibility Path Search
Indirect Path Discovery
Legitimate Workaround Discovery

related_primes: constraint search_and_retrieval abstraction uncertainty optimization counterfactual_reasoning boundary threshold representation interoperability

slug: topology

slug: constraint

slug: abstraction

slug: uncertainty

slug: boundary

slug: threshold

slug: representation

slug: interoperability

components:
Apparent Barrier Definition
Goal Invariant
Problem-Space Reframe
Adjacent Possibility Map
Alternate Path Generation
Feasibility Probe
Constraint and Legitimacy Review
Path Risk Review
Path Validation and Selection Rule
Transition or Integration Plan
Constraint Taxonomy
Analogy Source Scan
Intermediary or Bridge Actor
Safe-to-Fail Experiment Boundary
Fallback Route

mechanisms:
Workaround Discovery
Lateral Reframing Workshop
Legal or Regulatory Pathway Search
Technical Bypass or Adapter Design
Route-Finding and Topology Search
Indirect Negotiation Route
Clinical Alternative Pathway Review
Constraint Relaxation Experiment
Analogical Path Transfer
Sandbox or Pilot Pathway

essence_one_line: Search for non-obvious routes around barriers that appear impossible from the ordinary path.

compression_statement: When a barrier appears to block progress, deliberately search for hidden paths, alternate mechanisms, or overlooked transformations that make crossing feasible.

core_intuition: A barrier can be real on one representation of the problem and crossable on another. Hidden Path Discovery does not pretend that barriers are imaginary; it changes the search frame, explores adjacent possibilities, and tests whether a different route can preserve the original goal without violating essential constraints.

canonical_formula: apparent_barrier + goal_invariant + problem_space_reframe + adjacent_possibility_map + alternate_path_generation + feasibility_probe + legitimacy_review + risk_review + integration_plan → validated non-obvious route

structural_problem: A goal appears blocked because the obvious route is impossible, forbidden, too costly, or too risky.

trigger_conditions: The ordinary route is blocked, unavailable, prohibited, too costly, too slow, too risky, or structurally impossible under the current representation.

trigger_conditions: The desired outcome remains important enough that abandoning the goal or waiting passively is costly.

trigger_conditions: At least some constraints are negotiable, representational, sequential, institutional, technical, or topological rather than absolute physical impossibilities.

trigger_conditions: The system can run bounded probes or reviews without creating unacceptable harm if a candidate path fails.

trigger_conditions: Preserving the goal invariant matters more than preserving the familiar route.

trigger_conditions: There are plausible adjacent possibilities, intermediaries, analogies, translation layers, alternate sequences, or procedural pathways worth searching.

symptoms: Actors repeatedly say that the goal is impossible because the obvious route is blocked.

symptoms: Work stalls at a single constraint even though adjacent resources, roles, routes, technologies, or procedures remain unexplored.

symptoms: The system treats one implementation path as identical with the goal itself.

symptoms: Teams generate generic ideas but do not validate whether any route actually crosses the barrier.

symptoms: Workarounds appear informally, but no one knows whether they are safe, legitimate, scalable, or preservative of the intended outcome.

symptoms: A problem looks impossible in one discipline or institutional frame but appears solvable when reframed at another layer.

root_tension: The intervention must be imaginative enough to find routes that the ordinary path hides, but disciplined enough not to mistake unsafe circumvention, loophole exploitation, or goal abandonment for genuine feasibility. The same move that reveals a hidden path can also bypass safeguards or create shadow systems if legitimacy, risk, and integration are not checked.

anti_signatures: The barrier is a valid safety, legal, ethical, or consent boundary that should not be crossed or worked around.

anti_signatures: The route is already known and the issue is only reducing cost, fear, friction, or activation energy; that points toward Barrier Lowering.

anti_signatures: The system simply needs to route known flow around a bottleneck; that points toward Flow Diversion or Rerouting.

anti_signatures: The goal is to escape lock-in created by previous decisions, switching costs, or history; that may point toward Path-Dependence Escape.

anti_signatures: The activity is unconstrained ideation without an apparent barrier, validation loop, or goal invariant.

anti_signatures: The proposed path preserves the route but changes the goal, harms affected parties, violates law, or hides accountability.

structural_intervention: Reframe the barrier, map adjacent possibilities, test indirect routes, and validate that the hidden path preserves the goal.

action_logic: State the blocked goal and separate the desired outcome from the familiar route that currently appears blocked.

action_logic: Define the apparent barrier and classify the type of constraint: physical, technical, procedural, institutional, economic, social, temporal, epistemic, or representational.

action_logic: Specify the goal invariant: what must remain true for an alternate route to count as a valid solution.

action_logic: Reframe the problem space by changing scale, sequence, actor boundary, mechanism, topology, representation, or institutional pathway.

action_logic: Map adjacent possibilities: nearby states, existing permissions, intermediaries, spare capacities, analogies, bridge technologies, or partial transformations.

action_logic: Generate multiple alternate routes instead of committing to the first clever workaround.

action_logic: Run feasibility probes to test whether each candidate path actually crosses the barrier under realistic constraints.

action_logic: Review legitimacy, safety, consent, governance, and ethical constraints before treating the route as usable.

action_logic: Review path-specific risks such as brittleness, shadow-process formation, inequitable access, dependency, or technical debt.

action_logic: Select, revise, or reject paths using an explicit validation rule, then document how the chosen path integrates with the larger system.

decision_rules: If the path changes the goal invariant, reject it even if it appears easier.

decision_rules: If the barrier is a necessary safeguard, search only for legitimate alternatives that satisfy the same protective function.

decision_rules: If the barrier is representational, reframe the problem before investing in more resources on the blocked route.

decision_rules: If a candidate path works only in one exceptional case, treat it as a local workaround until reproducibility and integration are tested.

decision_rules: If several paths appear feasible, prefer the route that preserves invariants, reduces future dependency, and can be explained to affected stakeholders.

decision_rules: If no legitimate hidden path can be validated, return to barrier lowering, negotiation, redesign, or explicit acceptance of the constraint rather than forcing a bypass.

decision_rules: If the hidden path becomes a recurring operating route, document, govern, and integrate it rather than leaving it as tacit knowledge.

target_invariants: The underlying goal remains distinct from the originally assumed route.

target_invariants: Essential safety, legality, consent, quality, fairness, and legitimacy constraints are preserved.

target_invariants: Candidate paths are tested before full commitment.

target_invariants: The route is documented enough that accountability and maintainability are not lost.

target_invariants: Discovery does not create inequitable hidden access available only to insiders.

target_invariants: The intervention preserves the option to stop when all available paths violate core constraints.

expected_outcomes: A goal that looked blocked gains one or more validated feasible routes.

expected_outcomes: Actors understand which constraints were absolute, which were representational, and which could be legitimately navigated.

expected_outcomes: The chosen path preserves the goal invariant while reducing dependence on the blocked route.

expected_outcomes: Workarounds that would otherwise remain informal are reviewed, documented, and either integrated or rejected.

expected_outcomes: The system gains a reusable map of adjacent possibilities, bridge actors, route patterns, or procedural options.

expected_outcomes: Stakeholders gain a clearer boundary between creative route discovery and unsafe circumvention.

prose_essence:
Hidden Path Discovery is the intervention pattern for situations where a goal appears blocked because the ordinary route has failed. The archetype does not assume that every barrier can or should be crossed. Instead, it asks whether the barrier belongs to the goal itself or only to the route that people first imagined.

The core move is to separate the desired outcome from the familiar path, reframe the problem space, search adjacent possibilities, generate candidate routes, and validate any route before using it. A hidden path is successful only if it preserves the goal invariant and respects required constraints.

prose_when_to_use:
Use this archetype when progress has stopped at an apparent impossibility, but there is reason to believe that another representation, sequence, actor, interface, route, institution, or mechanism could preserve the original goal. It is especially useful when the current path is blocked by an inherited assumption, a route-specific bottleneck, an institutional pathway, a technical interface, a social sequence, or a topology that has not been fully mapped.

Do not use it as a euphemism for bypassing safeguards. If the barrier is a necessary safety, legal, ethical, or consent boundary, the search should focus only on legitimate alternatives that preserve the same protective function.

prose_structural_problem:
The structural problem is route-goal confusion. Actors treat the obvious route as if it were the goal itself. When that route is blocked, they conclude that the goal is impossible.

Hidden Path Discovery looks for cases where the blockage is specific to a path, representation, sequence, or institutional frame rather than to the underlying objective. The system may need a different topology, bridge actor, adapter, procedural pathway, negotiation sequence, analogy, or constraint relaxation test to reveal feasibility.

prose_intervention_logic:
The intervention begins by naming the apparent barrier and defining the goal invariant. The invariant is crucial: it says what must remain true for an alternate path to count as a real solution. Without it, clever routes can become goal drift or unsafe circumvention.

Next, the problem space is reframed. The search may shift scale, change sequence, introduce an intermediary, move to a different technical layer, look through a different institutional procedure, or map adjacency in a network. Candidate paths are then generated and tested. Feasibility probes check whether a route works; legitimacy and risk reviews check whether it should be used; integration planning prevents a successful route from becoming a hidden shadow process.

prose_key_components:
- **Apparent Barrier Definition** (`apparent_barrier_definition`): names the route, constraint, rule, interface, or boundary that blocks ordinary progress. This prevents the team from treating vague difficulty as a single impossible wall.
- **Goal Invariant** (`goal_invariant`): states what must remain true if an alternate path is accepted. It protects safety, quality, legality, fairness, consent, and the original outcome.
- **Problem-Space Reframe** (`problem_space_reframe`): changes the representation of the problem so hidden routes can become visible. This may mean shifting scale, sequence, actors, layers, or topology.
- **Adjacent Possibility Map** (`adjacent_possibility_map`): identifies nearby resources, states, permissions, actors, technologies, analogies, or partial transformations that could support a route.
- **Alternate Path Generation** (`alternate_path_generation`): creates multiple candidate routes rather than overcommitting to the first clever workaround.
- **Feasibility Probe** (`feasibility_probe`): tests whether a candidate path actually works under realistic constraints before full commitment.
- **Constraint and Legitimacy Review** (`constraint_and_legitimacy_review`): checks whether the route respects required safeguards, rules, norms, and ethical boundaries.
- **Path Risk Review** (`path_risk_review`): examines brittleness, technical debt, inequity, opacity, dependency, or integration problems introduced by the route.
- **Path Validation and Selection Rule** (`path_validation_and_selection_rule`): defines when to accept, revise, reject, or stop searching among candidate routes.
- **Transition or Integration Plan** (`transition_or_integration_plan`): connects the chosen route back to operating routines, ownership, documentation, and governance.

prose_common_mechanisms:
- **Workaround Discovery** implements the archetype when a blocked process still needs its function preserved. It is a mechanism, not the archetype, because a workaround without validation can become a risky exception.
- **Lateral Reframing Workshop** helps generate paths by changing frame, scale, analogy, or actor boundary. It implements the search part, but still needs probes and legitimacy review.
- **Legal or Regulatory Pathway Search** finds legitimate procedural alternatives inside a rule system. It must not become loophole exploitation.
- **Technical Bypass or Adapter Design** creates an approved adapter, bridge, or technical route when the direct path is blocked. It implements the archetype only when security, reliability, and governance are reviewed.
- **Route-Finding and Topology Search** maps networks, spaces, states, or process dependencies to discover a path around a blocked edge.
- **Indirect Negotiation Route** changes sequence, intermediary, or agenda frame so social progress becomes feasible without manipulating or excluding affected parties.
- **Clinical Alternative Pathway Review** identifies safe care routes when a standard pathway is unavailable or contraindicated.
- **Constraint Relaxation Experiment** tests whether a constraint is essential or inherited, but only within a safe-to-fail boundary.
- **Analogical Path Transfer** imports a route structure from another domain after checking whether the structural conditions really match.
- **Sandbox or Pilot Pathway** bounds the test of a candidate hidden path before it is exposed to the full system.

prose_failure_modes:
Common failure modes include unsafe circumvention, goal drift disguised as creativity, undocumented shadow systems, brittle one-off paths, insider-only access, over-search paralysis, and false analogy transfer. Each arises when a component is missing: no invariant, no legitimacy review, no integration plan, no reproducibility probe, or no selection rule.

The archetype is most dangerous when it is used to valorize cleverness over accountability. It is strongest when creativity is paired with reviewable evidence and explicit constraints.

prose_neighbor_distinctions:
**Flow Diversion or Rerouting** uses known alternate channels for known flows. Hidden Path Discovery first has to discover that a viable route exists.

**Barrier Lowering** reduces friction on a known path. Hidden Path Discovery changes path, representation, sequence, actor, or mechanism.

**Path-Dependence Escape** addresses lock-in from past choices. Hidden Path Discovery may help with lock-in, but it is not limited to historically created traps.

**Problem Space Mapping** represents a problem space. Hidden Path Discovery uses mapping specifically to find and validate a route across an apparent barrier.

**Creative Problem Solving** is broader. Hidden Path Discovery has a sharper structure: blocked goal, goal invariant, route search, feasibility probe, legitimacy review, and integration.

prose_cross_domain_examples:
In software architecture, a legacy system with no direct API may still support an approved event stream and adapter. In logistics, a blocked corridor may be bypassed through a transfer hub and a different carrier class. In regulation, a project may find a lawful demonstration pathway instead of forcing a standard approval path that does not fit. In clinical care, a contraindicated standard pathway may lead to an evidence-reviewed alternative. In negotiation, a mediator and a different sequence may reopen an issue that direct meetings repeatedly close.

Across these examples, the common structure is not cleverness alone. The common structure is disciplined discovery of legitimate feasibility across an apparent barrier.

prose_non_examples: Ignoring a safety gate, exploiting a legal loophole that undermines the purpose of the rule, using a known detour without discovery, simplifying a known form, or brainstorming without validation are not Hidden Path Discovery. A route that only works by abandoning the original goal is also not this archetype.

prose_tradeoffs:
Hidden Path Discovery trades speed against search breadth, novelty against legitimacy, local feasibility against system integration, and tacit expert navigation against transparent access. It can recover possibility under blockage, but it can also create brittle exceptions if the route is not reviewed and governed.

The strongest drafts of this archetype should be explicit about when to stop. Not every barrier should be crossed. Sometimes the correct conclusion is that the goal needs redesign, the barrier should be lowered through formal channels, or the constraint should be accepted.

prose_invariants_to_preserve: The route may change, but the goal invariant must not. Required safeguards should remain intact. A discovered path should be explainable, reviewable, and maintainable. The archetype should not create insider-only access, hidden accountability gaps, or permanent shadow processes. It should also preserve the option to reject all candidate paths if none can cross the barrier legitimately.

prose_target_outcomes:
The desired outcome is validated feasibility: a goal that appeared blocked gains a legitimate, tested, and integrated route. The system also learns which constraints are absolute, which are route-specific, and which are assumptions inherited from the original framing.

A mature use of the archetype leaves behind better maps, better review practices, and reusable route patterns rather than only a clever one-time workaround.

prose_parameter_dimensions:
Important tuning dimensions include the breadth of search, strictness of the goal invariant, tolerance for novelty, reversibility of probes, number of candidate paths generated, evidence threshold for feasibility, strength of legitimacy review, stakeholder visibility, and integration depth.

A high-novelty search may reveal more routes but needs stronger review. A narrow search may be faster but can miss the actual path. A lightweight probe is useful when risks are low; high-stakes contexts require more formal testing and approval before the path is used.

prose_variants_and_near_names:
Recognized variants include workaround path discovery, technical adapter path, procedural pathway search, indirect social route, and topological route search. Near names include hidden route discovery, alternative pathway discovery, barrier bypass search, and feasibility path search.

`barrier_lowering` remains a promotion candidate or second-wave neighbor, not a collapsed child. It should be drafted separately if the primary intervention is reducing activation cost on a known path rather than discovering a non-obvious path.

Workaround Path Discovery

short_definition: Finds a practical alternate route when the standard process is blocked but the desired function still needs to be achieved.

distinctive_feature: It emphasizes practical function preservation under blockage rather than broad invention or long-horizon redesign.

distinct_from_parent: The parent includes any non-obvious route across an apparent barrier; this variant is focused on operational workarounds within an existing system.

still_same_parent_because: It still uses barrier definition, alternate path search, feasibility probing, risk review, and goal-invariant preservation.

use_when: The ordinary route is blocked by a process, tool, interface, rule, resource gap, or local operating constraint.

use_when: A timely solution is needed, but the route must still preserve safety, legitimacy, quality, and the underlying goal.

Apparent Barrier Definition

role: Names the blocked standard route.

Goal Invariant

role: Keeps the workaround tied to the original function.

Transition or Integration Plan

role: Prevents the workaround from becoming an undocumented shadow system.

Workaround Discovery

role: Searches for functional alternatives.

Sandbox or Pilot Pathway

role: Bounds testing of the workaround.

example_domains:
operations
software administration
customer support
public services

domain: operations

example: A blocked approval queue is routed through a legitimate emergency review procedure while the ordinary queue is repaired.

domain: software

example: A team uses an approved adapter to preserve data flow when the direct integration is unavailable.

failure_modes: The workaround becomes a permanent undocumented exception.

failure_modes: The route bypasses a safeguard that existed for a valid reason.

Technical Adapter Path

short_definition: Uses an adapter, bridge, protocol translation, or architectural reroute to make a blocked technical transition feasible.

distinctive_feature: The hidden path is created through technical topology or interface redesign.

distinct_from_parent: The parent can operate in any domain; this variant emphasizes technical systems, adapters, and interoperability boundaries.

still_same_parent_because: It still discovers a non-obvious route around an apparent technical barrier and validates the route before integration.

use_when: The direct technical integration, migration, or interface path is unavailable, incompatible, or too risky.

use_when: A legitimate intermediate layer can preserve the function without violating security, reliability, or governance constraints.

Problem-Space Reframe

role: Recasts the barrier as an interface or topology problem.

Feasibility Probe

role: Tests the adapter route.

Path Risk Review

role: Checks reliability, security, maintenance, and compatibility risk.

Technical Bypass or Adapter Design

role: Implements the alternate technical route.

Sandbox or Pilot Pathway

role: Tests the route before main-system connection.

example_domains:
software architecture
data integration
infrastructure migration
manufacturing automation

example: A system that cannot expose a direct API uses an approved event stream and adapter to supply the same information.

domain: manufacturing

example: A machine that cannot be replaced immediately is connected through an interface module while the line is modernized.

failure_modes: The adapter becomes brittle technical debt.

failure_modes: The route evades security or reliability review.

Procedural Pathway Search

short_definition: Searches within rules, institutions, permissions, or procedures for a legitimate route that the obvious process misses.

distinctive_feature: The hidden path exists in the structure of rules or institutional procedure rather than in physical or technical topology.

distinct_from_parent: The parent is domain-general; this variant focuses on legitimate procedural and institutional alternatives.

still_same_parent_because: It still turns an apparent blockage into an alternate route through reframing, search, validation, and risk review.

use_when: The apparent barrier is institutional, legal, administrative, contractual, or procedural.

use_when: The aim is to find a legitimate pathway, not evade oversight or ignore safeguards.

Constraint and Legitimacy Review

role: Separates legitimate pathways from rule evasion.

Intermediary or Bridge Actor

role: Provides legitimate access, interpretation, or sponsorship.

Legal or Regulatory Pathway Search

role: Identifies approved procedural alternatives.

Indirect Negotiation Route

role: Uses trusted process pathways where direct routes fail.

example_domains:
law
regulation
public administration
procurement
institutional governance

domain: regulation

example: A project that cannot use a standard permit route applies through a lawful demonstration pathway with added reporting.

domain: procurement

example: A blocked purchase is reframed as an approved shared-service agreement rather than an exception to purchasing rules.

failure_modes: Actors confuse lawful pathway search with loophole exploitation.

failure_modes: The route is technically allowed but undermines legitimacy or public trust.

Indirect Social Route

short_definition: Uses trusted intermediaries, sequencing, agenda reframing, or backchannel preparation when direct social or negotiation routes are blocked.

distinctive_feature: The hidden path is social and relational: who speaks, in what sequence, with what frame, changes feasibility.

distinct_from_parent: The parent covers any hidden route; this variant concerns indirect pathways through trust, sequencing, and social position.

still_same_parent_because: It still discovers and validates a non-obvious path across an apparent barrier.

use_when: Direct communication or negotiation triggers threat, loss of face, positional conflict, or immediate rejection.

use_when: A legitimate indirect route can preserve consent, transparency where required, and the substantive goal.

Goal Invariant

role: Prevents indirectness from becoming manipulation.

Intermediary or Bridge Actor

role: Carries trust, translation, or legitimacy across the boundary.

Path Risk Review

role: Checks secrecy, trust damage, and escalation risk.

Indirect Negotiation Route

role: Implements the social route.

Lateral Reframing Workshop

role: Generates alternate frames and sequences.

example_domains:
diplomacy
organizational conflict
labor relations
community mediation

domain: workplace

example: A conflict that fails in direct meetings is reopened through a neutral facilitator and a narrower first agreement.

domain: diplomacy

example: Parties that cannot publicly negotiate prepare terms through trusted intermediaries before formal talks.

failure_modes: Indirect routing becomes deception or exclusion of affected parties.

failure_modes: The intermediary gains undue control over the outcome.

Topological Route Search

short_definition: Searches the structure of a network, space, process, or state graph for an alternate route around a blocked edge or boundary.

distinctive_feature: The hidden path is discovered by analyzing structure and adjacency rather than merely inventing a new tactic.

distinct_from_parent: The parent is broader; this variant is explicitly topological or network-structured.

still_same_parent_because: The intervention still turns apparent blockage into feasible movement across an alternate path.

use_when: The barrier is shaped by connectivity, adjacency, sequence, transfer points, bottlenecks, or network structure.

use_when: A route can be validated by mapping nodes, edges, capacities, constraints, and transfer risks.

Adjacent Possibility Map

role: Maps nearby nodes, states, or transfer points.

Feasibility Probe

role: Tests the route under realistic constraints.

Route-Finding and Topology Search

role: Finds paths across the topology.

Analogical Path Transfer

role: Transfers route structures from analogous networks.

example_domains:
logistics
network operations
project sequencing
state-space planning

domain: logistics

example: A blocked corridor is replaced by a multimodal route through a transfer hub and different carrier class.

domain: project management

example: A blocked dependency is bypassed by sequencing a different module first and using a temporary interface.

failure_modes: A shortest-looking path fails under unmodeled constraints.

failure_modes: Optimization ignores legitimacy, safety, or stakeholder acceptance.

near_names:
Hidden Route Discovery
Barrier Bypass Search
Alternative Pathway Discovery
Workaround Discovery
Lateral Thinking
Technical Bypass Design


Hidden Support Depletion Guarding

batch: Batch 10

canonical_family: Overextension & Load Fragility

slug: maintenance

slug: resilience

slug: boundedness

slug: coupling

slug: inertia

slug: dependency

components:
Visible Load-Bearing Shell
Hidden Support Substrate Map
Substrate Depletion Pathway
Void Growth Indicator
Unsupported Span Model
Collapse Threshold Band
Load Relief Trigger
Support Replenishment Path
Surface Patch Filter
Support Owner Authority
Near-Miss Substrate Review
Destructive Probe or Inspection Policy
Controlled Retreat Plan
Support Substitution Path
Backstage Workload Register

mechanisms: Backfill, Reinforcement, or Recapitalization Plan

essence_one_line: Protect an apparently stable structure by monitoring and replenishing the hidden support substrate before ordinary load becomes unsupported.

compression_statement: Hidden Support Depletion Guarding applies when failure is not primarily caused by visible load increase or surface rot. The visible structure still looks viable, but the support it depends on has been quietly withdrawn, consumed, hollowed, subsidized away, or decoupled. The intervention maps the load-bearing shell, identifies the hidden substrate, measures substrate depletion and void growth, defines collapse thresholds, and triggers load reduction, support replenishment, reinforcement, evacuation, or redesign before the shell falls into the missing support beneath it.

core_intuition: A bridge can fail because its beams are overloaded. A caldera fails because the ground beneath it has been emptied. Many organizational, technical, ecological, and economic failures follow the same shape: the part people watch remains present while the support it silently stands on disappears.

canonical_formula: collapse_risk = visible_load / effective_support_substrate × void_growth_rate × detection_delay - replenishment_capacity - load_relief_margin

structural_problem: A system continues to operate, expand, or promise capacity while the hidden substrate that makes operation possible is being depleted. The visible surface provides reassuring continuity, but support thickness, slack, trust, maintenance capacity, workforce resilience, reserve liquidity, institutional legitimacy, or infrastructure condition is quietly falling below the level needed to carry ordinary load.

trigger_conditions: A visible structure or operation depends on a less-visible support layer that can be depleted independently of visible demand.

trigger_conditions: The support layer changes slowly, privately, underground, backstage, or in accounting categories that ordinary dashboards do not inspect.

trigger_conditions: Short-term performance can be maintained by consuming reserves, maintenance backlog, trust, redundancy, slack, or substrate quality.

trigger_conditions: Visible load appears normal or manageable until the support layer crosses a collapse threshold.

trigger_conditions: Stakeholders interpret the absence of surface failure as evidence of health.

trigger_conditions: Repair becomes much harder after the void, debt, or support deficit becomes visible.

trigger_conditions: The system has incentives to keep the surface looking intact while postponing support repair.

symptoms: Performance indicators remain acceptable while maintenance backlog, reserves, morale, redundancy, or substrate quality deteriorates.

symptoms: Small shocks produce surprisingly large failures because the hidden support layer has already been hollowed out.

symptoms: People explain near misses as isolated incidents rather than signs of substrate evacuation.

symptoms: Teams repeatedly bridge gaps with heroic effort, undocumented workarounds, borrowing, deferred repair, or temporary patches.

symptoms: Support functions are treated as overhead until their absence causes an abrupt structural failure.

symptoms: The visible frontier expands while the sustaining backbone, supply line, legitimacy base, or capacity reserve shrinks.

symptoms: Collapse is described as sudden even though the support deficit accumulated slowly.

root_tension: Surface continuity hides substrate depletion. The system can appear stable precisely because it is consuming the support that makes stability possible, so ordinary success indicators become misleading late-stage signals.

anti_signatures: The main risk is generic approach to a known threshold; use Tipping Point Prevention if no hidden support layer is central.

anti_signatures: The main work is tracking slow degradation of the asset itself; use Deterioration Monitoring when surface condition is the primary variable.

anti_signatures: The main work is mapping hidden dependencies rather than measuring their depletion; use Dependency Exposure.

anti_signatures: The main work is enumerating possible failure modes before implementation; use Failure Mode Anticipation.

anti_signatures: The main risk is growth outpacing governance or control capacity without a specific substrate-withdrawal mechanism; use Over-Scaling Guardrail.

anti_signatures: The support layer is visible, independently governed, and already represented in decision thresholds.

structural_intervention: Create a substrate-integrity control loop: map the visible load-bearing shell to its hidden support substrate; measure support thickness, reserve, slack, legitimacy, maintenance capacity, or dependency health; model void growth and collapse thresholds; then trigger load relief, support replenishment, reinforcement, substitution, shutdown, evacuation, or redesign before surface failure becomes the first reliable signal.

action_logic: Name the visible structure, operation, promise, frontier, or performance surface being kept upright.

action_logic: Identify the hidden support substrates it depends on, including physical, operational, social, financial, informational, and institutional supports.

action_logic: Define substrate depletion paths: extraction, erosion, deferred maintenance, reserve drawdown, debt accumulation, trust loss, dependency concentration, or support diversion.

action_logic: Build indicators for support thickness and void growth rather than relying only on surface performance.

action_logic: Estimate collapse thresholds, unsupported span, recovery time, and intervention lead time.

action_logic: Set trigger bands for inspection, slowdown, load shedding, replenishment, reinforcement, substitution, or evacuation.

action_logic: Separate cosmetic surface patching from structural support repair.

action_logic: Assign ownership and funding for hidden support maintenance, not only visible output delivery.

action_logic: Review near misses as support-depletion evidence even when the visible structure recovers.

decision_rules: Treat stable surface output plus declining support indicators as a warning, not proof of resilience.

decision_rules: Do not expand the visible frontier when the support substrate is below its maintenance or reserve threshold.

decision_rules: Prefer early load relief or reinforcement when support-depletion lead time exceeds collapse-warning lead time.

decision_rules: Require explicit distinction between temporary bridging and support repair.

decision_rules: Escalate when support indicators are unmeasured, ownerless, or systematically excluded from performance review.

decision_rules: Consider evacuation or controlled shutdown when void growth is faster than replenishment or reinforcement capacity.

target_invariants: Visible load remains matched to actual support substrate, not to last period’s surface performance.

target_invariants: Support indicators cannot be hidden behind aggregate performance scores.

target_invariants: Temporary patches are time-limited and cannot count as substrate restoration unless they replenish support capacity.

target_invariants: Support owners have authority to slow, stop, or redesign visible load when substrate integrity is unsafe.

target_invariants: Collapse thresholds, uncertainty, and inspection blind spots are communicated before failure.

target_invariants: Near misses update the substrate model rather than resetting confidence to normal.

expected_outcomes: Earlier detection of collapse risk caused by quiet support withdrawal.

expected_outcomes: Reduced dependence on misleading surface-performance signals.

expected_outcomes: Better timing for reinforcement, replenishment, slowdown, evacuation, or redesign.

expected_outcomes: Clearer accountability for maintaining hidden supports and reserves.

expected_outcomes: Fewer abrupt failures that appear sudden only because support depletion was not monitored.

Physical Foundation Void Guarding

short_definition: Detect and repair physical voids, scour, erosion, or substrate loss beneath infrastructure before surface failure.

distinctive_feature: Uses physical inspection, sensing, and reinforcement mechanisms.

distinct_from_parent: A physical infrastructure subtype of hidden support depletion guarding.

still_same_parent_because: It uses the same visible-shell, hidden-substrate, void-growth, and load-relief logic.

use_when: The support layer is geological, structural, or material.

use_when: Surface inspection can miss the void or undermining below.

example: Inspect bridge foundations for scour before normal traffic becomes unsafe.

failure_modes:
false surface reassurance
inspection blind spot
delayed closure

Operational Backbone Hollowing Guarding

short_definition: Detect when visible operations are sustained by a shrinking backbone of staff, maintenance, supply, or support capacity.

distinctive_feature: Focuses on the frontier-to-backbone ratio and backstage support work.

distinct_from_parent: A management and operations subtype.

still_same_parent_because: It still centers on hidden support depletion beneath a visible operating surface.

use_when: Service output remains acceptable while backstage capacity is being consumed.

use_when: Expansion pressures hide support deficits.

example: Uptime remains high while on-call resilience and platform maintenance are depleted.

failure_modes:
heroic workaround normalization
support staff burnout
hidden backlog inflation

name: Legitimacy or Trust Substrate Depletion Guarding

short_definition: Protect institutions or communities from collapse caused by quiet depletion of trust, legitimacy, consent, or informal support.

distinctive_feature: The depleted support substrate is social or institutional rather than physical or operational.

distinct_from_parent: A governance subtype with harder measurement and ethical issues.

still_same_parent_because: It preserves the same shell/substrate/depletion/collapse geometry.

use_when: Formal authority remains intact while trust and legitimacy erode.

use_when: Surface compliance hides withdrawal of real support.

example: Formal compliance remains high while public trust in the institution is hollowed out.

failure_modes:
measurement proxy distortion
performative trust repair
late legitimacy crisis

near_names:
Substrate Support Guarding
Hidden Substrate Depletion Monitoring
Undermining Failure Prevention
Support Void Detection
Caldera Collapse Prevention


Hidden-Type Screening

batch: First Iteration/Batch 12

Hidden-Attribute Screening

alias_scope: Near-alias emphasizing that the hidden property may be quality, risk, need, ability, intent, or safety rather than a human “type.”

Type-Revelation Screening

alias_scope: Technical near-name for screens that reveal private attributes before commitment.

Vetting

slug: vetting

alias_scope: Common cross-domain name for examining candidates before trust, access, or allocation.

Prequalification

slug: prequalification

alias_scope: Procurement, lending, admissions, and access-control name for screening before full evaluation or commitment.

Risk Screening

alias_scope: Domain-specific near-name when the hidden attribute is risk.

Screening

slug: screening

role: Primary canonical prime: the uninformed party designs a test, menu, trial, or evidence request that reveals a candidate’s hidden attribute before commitment.

Adverse Selection

role: Primary canonical prime: screening becomes important when hidden high-risk, low-fit, or low-quality candidates can self-select into an offer or pool.

Set and Membership

role: Primary canonical prime: the intervention decides whether a candidate belongs in a set, pool, role, access class, or allocation track based on revealed attributes.

Uncertainty

role: The decision-maker must act before the candidate’s true quality, risk, need, ability, or intention is directly known.

Observability

role: Screening converts an otherwise hidden attribute into observable evidence, behavior, or choice data.

Threshold

role: Many screens use thresholds to separate acceptable, risky, uncertain, or review-needed cases.

Type I / Type II Errors

role: Every screen creates false rejection and false acceptance risks that must be explicitly managed.

Procedural Fairness

role: Screening must be explainable, contestable, and applied consistently when it affects access, livelihood, care, or rights.

Equity

slug: equity

role: Screening burdens can exclude capable or deserving candidates if cost, language, wealth, disability, or context is ignored.

Incentive Compatibility

role: A strong screen is hard to game and makes truthful revelation or appropriate self-sorting more attractive than misrepresentation.

Access Control

role: Screening often precedes access decisions, but it is not the same as permission enforcement after eligibility is known.

Selection Bias

role: Poorly designed screens can distort the observed candidate pool by filtering for test-taking ability, resources, or willingness to comply rather than the target attribute.

Signaling

slug: signaling

role: Candidates may respond to screening by producing signals; the screen must distinguish meaningful signals from cheap claims.

components:
Hidden Attribute Hypothesis
Candidate Pool Boundary
Screening Signal or Test
Elicitation Channel
Threshold and Routing Rule
Validation and Base-Rate Check
False Positive / False Negative Policy
Fairness and Accessibility Review
Review or Appeal Path
Monitoring and Recalibration Loop
Self-Selection Menu
Staged Commitment Path
Evidence Standard
Privacy and Data Minimization Rule
Assessor Independence Rule
Fallback Measurement Path

mechanisms:
Structured Application
Diagnostic Test
Work Sample or Audition
Structured Interview
Background Check
Probationary Period
Pilot Project
Self-Selection Menu
Underwriting Assessment
Credential Verification
Reference Check
Challenge or Proof-of-Work
Risk Scoring Model

essence_one_line: Design tests, menus, thresholds, trials, or evidence requirements that reveal hidden attributes before accepting risk or allocating scarce resources.

compression_statement: When candidates differ in important but hidden attributes, create a structured screening process that elicits reliable evidence, behavior, or self-selection before commitment, while managing error, gaming, fairness, and privacy costs.

core_intuition: A system does not have to guess blindly or rely on cheap claims. It can ask candidates to reveal relevant information through a designed interaction that is hard enough to fake, relevant enough to predict, and fair enough to justify the resulting decision.

canonical_formula: hidden attribute + pre-commitment decision + designed elicitation/evidence channel + validated routing rule -> better allocation under information asymmetry

structural_problem: An uninformed party must choose among candidates whose relevant quality, risk, need, capability, safety, reliability, or intention is hidden, and accepting the wrong candidates would create loss, misallocation, unfairness, or pool degradation.

condition: Relevant attributes are privately known, costly to observe, delayed, or only revealed after commitment.

why_it_matters: The decision would otherwise be made using cheap claims, stereotypes, or accidental evidence.

condition: The decision is partially irreversible or costly to undo.

why_it_matters: Screening is valuable when mistaken admission, treatment, funding, access, or contracting has downstream consequences.

condition: Candidates have incentives to exaggerate, conceal, mimic, or strategically select into favorable terms.

why_it_matters: The screen must be incentive-aware rather than a naive information request.

condition: Scarce resources, protected access, shared risk, or high-trust roles are being allocated.

why_it_matters: Incorrect selection imposes costs on pools, users, patients, employers, communities, or future maintainers.

condition: Directly observing the target attribute for everyone is too slow, invasive, costly, or unsafe.

why_it_matters: Screening trades perfect knowledge for a controlled evidence-generation process.

symptom: Accepted candidates later reveal avoidable mismatch, risk, low capability, fraud, or poor fit.

diagnostic_hint: The system is learning too late what it needed to know before commitment.

symptom: Decision-makers rely on reputation, charisma, credentials, or demographics without validation.

diagnostic_hint: Visible proxies may be substituting for actual hidden attributes.

symptom: The candidate pool degrades because low-fit or high-risk candidates disproportionately enter.

diagnostic_hint: The screen is too weak, too easy to game, or absent.

symptom: High-quality or high-need candidates are excluded because the screen favors those with resources, polish, or documentation.

diagnostic_hint: The screen may reveal privilege rather than the target attribute.

symptom: Review effort is wasted on obviously unsuitable cases while uncertain cases remain poorly evaluated.

diagnostic_hint: The screening funnel lacks staged routing or threshold discipline.

root_tension: The system needs to decide before it knows, while candidates may know more about themselves than the decision-maker and may have reason to reveal selectively.

condition: The relevant attributes are already known and verified.

why_not_this_archetype: The task is classification, routing, or access control rather than screening.

condition: The decision cost is trivial and errors are easy to reverse.

why_not_this_archetype: A screen may add friction without meaningful benefit.

condition: The screen cannot be validated against outcomes or relevant evidence.

why_not_this_archetype: It risks becoming ritual, bias, or pseudo-measurement.

condition: The primary problem is risky behavior after protection, not hidden attributes before acceptance.

why_not_this_archetype: That is closer to moral_hazard_mitigation.

condition: The primary problem is maintaining pool composition under self-selection.

why_not_this_archetype: That is closer to adverse_selection_filtering, although screening may be one of its components.

structural_intervention: Define the hidden attribute to reveal, design an elicitation or evidence channel, validate that the screen predicts the attribute in the relevant candidate pool, route candidates through explicit rules, and maintain fairness, privacy, appeal, and recalibration safeguards.

logic: Specify exactly what attribute matters to the decision and why it is hidden before commitment.

logic: Define who or what is subject to screening and whether screening is justified for that population.

logic: Choose tests, trials, documents, references, structured choices, or behavior observations that plausibly reveal the attribute.

logic: Check whether the screen actually predicts the relevant outcome or type, including base rates and subgroup performance.

logic: Translate screen results into acceptance, rejection, additional review, staged access, segmentation, or appeal paths.

logic: Decide how to handle false positives, false negatives, accessibility burdens, privacy, and contestability.

logic: Recalibrate the screen when candidates adapt, the pool changes, or observed outcomes reveal error.

rule: Use the least intrusive screen that can validly reveal the relevant hidden attribute.

rationale: Screening should not become unnecessary surveillance or burden.

rule: Raise screen strictness as the cost of false acceptance, irreversibility, or downstream harm increases.

rationale: High-risk decisions require stronger evidence, but stricter screens also require stronger fairness safeguards.

rule: Reserve costly or high-burden screens for later stages or ambiguous cases when possible.

rationale: A staged funnel reduces cost and avoids overburdening the entire candidate pool.

rule: Require appeal, accommodation, or human review when the screen affects rights, livelihood, essential services, safety, or protected groups.

rationale: High-stakes screening needs procedural fairness and recourse.

rule: Retire or revise a screen when validation shows low predictive value, systematic bias, or high gaming susceptibility.

rationale: A screen that does not reveal the target attribute is worse than a transparent admission of uncertainty.

invariant: Attribute relevance

preservation_logic: Every screen must connect to a decision-relevant hidden attribute, not vague desirability or convenience.

invariant: Predictive validity

preservation_logic: The evidence channel must be checked against outcomes or credible ground truth.

invariant: Proportional burden

preservation_logic: The cost, intrusion, and effort required by the screen must be proportional to the decision stakes.

invariant: Error transparency

preservation_logic: False acceptance and false rejection risks should be known, monitored, and managed.

invariant: Fairness and contestability

preservation_logic: Affected candidates need consistent rules, accessible processes, and a path to correct or contextualize errors.

invariant: Anti-gaming robustness

preservation_logic: The screen should not reward mimicry, coaching, wealth, or paperwork over the target attribute.

outcome: Better pre-commitment selection

description: More candidates are routed to roles, treatments, terms, access levels, or review paths that match their actual attributes.

outcome: Reduced hidden-risk exposure

description: The system accepts fewer candidates whose hidden risk or mismatch would impose downstream costs.

outcome: Lower review waste

description: Review capacity is focused on uncertain or promising cases rather than obviously unsuitable cases.

outcome: Improved trust in allocation

description: Stakeholders can see why candidates are accepted, rejected, deferred, or moved to staged review.

outcome: Managed adverse selection pressure

description: High-risk or low-fit types cannot enter purely by making cheap claims or exploiting weak information.

prose_essence:
Hidden-Type Screening is the pattern of making an otherwise hidden attribute visible enough to support a decision before commitment. The attribute might be ability, risk, need, quality, reliability, intent, safety, compliance, or fit. The screen might be a test, trial, questionnaire, work sample, structured choice, background check, diagnostic, or evidence review. The archetype is not any one of those mechanisms; it is the intervention logic that asks, “What do we need to know before accepting this candidate, and what designed interaction can reveal it fairly and reliably?”

The core move is to avoid blind admission and cheap claims without pretending that screening gives perfect knowledge. A mature screen is explicit about what it measures, what errors it can make, who may be burdened by it, and how the result is reviewed or recalibrated.

prose_when_to_use:
Use this archetype when a system must decide among candidates before it knows the traits that matter. It fits especially well when commitment is costly or risky: hiring, admission, access, procurement, triage, underwriting, funding, security approval, vendor selection, or staged entry into a protected pool.

It is strongest when the hidden attribute can be connected to observable evidence or behavior. It is weak when the screen cannot be validated, when the decision is easy to reverse, or when the screen merely measures convenience, wealth, polish, or documentation access.

prose_structural_problem:
The structural problem is asymmetric information before selection. Candidates, applicants, vendors, patients, users, devices, projects, or artifacts differ in important ways, but the decision-maker cannot directly observe those differences in time. If the system accepts everyone, it may admit avoidable risk or mismatch. If it rejects too broadly, it may exclude valuable or deserving candidates.

The tension is that the system needs a decision now, while the relevant truth would normally appear only later. Screening creates a controlled pre-commitment encounter that turns some hidden attribute into evidence.

prose_intervention_logic:
A Hidden-Type Screening intervention begins by naming the hidden attribute. A vague desire to find “good” candidates is not enough; the screen must identify whether it is looking for skill, risk, need, reliability, compliance, intent, safety, or fit.

The designer then chooses an elicitation channel. A work sample reveals capability differently from a diagnostic test, a pilot, a structured application, a self-selection menu, or a background check. The channel should be relevant, proportionate, hard enough to fake, and accessible enough not to become unfair gatekeeping.

The screen also needs a routing rule. Results should determine whether the candidate is accepted, rejected, deferred, sent to manual review, offered a trial, segmented into terms, or given an appeal path. Finally, the screen must be validated and recalibrated because candidates adapt, pools change, and proxies drift.

prose_key_components:
### Hidden Attribute Hypothesis

This component states what the screen is trying to reveal. The hidden attribute might be quality, risk, ability, need, intention, reliability, safety, compliance, or fit. Without this hypothesis, the screen becomes a generic hurdle rather than a knowledge-generating intervention.

### Candidate Pool Boundary

The pool boundary defines who or what is being screened. It prevents screening from expanding into general surveillance and clarifies why the screen applies to this set of candidates, artifacts, cases, vendors, patients, users, or projects.

### Screening Signal or Test

This is the observable evidence used to infer the hidden attribute. It can be a measurement, work sample, document, trial behavior, record, reference, diagnostic marker, structured answer, or choice among options.

### Elicitation Channel

The elicitation channel is the designed interaction that produces evidence. It is what distinguishes screening from passive observation: the system intentionally creates a test, interview, menu, pilot, questionnaire, diagnostic, or evidence request.

### Threshold and Routing Rule

Screen results need consequences. The routing rule determines whether a candidate is accepted, rejected, deferred, staged, segmented, or sent to review. The threshold should be tied to operational risk rather than arbitrary convenience.

### Validation and Base-Rate Check

A screen should be checked against real outcomes and the base rates of the candidate pool. A screen that worked in one population can fail in another, and a strong-looking signal can become meaningless if it has no predictive relation to the target attribute.

### False Positive / False Negative Policy

Every screen makes mistakes. A false positive accepts a candidate who should not have passed; a false negative rejects or delays a candidate who should have passed. The policy states which error matters more in the domain and how the system compensates for both.

### Fairness and Accessibility Review

Screening can easily favor candidates with money, language fluency, coaching, paperwork, disability accommodation, or time. This component asks whether the screen measures the target attribute or merely the ability to survive the screen.

### Review or Appeal Path

A mature screen gives candidates a way to correct missing evidence, contest error, add context, or request accommodation. This is essential when screening affects rights, livelihood, care, education, security access, or essential services.

### Monitoring and Recalibration Loop

Screens drift. Candidates learn to game them, base rates change, scoring rubrics become stale, and evidence channels lose predictive value. Monitoring keeps the screen from becoming ritualized bureaucracy.

prose_common_mechanisms:
### Structured Applications

A structured application collects comparable evidence across candidates. It implements the archetype only when the questions reveal decision-relevant hidden attributes rather than simply creating paperwork.

### Diagnostic Tests

A diagnostic test reveals a hidden state such as disease, readiness, safety, or capability. It is a mechanism of hidden-type screening when it informs pre-commitment routing.

### Work Samples and Auditions

A work sample or audition observes behavior close to the target task. It is useful when future performance is hard to infer from claims or credentials alone.

### Structured Interviews

A structured interview uses common questions and rubrics to produce comparable evidence. It is stronger than informal conversation because it reduces arbitrary judgment and makes validation possible.

### Background Checks and Reference Checks

These mechanisms gather external evidence about past conduct, claims, reliability, or risk. They must be relevant and proportionate; otherwise they become privacy-invasive proxy screens.

### Probationary Periods and Pilot Projects

These mechanisms reveal type through limited real-world exposure. They work when the system can safely learn from a small commitment before making a larger one.

### Self-Selection Menus

A self-selection menu offers options with different costs, constraints, benefits, or obligations so candidates sort themselves. This can implement screening, but it may deserve separate treatment when option-menu design becomes the central intervention.

### Underwriting Assessments

Underwriting is a domain mechanism for revealing hidden risk before accepting someone into credit, insurance, warranty, or shared-risk arrangements. It is not the archetype by itself.

### Credential Verification

Credential verification checks whether a claimed qualification is genuine and relevant. It implements screening only when the credential actually helps reveal the hidden attribute.

### Risk Scoring Models

A risk score combines evidence into a decision aid. It is a mechanism, not the archetype, and it requires validation, bias review, explanation, and appeal in high-stakes uses.

prose_failure_modes:
The most common failure mode is the proxy trap: the screen measures what is easy rather than what matters. Other failures include screen gaming, credential capture, false rejection of nonstandard candidates, false acceptance of well-prepared mimics, privacy overreach, stale validation, opaque automated denial, and burden-induced selection bias.

A particularly dangerous failure occurs when a screen becomes culturally accepted but no longer predicts the hidden attribute. At that point it can continue excluding people or admitting risk while feeling administratively legitimate.

prose_neighbor_distinctions:
Hidden-Type Screening is distinct from Adverse Selection Filtering. Screening reveals candidate attributes; adverse-selection filtering protects pool composition when hidden high-risk or low-quality participants self-select into an offer.

It is distinct from Priority-Based Admission because priority admission ranks known claims or urgency, while screening reveals unknown qualities. It is distinct from Canonical Classification because classification labels already-known or defined attributes, while screening generates evidence.

It is also distinct from Credible Signaling. In signaling, the informed party sends a hard-to-fake signal. In screening, the uninformed party designs the elicitation structure. In practice they often interact: a screen may require a candidate to produce a credible signal.

prose_cross_domain_examples:
In hiring, a work sample and structured interview reveal future job capability better than a resume alone. In medicine, a diagnostic test screens for a hidden condition before treatment. In insurance, underwriting reveals hidden risk before coverage terms are set. In procurement, a pilot project reveals vendor reliability before a full contract. In cybersecurity, identity and device posture checks screen hidden trustworthiness before access. In research funding, staged review screens proposal feasibility before full funding.

These examples differ in surface form, but share the same intervention logic: reveal what matters before commitment.

prose_non_examples: A taxonomy that labels already-known entities is not hidden-type screening. A first-come queue is not screening if hidden attributes do not matter. A credential badge accepted without verification is not a screen. A punishment after failure is accountability, not pre-commitment screening. Segmenting a pool after risk classes are already known is risk segmentation, not the screening pattern itself.

prose_tradeoffs:
Screening improves information but adds friction. More evidence can reduce risk, but it can also delay decisions, deter good candidates, and invade privacy. Strict thresholds may prevent harm, but they can also reject capable or deserving candidates. Transparent criteria support fairness, but overly transparent screens can become easier to game.

The design question is not whether to screen maximally. It is how much screening is justified by the stakes, how reliable the evidence is, and how the system will handle error.

prose_invariants_to_preserve:
The screen must remain connected to a decision-relevant hidden attribute. It must preserve predictive validity, proportional burden, fairness, contestability, and error visibility. It should also preserve anti-gaming robustness: candidates should not be able to pass merely by mimicking the signal while lacking the hidden attribute.

The most important invariant is relevance. A screen that measures paperwork, status, wealth, charisma, or compliance with bureaucracy instead of the target attribute may appear objective while producing systematically bad allocation.

prose_target_outcomes:
A successful Hidden-Type Screening design improves pre-commitment selection. It reduces avoidable mismatch, hidden-risk acceptance, and review waste. It helps scarce resources, roles, access, funding, treatment, or shared-risk arrangements flow toward candidates whose revealed attributes fit the decision.

It can also improve trust in allocation because stakeholders understand the decision basis. That trust depends on more than accuracy: it requires clear criteria, proportional evidence, appeal paths, and monitoring for bias or drift.

prose_parameter_dimensions:
Important tuning dimensions include screen strictness, evidence burden, candidate cost, decision stakes, reversibility, score threshold, number of funnel stages, validation frequency, privacy intrusiveness, appeal availability, and tolerance for false positives versus false negatives.

High-risk domains usually justify stronger screens, but stronger screens also require stronger fairness and contestability safeguards. Low-stakes or reversible decisions often need lighter screens, staged entry, or random sampling rather than heavy prequalification.

prose_variants_and_near_names:
Important variants include direct evidence screening, behavioral trial screening, self-selection menu screening, threshold screening, and staged screening funnels. Near names include vetting, eligibility screening, prequalification, risk screening, quality screening, and due diligence screening.

The roadmap also names self-selection mechanisms as a likely second-wave candidate. This draft preserves self-selection menu screening as a promotion candidate rather than collapsing it completely.

Direct Evidence Screening

short_definition: Reveal hidden attributes through documents, tests, records, references, or measurements presented before commitment.

distinctive_feature: The screen relies on evidence items or measurements rather than choices among options or longitudinal trial behavior.

distinct_from_parent: The parent covers all hidden-type elicitation; this variant emphasizes evidence collection and verification.

still_same_parent_because: The intervention is still organized around revealing hidden type before acceptance or allocation.

source_primes: screening observability

use_when: The hidden attribute can be approximated by independently checkable evidence.

use_when: The decision context needs comparable evidence across candidates.

use_when: The cost of direct later discovery is higher than the cost of pre-screening.

Screening Signal or Test

role: Defines the evidence item or test used to reveal the hidden attribute.

Evidence Standard

role: Specifies what evidence counts and how it is checked.

example_domains:
medicine
hiring
procurement
security access

domain: Medicine

example: A diagnostic test screens for a hidden condition before treatment selection.

domain: Hiring

example: A verified license and work sample reveal capability before hiring.

failure_modes: Evidence becomes stale, forged, irrelevant, or biased toward candidates with better documentation.

Behavioral Trial Screening

short_definition: Reveal hidden fit, reliability, capability, or risk through limited real or simulated participation before full commitment.

distinctive_feature: The screen learns over time from behavior under constrained exposure.

distinct_from_parent: The parent can use any screen; this variant uses staged exposure as the screening medium.

still_same_parent_because: The trial’s purpose is to reveal hidden type before full admission or allocation.

source_primes: screening uncertainty

use_when: The hidden attribute is best learned through behavior rather than claims.

use_when: Full admission is risky but a limited trial is safe enough.

use_when: The system can observe meaningful behavior during a pilot, probation, audition, or sandbox.

Staged Commitment Path

role: Limits exposure while evidence accumulates.

Monitoring and Recalibration Loop

role: Checks whether trial behavior predicts later performance.

example_domains:
employment
vendor procurement
software rollout
education

domain: Vendor procurement

example: A pilot project screens a vendor’s reliability before a full contract.

domain: Employment

example: A probationary period tests fit and reliability before permanent appointment.

failure_modes: Trial conditions are unrepresentative, exploit unpaid labor, or become an indefinite gate.

Self-Selection Menu Screening

short_definition: Offer differentiated options whose tradeoffs cause candidates with different hidden attributes to sort themselves.

distinctive_feature: The candidate reveals type through choice rather than through a test score or document.

distinct_from_parent: The parent includes tests, trials, and evidence requests; this variant uses option-menu design as the screen.

still_same_parent_because: It remains a way of revealing hidden type before commitment.

use_when: Directly measuring the hidden type is costly or invasive.

use_when: Different hidden types prefer meaningfully different cost-benefit bundles.

use_when: The options can be designed so truthful sorting is easier than strategic mimicry.

Self-Selection Menu

role: Differentiates options so type-specific preferences produce sorting.

Threshold and Routing Rule

role: Routes the selected option to terms, track, access, or review.

example_domains:
insurance
service tiers
contracts
admissions tracks

domain: Insurance

example: Deductible choices reveal risk tolerance and expected usage.

domain: Services

example: Different support tiers reveal urgency and willingness to bear constraints.

failure_modes: Menus exploit vulnerable candidates, become price discrimination, or fail when types can mimic each other cheaply.

Threshold Screening

short_definition: Use a defined score, cutoff, criterion, or risk band to route candidates based on screened evidence.

distinctive_feature: The separator is an explicit threshold or band rather than case-by-case discretion.

distinct_from_parent: The parent is broader; threshold screening is the cutoff-based implementation form.

still_same_parent_because: The threshold is useful only because it routes inferred hidden types.

source_primes: screening threshold

use_when: The decision requires repeatable routing across many cases.

use_when: Evidence can be scored or banded with known error rates.

use_when: The system can tolerate explicit cutoff governance and review.

Threshold and Routing Rule

role: Defines score bands and routing.

False Positive / False Negative Policy

role: Defines acceptable error balance.

example_domains:
clinical triage
credit review
content moderation
capacity allocation

domain: Clinical triage

example: A test threshold routes patients to treatment, retesting, or observation.

domain: Credit review

example: A score band routes applicants to approval, manual review, or denial.

failure_modes: Cutoffs become arbitrary, hidden, brittle, or optimized by candidates rather than predictive of the target attribute.

Staged Screening Funnel

short_definition: Apply low-cost screens first, then more costly or intrusive screens only to ambiguous or promising candidates.

distinctive_feature: Screening is sequenced by cost, uncertainty, and error tolerance.

distinct_from_parent: The parent can be a single screen; this variant organizes multiple screens into a funnel.

still_same_parent_because: Each stage is still designed to reveal hidden attributes before final commitment.

use_when: The candidate pool is large and evaluation resources are scarce.

use_when: A single screen is too noisy or too costly.

use_when: Later-stage screens are more accurate but should be reserved for a smaller set.

Threshold and Routing Rule

role: Moves candidates between stages.

Review or Appeal Path

role: Handles borderline cases and contestation.

example_domains:
hiring
grants
research review
vendor selection

example: Application review, work sample, interview, and reference check form a staged funnel.

domain: Grants

example: Letter of intent, full proposal, and due diligence reduce review burden.

failure_modes: Early cheap filters remove unconventional high-quality candidates before richer evidence can appear.

near_names:
Vetting
Eligibility Screening
Prequalification
Risk Screening
Quality Screening
Due Diligence Screening
Screening Test