Parameter Rescaling

batch: First Iteration/Batch 28

related_primes: representation correspondence_principle invariance approximation dimension proportionality adaptation stationarity

Renormalization

slug: renormalization

role: Motivates changing parameters across scales while preserving relevant behavior.

Scale

slug: scale

role: Defines the source and target levels between which direct parameter transfer becomes unsafe.

Dimensional Analysis

role: Supports unit, denominator, and proportionality checks during parameter transformation.

Representation

slug: representation

role: Rescaling changes how quantities are represented at a target scale.

Correspondence Principle

role: The target-scale parameter should correspond to source-scale behavior where the scales overlap.

Invariance

slug: invariance

role: The draft asks what behavior or decision boundary should remain invariant after rescaling.

Approximation

slug: approximation

role: Some mappings are approximate and must state their tolerance and validation range.

Dimension

slug: dimension

role: Parameters often depend on dimensional units, denominators, rates, or resolution.

Proportionality

slug: proportionality

role: Some scale transfers preserve ratios or proportional relationships rather than raw values.

Adaptation

slug: adaptation

role: Rescaled parameters may need later adjustment when target-scale conditions change.

Stationarity

slug: stationarity

role: Validation asks whether relationships remain stable enough for the rescaled value to stay meaningful.

essence_one_line: Adjust parameters when moving between scales so the model or rule preserves behavior at the new level.

compression_statement: When a parameter, threshold, metric, baseline, or rule works at one scale but becomes misleading at another, explicitly define the scale shift, map the value into the target context, recalibrate it, and validate that the behavior or decision effect is preserved.

core_intuition: Numbers are not portable by default. A value that means one thing for one unit, resolution, population, or time horizon can mean something else at another scale. Parameter Rescaling keeps the useful behavior of the original value while changing the numeric expression needed at the new scale.

canonical_formula: source_scale_parameter + scale_shift + parameter_mapping + recalibration_rule + behavior_preservation_test -> target_scale_parameter

structural_problem: A parameter, threshold, metric, baseline, or rule is copied from one scale to another even though its meaning depends on unit size, population, time horizon, aggregation level, model resolution, interaction density, or operating context. The raw value may look precise while producing the wrong behavior at the target scale.

condition: A model, rule, metric, threshold, or allocation formula is being moved from a source scale to a target scale.

condition: The target unit differs in size, time window, density, exposure, resolution, complexity, or interaction pattern.

condition: Raw totals, rates, ratios, or thresholds are being compared across units that are not directly comparable.

condition: A pilot, prototype, local rule, or small-scale model is being generalized to a larger or differently structured context.

condition: The model or rule must preserve a behavior, decision boundary, load level, risk level, or effect rather than preserve a literal numeric value.

symptom: Scale-transfer error

interpretation: A value valid in one setting produces overreaction, underreaction, unfairness, overload, or weak effect in another.

symptom: Misleading comparability

interpretation: Units are compared by raw totals or raw thresholds even though their denominators, exposure, or case mix differ.

symptom: False precision after aggregation

interpretation: The rescaled value appears authoritative because it has a number, but the mapping assumptions were never tested.

symptom: Pilot-to-scale failure

interpretation: A rule that worked locally changes behavior when expanded because population, incentives, or load changed.

symptom: Boundary drift

interpretation: A threshold or metric slowly changes meaning because the unit, time window, or measurement basis has shifted.

root_tension: The intervention must change the numerical value enough to fit the target scale while preserving the behavior, comparison, constraint, or decision effect that made the source value useful.

condition: The only task is to choose which scale to model, with no scale-sensitive parameter or rule value to transform.

condition: The source and target contexts are dimensionally identical and validation shows direct transfer is safe.

condition: The problem is ordinary optimization or parameter tuning within a fixed scale.

condition: The main issue is missing data quality, not scale-dependent parameter meaning.

condition: The needed intervention is a whole-system transition plan rather than recalibration of parameters, thresholds, metrics, or rule values.

structural_intervention: Transform the source-scale parameter into a target-scale parameter by naming the scale shift, identifying what behavior should be preserved, constructing a mapping or normalization basis, recalibrating the value, and validating it within explicit limits.

logic: Identify the source parameter, threshold, metric, baseline, or rule value and document the context where it currently works.

logic: Define the target scale and the differences that make direct transfer unsafe, such as unit size, time horizon, resolution, exposure, or interaction density.

logic: State the behavior, constraint, decision boundary, comparison, or effect that must be preserved after rescaling.

logic: Choose a mapping logic: proportional adjustment, dimensional transformation, normalization basis, empirical recalibration, benchmark rebasing, or model-derived transformation.

logic: Apply a recalibration rule that produces a target-scale value and records assumptions.

logic: Check dimensional consistency so totals, rates, denominators, time windows, and units are not mixed.

logic: Validate target-scale behavior against data, simulations, pilots, reference cases, sensitivity bands, or expert review.

logic: Define comparability limits, validation windows, and recalibration triggers so the rescaled value is not overextended.

rule: Rescale for the behavior to be preserved, not for numerical resemblance to the source value.

rule: Do not compare values across scales until units, denominators, time bases, and exposure bases are made explicit.

rule: Use a simpler proportional mapping only when sensitivity checks show that nonlinear or interaction effects are not decision-critical.

rule: When fixed costs, thresholds, network effects, or subgroup differences matter, avoid naive per-unit normalization.

rule: Treat the rescaled value as valid only inside its documented validation window and comparability limits.

rule: If validation shows changed behavior, revise the mapping rather than forcing the source-scale value onto the target scale.

invariant: Behavioral effect

description: The practical effect produced by the parameter remains equivalent or acceptable at the target scale.

invariant: Decision boundary meaning

description: Thresholds and cutoffs continue to trigger the intended action at the intended risk or load level.

invariant: Dimensional meaning

description: Units, denominators, rates, and time windows remain interpretable after the transformation.

invariant: Comparability basis

description: Cross-unit comparisons reflect scale-adjusted meaning rather than raw size differences.

invariant: Validation traceability

description: Users can see how the target-scale value was derived and where it is valid.

outcome: Valid cross-scale transfer

description: Rules, metrics, or models can move between scales without silently changing meaning.

outcome: Reduced scale bias

description: Large, small, dense, sparse, local, and aggregate units are not judged by raw values that favor one scale.

outcome: Improved model or policy fit

description: Target-scale behavior more closely matches the intended behavior from the source scale.

outcome: Clearer comparability

description: Stakeholders can tell when comparisons are fair and when they exceed the mapping limits.

outcome: Safer scaling decisions

description: Pilot, prototype, or local rules are adjusted before broader use rather than copied directly.

prose_essence:
Parameter Rescaling is the intervention pattern for situations where a value that worked at one scale stops meaning the same thing at another. The value might be a model coefficient, alert threshold, staffing ratio, policy formula, performance metric, benchmark, capacity rule, or budget assumption. The archetype does not merely convert units. It asks what behavior the original value preserved, how the source and target scales differ, what transformation is needed, and whether the target-scale value still produces the intended effect.

A useful shorthand is: **do not copy the number; preserve the behavior.**

prose_when_to_use:
Use this archetype when a parameter, threshold, metric, baseline, or rule is being moved across a scale boundary. Common triggers include moving from pilot to rollout, local to regional, individual to population, component to system, fine-resolution model to coarse-resolution model, short time window to long time window, or raw totals to comparable rates.

It is especially useful when stakeholders are tempted to reuse a familiar value because it is convenient. A team-level queue threshold, a site-level budget ratio, a model coefficient, or a pilot policy rule may be valid in its original setting but misleading after aggregation, expansion, or resolution change.

prose_structural_problem:
The structural problem is scale-dependent meaning. A value carries assumptions about unit size, exposure, density, resolution, time horizon, interaction pattern, fixed cost, and measurement basis. When those assumptions change, the same number can create a different effect. It may trigger too early or too late, rank units unfairly, make a model unstable, hide fixed costs, or make a pilot look transferable when it is not.

The dangerous part is that the bad value often still looks precise. The failure is not that the parameter is missing; the failure is that its original meaning was silently carried into a context where it no longer applies.

prose_intervention_logic:
The intervention begins by naming the source-scale parameter and the target-scale context. Then it states what must be preserved: a risk level, load response, comparison basis, model behavior, policy effect, constraint, or decision boundary. Only after that does it choose a mapping. The mapping might be proportional, dimensional, empirical, nonlinear, denominator-based, benchmark-based, or model-derived.

After producing the target-scale value, the archetype requires validation. The value should be checked for dimensional consistency and, more importantly, for behavioral correspondence. A target value that is arithmetically tidy but produces the wrong action is not a successful rescaling.

prose_key_components:
### Scale Shift

Defines the move from the source scale to the target scale where the parameter, threshold, metric, or rule must operate. The scale shift may involve unit size, population size, time horizon, spatial extent, organizational level, model resolution, sampling density, or operating regime. Without a named scale shift, rescaling becomes ordinary tuning.

### Source-Scale Parameter

Names the parameter, threshold, metric, coefficient, rate, budget, or rule value that works at the original scale. The source parameter should include its original units, assumptions, calibration context, and behavior it helped preserve. This prevents raw values from being copied without context.

### Target-Scale Context

Specifies the scale, units, population, time frame, resolution, or operating conditions where the parameter will be used after rescaling. The target context is not only larger or smaller. It may have different interaction density, exposure, variability, incentives, uncertainty, or measurement noise.

### Parameter Mapping

Defines how the source-scale value transforms into a target-scale value. The mapping may be proportional, nonlinear, dimensional, empirical, rule-based, or model-derived. It should state what is being preserved rather than merely producing a new number.

### Recalibration Rule

