Probabilistic Risk Weighting

batch: First Iteration/Batch 29

Risk Prioritization

relationship: common operational name

Expected Loss Prioritization

relationship: recognized variant

Tail-Risk Weighting

relationship: candidate variant

source_primes: probability uncertainty

slug: probability

components:
Uncertain Event
Probability Estimate
Consequence Estimate
Risk Weighting Rule
Action Priority Mapping
Update Rule
Evidence Quality Note
Tail-Risk Exception Rule
Risk Owner
Calibration Feedback Signal

mechanisms:
Risk Matrix
Expected Value Calculation
Probabilistic Forecast
Risk Scoring Model
Bayesian Risk Update
Actuarial Risk Model
Probabilistic Safety Analysis
Decision Tree
Risk Register
Scenario Probability Table

essence_one_line: Weight decisions by likelihood and consequence rather than treating all possible outcomes as equally likely or equally important.

compression_statement: When uncertain outcomes matter, estimate probability and consequence together so attention, resources, and safeguards match expected and tail risk.

core_intuition: Uncertainty should not make all possibilities feel equally important. A vivid but unlikely event, a common but minor event, and a rare catastrophic event require different responses. This archetype forces the decision to ask both “How likely?” and “How bad or valuable if it happens?” before allocating attention, safeguards, money, or escalation.

canonical_formula: risk_weight ≈ f(probability_estimate, consequence_estimate, uncertainty_about_estimate, reversibility, tail_risk_policy) → mapped_action_priority

structural_problem: A decision faces multiple possible outcomes, but actors overreact to vivid possibilities, ignore likelihood, or fail to combine likelihood with impact.

condition: Multiple possible outcomes compete for attention or resources.

why_it_matters: Unweighted possibility lists invite overreaction to vivid cases and neglect of common or severe cases.

condition: Likelihood and consequence are discussed separately or implicitly.

why_it_matters: A high-impact event and a high-probability event can be misprioritized unless the dimensions are combined.

condition: Risk response capacity is limited.

why_it_matters: Mitigation, monitoring, reserves, inspections, and safeguards must be allocated rather than applied equally.

condition: New evidence may change the probability or consequence estimate.

why_it_matters: A one-time risk ranking can become obsolete as exposure, data, or conditions change.

symptom: Vivid low-probability scenarios dominate planning.

diagnostic_meaning: Attention is being allocated by salience rather than calibrated risk.

symptom: Frequent small losses are normalized and ignored.

diagnostic_meaning: Cumulative expected loss is hidden because individual events look minor.

symptom: Catastrophic low-probability scenarios are dismissed as “unlikely.”

diagnostic_meaning: Consequence severity or irreversibility is not being protected by an exception rule.

symptom: Risk registers contain labels but no action thresholds.

diagnostic_meaning: The assessment is not connected to response weighting.

symptom: Old risk ratings persist after conditions change.

diagnostic_meaning: The update rule is missing or not governed.

root_tension: Decision makers need to act under uncertainty, but unaided judgment tends to confuse possibility with probability, emotional vividness with consequence, and static estimates with living risk.

case: The outcome is already certain and the only issue is implementation.

why_not: No probabilistic weighting is needed; use planning, sequencing, or execution controls.

case: The decision only needs uncertainty to be displayed, not acted on.

why_not: Uncertainty Explicitness may be sufficient if no response priority changes.

case: All outcomes have nearly identical consequence and likelihood.

why_not: Risk weighting adds burden without meaningful discrimination.

case: The primary issue is moral, legal, or rights-based prohibition.

why_not: A constraint, duty, or safety invariant may override probabilistic tradeoff.

structural_intervention: Define uncertain events, estimate probability, estimate consequence, rank or weight response, and update as evidence changes.

action: Name the uncertain event or outcome class.

purpose: Prevents vague concern from masquerading as a comparable risk.

action: Represent likelihood on a declared scale.

purpose: Makes probability explicit enough to compare and update.

action: Represent consequence on a declared scale or category.

purpose: Keeps impact, severity, upside, reversibility, and harm type visible.

action: Apply a risk weighting rule.

purpose: Combines likelihood and consequence into an action-relevant priority.

action: Map weight to response.

purpose: Turns assessment into monitoring, mitigation, escalation, reserve allocation, or acceptance.

action: Update and calibrate over time.

purpose: Prevents stale estimates and improves future weighting accuracy.

rule: Use explicit probability and consequence scales before ranking.

reason: Ranking without scales usually smuggles in hidden assumptions.

rule: Escalate low-probability catastrophic or irreversible risks for tail-risk review.

reason: Simple expected-value treatment can underweight non-compensable harms.

rule: Require action thresholds for each risk tier.

reason: A risk weight is useful only if it changes attention, resources, safeguards, or decisions.

rule: Refresh weights when exposure, evidence quality, observed incidents, or assumptions change.

reason: Risk is dynamic; old weights can become dangerous.

rule: Separate uncertainty about the estimate from the estimate itself.

reason: Weak evidence should affect confidence, escalation, or monitoring even when a point estimate exists.

invariant: Likelihood and consequence remain visibly linked.

why_preserve: The archetype fails if action is driven by one dimension alone.

invariant: The consequence scale remains meaningful and ethically reviewable.

why_preserve: Some harms cannot be flattened into a convenient numeric score without review.

invariant: Risk weights map to actual response choices.

why_preserve: Assessment without action mapping creates false governance.

invariant: Update triggers and ownership remain explicit.

why_preserve: Risk weights must change when evidence or exposure changes.

invariant: Mechanisms remain subordinate to the archetype.

why_preserve: A risk matrix or score is not enough unless it implements likelihood–consequence action weighting.

outcome: Better allocation of attention and mitigation capacity.

indicator: High-weight risks receive clearer owners, resources, and action thresholds.

outcome: Less salience-driven overreaction.

indicator: Vivid but low-weight risks are monitored rather than allowed to dominate planning.

outcome: Less neglect of common or severe risks.

indicator: Frequent losses and rare catastrophic events are both visible in the weighting rule.

outcome: More auditable risk decisions.

indicator: Probability, consequence, update assumptions, and response mappings can be traced.

outcome: Improved calibration over time.

indicator: Predicted and observed outcomes are compared and used to revise weights.

prose_essence:
Probabilistic Risk Weighting is the intervention of making uncertain outcomes action-relevant. It does not merely say “we are uncertain.” It asks which uncertain events might occur, how likely they are, how consequential they would be, and what response should follow from that combination.

The simplest version is likelihood times consequence. The mature version also asks whether the estimate is well supported, whether the harm is reversible, whether rare catastrophic outcomes need special treatment, and whether the resulting weight actually changes attention, safeguards, budgets, escalation, or monitoring.

prose_when_to_use:
Use this archetype when a decision faces several possible outcomes and equal treatment would be misleading. It is especially useful when teams are overreacting to vivid possibilities, ignoring quiet but common losses, or dismissing severe events because they are unlikely.

It is also useful when resources are limited. A team cannot mitigate every risk with equal intensity, so it needs a principled way to decide what to monitor, what to accept, what to insure, what to redesign, and what to escalate.

Do not use it as a substitute for non-negotiable constraints. Some duties, rights, safety invariants, and legal requirements override risk-weighted tradeoffs.

prose_structural_problem:
The structural problem is a mismatch between possible outcomes and action priority. People often reason from salience: the most emotionally vivid or recently discussed scenario feels most important. Other times, they make the opposite error and dismiss low-probability severe harms because “it probably will not happen.”

The missing structure is a joint representation of likelihood and consequence. Without it, probability, impact, evidence quality, and response thresholds remain implicit. That makes decisions hard to audit and easy to distort.

prose_intervention_logic:
The intervention starts by naming the uncertain event clearly. Then it gives the event a likelihood representation and a consequence representation. The risk weighting rule combines those dimensions into a priority or response class. Finally, an update rule keeps the weight from becoming stale.