Operationalizes the mapping as a repeatable rule for updating the parameter at the target scale. A recalibration rule can be a formula, lookup table, adjustment procedure, benchmark rule, or decision protocol. It should be auditable and updateable when conditions change.

### Dimensional Consistency Check

Checks that units, denominators, rates, time bases, and reference quantities remain meaningful after the scale change. Many rescaling failures are hidden unit errors: totals are compared to rates, per-person values are treated as aggregate values, short-horizon thresholds are applied to long-horizon systems, or measurement bases quietly change.

### Behavior Preservation Test

Tests whether the rescaled parameter preserves the behavior, decision boundary, constraint, or practical effect that mattered at the source scale. The test should be expressed in behavior terms, not just numerical closeness. A value can be dimensionally correct but behaviorally wrong if it changes incentives, risk, load, or response timing.

### Validation Window

Defines where and for how long the rescaled value is considered valid before it must be retested. A validation window protects against overgeneralizing the rescaled value. It can be temporal, spatial, statistical, operational, jurisdictional, or scenario-based.

### Optional Supporting Components

### Normalization Basis

Provides the denominator, reference unit, exposure basis, or comparison basis used to make quantities comparable across scales. Examples include per capita, per unit area, per transaction, per machine-hour, per exposure, per team, per dollar, or per time window. The basis must match the behavior being preserved.

### Reference Case Anchor

Anchors the transformation to a known case, benchmark, baseline, calibration scenario, or validated operating point. A reference case keeps rescaling from becoming arbitrary. It also helps reviewers understand what the target-scale value is supposed to reproduce.

### Sensitivity Band

Defines a range over which the rescaled parameter can vary without changing the target decision or behavior unacceptably. Sensitivity bands are useful when the mapping is approximate, data are limited, or the target scale has uncertainty. They prevent false precision.

### Baseline Rebasing Rule

Updates comparison baselines after scale, context, or measurement basis changes so performance judgments remain meaningful. This absorbs much of the deferred Batch 028 candidate renormalized_baseline_tracking as a component rather than a separate first-wave archetype.

### Assumption Log

Records assumptions used in the mapping, including which interactions, distributions, boundary effects, and contextual differences are being ignored or approximated. Parameter rescaling is often fragile when assumptions are implicit. The assumption log supports later review, rollback, or refinement.

### Rollback or Recalibration Trigger

Specifies signals that the rescaled value is no longer valid and must be revised, replaced, or returned to the source-scale rule. Triggers can include drift, threshold misses, unexpected residuals, safety incidents, capacity saturation, fairness concerns, or evidence that the target scale has changed regime.

### Comparability Limit

States where comparisons using the rescaled parameter are no longer valid. Comparability limits prevent users from extending a rescaled value beyond its calibration range, jurisdiction, population, time horizon, model resolution, or operating assumptions.

prose_common_mechanisms:
Mechanisms implement the archetype, but they are not the archetype by themselves. A normalized metric, a dimensional-analysis table, or a threshold adjustment only becomes Parameter Rescaling when it is tied to a named scale shift, a mapping rationale, and a test of preserved behavior.

### Unit Normalization

This is a **method** for implementing Parameter Rescaling. Converts or normalizes values into comparable units before applying the scale transformation. Unit normalization supports the archetype but does not complete it; behavior preservation still needs to be checked. It should not be treated as the archetype by itself unless the scale shift, mapping, recalibration rule, and behavior-preservation test are explicit.

### Per-Capita Scaling

This is a **metric_or_dashboard** for implementing Parameter Rescaling. Expresses aggregate values relative to population size when population is the relevant exposure basis. This mechanism is useful for population-scale comparison, but it can mislead when interaction density, subgroup risk, or fixed costs matter more than headcount. It should not be treated as the archetype by itself unless the scale shift, mapping, recalibration rule, and behavior-preservation test are explicit.

### Threshold Rescaling

This is a **procedure** for implementing Parameter Rescaling. Adjusts a trigger, cutoff, quota, alert level, or decision threshold when the unit of analysis changes. Threshold rescaling is common in operations, policy, analytics, and governance. It should be distinguished from adaptive threshold recalibration, which is primarily about ongoing change over time rather than scale transfer. It should not be treated as the archetype by itself unless the scale shift, mapping, recalibration rule, and behavior-preservation test are explicit.

### Dimensional Analysis Table

This is a **template** for implementing Parameter Rescaling. Lists quantities, units, dimensions, denominators, and transformations so scale-dependent parameters are not copied blindly. The table is a supporting artifact. It can reveal impossible mappings but cannot by itself prove that target-scale behavior is preserved. It should not be treated as the archetype by itself unless the scale shift, mapping, recalibration rule, and behavior-preservation test are explicit.

### Model Parameter Recalibration

This is a **method** for implementing Parameter Rescaling. Fits or adjusts model parameters at a new resolution, sampling regime, scenario, or operating scale. This mechanism implements rescaling when a model is moved from one scale or resolution to another and then checked against target behavior. It should not be treated as the archetype by itself unless the scale shift, mapping, recalibration rule, and behavior-preservation test are explicit.

### Policy Scaling Rule

This is a **protocol** for implementing Parameter Rescaling. Defines how rules, thresholds, budgets, reporting requirements, or interventions change when moving from pilot, local, or small-scale settings to larger settings. Policy scaling rules need assumption logs and validation windows because institutional, population, and incentive effects often change with scale. It should not be treated as the archetype by itself unless the scale shift, mapping, recalibration rule, and behavior-preservation test are explicit.

### Organizational Metric Rescaling

This is a **metric_or_dashboard** for implementing Parameter Rescaling. Adjusts KPIs, service levels, staffing ratios, capacity thresholds, or workload metrics when moving between teams, departments, sites, or enterprise levels. This mechanism is useful when organizational units differ in size or load, but it can hide local constraints if only ratios are compared. It should not be treated as the archetype by itself unless the scale shift, mapping, recalibration rule, and behavior-preservation test are explicit.

### Budget Normalization

This is a **method** for implementing Parameter Rescaling. Restates budget or resource quantities relative to the unit that makes them comparable across scales. Budget normalization may use per-user, per-transaction, per-project, per-site, or per-output bases. It is a mechanism under the broader rescaling logic. It should not be treated as the archetype by itself unless the scale shift, mapping, recalibration rule, and behavior-preservation test are explicit.

### Scale-Adjusted KPI

This is a **metric_or_dashboard** for implementing Parameter Rescaling. Displays a performance metric after adjusting for unit size, exposure, case mix, throughput, or operating scale. A scale-adjusted KPI is an artifact or dashboard mechanism; it becomes part of Parameter Rescaling only when tied to a mapping and behavior-preservation test. It should not be treated as the archetype by itself unless the scale shift, mapping, recalibration rule, and behavior-preservation test are explicit.

### Benchmark Rebasing

This is a **procedure** for implementing Parameter Rescaling. Updates the reference baseline or comparison benchmark when scale, unit mix, measurement basis, or operating context changes. Benchmark rebasing is a concrete way to implement the baseline rebasing component, especially in performance evaluation and planning. It should not be treated as the archetype by itself unless the scale shift, mapping, recalibration rule, and behavior-preservation test are explicit.

prose_failure_modes:
The first failure mode is naive scale copying: the old value is reused because it is familiar. The second is wrong-denominator normalization, where a per-unit metric hides the real exposure or burden. The third is linear scaling fallacy, where a proportional adjustment is used despite nonlinear target-scale effects.

Other failures include metric laundering, where rescaling gives unjustified authority to a convenient metric; overextended validation windows, where a rescaled value remains in use after conditions change; and behavioral mismatch, where the value is dimensionally correct but practically wrong.

prose_neighbor_distinctions:
Parameter Rescaling is close to **Scale-Appropriate Modeling**, but the two answer different questions. Scale-Appropriate Modeling asks which level of representation should be used. Parameter Rescaling asks how a value must change when it is used at another scale.

It is close to **Coarse-Graining**, but Coarse-Graining groups fine-grained elements into macro units. Parameter Rescaling adjusts the values, thresholds, metrics, or rules that operate after a scale change.

It is close to **Dimensional Analysis**, but dimensional analysis is a supporting method. Parameter Rescaling adds target-context recalibration and behavioral validation.

It is close to **Adaptive Threshold Recalibration**, but that neighbor focuses on revising thresholds as conditions change over time. Parameter Rescaling focuses on thresholds, parameters, and metrics whose meaning changes because the scale changes.

It is close to **Scale-Bridging Translation**, a likely later candidate, but Scale-Bridging Translation may translate whole insights, models, and assumptions between micro, meso, and macro levels. Parameter Rescaling is narrower: it centers on scale-sensitive values.

prose_cross_domain_examples:
In operations, a team-level queue alert threshold may be rescaled for a regional service center. The target threshold should preserve the same load-risk behavior, not the same ticket count.

In public policy, a pilot allocation formula may need rescaling before jurisdiction-wide rollout. Population size, demand density, administrative burden, and compliance behavior may all change the target-scale effect.

In analytics, incident counts across sites may be normalized by exposure or operating scale. The metric should state where the comparison is valid and where case-mix or fixed-cost differences require additional detail.

In simulation, a coefficient fitted at fine timestep resolution may need recalibration for a coarser model. Validation should compare target behavior, not just copied parameter values.

In organizational design, a staffing ratio from a small specialist team may need adjustment before being applied to a larger mixed-function department.

prose_non_examples:
A pure unit conversion is not Parameter Rescaling if it only changes notation and does not change scale-dependent behavior. Ordinary parameter tuning within a fixed scale is not this archetype. A dashboard that displays per-capita values without validating the denominator is only a mechanism. Choosing the department level rather than the individual level is closer to Scale-Appropriate Modeling unless a parameter or rule also needs transformation.

A politically convenient threshold change is also not Parameter Rescaling unless the change is justified by a scale shift and validated against behavior.

prose_tradeoffs:
Parameter Rescaling trades simplicity for validity. A simple copied value is easy to communicate but often wrong. A rescaled value is more defensible but requires assumptions, validation, and review.

It also trades comparability against richness. Normalized metrics make units comparable, but the chosen denominator can hide fixed costs, subgroup burdens, nonlinear effects, or interaction density. The remedy is not to avoid normalization, but to document what it preserves and what it hides.

prose_invariants_to_preserve:
The main invariant is not the raw value. The main invariant is the target behavior: the rule should still trigger the intended response, the metric should still support fair comparison, the model should still reproduce the relevant dynamics, and the baseline should still support meaningful evaluation.

Other invariants include dimensional meaning, traceability, comparability, validation scope, and decision-boundary meaning. These invariants let users see whether the rescaled value is a real transformation or just a convenient renaming of the old number.

prose_target_outcomes:
A successful use of Parameter Rescaling produces valid cross-scale transfer. Models, policies, dashboards, thresholds, and rules can move between scales without silently changing meaning. The target value is easier to defend because it has a source context, mapping logic, validation evidence, and stated limits.

The archetype also reduces scale bias. Large units are not automatically judged worse because their totals are larger, and small units are not automatically judged better because their absolute burden is lower. Comparisons become more meaningful because the scale effect is made explicit.

prose_parameter_dimensions:
Important tuning dimensions include the distance between the source and target scale, the normalization basis, the linearity or nonlinearity of the mapping, the tolerance allowed in the behavior-preservation test, the update cadence, and the scope over which comparisons remain valid.

The most common tuning mistake is choosing a denominator because it is easy to explain rather than because it preserves the relevant behavior. Per-capita, per-site, per-dollar, per-transaction, per-area, and per-time normalization each answer different questions. The chosen basis should match the practical effect the rescaled value is meant to preserve.

prose_variants_and_near_names:
The strongest variant is **Threshold Rescaling**, where the value being transformed is a trigger, cutoff, quota, or alert level. Its distinctive risk is changing the false-positive, false-negative, escalation, or approval behavior of the threshold.

**Metric Normalization by Scale** captures normalized metrics, per-capita metrics, scale-adjusted KPIs, and budget normalization. These should remain mechanisms or variants unless the normalization logic develops distinct components and failure modes beyond Parameter Rescaling.

**Model Parameter Recalibration** handles coefficients, rates, and fitted values when a model changes resolution, timestep, population, or operating regime. It remains under the parent when the core logic is still source-to-target value transformation.

**Policy Scaling Rule** applies the archetype to governance settings, especially pilot-to-scale transfer. It should be reviewed near Scale-Bridging Translation if the intervention becomes broader than parameter mapping.

**Baseline Rebasing After Scale Shift** captures the deferred roadmap idea of renormalized baseline tracking. In this draft it is treated as a component or candidate variant, not as a first-wave archetype.

short_definition: A variant that adjusts cutoffs, triggers, quotas, limits, or alert levels when the unit of analysis changes.

distinctive_feature: The rescaled parameter is a decision boundary or trigger rather than a continuous coefficient or metric.

distinct_from_parent: The parent covers any scale-sensitive parameter; this variant focuses on thresholds whose practical role is to start, stop, escalate, approve, or block action.

still_same_parent_because: The core logic is still a scale shift, parameter mapping, recalibration rule, and behavior-preservation test.

source_primes: renormalization scale

use_when: A threshold that worked for individuals, small groups, short windows, or local units is being applied at a larger, smaller, or differently aggregated scale.

use_when: The trigger should preserve a response behavior rather than preserve the same raw number.

use_when: False alarms, missed alarms, unfair cutoffs, or overload would result from copying the source-scale threshold directly.

Scale Shift

role: Names the scale movement that invalidates the old threshold.

Recalibration Rule

role: Defines the new cutoff or trigger logic.

Behavior Preservation Test

role: Checks whether the threshold still triggers the intended response.

Threshold Rescaling

mechanism_type: procedure

example_domains:
operations
risk management
public policy
analytics

domain: Operations

example: A local queue alert threshold is rescaled for a regional service center so escalation happens at the same load-risk point.

domain: Analytics

example: A small-sample anomaly trigger is adjusted before being used in a large aggregated dashboard.

failure_modes: The threshold is copied numerically and changes the practical false-positive or false-negative behavior.

Metric Normalization by Scale

short_definition: A variant that adjusts metrics by an explicit denominator or reference basis so comparisons across scale become meaningful.

distinctive_feature: The mapping is anchored by a normalization basis such as per person, per transaction, per site, per unit area, per exposure, or per time window.

distinct_from_parent: The parent can rescale any parameter; this variant specifically makes metrics comparable by choosing a scale-aware denominator.

still_same_parent_because: It still changes a quantity for a new scale and must validate that the normalized metric preserves the intended comparison behavior.

use_when: Raw totals are being compared across units with different sizes, exposures, case mixes, or time windows.

use_when: The relevant behavior is a rate, ratio, intensity, density, or normalized performance rather than an absolute quantity.

use_when: Stakeholders may otherwise mistake scale effects for performance differences.

Normalization Basis

role: Supplies the denominator or reference basis.

Dimensional Consistency Check

role: Prevents totals, rates, and ratios from being mixed.

Comparability Limit

role: States where the normalized comparison is no longer valid.

Budget Normalization

mechanism_type: method

example_domains:
public policy
finance
organizational performance
environmental planning

domain: Public policy

example: Service demand is compared per resident rather than by raw total across jurisdictions of different sizes.

domain: Finance

example: Project cost is compared per delivered unit so portfolio decisions are not dominated by project size alone.

failure_modes: The chosen denominator hides fixed costs, subgroup burden, interaction effects, or case-mix differences.

Model Parameter Recalibration

short_definition: A variant that refits or adjusts model parameters when model resolution, sampling regime, or operating scale changes.

distinctive_feature: The rescaled object is a model parameter whose validity depends on representation, sampling, and calibration context.

distinct_from_parent: The parent includes rules, thresholds, and metrics; this variant emphasizes model behavior under changed resolution or calibration context.

still_same_parent_because: The same scale-shift, parameter-mapping, recalibration, and validation structure applies.

source_primes: renormalization representation scale

use_when: A model is moved from one resolution, population, time step, spatial grid, or operating context to another.

use_when: Parameters estimated at the source scale would produce wrong target-scale behavior if copied directly.

use_when: The model needs to preserve prediction, control, or explanatory behavior after the scale change.

Source-Scale Parameter

role: Records the original fitted value and assumptions.

Parameter Mapping

role: Maps the parameter into the target representation.

Validation Window

role: Defines where the fitted value is trusted.

Dimensional Analysis Table

mechanism_type: template

example_domains:
simulation
machine learning operations
engineering models
ecological modeling

domain: Simulation

example: A parameter fitted on fine time steps is recalibrated for a coarser time-step simulation.

domain: Engineering

example: A load factor used for component-level analysis is adjusted before being used in system-level planning.

failure_modes: The model appears calibrated numerically but fails to preserve the target-scale behavior it is meant to represent.

short_definition: A variant that adjusts policy rules, limits, reporting requirements, or resource formulas when moving between pilot, local, regional, or system-wide scales.

distinctive_feature: The rescaled parameter is embedded in institutional behavior, governance, and compliance rather than only in a model or metric.

distinct_from_parent: The parent is general; this variant emphasizes policy effects, institutional assumptions, and affected populations.

still_same_parent_because: The intervention still transforms scale-sensitive quantities and tests whether target-scale behavior is preserved.

use_when: A rule or allocation formula from a small setting is being reused at a larger or different governance scale.

use_when: Direct transfer would change incentives, burden, compliance behavior, or service effects.

use_when: The target-scale policy must preserve an intended effect while acknowledging changed context.

Target-Scale Context

role: Defines the new population, jurisdiction, or implementation setting.

Assumption Log

role: Records changed institutional assumptions.

Behavior Preservation Test

role: Checks policy effect rather than raw rule similarity.

Policy Scaling Rule

mechanism_type: protocol

example_domains:
public administration
education policy
organizational governance
service design

domain: Public administration

example: A pilot staffing formula is rescaled before being applied across regions with different demand density.

domain: Education policy

example: A classroom support ratio is adjusted before use across schools with different enrollment and need profiles.

failure_modes: The policy preserves the old formula but not the old effect, creating new inequity, burden, or noncompliance.

Baseline Rebasing After Scale Shift

short_definition: A candidate variant that updates comparison baselines after scale or context changes so evaluation remains meaningful.

distinctive_feature: The rescaled object is a baseline or benchmark rather than an operating parameter.

distinct_from_parent: The parent focuses on parameter transfer; this variant focuses on comparability and evaluation after scale change.

still_same_parent_because: It uses the same normalization, mapping, validation, and comparability-limit logic.

use_when: A before-after or cross-unit comparison uses baselines created at a different scale or context.

use_when: Raw baselines would make performance, change, or risk appear better or worse than it is.

use_when: The main work is making comparisons stable after scale-dependent rebasing.

Baseline Rebasing Rule

role: Defines how the baseline is updated.

Comparability Limit

role: Restricts cross-scale comparisons.

Reference Case Anchor

role: Anchors the rebased comparison.

example_domains:
performance evaluation
finance
operations
policy analysis

example: A service benchmark is rebased after merging several small sites into a regional operation.

example: Spending comparisons are rebased after portfolio scope changes.

failure_modes: The baseline update becomes a way to hide real performance changes or erase accountability.