This is not just a calculation. The defining question is: what should change because this event has this likelihood and this consequence? A weighted risk should lead to a mapped response: mitigation, monitoring, contingency reserve, escalation, transfer, acceptance, or redesign.

prose_key_components:
### Uncertain Event

```yaml
component:
  slug: uncertain_event
  name: Uncertain Event
  role: >-
    Identifies the possible outcome, scenario, failure, opportunity, or transition whose likelihood
    and consequence need to be weighted.
  notes: >-
    The event must be specific enough to estimate. Vague fears such as “something bad might
    happen” should be decomposed into events that can be compared, monitored, and updated.
```

This component keeps the risk object from being a vague mood. It forces the team to identify what could happen, under what conditions, and at what level of granularity it can be estimated.

### Probability Estimate

```yaml
component:
  slug: probability_estimate
  name: Probability Estimate
  role: >-
    Represents how likely the uncertain event is using a qualitative, ordinal, frequency-based,
    or numeric likelihood scale.
  notes: >-
    The estimate can be rough, but the scale must be explicit. A likelihood band, base rate,
    forecast distribution, or calibrated expert estimate is usually better than an unmarked
    intuition.
```

This component gives the event a likelihood representation. The estimate can be numeric, ordinal, qualitative, or distributional, but it must be explicit enough to compare and revise.

### Consequence Estimate

```yaml
component:
  slug: consequence_estimate
  name: Consequence Estimate
  role: >-
    Represents the impact of the event if it occurs, including harm, cost, delay, loss of
    trust, safety effect, upside opportunity, or irreversible damage.
  notes: >-
    Consequences need a comparable scale or a declared non-comparable category. Some consequences
    cannot be reduced to money or a single score without ethical or safety review.
```

This component records why the event matters. It should include severity, cost, harm type, reversibility, and who bears the impact rather than only a generic “impact” score.

### Risk Weighting Rule

```yaml
component:
  slug: risk_weighting_rule
  name: Risk Weighting Rule
  role: >-
    Combines likelihood and consequence into an action-relevant weight, priority tier, expected
    loss, safety class, or escalation category.
  notes: >-
    The rule is the bridge from assessment to action. It should state whether rare catastrophic
    outcomes, uncertainty about the estimate, reversibility, or equity concerns override simple
    expected-value ranking.
```

This is the core bridge from assessment to priority. The rule explains how likelihood and consequence combine, and when uncertainty, tail risk, or non-compensable harms override the ordinary combination.

### Action Priority Mapping

```yaml
component:
  slug: action_priority_mapping
  name: Action Priority Mapping
  role: >-
    Maps each weighted risk to a response such as ignore, monitor, investigate, insure, mitigate,
    redesign, escalate, or reserve capacity.
  notes: >-
    Without this mapping, risk weighting remains descriptive. The archetype is complete only
    when weights change attention, resource allocation, safeguards, or decision thresholds.
```

This component prevents risk assessment from becoming a report-writing exercise. It states what each weight or tier causes people to do differently.

### Update Rule

```yaml
component:
  slug: update_rule
  name: Update Rule
  role: >-
    Specifies when new evidence, incident data, exposure changes, or forecast revisions should
    change the probability, consequence, or response weight.
  notes: >-
    The update rule prevents stale risk weights from hardening into false certainty. It should
    include triggers for revision, owners, and a record of what changed.
```

This component keeps the risk weight alive. As evidence, exposure, or system conditions change, the rule triggers recalibration rather than letting the first estimate become permanent.

### Evidence Quality Note

```yaml
component:
  slug: evidence_quality_note
  name: Evidence Quality Note
  role: >-
    Records the strength, recency, and source of the evidence behind a likelihood or consequence
    estimate.
  notes: >-
    This is especially useful when numbers appear precise but are built from sparse, biased,
    or extrapolated data.
```

This component keeps weak evidence from being laundered into a confident score. It records whether the estimate is based on incident data, base rates, expert judgment, extrapolation, or assumption.

### Tail-Risk Exception Rule

```yaml
component:
  slug: tail_risk_exception_rule
  name: Tail-Risk Exception Rule
  role: >-
    Allows low-probability high-consequence risks to receive special treatment when expected-value
    ranking would underweight catastrophic or irreversible outcomes.
  notes: >-
    This component protects against a common misuse of expected value: treating extinction-level,
    safety-critical, or irreversible harms as if they were ordinary losses.
```

This component protects against average-case thinking when the downside is catastrophic, irreversible, or ethically unacceptable.

### Risk Owner

```yaml
component:
  slug: risk_owner
  name: Risk Owner
  role: >-
    Assigns responsibility for maintaining the risk estimate, monitoring updates, and initiating
    the mapped response.
  notes: >-
    Ownership matters when the risk weight changes over time or when mitigation requires coordinated
    action across teams.
```

This component assigns responsibility for maintaining the estimate and ensuring the mapped response happens.

### Calibration Feedback Signal

```yaml
component:
  slug: calibration_feedback_signal
  name: Calibration Feedback Signal
  role: >-
    Compares predicted likelihoods and consequences against observed outcomes so future weights
    become better calibrated.
  notes: >-
    Calibration prevents systematic overreaction to vivid events and underreaction to common,
    quiet, or slowly accumulating harms.
```

This component compares prediction to reality so risk weighting improves instead of repeating old biases.

prose_common_mechanisms:
These mechanisms implement Probabilistic Risk Weighting in different contexts. They should not be confused with the archetype itself. The archetype is the transferable pattern: connect likelihood and consequence to action weighting, then update as evidence changes.

### Risk Matrix

```yaml
mechanism:
  slug: risk_matrix
  name: Risk Matrix
  mechanism_type: artifact
  role: >-
    Plots likelihood and consequence categories in a grid so risks can be triaged quickly
    and communicated to non-specialists.
```

A risk matrix implements the archetype when its cells connect likelihood and consequence to action tiers. It should not be treated as the archetype itself, because a matrix can become a static display with no update rule or response mapping.

### Expected Value Calculation

```yaml
mechanism:
  slug: expected_value_calculation
  name: Expected Value Calculation
  mechanism_type: method
  role: >-
    Multiplies or otherwise combines probability and consequence on a common scale to rank
    options by expected gain, loss, or exposure.
```

An expected-value calculation implements one variant by using a common scale for probability and consequence. It is useful for comparable losses or gains, but it can fail in tail-risk or incommensurable-harm cases.

### Probabilistic Forecast

```yaml
mechanism:
  slug: probabilistic_forecast
  name: Probabilistic Forecast
  mechanism_type: method
  role: >-
    Expresses future outcomes as probabilities or distributions so decision makers can weight
    responses rather than treating forecasts as binary predictions.
```

A probabilistic forecast supplies the likelihood side of the archetype. It becomes part of risk weighting only when the probabilities drive choices, safeguards, reserves, or escalation.

### Risk Scoring Model

```yaml
mechanism:
  slug: risk_scoring_model
  name: Risk Scoring Model
  mechanism_type: metric_or_dashboard
  role: >-
    Converts multiple risk factors into a score or tier used to prioritize review, intervention,
    safeguards, or resource allocation.
```

A risk score operationalizes weighting for repeated decisions. The score is a mechanism; the archetype is the broader design that defines what the score means and how it changes action.

### Bayesian Risk Update

```yaml
mechanism:
  slug: bayesian_risk_update
  name: Bayesian Risk Update
  mechanism_type: method
  role: >-
    Updates prior risk estimates with new evidence so the weight assigned to a risk changes
    as observations accumulate.
```

A Bayesian update is a mechanism for revising estimates. It supports the update rule, but the archetype requires that revised estimates change action weights.

### Actuarial Risk Model

```yaml
mechanism:
  slug: actuarial_risk_model
  name: Actuarial Risk Model
  mechanism_type: method
  role: >-
    Uses historical frequency, exposure, and cohort patterns to estimate expected loss and
    allocate premiums, reserves, safeguards, or inspection effort.
```

An actuarial model implements the archetype by using base rates and exposure patterns. It needs fairness and transfer checks because historical frequencies can encode biased or obsolete conditions.

### Probabilistic Safety Analysis

```yaml
mechanism:
  slug: probabilistic_safety_analysis
  name: Probabilistic Safety Analysis
  mechanism_type: test_or_assessment
  role: >-
    Models event chains, failure probabilities, and consequence paths in safety-critical systems
    to identify mitigation priorities.
```

Probabilistic safety analysis implements risk weighting in safety-critical systems by modeling failure paths and severe consequences. It should remain tied to safety invariants, not just a numeric expected loss.

### Decision Tree

```yaml
mechanism:
  slug: decision_tree
  name: Decision Tree
  mechanism_type: artifact
  role: >-
    Represents uncertain branches, probabilities, and payoffs so alternative actions can be
    compared under explicit possible outcomes.
```

A decision tree implements the archetype by showing branches, probabilities, and payoffs. It remains a representation mechanism unless it directly informs response choice.

### Risk Register

```yaml
mechanism:
  slug: risk_register
  name: Risk Register
  mechanism_type: document
  role: >-
    Maintains a living inventory of risks, weights, owners, mitigation actions, and update
    history.
```

A risk register implements the archetype by maintaining the living inventory of events, weights, owners, actions, and update history.

### Scenario Probability Table

```yaml
mechanism:
  slug: scenario_probability_table
  name: Scenario Probability Table
  mechanism_type: template
  role: >-
    Lists scenarios with likelihood bands, consequences, assumptions, and action thresholds
    when a full model would be excessive.
```

A scenario probability table is a lightweight mechanism for early-stage or qualitative contexts where a full quantitative model would be excessive.

prose_failure_modes:
False precision occurs when weak evidence is converted into confident numbers. The mitigation is to use bands, evidence-quality notes, and calibration checks.

Tail-risk underweighting occurs when rare catastrophic events are averaged into ordinary expected-loss comparisons. The mitigation is to use tail-risk exception rules and safety review thresholds.

Matrix theater occurs when a risk matrix is produced for governance optics but does not affect actions, budgets, owners, or update cadence. The mitigation is to require every tier to map to a response.

Static risk lock-in occurs when old weights persist after exposure changes or evidence improves. The mitigation is a clear update rule with ownership.

Consequence-scale collapse occurs when unlike harms are forced into a single score. The mitigation is categorical review, separate harm classes, or constraints that override risk-weighted tradeoff.

prose_neighbor_distinctions:
**Uncertainty Explicitness** makes uncertainty visible. Probabilistic Risk Weighting goes further: it uses likelihood and consequence to decide what to do.

**Bayesian Updating** revises beliefs in light of evidence. This archetype may use Bayesian updates, but its defining feature is action weighting.

**Confidence Intervals** communicate statistical uncertainty. They do not by themselves decide which risks deserve resources or escalation.

**Cost–Benefit Framing** compares costs and benefits. Probabilistic Risk Weighting is specifically about uncertain outcomes and likelihood-weighted consequences.

**Risk Aversion Calibration** concerns how actors perceive or over/underweight downside. Probabilistic Risk Weighting provides a structural decision frame that can then be compared against psychological risk posture.

prose_cross_domain_examples:
In safety engineering, a team ranks failure modes by probability and severity, then assigns inspection, redesign, or fail-safe action based on the resulting weight.

In cybersecurity, a vulnerability with modest exploit probability but severe blast radius may outrank a highly visible low-impact issue.

In public health, surveillance resources can be allocated by outbreak likelihood, population vulnerability, expected harm, and update signals from new data.

In project management, schedule risks can be weighted by probability and delay consequence, then mapped to contingency budgets and escalation rules.

In insurance, actuarial estimates combine frequency and severity so reserves, premiums, or inspections match expected exposure.

prose_non_examples:
A list of possible risks is not Probabilistic Risk Weighting unless likelihood, consequence, and response mapping are included.

A single worst-case scenario plan is not this archetype unless it is placed within a broader likelihood–consequence comparison or tail-risk exception rule.

A risk matrix used after decisions are already made is not this archetype; it is documentation theater.

A legal or ethical prohibition is not risk weighting when it blocks action regardless of expected value.

prose_tradeoffs:
The main tradeoff is precision versus usability. A sophisticated model may be accurate but too slow or opaque for action. A qualitative matrix may be usable but too coarse for fine prioritization.

Another tradeoff is expected-value efficiency versus tail-risk protection. Expected value is powerful for ordinary comparable risks, but severe irreversible harms may need special escalation even when their probability is low.

There is also a tradeoff between comparability and moral fidelity. Ranking requires shared scales, but shared scales can hide important differences between money, safety, dignity, trust, and irreversible harm.

prose_invariants_to_preserve:
The core invariant is that likelihood and consequence remain jointly visible. If either side disappears, the pattern collapses into guesswork: probability without consequence becomes trivia, and consequence without probability becomes fear or wishcasting.

The second invariant is action linkage. A risk weight should not stop at a label; it should trigger a response. The third invariant is updateability. Risk estimates are living claims, not permanent truths.

A final invariant is ethical legibility. Consequence scales should make clear who is harmed, who benefits, and which harms cannot be responsibly averaged away.

prose_target_outcomes:
The target outcome is better allocation under uncertainty. High-weight risks receive owners, resources, safeguards, reserves, or redesign attention. Low-weight risks can be monitored or accepted without pretending they are impossible.

A second target outcome is reduced salience bias. Vivid but unlikely scenarios stop dominating planning merely because they are memorable. Frequent losses and severe tail risks become more visible.

A third target outcome is auditability. Future reviewers can see why a risk was ranked, what assumptions supported the estimate, and when the decision should be updated.

prose_parameter_dimensions:
**Probability scale.** The likelihood representation may be qualitative, ordinal, percentage-based, frequency-based, or distributional. More precision is not automatically better; the scale should match the evidence.

**Consequence scale.** Consequences may be monetary, operational, safety-related, reputational, ethical, ecological, or social. When consequences are not commensurable, the weighting rule should keep separate harm categories rather than forcing a single score.

**Weighting rule.** The rule may be simple expected loss, a likelihood-impact matrix, a safety class, an exposure-adjusted score, or a tail-sensitive escalation rule. The rule should be chosen for the decision, not for mathematical convenience.

**Tail-risk threshold.** Low-probability high-consequence events may need special treatment when the downside is catastrophic, irreversible, systemic, or non-compensable.

**Update cadence.** Some weights update after every incident or forecast revision; others update at scheduled review points. The cadence should match the rate at which exposure and evidence change.

**Action thresholds.** The same risk weight can map to different actions in different organizations. Thresholds define when a risk is accepted, monitored, mitigated, escalated, transferred, or redesigned away.

prose_variants_and_near_names:
Expected Loss Prioritization is the variant used when probability and consequence can be placed on a common scale. Tail-Risk Weighting is the candidate variant used when rare severe outcomes need special escalation. Actuarial Risk Weighting uses base rates, cohorts, and exposure patterns. Safety-Case Risk Weighting applies stricter standards in safety-critical contexts.

Near names include Risk Prioritization and Likelihood–Impact Weighting. Risk Matrix, Risk Scoring, Expected Value Calculation, Bayesian Risk Update, and Decision Tree should normally be treated as mechanisms, not separate archetypes.

Expected Loss Prioritization

short_definition: Ranks risks by expected loss or expected value when probability and consequence can be compared on a common scale.

distinctive_feature: The weighting rule is explicitly expected-value-like: likelihood and consequence are combined into a comparable priority measure.

distinct_from_parent: The parent also covers ordinal, qualitative, safety-class, and tail-sensitive weighting rules; this variant narrows to expected-loss comparison.

still_same_parent_because: The intervention still connects likelihood and consequence to action/resource weighting rather than merely calculating a number.

use_when: The consequences can be expressed in a shared unit or defensible scoring scale.

use_when: The decision requires prioritizing limited resources across many risks.