near_names:
Scale-Adjusted Metric
Normalized Metric
Per-Capita Metric
Scale-Adjusted KPI
Parameter Normalization
Scale-Dependent Recalibration
Budget Normalization


Pareto Focus

type: archetype

source: generated

batch: First Iteration/Batch 27

aliases:
80/20 focus
critical few focus
vital few focus
top-driver focus
disproportionate-contribution focus

alias_records:
80/20 focus
critical few focus
vital few focus
top-driver focus
disproportionate-contribution focus

slug: constraint

slug: feedback

slug: equity

slug: optimization

slug: externality

components:
Outcome of Interest
Contribution Distribution
Critical Few Identification
Focus Rule
Causal Verification Check
Tail-Risk Review
Minimum Service Floor
Remeasurement Loop
Segment Boundary
Diminishing Returns Trigger

mechanisms:
Pareto Chart
Top-Driver Analysis
Defect-Cause Prioritization
Top-Cost-Source Intervention
High-Risk Targeting List
Key Account List
Tiered Support Model
Long-Tail Monitor
Exception Budget
Cumulative Contribution Curve
Marginal Reallocation Review

essence_one_line: Identify the small subset of inputs, causes, users, or tasks responsible for most of the outcome and focus effort there.

compression_statement: When outcomes are unevenly distributed, use Pareto Focus to measure contribution concentration, identify the critical few drivers, redirect limited effort toward them, and explicitly review what the long tail still needs.

core_intuition: Some systems are not evenly shaped. A small number of causes, users, tasks, cases, assets, or decisions can account for a large share of value, cost, harm, delay, or risk. Treating every contributor equally wastes scarce attention. Pareto Focus makes the distribution visible, concentrates effort where it can change the most outcome, and prevents the long tail from disappearing from view.

canonical_formula: pareto_focus = outcome_of_interest × contribution_distribution × critical_few_identification × focus_rule × causal_check × tail_risk_review × remeasurement_loop

structural_problem: Resources, attention, analysis, support, or intervention effort are spread evenly, reactively, or politically despite evidence that a small subset of contributors drives a disproportionate share of the relevant outcome.

trigger_conditions: The outcome has a visibly skewed distribution: a few causes, cases, users, sites, tasks, assets, defects, accounts, or decisions produce most cost, value, harm, risk, delay, demand, or opportunity.

trigger_conditions: Limited resources make equal treatment of every contributor impractical or ineffective.

trigger_conditions: Teams are overwhelmed by many possible problems and need a principled way to choose where concentrated effort begins.

trigger_conditions: Improvement efforts are diluted across low-impact categories while high-impact drivers remain under-addressed.

trigger_conditions: A recurring outcome can be categorized and measured well enough to rank contributors.

trigger_conditions: The long tail can be monitored or protected so concentration does not silently abandon rare but important cases.

symptoms: Work lists, backlogs, causes, customers, incidents, or tasks are treated as equally important even though their effects differ sharply.

symptoms: Effort feels busy but produces little aggregate improvement because it is scattered across many low-contribution items.

symptoms: A few recurring drivers keep explaining most failures, complaints, rework, delay, cost, or risk.

symptoms: The organization alternates between reactive firefighting and vague prioritization rather than using a measured contribution distribution.

symptoms: Important tail cases are either ignored entirely or invoked so broadly that no focused intervention can occur.

symptoms: People cite an 80/20 slogan without knowing which outcome, distribution, or threshold they are actually using.

root_tension: The system needs concentration because contribution is uneven, but concentration can become blind, unfair, brittle, or misleading if the chosen outcome, data categories, causal assumptions, and long-tail obligations are not checked.

anti_signatures: The distribution is roughly even, so a critical-few focus would be arbitrary rather than evidence-based.

anti_signatures: The main problem is not concentration but a single throughput bottleneck; Bottleneck Identification and Relief may be more precise.

anti_signatures: The decision requires balancing multiple objectives on an efficient frontier rather than ranking contributors to one outcome; Pareto Frontier Navigation may be the better neighbor.

anti_signatures: The system lacks enough measurement or categorization to rank contributors; exploratory characterization or instrumentation should come first.

anti_signatures: The tail contains safety-critical, legally protected, or ethically important cases that cannot be deprioritized without a separate preservation design.

anti_signatures: The apparent high contributors are only symptoms, reporting artifacts, or category-size effects rather than actionable causes or leverage points.

structural_intervention: Define the outcome, measure how contributors are distributed, identify the critical few, redirect effort toward them, verify that the focus targets addressable drivers, preserve a baseline or exception path for the tail, and remeasure as the distribution changes.

action_logic: Name the outcome of interest precisely enough that contribution can be meaningfully ranked.

action_logic: Choose categories or segments that are comparable, action-relevant, and not misleadingly broad or narrow.

action_logic: Measure and rank contributors by total contribution, severity-adjusted contribution, risk contribution, value contribution, cost contribution, or another justified metric.

action_logic: Identify the critical few using the actual distribution shape rather than assuming a literal 80/20 split.

action_logic: Check whether the top contributors are actionable causes, leverageable segments, valid risk groups, or merely visible symptoms.

action_logic: Define the focus rule: what receives added effort, what remains at baseline, and what is temporarily deprioritized.

action_logic: Add a tail-risk review and, where needed, a service floor, reserve, sampling rule, exception channel, or monitoring mechanism.

action_logic: Remeasure after intervention because reducing the top drivers changes the distribution and may reveal the next tier.

decision_rules: Use Pareto Focus only when the contribution distribution is sufficiently uneven to justify concentrated effort.

decision_rules: Do not treat the 80/20 ratio as a law; use whatever threshold the data, context, and obligations support.

decision_rules: Focus on high-contribution drivers only when the selected outcome is legitimate, aligned with purpose, and not merely convenient to measure.

decision_rules: Before reallocating resources, ask what minimum floor or exception rule must protect low-frequency but important cases.

decision_rules: Recheck causality before intervening: high contribution is a clue for investigation, not automatic proof of cause.

decision_rules: Stop adding effort to the same critical few when marginal returns flatten or when tail harm, strategic neglect, or equity concerns dominate the benefit.

target_invariants: The chosen outcome remains explicit and does not drift into whatever metric is easiest to rank.

target_invariants: The critical few are identified from a measured or defensible distribution rather than from intuition alone.

target_invariants: Categories and segments remain comparable enough that ranking them does not create false conclusions.

target_invariants: Rare, low-frequency, emerging, protected, or safety-critical cases remain visible through tail review.

target_invariants: Baseline duties, legal obligations, access commitments, or mission-critical coverage are not erased by concentration.

target_invariants: The distribution is revisited after intervention so focus does not fossilize into permanent privilege for yesterday’s drivers.

expected_outcomes: Scarce effort shifts from diffuse activity to the subset most likely to change the target outcome.

expected_outcomes: Teams gain a clearer rationale for priority, sequencing, and resource allocation.

expected_outcomes: Improvement becomes more measurable because intervention begins where contribution is concentrated.

expected_outcomes: Waste, delay, defect, cost, risk, or opportunity loss falls faster than under evenly spread effort.

expected_outcomes: Tail obligations become explicit instead of being accidentally ignored or used to block all focus.

expected_outcomes: The system learns how its contribution distribution changes over time.

prose_essence:
Pareto Focus is the intervention pattern of finding the small subset of contributors that drives a disproportionate share of an outcome, then focusing limited effort there while preserving explicit protection for the long tail.

The core move is not simply “do the 80/20 rule.” The ratio may be 70/10, 95/5, or something else. The important structure is an uneven contribution distribution: a few causes, users, tasks, sites, defects, accounts, assets, or decisions explain much more of the outcome than the rest. Pareto Focus turns that distribution into a disciplined focus rule.

prose_when_to_use:
Use Pareto Focus when effort is being spread evenly or reactively, but the outcome is not evenly distributed. It works especially well when a team can rank contributors to a defined result such as defects, costs, incidents, risk, delay, revenue, usage, support burden, learning errors, or preventable harm.

It is a poor fit when the distribution is not skewed, when the data cannot support ranking, when the highest contributors are not actionable, or when rare cases are too important to deprioritize without a separate preservation mechanism.

prose_structural_problem:
The structural problem is diffuse effort in the face of concentrated contribution. The system treats many contributors as if they matter equally even though a small subset drives most of the burden or value. This creates busy work, slow improvement, weak prioritization, and hidden opportunity cost.

A second problem sits inside the first: concentration can create blindness. If the long tail contains rare catastrophic risks, underserved groups, emerging patterns, mission-critical exceptions, or legally protected cases, focusing only on the critical few can improve the aggregate metric while making the system worse.

prose_intervention_logic:
Pareto Focus begins by naming the outcome of interest. The team then chooses meaningful categories, measures contribution, ranks contributors, and identifies the critical few. The resulting focus rule redirects effort toward the high-contribution subset.

The intervention is not complete until it checks causality and protects the tail. A high-contribution category may be a symptom rather than a cause. A low-frequency category may be rare but severe. The focus rule should therefore include causal verification, minimum coverage, exceptions, reserves, sampling, or monitoring as needed.

prose_key_components:
### Outcome of Interest

The outcome of interest defines what the system is trying to change. It may be defect count, total harm, preventable cost, user pain, latency, lost revenue, admissions, support load, or missed learning. Changing the outcome can change the critical few, so this component must be explicit.

### Contribution Distribution

The contribution distribution shows how much each contributor accounts for. It can appear as a ranked table, Pareto chart, cost curve, incident distribution, histogram, or burden profile. Without this distribution, Pareto Focus collapses into intuition-based prioritization.

### Critical Few Identification

Critical few identification draws the boundary around the high-contribution subset. The boundary should follow the distribution shape and decision context, not a ritualized “top 20 percent.”