use_when: Rare catastrophic exceptions have been separately reviewed rather than buried in an average.

Probability Estimate

role: Supplies the likelihood term.

Consequence Estimate

role: Supplies the impact term.

Risk Weighting Rule

role: Combines the terms into an expected loss or value.

Expected Value Calculation

role: Computes expected loss or expected gain.

Decision Tree

role: Displays branches, probabilities, and payoffs.

example_domains:
insurance
portfolio planning
operations risk
public-policy triage

domain: Operations

example: Prioritizing maintenance items by expected outage cost.

domain: Security

example: Ranking vulnerabilities by exploit likelihood and business impact.

failure_modes: Treating consequences as comparable when they are ethically or operationally incommensurable.

failure_modes: Hiding low-probability catastrophic events inside a harmless-looking average.

Tail-Risk Weighting

short_definition: Gives special action weight to rare, severe, irreversible, or catastrophic outcomes that expected-value ranking may understate.

distinctive_feature: It adds an exception or escalation rule for the tail of the outcome distribution rather than relying only on average expected loss.

distinct_from_parent: The parent can weight ordinary risks; this variant focuses on preserving attention to extreme downside even when probability is small or uncertain.

still_same_parent_because: It still works by connecting probability, consequence, and action weighting; the distinctive move is the tail-sensitive weighting rule.

use_when: The downside is catastrophic, irreversible, systemic, or ethically non-compensable.

use_when: Low observed frequency may reflect limited data rather than true safety.

use_when: Decision makers would regret treating an extreme event as an ordinary weighted average.

Tail-Risk Exception Rule

role: Overrides ordinary priority ranking when stakes are extreme.

Evidence Quality Note

role: Flags uncertainty about sparse extreme-event data.

Probabilistic Safety Analysis

role: Models rare failure chains.

Scenario Probability Table

role: Keeps severe scenarios visible when a full model is unavailable.

example_domains:
nuclear safety
pandemic planning
financial risk
AI deployment governance

domain: Infrastructure

example: Escalating a rare dam-failure scenario because consequences are catastrophic.

domain: Finance

example: Stress-testing positions whose expected return hides a low-probability ruin path.

failure_modes: Over-escalating every vivid low-probability concern until action becomes impossible.

failure_modes: Using tail risk language to avoid transparent probability and consequence estimation.

Actuarial Risk Weighting

short_definition: Weights risk using base rates, exposure groups, and historical frequency patterns to allocate reserves, safeguards, or prices.

distinctive_feature: The probability estimate is anchored in cohort, exposure, or base-rate reasoning rather than a one-off forecast.

distinct_from_parent: The parent does not require actuarial data; it can use any defensible likelihood representation.

still_same_parent_because: The actuarial model is still used to weight actions by likelihood and consequence.

use_when: Past frequency data and exposure categories are informative enough to support estimation.

use_when: The decision concerns groups, pools, reserves, pricing, inspection, or capacity allocation.

use_when: Individual-case judgment would be noisier or less fair than transparent base-rate use.

Probability Estimate

role: Uses historical or cohort frequency.

Consequence Estimate

role: Estimates expected loss by event category.

Calibration Feedback Signal

role: Checks model estimates against realized outcomes.

Actuarial Risk Model

role: Estimates expected loss for cohorts or pools.

Risk Scoring Model

role: Translates estimates into operational tiers.

example_domains:
insurance
credit risk
public health screening
asset maintenance

domain: Insurance

example: Allocating reserves by exposure class and expected claim severity.

domain: Maintenance

example: Scheduling inspections by historical failure rates and asset criticality.

failure_modes: Encoding historical bias as if it were neutral probability.

failure_modes: Applying group-level estimates to individuals without fairness, consent, or error review.

Safety-Case Risk Weighting

short_definition: Weights uncertain failures by likelihood, severity, detectability, and safety margin in systems where harm prevention dominates ordinary optimization.

distinctive_feature: The weighting rule is embedded in a safety case: acceptable risk, mitigation evidence, residual risk, and escalation thresholds must be documented.

distinct_from_parent: The parent applies broadly; this variant gives safety-critical risks stricter consequence and evidence standards.

still_same_parent_because: It remains a likelihood–consequence-to-action intervention, with stronger safety invariants.

use_when: The decision affects safety-critical systems, clinical harms, infrastructure reliability, or public protection.

use_when: A risk response must satisfy audit, regulatory, or engineering safety expectations.

use_when: The consequence scale includes unacceptable harm categories that cannot be traded away cheaply.

Tail-Risk Exception Rule

role: Protects severe harm categories from being averaged away.

Risk Owner

role: Maintains accountability for residual risk.

Probabilistic Safety Analysis

role: Quantifies failure chains where feasible.

Risk Register

role: Tracks residual risk and mitigation status.

example_domains:
aviation safety
medical-device review
civil infrastructure
industrial operations

domain: Aviation

example: Escalating a rare failure mode because severity and detectability exceed safety thresholds.

domain: Healthcare

example: Prioritizing medication-safety mitigations by likelihood and patient harm severity.

failure_modes: Using a numeric risk score as a substitute for a defensible safety argument.

failure_modes: Treating regulatory checkboxes as if they prove risk acceptability.

near_names:
Risk Prioritization
Risk Scoring
Expected Loss Ranking
Probabilistic Safety Assessment
Likelihood–Impact Weighting


Problem-Distribution Fit Selection

type: archetype

source: generated

batch: Batch 10

canonical_family: Optimization & Constrained Search

source_primes: no_free_lunch_theorem optimization algorithm bias learning distributional_assumption

slug: optimization

slug: algorithm

slug: bias

slug: learning

slug: regularization

slug: overfitting

slug: heuristic

slug: decision

slug: validation

slug: uncertainty

slug: robustness

slug: constraint

slug: representation

slug: stationarity

slug: satisficing

slug: feedback

components:
Method Selection Question
Target Problem Distribution
Method Bias Profile
Assumption Contract
Fit Hypothesis
Representative Benchmark Suite
Challenge Case Suite
Baseline and Alternative Set
Fit Evidence Record
Operating Scope Boundary
Distribution-Shift Sentinel
Retuning or Switching Trigger
Method Portfolio Registry
Stakeholder Tradeoff Statement
Benchmark Refresh Cadence
Domain Expert Review Gate

mechanisms:
Problem Distribution Profile
Method Bias Matrix
Assumption Register
Stratified Benchmark Suite
Challenge Case Red Team
Baseline Comparison Table
Method Card or Model Card
Algorithm Portfolio Router
Regularization Path Review
Out-of-Distribution Monitor
Benchmark Refresh Audit
No-Universal-Winner Claim Review

essence_one_line: Select and tune methods by their fit to the expected problem distribution, because no optimizer, learner, search procedure, or decision rule is best averaged across all possible worlds.

compression_statement: Problem-Distribution Fit Selection applies when a team is comparing methods, models, algorithms, heuristics, policies, or optimization strategies and is tempted to ask which one is best in general. The intervention reframes the question around the operating distribution: what problem instances, noise patterns, constraints, costs, adversaries, objectives, and shifts will the method actually face? It then records each candidate method’s bias and assumption profile, benchmarks candidates against representative and challenge cases, selects or routes methods according to explicit fit evidence, and monitors for distribution drift so a once-useful bias does not become a hidden failure mode.

core_intuition: A method wins by being biased in the right way for the cases it sees. The same simplifying assumption that makes one method powerful in one environment can make it blind in another. The practical answer to no-free-lunch is not method nihilism; it is disciplined context matching.

canonical_formula: method_value(m | D, C, O) = performance(m, D, C, O) - assumption_mismatch_cost(m, D) - monitoring_and_switching_cost; choose or route m only for the distribution D and constraints C where its bias is justified.

structural_problem: A system must choose among search, optimization, inference, or learning procedures while the candidate methods are being compared as if one could dominate across all possible problem instances. Without an explicit problem distribution and bias-fit test, the chosen method may win benchmark theater, overfit to a narrow suite, fail out of distribution, or become a dogma that suppresses better domain-matched alternatives.

trigger_conditions: A team asks which algorithm, model, heuristic, solver, policy, or decision procedure is best without specifying the operating problem class.

trigger_conditions: A method has strong performance in one benchmark, domain, or data regime and is being generalized to a broader environment.

trigger_conditions: Different methods embody different assumptions about smoothness, sparsity, stationarity, independence, convexity, adversarial behavior, noise, or cost structure.

trigger_conditions: The true distribution of cases is narrower than all possible cases but broad enough that naive benchmark selection is risky.

trigger_conditions: The environment may shift, creating a gap between historical fit evidence and future performance.

trigger_conditions: High-stakes deployment requires knowing where a method is not expected to work.

trigger_conditions: A domain uses slogans such as best model, best optimizer, best practice, or universal solution without stating the reference class.

symptoms: Benchmark winners fail in ordinary deployment because the benchmark cases were not representative of the operating distribution.

symptoms: Teams argue over method superiority while silently assuming different problem classes.

symptoms: A simple method outperforms a complex one in one regime and underperforms in another, but the regime boundary is undocumented.

symptoms: A method is chosen for prestige, novelty, or aggregate leaderboard rank rather than fit to the actual task.

symptoms: Regularization, priors, heuristics, feature choices, or solver settings act as hidden biases that are not audited.

symptoms: Distribution shift turns a useful inductive bias into systematic error.

symptoms: Operators keep adding complexity to rescue a method instead of asking whether another method has a better bias for the task.

root_tension: Decision-makers want a general winner, but method performance is conditional on the problem distribution. The intervention must preserve useful specialization while preventing overclaiming, overfitting, and context-blind transfer.

anti_signatures: The main question is whether to use a heuristic or algorithm given stakes, latency, and accountability burden; use Heuristic vs. Algorithm Tradeoff and Selection instead.

anti_signatures: The main task is validating whether a learned pattern transfers outside its fit cases; use Generalization Validation instead.

anti_signatures: The main task is choosing a representation or encoding of the problem before solving; use Representation Fit Selection instead.

anti_signatures: The main task is defining the objective, reward, metric, or KPI being optimized; use Objective Function Alignment instead.

anti_signatures: The main task is selecting the option with acceptable performance across uncertainty scenarios; use Robust Solution Selection instead.

anti_signatures: The main intervention is using a tunable complexity penalty to improve out-of-sample performance; treat Regularization as the more specific archetype or mechanism when that is central.

anti_signatures: There is only one feasible method and no meaningful choice, tuning, routing, or scope decision to make.

anti_signatures: The operating distribution is unknowable and cannot be sampled, bounded, simulated, or monitored enough to justify a fit claim.

structural_intervention: Replace universal-method comparison with explicit problem-distribution matching: define the reference class, describe each candidate method’s bias and assumption profile, test candidates against representative and challenge cases, choose or route methods only for their justified scope, and monitor for drift or mismatch after deployment.

action_logic: State the decision: which method, model, optimizer, heuristic, solver, or policy family is being selected or tuned.

action_logic: Define the target problem distribution, including typical cases, rare but consequential cases, constraints, noise, adversaries, objective structure, and resource limits.

action_logic: Document candidate methods and their bias profiles: what each method assumes, prefers, compresses, ignores, regularizes, searches first, or cannot represent.

action_logic: Translate domain knowledge into explicit fit hypotheses about why a method’s bias should help on this distribution.

action_logic: Build a representative benchmark suite and a challenge suite that cover expected regimes, boundary cases, and known failure zones.

action_logic: Compare methods against baselines, simpler alternatives, incumbent practice, and domain-relevant thresholds rather than only aggregate leaderboard scores.

action_logic: Select, tune, or route methods according to fit evidence, cost, interpretability, robustness, fairness, maintainability, and switching burden.

action_logic: Write an operating scope boundary that says where the method is justified, where it is unknown, and where it should not be used.

action_logic: Install distribution-drift, performance, and assumption-mismatch monitors that can trigger retuning, fallback, portfolio routing, or replacement.

action_logic: Revisit the selection when new cases, incentives, adversarial conditions, or objectives change the problem distribution.

decision_rules: Do not accept claims of universal superiority without a declared reference distribution and evaluation basis.

decision_rules: Prefer the method whose assumptions and bias are best justified for the expected cases, not the method with the best average performance on unrelated cases.

decision_rules: When the operating distribution has multiple stable regimes, route among methods or maintain a method portfolio instead of forcing one global method.

decision_rules: When data are scarce or distributional assumptions are fragile, prefer simpler, assumption-light, robust, or human-review-assisted methods until fit evidence improves.

decision_rules: When a method wins only by exploiting benchmark artifacts, reject the fit claim or redesign the benchmark.

decision_rules: When failure costs are asymmetric, weight challenge cases and tail cases accordingly rather than averaging them away.

decision_rules: Use regularization, priors, constraints, or representation choices as deliberate bias controls, not as opaque tuning rituals.

decision_rules: Escalate to review when drift monitors show the deployed distribution no longer matches the selection evidence.

target_invariants: The operating problem distribution remains explicit and reviewable.

target_invariants: Every candidate method has a documented assumption and bias profile.

target_invariants: Benchmarks include representative, boundary, and challenge cases rather than only convenient cases.

target_invariants: Claims of superiority are scoped to the reference class that was tested or argued.

target_invariants: The selected method’s hidden regularization, priors, objective, representation, and data filters are inspectable enough to audit.

target_invariants: Out-of-distribution behavior and distribution shift are monitored after deployment.

target_invariants: A fallback, retuning, or method-switch path exists when fit evidence fails.

target_invariants: Stakeholders can distinguish method limitations from implementation mistakes.

expected_outcomes: Fewer context-blind transfers of algorithms, models, heuristics, or best practices.

expected_outcomes: More honest method comparisons because performance claims name their reference class.

expected_outcomes: Better out-of-sample performance through deliberate bias and assumption matching.

expected_outcomes: Earlier detection of distribution shift, benchmark overfitting, and hidden assumption failure.

expected_outcomes: Clearer separation between method design, objective design, representation design, and validation work.

expected_outcomes: A more resilient method portfolio when no single approach fits every regime.

expected_outcomes: Reduced prestige-driven or leaderboard-driven method adoption.

Algorithm Portfolio Routing Variant

short_definition: A variant that maintains multiple methods and routes each case to the method whose assumptions best fit the recognized regime.

distinctive_feature: Selection occurs per case or regime rather than once globally.

distinct_from_parent: The parent can select one scoped method; this variant uses a portfolio and routing layer.

still_same_parent_because: The routing rule is still governed by bias-to-distribution fit.

source_primes: algorithm decision optimization

use_when: The problem distribution has distinguishable regimes.

use_when: No single method performs acceptably across regimes.

use_when: The regime recognizer is reliable enough to avoid arbitrary routing.

example: Cases with sparse tabular data use a different model family than unstructured-image cases.

failure_modes: Misclassified regimes, brittle routing thresholds, and portfolio complexity that exceeds monitoring capacity.

Domain-Specific Benchmark Fit Variant

short_definition: A variant focused on designing benchmarks that represent a particular operating domain before selecting a method.

distinctive_feature: Benchmark construction is the main work product.

distinct_from_parent: The parent includes benchmark design as one component; this variant foregrounds benchmark/domain alignment.

still_same_parent_because: Its purpose remains evidence for problem-distribution fit selection.

use_when: Generic benchmarks are available but poorly matched to deployment.

use_when: Domain cases, constraints, or failure costs differ from common benchmark suites.

domain: healthcare

example: A model is evaluated on local patient mix and workflow cases before adoption.

failure_modes: Benchmark overfitting, stale benchmarks, and hidden exclusion of hard cases.

short_definition: A variant that deliberately simplifies or regularizes a method because the expected distribution rewards that bias.