### Focus Rule

The focus rule translates analysis into allocation. It states what gets more attention, what remains at baseline, and what is temporarily deprioritized. This prevents Pareto analysis from becoming a descriptive chart that changes nothing.

### Causal Verification Check

Causal verification checks whether the high-contribution subset is actually addressable. A category can be large because it is broad, visible, overreported, or downstream of another cause. The archetype works best when top contributors are linked to real intervention points.

### Tail-Risk Review

Tail-risk review asks what could be missed or harmed when focus narrows. It protects rare, emerging, low-volume, safety-critical, legally protected, strategically important, or ethically significant cases.

### Minimum Service Floor

A minimum service floor preserves baseline attention or access for items outside the critical few. It is especially important in public services, healthcare, education, infrastructure, and any domain with rights or safety obligations.

### Remeasurement Loop

Focused intervention changes the distribution. The remeasurement loop updates the ranking so the system does not keep concentrating on yesterday’s drivers after they have improved.

prose_common_mechanisms:
A **Pareto chart** is a common mechanism: it ranks categories and shows cumulative contribution. It is not the archetype itself because a chart alone does not allocate effort or protect the tail.

**Top-driver analysis** ranks the causes, segments, or inputs that explain most of the outcome. It implements the measurement and ranking part of the archetype.

**Defect-cause prioritization** applies the pattern to quality improvement by focusing on the few defect causes that create most rework, complaints, or failures.

**High-risk targeting lists** implement Pareto Focus in risk-bearing domains by identifying cases most likely to contribute to harm, cost, failure, or demand. These mechanisms require safeguards because risk scores can encode bias.

**Tiered support models** focus extra service on high-contribution or high-risk segments while maintaining baseline support for everyone else.

**Long-tail monitors** and **exception budgets** implement the guardrail side of the archetype. They keep rare but important cases from becoming invisible after focus shifts to the critical few.

prose_failure_modes:
The most common failure mode is **sloganized 80/20 thinking**: using the phrase without measuring anything.

Another failure mode is **tail neglect**, where low-volume cases are treated as unimportant even when they are severe, protected, emerging, or mission-critical.

A third failure mode is **metric capture**. If the ranked outcome is not the real objective, Pareto Focus can efficiently optimize the wrong thing.

A fourth failure mode is **causal misread**. A high-contribution category may not be an intervention point; it may simply be visible, broad, or downstream.

A fifth failure mode is **frozen focus**. Once the top drivers improve, the system must remeasure rather than keep allocating resources to the same old categories.

prose_neighbor_distinctions:
**Leverage Point Intervention** is about causal power: where a small change changes the system. Pareto Focus is about contribution concentration: which contributors account for most of the outcome. The two can overlap, but a top contributor is not automatically a leverage point.

**Marginal Reallocation** asks whether the next unit of resource should move elsewhere based on marginal return. Pareto Focus often comes earlier by identifying the critical few from a skewed distribution.

**Bottleneck Identification and Relief** identifies a throughput constraint. Pareto Focus ranks contributors to an outcome; the top contributor may or may not be a bottleneck.

**Pareto Frontier Navigation** concerns efficient tradeoffs among multiple objectives. Pareto Focus concerns a Pareto-effect distribution within an outcome.

**Variance Reduction** reduces unwanted spread. Pareto Focus may reduce variation by targeting major sources, but its defining structure is disproportionate contribution.

prose_cross_domain_examples:
In manufacturing, a plant may find that a few defect categories account for most scrap and rework. Pareto Focus directs the improvement sprint toward those categories while continuing to watch rare safety defects.

In software, a small number of endpoints may explain most latency complaints. The engineering team focuses optimization there before tuning lower-impact paths.

In healthcare, a small set of high-risk patients may account for a disproportionate share of preventable readmissions. A care team can focus outreach there while preserving access for others.

In education, a few prerequisite misconceptions may explain many downstream errors. The teacher focuses review and practice on those blockers.

In compliance, a few transaction types or sites may produce most serious violations. Inspection resources can concentrate there while still sampling the tail for emerging risks.

In customer success, a small number of accounts may drive most expansion and support risk. Extra relationship management can be justified, but baseline support obligations should remain visible.

prose_non_examples:
A motivational claim that “80 percent of results come from 20 percent of effort” is not Pareto Focus unless it identifies an outcome, measures contribution, selects a critical few, and changes action.

A dashboard that ranks categories is not the archetype by itself. It is a mechanism.

A policy that abandons low-volume users, rare diseases, remote communities, or uncommon failure modes is not good Pareto Focus; it is tail neglect.

A priority list based on seniority, politics, salience, or whoever complains loudest is not Pareto Focus unless it is tied to disproportionate contribution.

A single process bottleneck may require bottleneck relief rather than Pareto Focus.

prose_tradeoffs:
Pareto Focus trades coverage for concentration. That trade can be valuable, but it becomes dangerous when the tail contains rare severe cases or people with legitimate claims to service.

It also trades simplicity for accuracy. A ranked list is usable because it simplifies complexity, but it can hide causal ambiguity, biased categories, or unmeasured harms.

Finally, it trades current returns for future optionality. Concentrating on current top contributors can miss emerging drivers or make the system dependent on a few accounts, suppliers, causes, or interventions.

prose_invariants_to_preserve:
Pareto Focus should preserve an explicit outcome, a defensible contribution distribution, comparable categories, a justified critical-few threshold, and an action rule tied to the distribution.

It should also preserve tail visibility. The long tail must not disappear merely because it contributes less to the aggregate metric. Rare severe cases, protected groups, emerging signals, strategic options, and mission obligations may still deserve attention.

prose_target_outcomes:
The target outcome is concentrated impact. Scarce effort should move from scattered activity to the subset most likely to change the chosen result. The system should become clearer about why some work is prioritized and what baseline protection remains elsewhere.

A successful Pareto Focus reduces waste, defects, delays, costs, risk, or opportunity loss faster than uniform effort would. It also makes tradeoffs visible by showing what the critical few are and what the tail still needs.

prose_parameter_dimensions:
The first tuning dimension is the **outcome definition**. A cost distribution, harm distribution, revenue distribution, and risk distribution can point to different critical few.

The second is the **contribution metric**. Frequency, severity, preventability, total burden, value, and risk-weighted contribution are not interchangeable.

The third is **category granularity**. Categories that are too broad hide causes; categories that are too narrow fragment the pattern until nothing looks important.

The fourth is the **focus threshold**. The critical few may be the top three drivers, the point before diminishing returns, contributors above a threshold, or the segment that accounts for a chosen share of total burden.

The fifth is **tail protection level**. Some domains need only light monitoring of the tail; others need reserved capacity, legal exceptions, rare-case review, or minimum service commitments.

The sixth is **remeasurement cadence**. Fast-moving systems need frequent updates; slower systems can rely on periodic or trigger-based reviews.

prose_variants_and_near_names:
Common near names include **80/20 rule**, **critical few focus**, **vital few focus**, and **top-driver focus**. These should point to Pareto Focus unless they become concrete mechanisms.

Recognized variants include **Defect-Cause Pareto Focus**, **High-Risk Case Targeting**, **Key Account or Top User Focus**, and **Tail-Guarded Pareto Focus**. These variants differ in what counts as the high-contribution subset: defect causes, risk-bearing cases, high-contribution actors, or critical few drivers with explicit tail protection.

**Pareto chart** and **top 20 percent filter** should not be drafted as standalone archetypes. They are mechanisms or crude implementation names under the broader archetype.

Defect-Cause Pareto Focus

short_definition: Focus improvement effort on the small set of defect causes that accounts for most defects, rework, failures, or complaints.

distinctive_feature: The critical few are categories of failure or waste, usually displayed through a Pareto chart or ranked defect table.

distinct_from_parent: The parent can focus any uneven contribution distribution; this variant focuses specifically on quality, reliability, defect, or rework causes.

still_same_parent_because: The intervention still measures contribution concentration, selects a critical few, focuses intervention, and reviews neglected-tail risk.

use_when: Quality problems, incidents, or complaints can be grouped by cause, type, site, step, or source.

use_when: A ranked distribution shows that a few categories account for a disproportionate share of harm or waste.

use_when: Resources for improvement are limited and broad equal effort would dilute impact.

example_domains:
manufacturing
software reliability
service operations
safety investigations

failure_modes: Treating counted defect categories as causal proof without root-cause validation.

failure_modes: Suppressing minor categories so long that rare but severe failures escape attention.

High-Risk Case Targeting

short_definition: Focus support, prevention, or review on the subset of cases most likely to generate severe outcomes, costs, failures, or harms.

distinctive_feature: The critical few are defined by risk or vulnerability rather than only by frequency, volume, revenue, or cost.

distinct_from_parent: The parent only requires an uneven contribution distribution; this variant adds risk scoring, support targeting, and equity safeguards.

still_same_parent_because: The focus logic is still distributional concentration plus resource redirection toward the highest-contribution subset.

use_when: Risk or cost is concentrated among a small number of cases, clients, patients, sites, events, suppliers, or accounts.

use_when: Early intervention on the highest-risk subset can prevent disproportionate harm or cost.

use_when: The system can protect access, dignity, and procedural fairness for lower-risk or less visible cases.

example_domains:
healthcare care management
public services
fraud review
safety inspection

failure_modes: Confusing predicted cost with moral worth or entitlement to service.

failure_modes: Using biased risk signals that amplify existing inequities.

Key Account or Top User Focus

short_definition: Focus service, retention, or relationship effort on users, customers, accounts, partners, or contributors that drive a disproportionate share of a chosen outcome.

distinctive_feature: The critical few are actors or accounts rather than causes, tasks, defects, or cost sources.