distinctive_feature: The chosen bias is a simplification or penalty rather than a richer method family.

distinct_from_parent: The parent is broader method-distribution selection; this variant narrows to selecting a simplicity or penalty bias.

still_same_parent_because: The simplification is justified by target-distribution fit rather than by universal simplicity alone.

source_primes: bias regularization overfitting

use_when: High-capacity methods overfit or chase noise.

use_when: A simpler bias is known to match the domain better than flexible fitting.

domain: statistics

example: A penalized model is preferred when sparse effects are plausible and unpenalized fitting overfits.

failure_modes: Underfitting, false simplicity, and hiding policy choices in penalty weights.

near_names:
No Free Lunch Theorem
No-Free-Lunch Guardrail
NFL Guardrail
Assumption-Matched Method Selection
Method–Problem Fit Selection
Inductive Bias Alignment


Problem Space Mapping

batch: First Iteration/Batch 36

Problem Landscape Mapping

notes: Useful when the space is understood as a landscape of paths, barriers, high-potential regions, and dead ends.

Possibility Mapping

notes: Search-friendly phrase for mapping possible states, moves, and branches.

Problem Space Map

notes: Artifact noun form often used for the resulting map.

Solution Landscape Mapping

notes: Near name when the map emphasizes possible solution regions; distinguish from solution-space bounding and search-space pruning.

Option Space Mapping

notes: A narrower near name when the map centers options and paths; keep under this parent unless selection or pruning is the real intervention.

slug: boundary

components:
Initial State
Goal State
Action Set
Constraint Set
State Transition Map
Search Boundary
Unexplored Region
Exploration Strategy
Map Validation Loop
Stakeholder Perspective Layer
Dead-End and Trap Marker
Evidence Gap Marker
Representation Choice Rationale

mechanisms:
State / Action Map
Design Space Map
Decision Tree
Search Space Diagram
Option Map
Diagnostic Possibility Map
Strategic Option Map
Constraint Matrix
Unknowns and Assumptions Register

essence_one_line: Map the states, actions, constraints, and goals of a problem so exploration becomes deliberate rather than ad hoc.

compression_statement: When a problem feels vague, overwhelming, or prematurely narrowed, Problem Space Mapping externalizes the possible states, actions, constraints, paths, dead ends, goals, boundaries, and unexplored regions so people can reason about where they are, where they could go, and how to explore before choosing or pruning.

core_intuition: People often fail not because they lack effort, but because the shape of the problem is invisible. A map turns a foggy challenge into a navigable structure: current state, target state, available moves, blocked moves, unknown regions, and possible paths. Once that structure exists, the team can explore, test, narrow, or revise intentionally instead of reacting to whichever option is most salient.

canonical_formula: vague_problem + implicit_possibility_space → initial_state + goal_state + action_set + constraints + search_boundary + unexplored_regions → exploration_strategy → validated_problem_space_map → deliberate_next_moves

structural_problem: Actors cannot reason clearly because the possible states, moves, constraints, goals, dependencies, and unexplored regions of the problem are implicit, scattered, contested, or poorly organized. The problem may look like a single question, a list of options, or a conflict of opinions, when it is actually a space of possible positions and transitions that must be made visible before intelligent exploration can occur.

condition: The problem feels vague, large, or overwhelming.

why_it_matters: A map can convert undifferentiated complexity into states, actions, constraints, and regions that can be inspected separately.

condition: The team is debating solutions before agreeing on the shape of the problem.

why_it_matters: Premature solution debate often hides disagreement about starting conditions, goals, constraints, or possible paths.

condition: Options are listed but not related to prerequisites, consequences, or downstream states.

why_it_matters: An option list does not explain where each move can lead or what it blocks.

condition: Exploration keeps returning to familiar moves or local fixes.

why_it_matters: The visible part of the problem space may be too narrow, making unexplored regions easy to ignore.

condition: Constraints are invoked inconsistently or treated as obvious.

why_it_matters: Constraint visibility helps distinguish hard limits, soft limits, assumptions, and challengeable boundaries.

condition: Different actors perceive different possible moves.

why_it_matters: Divergent perceptions may indicate that each actor sees only part of the problem space.

symptom: People ask, “What are we even solving?” after many rounds of discussion.

interpretation: The initial state, goal state, or boundary of the problem is not yet stable enough to support solution work.

symptom: Teams cycle through the same options without learning.

interpretation: The exploration strategy may be missing; options are being revisited rather than positioned within a navigable space.

symptom: Important paths appear late and surprise the group.

interpretation: Unexplored regions were not marked early, so the map falsely appeared complete.

symptom: One representation dominates thinking even when it excludes relevant constraints.

interpretation: The map may need a different representation or an explicit representation-choice rationale.

symptom: Implementation fails because downstream states were not anticipated.

interpretation: The state transition effects of actions were not mapped before commitment.

symptom: Stakeholders reject a plan because it solved a different problem than the one they inhabit.

interpretation: The map may lack stakeholder-specific positions, constraints, or action possibilities.

root_tension: Problem solving requires focus, but focusing too early can erase the shape of the space being navigated. The intervention must make enough of the possible space visible to guide exploration while avoiding infinite mapping, analysis paralysis, or false certainty from a neat but incomplete diagram.

condition: The possible space is already well mapped and the issue is eliminating poor candidates.

why_not: Use Search Space Pruning, Solution Space Bounding, or Progressive Narrowing rather than re-mapping.

condition: The problem is a formal dynamic system where trajectories in mathematical phase space are the central object.

why_not: Use Phase-Space Mapping or a domain-specific modeling method; Problem Space Mapping here centers human problem-solving intelligibility.

condition: The main need is to choose the best representation for a known task.

why_not: Use Representation Fit Selection; Problem Space Mapping may use a representation but is not only representation choice.

condition: The main barrier is cognitive overload from presentation, instructions, or workflow.

why_not: Use Cognitive Load Reduction unless the missing piece is the possibility structure of the problem itself.

condition: The actors lack authority, resources, or permission to act within any mapped path.

why_not: Mapping may clarify the barrier, but the solution requires governance, resource allocation, or empowerment.

structural_intervention: Externalize the implicit problem space by defining the initial state, goal state or target region, feasible and candidate actions, constraints, search boundaries, path dependencies, unexplored regions, and a strategy for exploring the map. Validate and revise the map as evidence, stakeholder input, or experiments reveal missing states, false constraints, or better paths.

logic: State the mapping purpose: design, diagnosis, strategy, learning, troubleshooting, policy, or another problem-solving task.

logic: Define the initial state: what is currently true, known, available, blocked, uncertain, and in scope.

logic: Define the goal state, target region, or acceptable outcomes, including unresolved goal tensions if they exist.

logic: List possible actions, inquiries, tests, design moves, policy moves, or transitions that could change the state.

logic: Map constraints and boundaries, separating hard limits from soft limits, assumptions, preferences, dependencies, and unknowns.

logic: Represent relationships among states, actions, constraints, paths, dead ends, and unexplored regions in a map, matrix, graph, tree, landscape, or layered artifact.

logic: Choose an exploration strategy: broad scan, targeted branch testing, coarse-to-fine exploration, constraint-first mapping, stakeholder-specific mapping, or staged narrowing after exploration.

logic: Validate the map against evidence, user/stakeholder experience, domain expertise, edge cases, experiments, or failed predictions, then revise the map before using it for selection or commitment.

rule: Map before pruning when the possible space is not yet understood.

rationale: Pruning before mapping can eliminate unseen paths or reinforce the current frame.

rule: Represent unexplored regions explicitly.

rationale: A map that hides its unknowns creates false completeness and premature confidence.

rule: Separate constraints from assumptions.

rationale: Teams often treat assumptions as constraints; making the difference visible can reopen feasible paths.

rule: Choose a representation that fits the reasoning task.

rationale: Trees, matrices, graphs, maps, canvases, and tables reveal different structures and hide different structures.

rule: Update the map when actions change the state.

rationale: A problem space is not static once interventions, tests, or stakeholder moves alter conditions.

rule: Stop mapping when the map is sufficient for the next decision or exploration move.

rationale: The archetype supports action; endless mapping becomes avoidance.

invariant: Initial conditions are visible.

why_it_must_hold: Without the starting state, paths and action feasibility cannot be interpreted.

invariant: Target outcomes or goal tensions are explicit.

why_it_must_hold: Exploration without a target cannot distinguish useful paths from irrelevant paths.

invariant: Actions are connected to state changes.

why_it_must_hold: A map of options is incomplete if it does not show what moves do.

invariant: Constraints and assumptions are distinguishable.

why_it_must_hold: This prevents the map from freezing challengeable beliefs as fixed boundaries.

invariant: Unexplored regions remain marked.

why_it_must_hold: This preserves humility and prevents false completeness.

invariant: The map remains usable for the people doing the problem-solving.

why_it_must_hold: A technically elegant map that humans cannot use fails the cognitive intervention.

outcome: Clearer shared understanding of the problem structure.

signal: Participants can identify current state, target state, possible moves, constraints, and unknown regions without relying on implicit memory.

outcome: Better option discovery.

signal: Previously hidden paths, neglected alternatives, or challengeable constraints become visible.

outcome: More deliberate exploration.

signal: The team can explain why it is exploring a region, testing a branch, or deferring a path.

outcome: Reduced premature convergence.

signal: The group postpones pruning or commitment until the relevant space is sufficiently represented.

outcome: Improved communication across roles.

signal: Different actors can point to where their constraints, moves, and goals sit in the shared space.

outcome: Better transition to selection, pruning, or implementation.

signal: Subsequent narrowing or commitment uses the map rather than starting from isolated preferences.

prose_essence:
Problem Space Mapping is the intervention of turning an implicit or overwhelming problem into a navigable possibility structure. It names where the actor starts, where they might be trying to go, what moves are available, what constraints shape those moves, what regions have not yet been explored, and how the space should be traversed.

The key move is not to solve the problem immediately. The key move is to make the problem's shape visible enough that later solving, pruning, narrowing, testing, or implementation can be deliberate. A good problem-space map gives people a shared object they can inspect: “Here is where we are, here is where we could go, here is what blocks or enables movement, and here is what we still have not looked at.”

prose_when_to_use:
Use this archetype when a group is stuck because the possible moves are implicit, scattered, or prematurely narrowed. It is especially useful when people are debating solutions before they agree on the starting conditions, target outcomes, constraints, or available actions.

Use it in design, diagnosis, strategy, learning, troubleshooting, service design, policy work, and complex problem-solving where the problem is better understood as a landscape or graph of states and moves than as a single isolated question.

Do not use it as decorative diagramming. If the only need is to eliminate bad options from an already known space, use a pruning or narrowing archetype instead. If the main issue is that the task is too cognitively burdensome, use Cognitive Load Reduction. If the main issue is choosing the best representation for known content, use Representation Fit Selection.

prose_structural_problem:
The structural problem is invisible possibility structure. Actors may have facts, opinions, constraints, and proposed solutions, but they do not yet have a shared map of the space in which those elements relate.

Several things can be unclear at once: the current state, the target state, what counts as a valid move, which constraints are fixed, which constraints are assumptions, what paths lead to dead ends, and which regions of the space have never been inspected. Without that structure, exploration becomes reactive. The group tends to revisit familiar options, debate preferred answers, or treat the first visible path as the whole problem.

prose_intervention_logic:
The intervention starts by defining the mapping purpose. A diagnostic map, a design-space map, and a strategy map all need different representational choices, even though they share the same archetype.

Next, define the initial state and goal state. The initial state captures the current facts, resources, constraints, uncertainties, and actor position. The goal state defines the target outcome or acceptable target region. Then identify the action set: the moves, tests, inquiries, design changes, policy changes, or decisions that could move the system from one state toward another.

After that, map constraints and boundaries. Separate hard constraints from soft limits, preferences, assumptions, unknowns, and governance boundaries. Then represent relationships among states, actions, paths, constraints, dead ends, and unexplored regions. Finally, choose an exploration strategy and validate the map against evidence, domain expertise, stakeholder experience, and experiments.

prose_key_components:
- **Initial State** (`initial_state`): Defines where the problem-solving effort starts, including current conditions, known facts, available resources, and current constraints. Without this, the map floats free of the real situation.
- **Goal State** (`goal_state`): Specifies the desired end condition or acceptable target region. This keeps exploration oriented by outcome rather than activity.
- **Action Set** (`action_set`): Lists the moves, interventions, tests, decisions, or inquiries that can transform the current state. This distinguishes possible movement from passive description.
- **Constraint Set** (`constraint_set`): Captures hard constraints, soft constraints, dependencies, prohibitions, resources, timing limits, and governance rules. It also helps reveal assumptions that have been mistaken for constraints.
- **State Transition Map** (`state_transition_map`): Shows how actions connect states and what changes after a move. This is what turns a list into a navigable structure.
- **Search Boundary** (`search_boundary`): Defines what part of the space is currently in scope, out of scope, deferred, unknown, or outside authority.
- **Unexplored Region** (`unexplored_region`): Marks plausible but uninspected areas. This preserves humility and prevents false completeness.
- **Exploration Strategy** (`exploration_strategy`): Defines how the mapped space will be traversed: broad scan, targeted inquiry, coarse-to-fine exploration, stakeholder-specific mapping, test-first exploration, or staged narrowing.
- **Map Validation Loop** (`map_validation_loop`): Checks the map against evidence and experience so it remains a working model rather than a frozen diagram.

prose_common_mechanisms:
A **state/action map** implements the archetype by representing states as nodes or regions and actions as transitions. It is useful when the path effects of moves matter.

A **design space map** implements the archetype in design contexts by showing dimensions, option combinations, constraints, and tradeoff regions. It should not be confused with a portfolio of favored concepts.

A **decision tree** can implement part of the archetype when branching conditions are stable, but it can fail when the space contains cycles, soft constraints, unknown regions, or changing conditions.

A **search space diagram** helps show candidate regions, excluded zones, and search directions. It remains a mechanism here; formal search-space pruning is a different archetype.

An **option map** groups alternatives by relevant dimensions and dependencies. It becomes a problem-space mechanism only when connected to initial state, goal state, actions, constraints, and unexplored regions.

A **diagnostic possibility map** represents plausible causes, tests, findings, exclusions, and next diagnostic moves. It implements the archetype in diagnosis and troubleshooting.

A **strategic option map** represents strategic paths, resource dependencies, commitment points, and alternative target states.

A **constraint matrix** cross-references options, states, or paths against constraints. It is a mechanism for making feasibility structure visible.

An **unknowns and assumptions register** keeps track of uncertain facts and unverified assumptions so the map does not present guesses as settled structure.

prose_failure_modes:
Common failure modes include decorative mapping, false completeness, premature pruning disguised as mapping, representation traps, analysis paralysis, stakeholder erasure, and static-map decay.

Decorative mapping happens when the artifact looks structured but does not guide action. False completeness happens when unexplored regions and evidence gaps are missing. Premature pruning happens when only favored options appear. Representation traps occur when the chosen format hides important paths. Analysis paralysis appears when mapping never transitions to action. Stakeholder erasure occurs when the map reflects only one actor's view. Static-map decay occurs when the problem changes but the map does not.

prose_neighbor_distinctions:
Problem Space Mapping is distinct from **Phase-Space Mapping**, which models formal system trajectories. It is distinct from **Solution Space Bounding**, which makes a huge solution space finite enough to search. It is distinct from **Search Space Pruning**, which removes regions judged low-value or impossible. It is distinct from **Progressive Narrowing**, which converges from broad options toward a stable choice.

It is also distinct from **Representation Fit Selection**. This archetype may require choosing a representation, but the core intervention is not representation choice; it is externalizing the possibility structure of a problem. It is adjacent to **Cognitive Representation Externalization**, but it is more specific: the externalized representation must include problem states, actions, constraints, goals, unexplored regions, and exploration implications.