distinct_from_parent: The parent can focus any concentrated driver; this variant centers relationship, service, or account strategy.

still_same_parent_because: It still uses an uneven contribution distribution to concentrate limited attention and resources.

use_when: Revenue, usage, support load, influence, referrals, donations, or contribution is highly concentrated.

use_when: A differentiated engagement strategy is legitimate and does not remove required baseline service from others.

use_when: The outcome metric is aligned with the organization’s purpose rather than only short-term extraction.

example_domains:
customer success
fundraising
developer relations
community management

failure_modes: Creating lock-in or dependency around a few dominant accounts.

failure_modes: Neglecting emerging, mission-critical, or underserved segments that are not yet high-contribution.

Tail-Guarded Pareto Focus

short_definition: Apply Pareto concentration while reserving explicit protection for rare, low-frequency, emerging, or ethically important cases in the long tail.

distinctive_feature: The focus rule is paired with an explicit tail protection rule rather than only a general warning.

distinct_from_parent: The parent requires tail-risk review; this variant makes long-tail protection a central design feature.

still_same_parent_because: It still begins with concentration of outcome contribution and focuses effort on critical few drivers.

use_when: Most effort should go to the critical few, but rare cases can produce severe harm, equity failure, reputational damage, or strategic surprise.

use_when: The long tail contains legally protected, safety-critical, mission-critical, or high-impact-low-frequency cases.

use_when: A reserve, exception, sampling, or monitoring mechanism can preserve tail coverage without dissolving the main focus.

example_domains:
rare disease provision
public service access
safety engineering
security monitoring

failure_modes: Letting the tail guard become symbolic while resources still vanish from rare but important cases.

failure_modes: Letting tail exceptions grow without criteria until the Pareto focus disappears.

near_names:
80/20 Rule
Critical Few Focus
Vital Few Focus
Top-Driver Analysis
Pareto Chart
Top 20 Percent Filter
High-Leverage Focus


Pareto Frontier Navigation

batch: First Iteration/Batch 10/second wave

Pareto Frontier Selection

notes: Near name from Batch 031; selection is treated as the final choice stage inside this navigation archetype.

Efficient Frontier Navigation

notes: Equivalent name when the frontier is described as efficient rather than Pareto-efficient.

Efficient Frontier Selection

notes: Commonly used when the main act is choosing a point on the frontier.

Non-Dominated Option Selection

notes: Emphasizes filtering dominated options before choosing among remaining alternatives.

Frontier Tradeoff Navigation

notes: Plain-language name emphasizing movement among efficient tradeoff options.

Trade-Offs

role: Provides the core condition: improvement in one valued dimension may require sacrifice in another, so choices must be made on an explicit tradeoff structure.

Indifference Curves

role: Supports the idea that different bundles can be preference-equivalent, helping stakeholders choose among non-dominated options rather than treating all differences as absolute.

Pareto Efficiency

role: Defines non-dominance: an option belongs on the frontier when no objective can improve without worsening at least one other objective.

Multiobjective Optimization

role: Supplies formal methods for finding efficient frontiers, while the archetype generalizes the intervention beyond mathematical solvers.

Optimization

role: Explains the search for better options, but this archetype avoids collapsing all objectives into a single hidden score too early.

Resource Management

role: Applies when the frontier is built from allocations of scarce budget, capacity, time, attention, labor, or infrastructure.

Opportunity Cost

role: Clarifies what is given up when moving from one frontier option to another.

Constraint

role: Defines feasibility boundaries; options outside the feasible region are not candidates for frontier comparison.

Bounded Rationality

role: Explains why decision-makers benefit from eliminating dominated options before deliberating over the smaller efficient set.

Sensitivity Analysis

role: Tests whether the frontier or preferred option changes when assumptions, weights, measurements, or scenarios shift.

Risk–Return Tradeoff

role: Provides a common domain-specific frontier pattern where higher expected return is balanced against exposure to risk.

Uncertainty

slug: uncertainty

role: Requires caution because the apparent frontier may depend on noisy estimates, changing conditions, or incomplete option discovery.

components:
Option Set
Objective Dimensions
Feasibility Constraints
Dominance Criterion
Frontier Map
Preference or Priority Rule
Tradeoff Rationale
Recheck Trigger
Stakeholder Preference Elicitation
Sensitivity Check
Knee Point Indicator
Implementation Commitment Record

mechanisms:
Dominance Screening
Pareto Frontier Analysis
Efficient Frontier Plot
Multiobjective Optimization Model
Tradeoff Curve Visualization
Weighted Scoring Overlay
Knee Point Analysis
Stakeholder Frontier Review
Scenario Sensitivity Sweep

essence_one_line: Search for options where no objective can improve without worsening another, then choose consciously along the efficient frontier.

compression_statement: When choices involve multiple competing objectives, identify feasible options, eliminate dominated alternatives, map the remaining non-dominated frontier, and choose a frontier point using explicit preferences, constraints, risk posture, or stakeholder judgment.

core_intuition: A hard tradeoff is only worth debating after obviously worse options have been removed. Pareto Frontier Navigation separates inefficient compromise from genuine value conflict: first stop choosing options that are worse on every relevant dimension, then make the remaining sacrifice explicit.

canonical_formula: option_set + objective_dimensions + feasibility_constraints + dominance_criterion -> frontier_map; frontier_map + preference_or_priority_rule + tradeoff_rationale -> conscious_efficient_choice

structural_problem: A decision space contains multiple feasible options and multiple valued objectives, but some options are strictly worse than others across the relevant dimensions. Without a frontier discipline, the system may select dominated compromises or argue over options that should have been eliminated before deliberation.

condition: Multiple objectives matter at once.

signal: Decision-makers are comparing cost, quality, speed, risk, equity, reliability, impact, or other dimensions that cannot all be maximized simultaneously.

condition: No single objective legitimately dominates the choice.

signal: A simple maximization rule would hide value judgments or sacrifice important dimensions without acknowledgment.

condition: The option set includes likely dominated alternatives.

signal: Some choices appear more costly, slower, riskier, or lower quality than another available option with no compensating benefit.

condition: Stakeholders are debating inefficient compromises.

signal: Attention is spent defending familiar, politically easy, or legacy options that perform worse than feasible alternatives.

condition: The tradeoff space is too large for intuitive comparison.

signal: Manual reasoning cannot reliably see which options are non-dominated across all important dimensions.

condition: A final value choice must be separated from technical screening.

signal: Decision-makers need to distinguish the objective fact that an option is dominated from the normative choice among efficient options.

symptom: Dominated compromise

description: The chosen option is worse than another feasible option on every relevant dimension, often because the comparison was fragmented or politically constrained.

symptom: False tradeoff

description: Stakeholders believe they must sacrifice one objective for another even though an available option improves both.

symptom: Hidden preference collapse

description: A weighted score or single metric silently decides the choice before stakeholders understand the tradeoffs.

symptom: Option overload

description: Too many alternatives are debated because no systematic filtering removes inferior options.

symptom: Frontier myopia

description: The apparent frontier is treated as complete even though important objectives, constraints, or options are missing.

symptom: Technical laundering

description: A mathematical frontier is used to present a value-laden choice as if it were purely objective.

root_tension: The system needs efficient choices, but efficiency does not determine preference. Pareto navigation can prove that some options are inferior, but among non-dominated options it must expose rather than conceal the value judgment that selects one sacrifice profile over another.

case: There is only one relevant objective and no meaningful tradeoff.

reason: Ordinary optimization or threshold selection is simpler; a frontier adds unnecessary complexity.

case: The main issue is defining the objectives or constraints, not choosing among non-dominated options.

reason: Objective formulation, constraint formulation, or tradeoff surface mapping may be needed first.

case: Some values are non-negotiable and cannot be traded away.

reason: A tradeoff guardrail or invariant-guarding archetype should set protected floors before frontier selection.

case: All options are ethically, legally, or practically unacceptable.

reason: Frontier navigation cannot rescue an invalid option set; new options or constraints are required.

case: The problem is ongoing resource governance across categories.

reason: Resource portfolio balancing or constrained resource allocation may be a closer fit than selecting a frontier point.

case: The choice is made by queue order, rights, entitlement, or triage priority rather than objective tradeoff efficiency.

reason: Queue discipline, resource rationing, or priority-based admission may be the primary archetype.

structural_intervention: Convert a multi-objective choice into an explicit frontier process: define feasible options and objective dimensions, remove dominated alternatives, map the non-dominated frontier, make the remaining tradeoffs visible, and select a frontier point through an explicit preference, priority, legitimacy, or risk rule.

step: Frame the choice as a multi-objective option space.

logic: Name the decision, the candidate options, and the objectives that must be considered together.

step: Define feasibility and non-negotiable constraints.

logic: Remove impossible or unacceptable options before evaluating efficiency.

step: Measure or estimate each option on relevant dimensions.

logic: Use comparable evidence where possible, while preserving qualitative dimensions that cannot be responsibly reduced to a single number.

step: Apply a dominance criterion.

logic: Eliminate options that are no better on any objective and worse on at least one relevant objective compared with another feasible option.

step: Map the frontier.

logic: Represent the remaining non-dominated options so movement along the frontier reveals what is gained and sacrificed.

step: Choose among frontier options explicitly.

logic: Use stakeholder preferences, strategic priorities, risk posture, acceptable substitution rules, guardrails, or governance process to select a point on the frontier.

step: Document the rationale and rejected alternatives.

logic: Record which options were dominated, which frontier options remained, why the selected option was chosen, and what opportunity costs were accepted.

step: Set recheck triggers.

logic: Revisit the frontier when objectives, constraints, measurements, options, or external conditions change.

rule: Do not deliberate over dominated options unless there is a missing objective or measurement concern.