prose_cross_domain_examples:
In **product design**, a team maps user states, possible feature moves, regulatory constraints, technical dependencies, and unexplored user segments before selecting a roadmap.

In **diagnosis**, a team maps plausible causes, tests, exclusions, constraints, and next inquiry moves before locking onto the first explanation.

In **organizational strategy**, leaders map current capabilities, target positions, investment paths, policy constraints, dead ends, and untested assumptions before choosing a major initiative.

In **education**, an instructor maps novice starting states, misconception branches, practice actions, and target understanding states before designing support.

In **public service design**, a team maps applicant states, eligibility rules, required documents, exception paths, waiting states, and failure points before redesigning intake.

prose_non_examples: A brainstorm board full of unrelated ideas is not Problem Space Mapping. A two-by-two matrix used only for presentation is not Problem Space Mapping. A decision tree that mechanically routes cases through fixed rules is not necessarily Problem Space Mapping. A mathematical phase portrait is not this archetype unless the purpose is human problem-solving navigation rather than formal dynamical modeling. A voting exercise that narrows options is not mapping; it is a convergence or selection mechanism.

prose_tradeoffs:
The major tradeoff is completeness versus action speed. More mapping may reveal hidden paths, but excessive mapping can become avoidance. A shared map improves coordination but may flatten local nuance. A clear representation helps people reason, but every representation hides some structure.

The archetype also balances exploration openness against decision closure. Keeping unexplored regions visible is valuable, but the team still needs thresholds for when to test, narrow, decide, or stop.

prose_invariants_to_preserve:
The initial state must remain visible. The target state or goal tension must remain explicit. Actions must connect to state changes rather than appear as isolated ideas. Constraints must be separated from assumptions. Unexplored regions must remain marked. The representation must remain usable for the people doing the problem-solving.

Most importantly, the map must remain a working model. It should be clear enough to guide action and humble enough to invite revision.

prose_target_outcomes:
The target outcomes are clearer shared understanding, better option discovery, more deliberate exploration, reduced premature convergence, improved communication across roles, and a stronger transition into later selection, pruning, experimentation, or implementation.

A successful draft of the map lets people explain not only which option they prefer, but where that option sits in the space, what it assumes, which constraints it faces, what paths it opens or blocks, and what remains unknown.

prose_parameter_dimensions:
Tune the archetype by scope, resolution, representation, stakeholder coverage, uncertainty marking, and stop rule.

A broader scope reveals more of the space but can slow action. A narrower scope supports immediate progress but may hide important paths. High resolution helps where details matter, while low resolution supports early orientation. Graphs, trees, matrices, maps, canvases, and tables all reveal different structures, so representation choice should match the reasoning task.

Stakeholder coverage matters when different actors inhabit different parts of the space. Uncertainty marking matters when the map contains assumptions, unverified constraints, or missing evidence. Finally, the map needs a stop rule: it is sufficient when it supports the next exploration, test, decision, or narrowing move.

prose_variants_and_near_names:
Recognized variants include state/action problem maps, design space mapping, diagnostic possibility mapping, strategic option space mapping, and learning problem space mapping.

Near names include problem landscape mapping, possibility mapping, problem space map, solution landscape mapping, and option space mapping. Mechanism names such as decision tree, option map, design-space map, and diagnostic possibility map should not be promoted automatically. They are ways of implementing or specializing the archetype.

State / Action Problem Map

variant_type: subtype

short_definition: A variant that makes the problem space explicit as a set of states connected by possible actions or transitions.

distinctive_feature: It emphasizes state transitions rather than option comparison alone.

distinct_from_parent: The parent can use trees, matrices, landscapes, canvases, or layered diagrams; this variant specifically models states and actions as connected structure.

still_same_parent_because: It still serves the parent logic of making human problem exploration deliberate through explicit states, actions, constraints, and goals.

condition: The central difficulty is understanding what moves can be made from the current state.

condition: Different actions unlock or block later states, creating path-dependent reasoning.

domain: operations

example: A team maps current queue states, available interventions, and resulting downstream states before redesigning a workflow.

domain: learning

example: A teacher maps possible student misconceptions and instructional moves so remediation is not improvised case by case.

failure_mode: Static state list

cause: States are listed without transitions or action implications.

mitigation: Add actions, prerequisites, and transition consequences.

Design Space Mapping

short_definition: A design-oriented variant that maps possible design dimensions, option combinations, constraints, and tradeoff regions.

distinctive_feature: It treats the problem space as combinations of design variables and constraints.

distinct_from_parent: The parent applies beyond design; this variant specifically organizes design alternatives and parameter combinations.

still_same_parent_because: It still maps possible states, moves, constraints, and unexplored regions for deliberate human exploration.

source_primes: problem_space constraint representation

condition: A design team is prematurely converging on one proposal without seeing the range of possible configurations.

condition: Important design variables interact, making one-dimensional option lists misleading.

domain: service design

example: A team maps service-channel options, eligibility constraints, staffing models, and failure points before selecting a service model.

failure_mode: Portfolio masquerading as space

cause: Only favored options are displayed.

mitigation: Add excluded, unexplored, and challengeable regions.

Diagnostic Possibility Mapping

short_definition: A diagnostic variant that maps plausible causes, evidence, tests, exclusions, and next inquiry moves.

distinctive_feature: It maps the problem space as competing explanations and evidence-linked next moves.

distinct_from_parent: The parent covers many kinds of problems; this variant focuses on diagnostic search and causal possibility.

still_same_parent_because: It remains a map of human exploration states, actions, constraints, goals, and unexamined regions.

condition: The team risks locking onto the first plausible diagnosis or cause.

condition: Different tests or observations would eliminate or open different branches of inquiry.

domain: incident response

example: Responders map possible failure causes, confirming tests, exclusion criteria, and recovery moves before blaming one subsystem.

failure_mode: Speculative cloud

cause: Possibilities are listed without tests, evidence, or next moves.

mitigation: Tie each branch to observations, tests, and exclusion rules.

Strategic Option Space Mapping

short_definition: A strategy variant that maps possible strategic paths, resource dependencies, constraints, and alternative target states.

distinctive_feature: It emphasizes path options and strategic dependencies rather than operational task steps.

distinct_from_parent: The parent includes learning, design, diagnosis, and other problem contexts; this variant applies the map to strategy formation.

still_same_parent_because: It still externalizes the possible states, moves, constraints, and unexplored regions of a problem space.

condition: A plan is being treated as the only available strategy.

condition: Strategic choices depend on sequencing, resource gates, competitive moves, or changing constraints.

domain: organizational change

example: Leaders map change paths, resistance points, dependencies, and alternative end states before committing to one rollout.

failure_mode: Plan rationalization

cause: The map is built around justifying the preferred plan.

mitigation: Require unexplored regions, dead ends, and at least one credible alternative path.

Learning Problem Space Mapping

short_definition: A learning-oriented variant that maps concepts, misconceptions, practice moves, prerequisites, and target understandings.

distinctive_feature: It uses the map to support learning and transfer rather than immediate operational choice.

distinct_from_parent: The parent is broader; this variant is tuned to instruction, misconceptions, and conceptual navigation.

still_same_parent_because: It still maps starting states, goal states, actions, constraints, and unexplored conceptual regions.

condition: Learners do not know what conceptual moves are possible or why certain solution paths fail.

condition: Instruction needs to reveal the landscape of possible approaches without overloading learners.

example_domains: education training onboarding

domain: training

example: An onboarding program maps common novice states, practice actions, misconceptions, and target competence states.

failure_mode: Map overload

cause: The instructional map shows the entire space before learners have prerequisites.

mitigation: Combine with cognitive load reduction or staged reveal.

near_names:
Problem Landscape Mapping
Option Space Mapping
Possibility Map
State/Action Mapping
Solution Landscape Mapping
Problem Space Map