example: A model that is less accurate, slower, and more expensive than another model is removed unless it has an unmodeled advantage such as interpretability or maintainability.

rule: Do not let the Pareto filter pretend to make the final value choice.

example: Two policy options may both be efficient; choosing between lower cost and wider access requires an explicit priority rule or stakeholder process.

rule: Add a missing dimension if an apparently dominated option has a real compensating value.

example: A slower procurement option might be retained if it has supply-chain resilience not included in the initial dimensions.

rule: Use guardrails before frontier selection when some dimensions cannot fall below a minimum.

example: A service plan must satisfy safety and fairness floors before being considered frontier-eligible.

rule: Prefer sensitivity checks when measurements, forecasts, or weights are uncertain.

example: A capital plan is tested against alternative demand and cost scenarios before selecting a frontier point.

rule: Escalate to governance when the selected frontier point distributes burdens unevenly.

example: Community planning choices that trade disruption against access are reviewed with affected stakeholders before commitment.

invariant: Only feasible options are frontier candidates.

reason: Including impossible or prohibited options makes the frontier misleading.

invariant: Dominance is evaluated across all relevant objectives, not only convenient metrics.

reason: Missing dimensions can falsely eliminate options or falsely crown a frontier.

invariant: The frontier is a decision aid, not a substitute for value judgment.

reason: Pareto efficiency cannot determine which efficient option should be chosen.

invariant: Preference rules are explicit and reviewable.

reason: Hidden weights undermine legitimacy and make tradeoffs harder to challenge.

invariant: Non-negotiable guardrails are applied before tradeoff selection.

reason: A frontier point can still be unacceptable if it violates safety, rights, fairness, or legal constraints.

invariant: The chosen frontier point is linked to implementation commitments.

reason: Without action, the frontier remains an analysis artifact rather than a solution intervention.

invariant: The frontier can be revised when conditions change.

reason: New options, data, constraints, or stakeholder priorities can change which options are efficient.

outcome: Dominated options removed

description: Decision attention shifts away from alternatives that are strictly worse than available options.

outcome: Real tradeoffs exposed

description: Remaining options show genuine sacrifices rather than false or avoidable compromises.

outcome: More legitimate choice rationale

description: The final selection among frontier options is explained through explicit values, priorities, constraints, or stakeholder process.

outcome: Reduced inefficient compromise

description: The system is less likely to choose an option that sacrifices multiple objectives without benefit.

outcome: Better option discovery

description: Seeing the frontier can reveal gaps where new options might improve multiple objectives at once.

outcome: Improved reviewability

description: Future reviewers can see which assumptions, objectives, and preferences drove the choice.

prose_essence:
Pareto Frontier Navigation is the discipline of refusing to spend decision energy on options that are worse than another feasible option on every relevant dimension. It does not say that the most mathematically efficient-looking option is automatically right. Instead, it separates two different jobs: first, remove dominated options; second, make a conscious value choice among the remaining non-dominated alternatives.

The archetype is especially useful when a decision feels like a tradeoff but some of the supposed tradeoffs are false. If an option costs more, performs worse, takes longer, and introduces more risk than another option, it should not remain in contention unless the comparison is missing an important objective. Once those dominated choices are removed, the remaining frontier shows real sacrifices: lower cost may require less quality, more speed may require higher risk, or wider access may require more funding.

prose_when_to_use:
Use this archetype when several objectives matter at once and no single objective can legitimately decide the case. Typical signals include debates over cost versus quality, speed versus reliability, reach versus burden, risk versus return, accuracy versus latency, or access versus administrative complexity.

It is also useful when stakeholders are arguing over too many options. Frontier navigation reduces the option set by eliminating alternatives that are worse across the relevant dimensions. The remaining conversation can then focus on genuinely hard choices rather than familiar but inferior compromises.

Do not use it when a simple threshold or single-objective rule is sufficient. If all options already meet fixed requirements and only price matters, this is ordinary selection. If some values are non-negotiable, apply guardrails first; a frontier option can be efficient and still unacceptable.

prose_structural_problem:
The structural problem is a multi-objective decision space containing both dominated and non-dominated options. Without a frontier discipline, the decision can be distorted in several ways. Dominated options may remain politically protected. Weighted scores may hide value choices before anyone sees the real tradeoffs. A visually persuasive chart may imply rigor while omitting important dimensions. A legacy option may survive because nobody compares it against a feasible alternative across all objectives.

The root tension is that Pareto efficiency can identify inferior options, but it cannot decide which efficient option is best. Non-dominance is a screening rule, not a moral or strategic conclusion. The archetype works only when that distinction is preserved.

prose_intervention_logic:
The intervention begins by naming the option set and the objective dimensions. The option set must be broad enough to include serious alternatives, not just legacy choices. The objective dimensions must include the values that matter in practice, including qualitative values where possible.

Next, feasibility constraints remove options that are impossible, illegal, unsafe, unaffordable, or otherwise ineligible. Only then should dominance be tested. An option is dominated when another feasible option is at least as good on all relevant objectives and better on at least one. Dominated options are removed or sent back for reframing if a missing dimension may explain their value.

The remaining non-dominated options form the frontier. The frontier is then used as a decision object: stakeholders can see what changes when they move from one frontier point to another. Final selection requires a preference rule, priority rule, risk posture, guardrail, or governance process. The selected frontier point should be documented together with the sacrifices accepted and the options rejected.

prose_key_components:
### Option Set

The option set is the collection of alternatives being compared. It should include real feasible options, not only the options that are familiar, politically available, or already in the budget. If the option set is poor, the frontier will be poor.

### Objective Dimensions

Objective dimensions are the values or outcomes used for comparison: cost, speed, quality, safety, access, reliability, fairness, risk, maintainability, or other relevant concerns. The more incomplete these dimensions are, the more likely the frontier will eliminate the wrong options.

### Feasibility Constraints

Feasibility constraints decide what is allowed into the comparison. Safety floors, legal requirements, technical limits, budget ceilings, and capacity constraints should be applied before frontier selection. This prevents efficient but unacceptable options from appearing eligible.

### Dominance Criterion

The dominance criterion defines when one option is strictly worse than another. It must specify which direction is better for each dimension and how ties, uncertainty, and thresholds are handled. A vague dominance rule produces arbitrary elimination.

### Frontier Map

The frontier map represents the non-dominated alternatives. It can be a graph, table, model output, decision board, or narrative map. Its purpose is not decoration; it makes the remaining tradeoffs inspectable.

### Preference or Priority Rule

Pareto filtering leaves multiple efficient options. A preference or priority rule determines how the final choice is made among them. This may come from stakeholder deliberation, strategic goals, risk tolerance, equity requirements, or explicit weights.

### Tradeoff Rationale

The tradeoff rationale explains why the selected frontier point is acceptable. It should name what is gained, what is sacrificed, and why the sacrifice is justified. This is the piece that prevents a technical frontier from hiding a value judgment.

### Recheck Trigger

A recheck trigger defines when the frontier should be revisited. New options, changed costs, altered constraints, updated evidence, or shifting stakeholder values can all change which options are non-dominated.

prose_common_mechanisms:
### Dominance Screening

Dominance screening is a method for removing options that are worse across the relevant dimensions. It implements the filtering part of the archetype, but it is not the whole archetype because it does not choose among the frontier options.

### Pareto Frontier Analysis

Pareto frontier analysis identifies the non-dominated set. In small decisions it may be a structured table; in complex decisions it may be computational. It implements the map-building step, but the final choice still requires judgment.

### Efficient Frontier Plot

An efficient frontier plot is a visual artifact. It is helpful when two or three dimensions can be displayed clearly, but it can mislead when hidden dimensions are excluded. The plot should be treated as a decision aid, not as the decision.

### Multiobjective Optimization Model

A multiobjective optimization model can search large feasible spaces for frontier points. It is useful when manual comparison is impossible. It becomes dangerous when the model’s assumptions, objectives, or constraints are treated as neutral facts.

### Tradeoff Curve Visualization

A tradeoff curve shows how one dimension changes as another improves or worsens. It helps users understand movement along the frontier, especially where sacrifices accelerate.

### Weighted Scoring Overlay

A weighted scoring overlay may be used after frontier filtering to choose among non-dominated options. It should not be used to hide value judgments. The weights are part of the choice and must be visible.

### Knee Point Analysis

Knee point analysis looks for a bend in the frontier where additional gains become increasingly expensive. It can suggest a pragmatic candidate, but it cannot substitute for checking values, guardrails, and legitimacy.

### Stakeholder Frontier Review

Stakeholder frontier review uses the frontier as a shared deliberation object. It is important when different groups bear different costs or benefits from the selected point.

### Scenario Sensitivity Sweep

A scenario sensitivity sweep tests whether the frontier changes under different assumptions. It implements the archetype’s recheck and robustness logic when uncertainty is material.

prose_failure_modes:
A common failure mode is an incomplete option set. If only familiar options are included, the frontier may merely compare legacy compromises. Mitigate this with option-generation and challenge steps.

Another failure mode is missing dimensions. A design that appears dominated on cost and speed may have maintainability or resilience benefits that were not measured. Mitigate this through objective audits and stakeholder review.

False dominance can occur when measurements are noisy, scales are inconsistent, or assumptions are wrong. Sensitivity checks help reveal this. Solver worship is another failure mode: the model or plot appears to choose, while in reality humans encoded values into objectives and constraints.

A serious misuse is guardrail violation. An option can be Pareto-efficient while still violating safety, rights, fairness, or legal constraints. Guardrails must be applied before frontier comparison.

prose_neighbor_distinctions:
Pareto Frontier Navigation differs from Tradeoff Surface Mapping because it does more than expose tradeoffs. It removes dominated options and guides selection among the remaining efficient set. Tradeoff Surface Mapping may be a predecessor, but it is not the same intervention.

It differs from Constrained Resource Allocation because it does not necessarily allocate resources or solve a constrained optimization problem. It can be used for designs, policies, models, and care pathways as well as resource allocations.

It differs from Multiobjective Optimization because optimization is a method family. The archetype includes framing, feasibility checks, dominance filtering, preference governance, rationale, and recheck triggers.

It differs from Resource Portfolio Balancing because portfolio balancing governs allocation across categories and time. Frontier navigation may help choose a portfolio point, but it does not by itself maintain target weights or rebalancing rules.

It differs from Opportunity Cost Surfacing because it compares many alternatives across objectives, rather than naming the best forgone alternative in a single choice.

It differs from Tradeoff Guardrail because guardrails define what cannot be sacrificed. Frontier navigation works after those non-negotiable boundaries are applied.

prose_cross_domain_examples:
In software architecture, the archetype helps teams reject architectures that are worse on cost, latency, reliability, and complexity than another feasible architecture. The remaining frontier options can then be chosen according to reliability goals and operating constraints.

In product design, the archetype helps compare bundles of battery life, weight, durability, price, and delivery time. A knee point may be useful, but the team still needs a rationale for why that sacrifice profile fits the product strategy.

In machine learning, the archetype filters out models that are dominated on accuracy, latency, compute cost, interpretability, or fairness. The final deployment choice among frontier models should include governance and risk review.

In public planning, transit or infrastructure options can be compared on cost, reach, disruption, emissions, travel time, and equity. The frontier helps remove inferior proposals while preserving the need for public deliberation.

In healthcare planning, treatment or care pathway options can be compared by efficacy, adverse effects, burden, access, and patient preference. Clinical guardrails must be applied before frontier comparison.

prose_non_examples:
A Pareto chart that ranks defect causes is not Pareto Frontier Navigation. It is a useful quality tool, but it does not map non-dominated tradeoff options.

A cheapest-vendor decision is not this archetype when all requirements are fixed and price is the only relevant dimension. A stakeholder workshop is also not enough by itself; without concrete options and dominance checks, it is deliberation rather than frontier navigation.

A weighted scorecard is not the archetype if it hides weights or skips dominance filtering. It may be used as a mechanism after frontier construction, but it should not replace frontier reasoning.

prose_tradeoffs:
The main tradeoff is decision quality versus analysis overhead. Frontier navigation takes time and may require data, modeling, facilitation, or stakeholder review. It is worth the overhead when the cost of an inefficient or illegitimate choice is high.

Another tradeoff is simplification versus omitted values. To compare options, the decision must name dimensions, but naming dimensions can exclude things that are hard to measure. This is why guardrails, qualitative notes, and stakeholder review matter.

There is also a transparency tradeoff. Making the frontier visible can expose uncomfortable sacrifices. That discomfort is often useful, but it can create political resistance.

prose_invariants_to_preserve:
The first invariant is feasibility: only eligible options belong on the frontier. The second is dimensional integrity: dominance must be checked across relevant dimensions, not just convenient metrics. The third is separation of roles: the frontier filters and clarifies; it does not make the final value choice.

A fourth invariant is explicit preference. When choosing among non-dominated options, the decision rule must be reviewable. A fifth invariant is revisability: the frontier must be open to change when new options, evidence, constraints, or values emerge.

prose_target_outcomes: A successful use of this archetype removes dominated options, reveals real tradeoffs, improves the legitimacy of the final choice, reduces inefficient compromise, and creates a record that future reviewers can understand. It can also stimulate better option discovery: if the frontier is unsatisfactory, the right response may be to invent new options rather than pick among poor ones.

prose_parameter_dimensions:
Important tuning dimensions include the breadth of the option set, the number and quality of objective dimensions, the strictness of feasibility constraints, the dominance threshold, the treatment of uncertainty, the degree of stakeholder participation, the preference rule used after filtering, and the cadence for frontier rechecks.

The strictness of dominance matters. A strict rule removes only options that are clearly worse. A looser rule may remove near-dominated options to reduce complexity, but it increases the risk of discarding a legitimate alternative. The number of dimensions also matters: too few dimensions hide values, while too many dimensions can make almost every option non-dominated and reduce the usefulness of the filter.

prose_variants_and_near_names:
Pareto Frontier Selection is the closest near name. This draft treats selection as the final act within navigation rather than as a separate top-level archetype. Efficient Frontier Selection and Efficient Frontier Navigation are also near aliases.

Dominated Option Elimination is a narrower variant focused on filtering. Knee Point Selection is a variant that uses the shape of the frontier to identify a pragmatic candidate. Robust Frontier Navigation is a stronger promotion candidate because it asks whether the frontier remains acceptable under changing assumptions. Stakeholder Frontier Deliberation is a governance variant for cases where efficient choices distribute costs and benefits unevenly.

Efficient frontier plots, weighted scoring models, and optimization solvers are mechanisms. They can implement parts of the archetype, but they should not be mistaken for the archetype itself.

Dominated Option Elimination

variant_type: subtype

short_definition: Focuses on removing options that are worse on all relevant dimensions before deeper deliberation begins.

distinctive_feature: The emphasis is on filtering rather than full frontier selection.

distinct_from_parent: The parent includes frontier mapping and final selection logic; this variant may stop after removing dominated options.

still_same_parent_because: The structural idea is still Pareto non-dominance applied to tradeoff choices.

use_when: The option set is large enough that clearly inferior choices are wasting attention.

use_when: Decision-makers are tempted by familiar but dominated compromises.

use_when: The main intervention is narrowing the field rather than making the final value choice.

example: Discard models that are both less accurate and more expensive to run than available alternatives.

domain: procurement

example: Remove bids that are slower, costlier, and lower quality than another feasible bid.

failure_modes: False dominance caused by missing objectives or unreliable measurements.

Knee Point Selection

short_definition: Selects a frontier point near the bend where additional gains on one objective begin to require sharply larger sacrifices.

distinctive_feature: It uses frontier shape as a decision cue rather than only stakeholder preference weights.

distinct_from_parent: The parent can choose any frontier point; this variant favors the apparent balance point near a marginal-sacrifice transition.

still_same_parent_because: It still requires identifying the non-dominated frontier before selecting a point.

use_when: The frontier has a visible bend or inflection region.

use_when: Stakeholders need a pragmatic default that avoids extreme sacrifice.

use_when: Marginal gains beyond the knee appear increasingly costly or risky.

example: Choose the battery size where weight increases steeply for only small additional runtime.

example: Choose a staffing level where wait-time improvements begin to flatten relative to cost.

failure_modes: Treating the visual knee as objective truth when the plotted dimensions omit fairness, safety, or long-term risk.

Robust Frontier Navigation

short_definition: Chooses among frontier options by testing which remain acceptable or efficient across plausible assumptions and scenarios.

distinctive_feature: The frontier is not fixed; the intervention checks stability across scenario variation.

distinct_from_parent: The parent identifies and selects among non-dominated options in a given decision model; this variant emphasizes robustness across model uncertainty.

still_same_parent_because: The choice still operates on non-dominated or acceptable frontier options.

use_when: The frontier depends strongly on uncertain assumptions.

use_when: The cost of choosing a fragile frontier point is high.

use_when: Decision-makers prefer acceptable performance across scenarios over best performance under one estimate.

domain: infrastructure

example: Pick a design that remains near-frontier under several future demand scenarios.

domain: policy

example: Favor a policy option whose cost-benefit-position remains acceptable under uncertain uptake rates.

failure_modes: Over-conservatism that rejects legitimate frontier gains because all uncertainty is treated as equally important.

Stakeholder Frontier Deliberation

short_definition: Uses the frontier as a shared deliberation object when different stakeholders value frontier points differently.

distinctive_feature: The frontier is embedded in a legitimacy process rather than treated as a purely technical choice.

distinct_from_parent: The parent can be used by one decision-maker; this variant requires multi-party deliberation and rationale capture.

still_same_parent_because: The shared object remains a non-dominated frontier of options.

use_when: No single actor legitimately owns the tradeoff.

use_when: The selected frontier point distributes benefits and burdens unevenly.

use_when: Legitimacy depends on explaining why a non-dominated option was chosen over other efficient alternatives.

example: Discuss transit options that are all efficient but distribute cost, access, and disruption differently.

example: Choose among efficient hybrid-work policies with different effects on collaboration, flexibility, and equity.

failure_modes: A technical frontier can launder political choices if affected stakeholders cannot challenge dimensions or assumptions.

Efficient Frontier Portfolio Selection

short_definition: Uses an efficient frontier to select a portfolio-like bundle balancing expected value, risk, liquidity, resilience, or time horizon.

distinctive_feature: The option is a portfolio composition, not only a single item or policy.

distinct_from_parent: The parent can select any non-dominated option; this variant is specifically portfolio-like and may overlap with resource portfolio balancing.

still_same_parent_because: It still navigates non-dominated tradeoff options rather than managing target weights over time as the main intervention.

use_when: The choice is a bundle or portfolio rather than a single design.

use_when: Different mixes produce different risk-return or resilience profiles.

use_when: The decision needs to avoid dominated portfolios before strategic allocation is chosen.

example: Compare research portfolios that differ in expected impact, risk, time horizon, and resilience.

domain: budgeting

example: Select a program mix that is not dominated on cost, reach, and quality.

failure_modes: Collapsing into resource_portfolio_balancing if ongoing allocation governance, not frontier choice, becomes the core intervention.

near_names:
Pareto Frontier Selection
Efficient Frontier Selection
Efficient Frontier Navigation
Non-Dominated Option Selection
Pareto-Efficient Choice
Frontier Tradeoff Navigation