Dimensional Consistency Check

batch: First Iteration/Batch 29

slug: representation

slug: scale

slug: uncertainty

components:
Variable List
Unit / Dimension Map
Quantity Semantics
Operation Compatibility Rule
Scale Basis
Consistency Test
Dimensionless Group
Correction Rule
Transfer Boundary
Reference Standard
Tolerance Threshold
Audit Trail
Edge-Case Quantity Check

mechanisms:
Unit Check
Dimensional Analysis Table
Unit Conversion Workflow
Normalized Metric Design
Per-Capita or Per-Unit Conversion
Dimensionless Ratio Construction
Stock / Flow Separation Check
Spreadsheet Unit Audit
Model Input / Output Contract
Cross-Scale Transfer Review
Finance / Accounting Unit Check
Engineering Equation Sanity Check

essence_one_line: Check that quantities, units, and scale relationships are compatible before trusting equations, comparisons, or transfers.

compression_statement: When formulas, metrics, comparisons, or model transfers combine quantities, verify dimensional consistency so invalid operations, misleading normalizations, and scale-transfer errors are caught before they influence decisions.

core_intuition: Numbers and symbols can look compatible because they share a table, equation, dashboard, or sentence. Dimensional Consistency Check asks a more basic question: do these quantities actually live on compatible dimensions, units, denominators, time bases, and scale meanings? A calculation can be arithmetically correct while still combining things that should not be combined. The intervention makes the hidden quantity structure visible, tests it, and forces correction before the result becomes authoritative.

canonical_formula: quantity_set + unit_dimension_map + operation_compatibility_rule + consistency_test + correction_or_transfer_boundary → dimensionally_valid_expression_or_rejected_comparison

structural_problem: A model, calculation, comparison, metric, or policy rule mixes quantities whose units, dimensions, denominators, time bases, or scale meanings may be incompatible.

condition: A formula or spreadsheet combines values from different sources.

why_it_matters: Different sources often use different unit conventions, denominators, time windows, or implicit assumptions.

condition: Teams compare totals, percentages, rates, indexed values, or normalized scores.

why_it_matters: These quantities answer different questions even when they are displayed side by side.

condition: A metric or model is transferred from one scale, population, jurisdiction, or system to another.

why_it_matters: A valid local expression may become invalid when denominators, fixed costs, population structure, or scale effects change.

condition: A result looks precise, automated, or mathematically formal.

why_it_matters: Formal presentation can hide basic compatibility errors and make reviewers less likely to ask what the quantities mean.

condition: Values have the same unit label but different semantic meaning.

why_it_matters: Unit compatibility does not guarantee that the quantities represent the same construct or valuation basis.

condition: A decision depends on a ratio, rate, index, or coefficient.

why_it_matters: The chosen numerator and denominator define the meaning of the number; if they are wrong, the result can be misleading despite unit cancellation.

symptom: A calculation produces a plausible number but no one can say what units the output has.

diagnostic_meaning: The expression may be dimensionally undefined or the output meaning was not specified.

symptom: Raw totals are compared across differently sized entities.

diagnostic_meaning: The comparison may need a per-unit or per-capita basis, or may need both total and normalized views.

symptom: Percentages, percentage-point changes, and ratios are used interchangeably.

diagnostic_meaning: Scale basis and operation rules are not being enforced.

symptom: One-time costs are compared with recurring costs without conversion.

diagnostic_meaning: Stock/flow or time-basis mismatch is likely.

symptom: A model works in a pilot but fails after rollout or transfer.

diagnostic_meaning: The expression may not be scale-invariant or may rely on a hidden local denominator.

symptom: Different teams report the same metric name with different definitions.

diagnostic_meaning: Quantity semantics and reference standards are missing.

symptom: A dashboard ranking changes dramatically after normalization, but the reason is unclear.

diagnostic_meaning: The normalization basis may be driving the conclusion rather than the underlying phenomenon.

root_tension: Formal operations make quantities easy to combine, but meaningful combination requires compatibility that the notation alone does not guarantee. The tension is between computational convenience and structural validity.

condition: The quantities are already governed by a trusted, inspected unit and definition contract, and no comparison or transfer is being made.

why_not_this: Routine use may not require a fresh archetype-level intervention.

condition: The issue is factual inaccuracy in source data rather than incompatibility among quantities.

why_not_this: Data Integrity Preservation or source validation is more central.

condition: The issue is uncertainty or confidence in an estimate, but the units and dimensions are already compatible.

why_not_this: Uncertainty Explicitness, confidence interval handling, or risk weighting is more central.

condition: The issue is choosing the right model form or representation rather than checking quantity compatibility inside a proposed form.

why_not_this: Representation Fit Selection or scale-appropriate modeling may be the parent intervention.

structural_intervention: Expose the quantity structure of the proposed expression, test compatibility across units, dimensions, denominators, time bases, and scale meanings, then correct or reject invalid operations before they shape decisions.

Name the quantities

logic: List every variable, metric, input, output, intermediate value, denominator, and comparison target.

Map unit and dimension structure

logic: Assign units, dimensions, time basis, denominator, scale basis, measurement convention, and reference frame to each quantity.

Define allowed operations

logic: State which quantities may be added, compared, divided, aggregated, averaged, transformed, or transferred, and under what conditions.

Run the consistency test

logic: Check whether the proposed formula, metric, comparison, or model transfer preserves compatible dimensional meaning.

Construct compatible forms if needed

logic: Convert units, normalize denominators, separate stocks from flows, construct dimensionless groups, or redefine metrics when the original expression is invalid.

Record correction and boundary

logic: Document conversions, assumptions, tolerance thresholds, and transfer boundaries so future users know when the expression must be rechecked.

rule: Only add or subtract quantities that share compatible dimensions, units, semantic meaning, and reference frame.

rationale: Addition and subtraction require stronger compatibility than many other operations.

rule: Only compare quantities after their denominator, time basis, and scale basis are explicit.

rationale: A raw total, a rate, and a percentage can all be valid but answer different questions.

rule: Treat unit cancellation as necessary but not sufficient for meaningful ratios.

rationale: A ratio can be dimensionless and still semantically empty or decision-misleading.

rule: Reject or redesign expressions whose output units cannot be interpreted.

rationale: An uninterpretable output is a signal that the operation is structurally invalid or underspecified.

rule: Recheck expressions when moving across unit systems, populations, time windows, scales, or domains.

rationale: Transfer can change the dimensional meaning even when symbols stay the same.

invariant: Quantity meaning remains stable across the calculation or comparison.

why_preserve: Without stable meaning, the result is formally precise but substantively invalid.

invariant: Units and dimensions are compatible for the operation being performed.

why_preserve: This guards against impossible equations and invalid comparisons.

invariant: Denominators and time bases are visible.

why_preserve: Rates, percentages, and normalized values depend on hidden bases.

invariant: Conversions are traceable.

why_preserve: Later reviewers need to know whether errors entered through unit conversion or convention changes.

invariant: Transfer boundaries are explicit.

why_preserve: A valid expression should not silently become universal.

outcome: Invalid comparisons are caught before they become evidence.

how_measured: Rejected or corrected expressions are documented before decision use.

outcome: Metrics become more interpretable and auditable.

how_measured: Each metric has a visible denominator, unit convention, and meaning.

outcome: Model transfers become safer.

how_measured: Transfer boundaries and recheck conditions are documented.

outcome: Cross-domain reasoning improves.

how_measured: Analogies and benchmarks preserve scale and quantity structure rather than just surface similarity.

outcome: Decision confidence is based on valid structure rather than formal polish.

how_measured: Reviewers can explain why a result is dimensionally meaningful.

prose_essence:
Dimensional Consistency Check prevents formal-looking calculations, metrics, comparisons, and model transfers from being trusted before their quantities are structurally compatible. It asks whether the numbers being combined or compared share compatible units, dimensions, denominators, time bases, scale bases, and meanings.

The archetype is broader than a unit check. A unit check catches inches mixed with centimeters or seconds mixed with milliseconds. Dimensional consistency also catches subtler failures: totals compared with rates, one-time costs compared with recurring costs, nominal dollars compared with present-value dollars, ratios whose units cancel but whose meaning is arbitrary, or pilot metrics reused at a different scale without a transfer boundary.

prose_when_to_use:
Use this archetype when a decision depends on a formula, metric, dashboard, model output, benchmark, normalized score, rate, ratio, or cross-context transfer. It is especially important when quantities come from multiple systems, when normalized metrics hide denominators, when a calculation appears precise, or when a result will influence safety, finance, policy, operations, or automated decisions.

It is less useful when the main problem is corrupt source data, missing evidence, representational aesthetics, or disagreement about values. In those cases, dimensional checking may still be a supporting review, but it is not the parent intervention.

prose_structural_problem:
The structural problem is that formal operations are easier than meaningful operations. A spreadsheet can add columns whose units do not match. A dashboard can rank percentages, totals, and rates side by side. A model can accept inputs with hidden unit conventions. A policy memo can compare regions of very different size without exposing denominators. These artifacts produce numbers that look usable even when the underlying quantities are incompatible.

The dangerous feature is that the error is often invisible. The output may be precise, visually polished, or mathematically sophisticated. Without an explicit compatibility check, reviewers may focus on the conclusion rather than the structure of the quantities that produced it.

prose_intervention_logic:
The intervention starts by naming all quantities involved. Then it maps their units, dimensions, denominators, time bases, measurement conventions, and reference frames. Next, it states which operations are allowed: what may be added, compared, divided, averaged, normalized, aggregated, or transferred. The consistency test then checks whether the proposed operation preserves dimensional meaning.

If the expression fails, the archetype does not merely flag an error. It routes the problem through a correction rule: convert units, normalize the denominator, separate stocks from flows, construct a meaningful dimensionless ratio, redefine the metric, reject the comparison, or escalate for redesign. Finally, it records the transfer boundary so future users know when the expression must be checked again.

prose_key_components:
### Variable List

The variable list names every quantity, metric, input, output, denominator, and intermediate value. This prevents hidden variables from entering through formulas, dashboards, or prose claims. If a quantity is not named, it cannot be checked.

### Unit / Dimension Map

The unit/dimension map assigns each quantity a unit, dimension, denominator, time basis, scale basis, and reference frame. It distinguishes values that look similar but are not commensurable, such as dollars versus dollars per month or counts versus rates.

### Quantity Semantics

Quantity semantics define what each measured quantity means in context. Two values can share units while representing different constructs, such as nominal dollars, present-value dollars, replacement-cost dollars, or annual recurring dollars.

### Operation Compatibility Rule

The operation compatibility rule states which operations are allowed for the mapped quantities. Addition, comparison, division, aggregation, and transfer each require different compatibility conditions.

### Scale Basis

The scale basis records whether a quantity is a raw total, per-unit rate, per-capita rate, percentage, indexed value, normalized score, log-scale value, or time rate. Many bad comparisons arise because this basis is implicit.

### Consistency Test

The consistency test verifies whether the proposed equation, comparison, metric, policy rule, or model transfer preserves compatible dimensional meaning. It can be a formal dimensional analysis or a practical review checklist.

### Dimensionless Group

A dimensionless group is a ratio, index, or coefficient whose units cancel or whose scale basis is intentionally defined. It can make cross-scale comparison possible, but only if the numerator, denominator, and interpretation are meaningful.

### Correction Rule

The correction rule says what happens when a mismatch appears. The answer may be conversion, normalization, separation, redesign, rejection, or escalation. Without a correction rule, dimensional review becomes advisory rather than protective.

### Transfer Boundary

The transfer boundary states where the checked expression remains valid. A formula or metric that is valid in one unit system, population, time window, or scale may need rechecking when moved elsewhere.

prose_common_mechanisms:
### Unit Check

A unit check verifies compatible unit labels across inputs, outputs, and intermediate calculations. It is a mechanism under the archetype, not the archetype itself, because dimensional consistency also includes denominators, quantity meaning, scale basis, and transfer validity.

### Dimensional Analysis Table

A dimensional analysis table records variables, dimensions, units, conversions, and cancellation logic. It is useful when equations, model formulas, or repeated calculations need systematic review.

### Unit Conversion Workflow

A unit conversion workflow converts quantities into a shared convention before they are combined. It must preserve conversion factors and assumptions; conversion alone does not prove that the quantities mean the same thing.

### Normalized Metric Design

Normalized metric design creates per-unit, per-capita, indexed, or standardized metrics so comparisons are made on a compatible basis. It implements the archetype when the denominator and interpretation are explicit.

### Per-Capita or Per-Unit Conversion

This mechanism converts totals into rates against a clear denominator. It is useful for benchmarking differently sized entities, but it can mislead if absolute burden or capacity still matters.

### Dimensionless Ratio Construction

Dimensionless ratio construction builds ratios or coefficients whose dimensions cancel or whose reference basis is explicit. It supports transfer across scale only when the ratio has a real interpretation.

### Stock / Flow Separation Check

A stock/flow check distinguishes accumulated quantities from rates over time. It prevents comparisons such as one-time cost versus monthly cost or prevalence versus incidence from being treated as direct equivalents.

### Spreadsheet Unit Audit

A spreadsheet unit audit reviews columns, formulas, labels, denominators, and hidden conversions. It is valuable because spreadsheet errors often arise from unlabeled intermediate values.

### Model Input / Output Contract

A model input/output contract defines units, dimensions, scale bases, expected ranges, and meanings for model fields. It helps prevent upstream data changes from silently invalidating downstream models.

### Cross-Scale Transfer Review

A cross-scale transfer review checks whether a metric, rule, or equation remains valid after moving from pilot to rollout, local to global, lab to field, or one domain to another.

### Finance / Accounting Unit Check

This mechanism separates currencies, time periods, accounting bases, nominal versus real values, and one-time versus recurring amounts. It catches money-like quantities that are not actually interchangeable.

### Engineering Equation Sanity Check

This familiar mechanism verifies that formulas, constants, coefficients, and calculated outputs are dimensionally coherent and plausible. It anchors the archetype but does not exhaust it.

prose_failure_modes:
Unit-label tunnel vision occurs when reviewers verify unit labels but ignore denominator, time basis, or construct meaning. False equivalence through normalization occurs when a normalized metric makes unlike cases look comparable. Dimensionless nonsense occurs when a ratio is accepted because units cancel even though the ratio has no useful interpretation.

Stock-flow confusion occurs when accumulated quantities are compared with rates. Transfer overreach occurs when a locally valid expression is reused universally. Bureaucratic checklist decay occurs when dimensional review is completed but has no power to change the decision. Hidden conversion assumptions occur when currency bases, fiscal periods, or rounding rules are applied invisibly.

prose_neighbor_distinctions:
Dimensional Consistency Check is distinct from Parameter Rescaling. Parameter Rescaling changes a model’s parameterization or numeric range; Dimensional Consistency Check verifies compatibility before trusting a calculation or comparison.

It is distinct from Conservation Accounting. Conservation Accounting tracks a conserved quantity across transformations. Dimensional Consistency Check asks whether quantities may be combined or compared at all.

It is distinct from Stationarity Validation. Stationarity Validation asks whether statistical properties remain stable over time or context. Dimensional Consistency Check asks whether units, dimensions, denominators, and scale meanings are compatible.

It is distinct from False Precision Avoidance. False Precision Avoidance prevents overstating certainty or resolution. Dimensional Consistency Check prevents structurally incompatible quantities from being made precise in the first place.

It is distinct from Representation Fit Selection. Representation Fit Selection chooses the representational form. Dimensional Consistency Check validates the quantity structure inside or across representations.

prose_cross_domain_examples: In engineering, a design calculation is checked to ensure its output has the intended dimension. In finance, one-time capital cost is separated from annual operating cost and discounted lifecycle cost. In public health, incidence, prevalence, raw case counts, and test positivity are not treated as interchangeable. In operations, backlog size, arrival rate, service time, and throughput are separated before staffing decisions. In product analytics, active users, retention, total revenue, and revenue per user are labeled with their distinct bases before a growth narrative is presented.

prose_non_examples: Adding more decimal places to a number is not dimensional consistency. Choosing a more attractive chart is not dimensional consistency unless the underlying quantities are incompatible. Fixing missing records is data integrity work. Rejecting a KPI because it incentivizes the wrong behavior is objective alignment or incentive design unless the KPI also combines incompatible quantities.

prose_tradeoffs:
The main tradeoff is speed versus validity. Checking dimensions slows the production of numbers, but the delay is often smaller than the cost of acting on invalid numbers. Another tradeoff is simplicity versus semantic fidelity: a single normalized score can make communication easier while hiding denominator choices or absolute magnitude.

There is also a tradeoff between standardization and local meaning. Common unit conventions help systems interoperate, but they can obscure context-specific quantities. Finally, automation improves coverage but can miss cases where two quantities share a unit label but represent different constructs.

prose_invariants_to_preserve: The most important invariant is quantity meaning. The same symbol or metric name should not change meaning during a calculation or transfer. Units and dimensions must remain compatible for the operation being performed. Denominators and time bases must remain visible. Conversions must be traceable. Transfer boundaries must be explicit enough that future users know when the expression must be checked again.

prose_target_outcomes: The target outcome is not mathematical elegance for its own sake. The goal is to prevent invalid formal structures from driving decisions. A successful dimensional consistency check produces interpretable metrics, auditable calculations, safer model transfers, clearer benchmarks, and fewer decisions based on incompatible quantities.

prose_parameter_dimensions:
Strictness can range from advisory warnings to hard blocks. High-stakes safety, finance, or automated decisions usually need hard rejection of incompatible expressions. Exploratory work may tolerate advisory flags.

Granularity can range from unit labels only to full quantity semantics. A simple conversion may be enough for routine unit-system mismatches; cross-scale policy comparisons may require denominator, time-window, construct, and transfer-boundary review.

Normalization basis is a central tuning choice. Raw totals, rates, indexed scores, and dimensionless ratios can all be valid, but they answer different questions. The archetype should expose the choice rather than hiding it inside a single score.

Automation level also matters. Automated unit contracts are useful for routine pipelines, but semantic quantity alignment often requires human judgment.

prose_variants_and_near_names:
Unit Consistency Check is the unit-focused variant. Scale Normalization Check focuses on raw totals, rates, percentages, indices, and denominator-adjusted comparisons. Dimensionless Ratio Design focuses on ratios or coefficients whose dimensions cancel or whose basis is explicitly defined. Semantic Quantity Alignment checks cases where unit labels match but meanings differ. Cross-Scale Transfer Check focuses on whether expressions remain valid after moving across scale or context. Stock / Flow Separation focuses on accumulated quantities versus rates over time.

Near names include Dimensional Analysis Check, Dimensional Sanity Check, Unit Sanity Check, Scale Consistency Review, and apples-to-apples comparison. Unit check, dimensional analysis table, per-capita conversion, and normalized metric should remain mechanisms or variants unless future reconciliation shows distinct standalone structure.

Unit Consistency Check

short_definition: A narrower variant focused on compatible unit labels and conversions across inputs, formulas, and outputs.

distinctive_feature: It emphasizes unit labels, conversion factors, and input/output compatibility more than semantic quantity meaning or cross-scale transfer.

distinct_from_parent: The parent includes units, dimensions, denominators, scale basis, and transfer boundaries. This variant concentrates on the unit-compatibility layer.

still_same_parent_because: It uses the same intervention logic: make quantity structure explicit, test compatibility, and correct mismatches before use.

condition: A calculation or workflow combines values from multiple sources or unit systems.

why_it_matters: Unit conversion errors can produce formally precise but invalid outputs.

condition: Inputs are entered manually or imported from systems that use different conventions.

why_it_matters: Implicit unit assumptions can change the magnitude of a result without changing the formula structure.

Unit / Dimension Map

role: Records unit labels and dimensions for each quantity.

Reference Standard

role: Defines the unit convention used for conversion.

Correction Rule

role: Specifies conversion or rejection of incompatible entries.

Unit Check

role: Checks unit labels before calculation.

Unit Conversion Workflow

role: Converts quantities to a common convention.

example_domains: engineering data_pipelines finance operations

domain: Engineering

example: Convert all forces, lengths, and material constants into a shared convention before evaluating a design equation.

domain: Analytics

example: Check whether imported fields are in seconds, minutes, or milliseconds before computing response-time statistics.

failure_modes: Treating unit labels as sufficient while ignoring denominator or quantity meaning.

failure_modes: Applying conversion factors without preserving uncertainty, rounding, or precision limits.

Scale Normalization Check

short_definition: A variant that verifies totals, rates, percentages, indexed values, and normalized metrics are being compared on a compatible basis.

distinctive_feature: The central concern is not unit conversion but the basis of comparison: total versus rate, absolute versus indexed, or raw versus normalized.

distinct_from_parent: The parent covers dimensional compatibility generally; this variant focuses on the scale basis selected for comparison.

still_same_parent_because: It still tests whether the quantities being compared preserve compatible dimensional meaning.

source_primes: scale representation

condition: Entities of different sizes are compared using raw totals.

why_it_matters: Raw totals can hide per-unit intensity or per-person burden.

condition: Normalized scores or indices replace original quantities.

why_it_matters: Normalization can clarify comparison but may hide absolute magnitude or denominator choice.

Scale Basis

role: Names the basis used for comparison.

Dimensionless Group

role: Creates scale-aligned ratios or indices when appropriate.

Quantity Semantics

role: Checks that normalization preserves the decision-relevant meaning.

Normalized Metric Design

role: Creates denominator-adjusted metrics.

Per-Capita or Per-Unit Conversion

role: Aligns quantities to a shared denominator.

example_domains: policy benchmarking public_health operations

domain: Public policy

example: Compare incidents per 100,000 people rather than total incidents when jurisdictions have very different populations.

domain: Operations

example: Compare cost per processed case rather than total cost when teams handle different volumes.

failure_modes: Choosing a denominator that flatters one option.

failure_modes: Hiding absolute load, concentration, or capacity limits behind a normalized score.

Dimensionless Ratio Design

short_definition: A variant focused on constructing ratios, coefficients, or indices that remove units or expose scale-invariant structure.

distinctive_feature: It deliberately creates a new dimensionless or normalized quantity rather than merely checking an existing expression.

distinct_from_parent: The parent can reject, convert, normalize, or redesign quantities. This variant emphasizes ratio construction as the chosen correction.

still_same_parent_because: The constructed ratio is justified by the same compatibility logic and must preserve dimensional meaning.

condition: A comparison must transfer across sizes, units, contexts, or scales.

why_it_matters: Dimensionless ratios can reveal comparable structure where raw units cannot.

condition: A model needs a compact parameter that combines multiple quantities.

why_it_matters: Ratio design can compress dimensional structure, but only if the numerator and denominator are meaningful.

Dimensionless Group

role: Holds the constructed ratio or index.

Operation Compatibility Rule

role: Verifies cancellation and interpretability.

Transfer Boundary

role: States where the ratio remains valid.

Dimensionless Ratio Construction

role: Builds the ratio or index.

Cross-Scale Transfer Review

role: Tests whether the ratio remains meaningful across scale.

example_domains: engineering finance public_health benchmarking

domain: Finance

example: Use debt-to-income ratio rather than debt alone when comparing borrowing burden across incomes.

example: Use a dimensionless coefficient to compare behavior across differently sized systems.

failure_modes: Creating an index whose units cancel but whose meaning is arbitrary.

failure_modes: Treating a dimensionless number as universally transferable without checking context.

Semantic Quantity Alignment

variant_type: other

short_definition: A candidate variant that checks whether quantities with compatible units actually represent the same construct or decision-relevant meaning.

distinctive_feature: The mismatch is semantic rather than purely dimensional: the units may be compatible, but the represented quantity is not.

distinct_from_parent: The parent includes semantic checks as one component. This variant would foreground construct meaning and correspondence.

still_same_parent_because: It remains a compatibility check on formal quantities before comparison or transfer.

condition: Values share units but come from different definitions, accounting bases, populations, or measurement methods.

why_it_matters: Unit compatibility alone may create false equivalence.

condition: A metric is reused in a new domain because its label looks familiar.

why_it_matters: Same label does not guarantee same measurement semantics.

Quantity Semantics

role: Defines what each quantity means.

Transfer Boundary

role: Prevents semantic drift during reuse.

Consistency Test

role: Checks whether matching units imply matching meaning.

Model Input / Output Contract

role: Defines expected quantity meaning.

Finance / Accounting Unit Check

role: Separates valuation and accounting bases.

example: Distinguish nominal dollars, constant dollars, present-value dollars, and annual recurring dollars before comparison.

domain: Research

example: Check whether two instruments reporting the same numeric score measure the same construct.

failure_modes: Over-formalizing semantic judgment as if every construct can be reduced to a unit label.

failure_modes: Collapsing into correspondence_validation if the core issue is empirical correspondence rather than dimensional compatibility.

Cross-Scale Transfer Check

short_definition: A variant that verifies whether an equation, rule, metric, or comparison remains valid when moved across scale, population, scope, or context.

distinctive_feature: It emphasizes the validity boundary of a checked expression under scale change.

distinct_from_parent: The parent checks consistency generally; this variant makes transfer across scale the central hazard.

still_same_parent_because: It still depends on explicit quantities, units, denominators, and correction rules.

condition: A pilot metric, model, or calculation is being generalized to a larger setting.

why_it_matters: Dimensional validity and denominator meaning may change with scale.

condition: An equation or benchmark from one domain is imported into another.

why_it_matters: Transfer can fail even when the algebraic form is unchanged.

Transfer Boundary

role: Defines where validity travels.

Scale Basis

role: Records the comparison basis before and after transfer.

Edge-Case Quantity Check

role: Tests breakdown conditions.

Cross-Scale Transfer Review

role: Reviews validity after scale change.

Normalized Metric Design

role: Redesigns metrics for comparability.

domain: Policy

example: Check whether a per-student cost estimate from one district transfers to another with different fixed costs and population density.

example: Check whether a throughput rule from one team remains valid when applied to many teams with shared bottlenecks.

failure_modes: Assuming scale invariance when fixed costs, nonlinear effects, or denominator changes matter.

failure_modes: Treating a local ratio as a universal benchmark.

Stock / Flow Separation

short_definition: A variant that prevents accumulated quantities from being confused with rates or flows over time.

distinctive_feature: The central mismatch is time dimension: accumulated state versus rate of change or flow.

distinct_from_parent: The parent covers many dimensions; this variant focuses on temporal dimensionality.

still_same_parent_because: It uses unit/dimension mapping and operation compatibility rules to prevent invalid comparisons.

condition: A metric mixes totals, balances, incidence rates, throughput, or time-indexed costs.

why_it_matters: Stocks and flows answer different questions and cannot be substituted without transformation.

condition: Dashboards or policies compare a one-time amount with a recurring rate.

why_it_matters: The comparison can drive wrong investment, staffing, or risk decisions.

Unit / Dimension Map

role: Marks time dimensions explicitly.

Operation Compatibility Rule

role: Blocks stock-flow comparisons without transformation.

Correction Rule

role: Converts or separates values when valid.

Stock / Flow Separation Check

role: Checks state-rate mismatches.

Finance / Accounting Unit Check

role: Separates one-time and recurring values.

example: Separate one-time capital expense from monthly operating expense before comparing project costs.

domain: Public health

example: Distinguish prevalence from incidence before interpreting disease burden.

failure_modes: Treating a rate as a level or a level as a rate.

failure_modes: Hiding time-window differences in labels such as monthly, annualized, or trailing average.

near_names:
Dimensional Analysis Check
Unit Sanity Check
Apples-to-Apples Comparison
Unit Check
Dimensional Analysis Table
Per-Capita Conversion
Normalized Metric
Scale-Invariant Ratio


Dimensionality Reduction for Signal

type: archetype

source: generated

batch: First Iteration/Batch 30

slug: compression

slug: dimension

slug: abstraction

slug: parsimony

slug: overfitting

slug: complexity

slug: robustness

slug: transparency

components:
Feature Set
Reduction Purpose
Preservation Target
Dimensionality Budget
Reduction Method
Latent Dimension
Information Loss Metric
Interpretability Check
Validation Task
Preprocessing Rule
Domain Constraint
Stability Check
Back-Projection Explanation

mechanisms:
PCA-like Projection
Embedding Projection
Feature Selection
Latent Variable Model
Summary Index Construction
Feature Clustering
Supervised Representation Learning
Dashboard Metric Consolidation

essence_one_line:
Reduce many variables into fewer informative dimensions so structure becomes visible without
drowning in noise.

compression_statement:
When high-dimensional data, indicators, features, or options obscure useful patterns, replace
the original space with a smaller purpose-fit representation, preserve the information needed
for the task, measure what is lost, and validate that the reduced dimensions remain interpretable
and decision-relevant.

core_intuition:
More variables do not automatically produce more understanding. Past a point, redundant,
correlated, noisy, or weakly relevant dimensions make patterns harder to see and decisions
harder to defend. This archetype turns reduction into a governed intervention: compress only
for a stated purpose, keep the signal that matters, and make the cost of simplification visible.

canonical_formula:
feature_space + reduction_purpose + preservation_target + reduction_method + loss_check +
interpretability_check -> reduced_representation + validated_signal + explicit_limits

structural_problem:
A system is represented with too many variables, indicators, features, categories, or degrees
of freedom for people or models to identify the important structure. Redundancy, correlation,
irrelevant variation, and noisy measurements obscure the signal, while informal simplification
risks discarding exactly the information needed for the decision.

trigger_conditions: A dataset, dashboard, choice space, or diagnostic frame contains many variables but only a smaller number of patterns appears to drive useful judgment.

trigger_conditions: Variables are correlated, redundant, sparse, highly noisy, or too numerous relative to the amount of evidence available.

trigger_conditions: The current representation makes visualization, modeling, communication, or comparison difficult because the number of dimensions overwhelms human or computational capacity.

trigger_conditions: Decision-makers need a compact representation but cannot safely collapse variables without preserving task-relevant differences.

trigger_conditions: A downstream model, index, segment, visualization, or monitoring system performs poorly because feature sprawl amplifies noise and overfitting.

trigger_conditions: The cost of collecting, processing, or explaining every variable exceeds the benefit of keeping the full representation.

symptoms: Dashboards show dozens of metrics but no clear operational signal.

symptoms: Models perform well on training data but poorly on new data because too many features chase noise.

symptoms: Analysts repeatedly discover that many variables move together but continue treating them as independent indicators.

symptoms: Stakeholders argue over individual measures because there is no validated summary dimension.

symptoms: Visualizations become unreadable, with too many axes, categories, or overlapping indicators.

symptoms: Teams delete variables ad hoc, then cannot explain which information was lost or preserved.

symptoms: Different groups build incompatible indexes from the same underlying feature set.

root_tension:
The system needs enough detail to preserve meaningful distinctions, but enough compression to
make patterns discoverable, communicable, and usable. Too little reduction leaves noise and
cognitive overload; too much reduction creates false simplicity and hidden loss.

anti_signatures: The original variables are few, independent, interpretable, and already aligned with the decision.

anti_signatures: The goal is only to store data more compactly, not to reveal or preserve decision-relevant structure.

anti_signatures: Each variable carries a legally, ethically, or operationally mandatory meaning that cannot be merged or projected away.

anti_signatures: The reduction would be used as a black box to hide contested value judgments or exclude affected groups from scrutiny.

anti_signatures: The problem is primarily choosing between representation formats rather than reducing a feature or indicator space.

structural_intervention:
Define the purpose of reduction, identify the original feature space, choose a reduction path
that preserves the information needed for the task, measure information loss and distortion,
validate the reduced representation against external or downstream criteria, and communicate
the boundaries of interpretation.

action_logic: Name the decision, model, comparison, visualization, or explanation that the reduced representation must support.

action_logic: Inventory the original variables and identify redundancy, correlation, sparsity, irrelevant variation, and known protected or critical distinctions.

action_logic: Define a preservation target: variance, predictive power, neighborhood relation, ordering, cluster structure, fairness-relevant subgroup distinction, interpretability, or domain meaning.

action_logic: Select a reduction mechanism that fits the preservation target rather than defaulting to a familiar algorithm.

action_logic: Construct the reduced dimensions, factors, selected features, embedding, summary index, or latent variables.

action_logic: Evaluate what was lost, distorted, merged, or made less interpretable by the reduction.

action_logic: Validate the reduced representation against the intended task and check stability across samples, groups, time, or perturbations.

action_logic: Use the reduced representation with explicit interpretation rules and keep an escalation path back to the full feature space when anomalies or high-stakes decisions require detail.

decision_rules: Use dimensionality reduction only when the reduction purpose is explicit and can be evaluated.

decision_rules: Do not prefer the smallest representation; prefer the smallest representation that preserves the needed signal and critical distinctions.

decision_rules: Choose mechanism families by the relation to preserve: variance, prediction, distance, rank, clustering, domain construct, or interpretability.

decision_rules: Require an information-loss or performance check before treating the reduced dimensions as sufficient.

decision_rules: Require interpretability or traceability when the reduced representation informs consequential human decisions.

decision_rules: Keep subgroup, boundary, and outlier checks when reduction could erase minority patterns or rare hazards.

decision_rules: Revisit the reduction when the data distribution, measurement system, or decision context changes.

target_invariants: Task-relevant signal is preserved well enough for the intended use.

target_invariants: Information loss is explicit rather than hidden by the elegance of the reduced form.

target_invariants: The reduction mechanism is matched to the preservation target.

target_invariants: Reduced dimensions are interpretable, traceable, or explicitly marked as opaque when opacity is unavoidable.

target_invariants: Critical subgroup, safety, legal, or domain distinctions are not silently merged away.

target_invariants: Validation uses evidence outside the same reduction procedure whenever possible.

target_invariants: Users can distinguish the reduced representation from the full system it approximates.

expected_outcomes: Patterns that were obscured by feature sprawl become easier to detect, communicate, and test.

expected_outcomes: Models or decisions become less vulnerable to noise, redundancy, and overfitting.

expected_outcomes: Dashboards, indexes, and comparisons become more usable without pretending that no information was lost.

expected_outcomes: Teams gain a shared compact representation for reasoning about complex systems.

expected_outcomes: Analysts can explain why dimensions were removed, merged, or transformed.

expected_outcomes: Downstream uncertainty and interpretation limits are easier to audit.

prose_essence:
Dimensionality Reduction for Signal is the practice of replacing an overwhelming variable space with a smaller, purpose-fit representation. The point is not simply to make the data smaller. The point is to make the relevant structure easier to see, explain, model, or act on while staying honest about what was lost.

This archetype applies when a system has many indicators, features, measures, categories, or axes and those dimensions obscure the pattern needed for a decision. A good reduction names the task, states what kind of signal must survive, chooses a mechanism that preserves that signal, and validates the result against the intended use.

prose_when_to_use:
Use this archetype when high-dimensional evidence is creating confusion, noise, overfitting, unreadable dashboards, or unmanageable comparison. It is especially useful when variables are redundant, correlated, sparse, or too numerous relative to the amount of evidence available.

It is also useful when people need a shared compact representation: a few health dimensions from many operational metrics, a smaller set of features for a model, a latent factor structure behind survey items, a policy index from many indicators, or an embedding space that makes similarity usable.

Do not use it merely because fewer variables look cleaner. If the task does not require reduction, if the original variables are already meaningful and manageable, or if each variable must remain individually accountable, reduction may create false simplicity rather than insight.

prose_structural_problem:
The structural problem is feature sprawl. The system is represented with more dimensions than people or models can use reliably. Some variables repeat the same information, some add mostly noise, some are weakly relevant, and some are meaningful only in combination. As the number of dimensions grows, it becomes harder to see what matters and easier to overfit, cherry-pick, or confuse complexity with understanding.

The opposite failure is careless simplification. Teams delete variables, average them, or project them into a small number of axes without checking whether critical information has disappeared. This can hide rare events, protected-group differences, safety signals, or domain meanings that do not dominate the average pattern.

prose_intervention_logic:
The intervention begins by naming the purpose of reduction. A reduction built for visualization may not work for prediction. A reduction built for prediction may not be interpretable enough for governance. A reduction built for a public index may need weighting transparency and challenge procedures that a private exploratory model does not need.

Next, the original feature set is inventoried. The reduction designer identifies redundancy, correlation, scale differences, missingness, outliers, domain constraints, and variables that must remain auditable. Then the designer names a preservation target: variance, distance, rank, cluster structure, predictive performance, construct meaning, subgroup distinction, or communication value.

Only after that does the designer choose a mechanism. PCA-like projections, feature selection, embeddings, latent variable models, summary indexes, and feature clustering all implement the archetype differently. After the reduced representation is created, it must be tested for information loss, interpretability, stability, and downstream performance.

prose_key_components:
- **Feature Set** (`feature_set`): the original variables, indicators, measurements, or attributes from which the reduced representation is built. This boundary matters because omitted variables cannot be recovered by a clever reduction.
- **Reduction Purpose** (`reduction_purpose`): the task the smaller representation must serve. It prevents method-first reduction and anchors validation.
- **Preservation Target** (`preservation_target`): the kind of information that must survive reduction, such as variance, prediction, similarity, ordering, clusters, domain constructs, or subgroup distinctions.
- **Dimensionality Budget** (`dimensionality_budget`): the target size or complexity of the reduced representation. The goal is not the smallest possible representation, but the smallest one that remains fit for purpose.
- **Reduction Method** (`reduction_method`): the implementation family used to select, project, aggregate, embed, cluster, or summarize variables. The method is a mechanism, not the archetype itself.
- **Latent Dimension** (`latent_dimension`): the reduced axis, factor, component, embedding coordinate, construct, or index that stands in for multiple original variables. It needs interpretation rules.
- **Information Loss Metric** (`information_loss_metric`): the check that shows what was discarded or distorted. This can be explained variance, reconstruction error, predictive degradation, subgroup error, or semantic loss.
- **Interpretability Check** (`interpretability_check`): the test of whether users can responsibly understand or trace the reduced dimensions. When the representation is opaque, the opacity itself must be governed.
- **Validation Task** (`validation_task`): an external or downstream test showing whether the reduced representation works for its stated purpose.

Optional components include preprocessing rules, domain constraints, stability checks, and back-projection explanations that connect reduced dimensions back to original variables.

prose_common_mechanisms:
- **PCA-like Projection** (`pca_like_projection`): reduces correlated variables into fewer linear axes that preserve major variance. It implements the archetype only when variance preservation is the right target and interpretation limits are documented.
- **Embedding Projection** (`embedding_projection`): maps complex objects into a lower-dimensional or learned space so similarity, neighborhood, retrieval, or clustering can be used. It requires monitoring for opacity, drift, and misleading visual interpretation.
- **Feature Selection** (`feature_selection`): keeps a smaller subset of original variables. It is useful when traceability matters and transformed latent dimensions would be hard to justify.
- **Latent Variable Model** (`latent_variable_model`): infers unobserved constructs from observed measures. It is appropriate when the reduced dimensions are meant to represent theoretical or domain concepts.
- **Summary Index Construction** (`summary_index_construction`): combines many indicators into fewer scores or indexes. It is especially sensitive to weighting, legitimacy, and hidden value judgments.
- **Feature Clustering** (`feature_clustering`): groups variables that behave similarly so each group can be represented by a prototype, centroid, or selected representative.
- **Supervised Representation Learning** (`supervised_representation_learning`): learns a compact representation optimized for a downstream task. It must be checked for overfitting, bias, and subgroup degradation.
- **Dashboard Metric Consolidation** (`dashboard_metric_consolidation`): turns metric sprawl into a smaller set of monitoring dimensions while preserving drill-down paths to original metrics.

These mechanisms implement the archetype; none of them is the archetype by itself.

prose_failure_modes:
The most common failure is purpose-free reduction: choosing a method because it is familiar or available, then inventing a purpose afterward. Another failure is false simplicity, where the reduced dimensions are treated as if they contain the whole truth. A third is erased minority signal, where reduction preserves dominant patterns while suppressing rare or marginalized ones.

Other failure modes include spurious latent meaning, overfit projections, metric laundering, unstable embeddings, and excessive reliance on visually appealing clusters. These failures are mitigated by explicit preservation targets, loss checks, subgroup diagnostics, stability tests, external validation, and cautious interpretation.

prose_neighbor_distinctions:
This archetype is close to **Task-Relevant Compression**, but it is narrower: it specifically reduces feature, variable, indicator, or dimensional spaces. It is close to **Representation Fit Selection**, but representation fit chooses how to present or model a situation, while dimensionality reduction changes the structure of the variable space itself.

It is related to **Essential Structure Extraction**, but essential structure can be conceptual or causal; this archetype is about lower-dimensional representation of many measured or defined dimensions. It overlaps with **Coarse Graining**, but coarse graining aggregates across scale, while dimensionality reduction may select, project, embed, cluster, or index variables.

It should not collapse into PCA, embeddings, or feature selection. Those are mechanisms. The archetype includes the full design logic: purpose, preservation target, method selection, loss governance, interpretation, validation, and boundaries.

prose_cross_domain_examples:
In bioinformatics, many gene-expression measurements may be reduced into latent components that reveal disease subtypes, provided clinically important markers and subgroup patterns remain visible.

In product analytics, dozens of behavioral metrics can be reduced into a few engagement dimensions validated against retention, user research, and support burden.

In public policy, many social, environmental, and infrastructure indicators can be consolidated into a vulnerability index, but only if weights, omitted variables, and equity-sensitive exceptions are documented.

In operations monitoring, correlated sensor measures can be clustered into health dimensions while preserving drill-down paths to raw telemetry when anomalies appear.

In machine learning, sparse text or image features can be compressed into embeddings for retrieval or classification, with validation for performance, semantic drift, and subgroup error.

prose_non_examples:
Deleting variables until software runs faster is not this archetype unless the loss is measured and the reduced representation is validated. Choosing a prettier chart for a small set of variables is visualization, not dimensionality reduction. Running PCA by default and assigning convenient meanings to components is method ritual, not governed reduction.

Averages that intentionally hide subgroup harms are also non-examples. They violate the invariant that critical distinctions must not be silently merged away.

prose_tradeoffs:
The main tradeoff is clarity versus fidelity. Fewer dimensions make patterns easier to see but inevitably discard or distort information. There is also a tradeoff between predictive power and interpretability: an embedding may be useful but hard to explain, while selected features may be transparent but less powerful.

Another tradeoff is global structure versus local exceptions. A reduction can capture dominant patterns while hiding rare cases. In safety, fairness, medicine, security, and public policy, rare cases may matter more than average explanatory elegance.

prose_invariants_to_preserve:
The key invariant is task-relevant signal. The reduced representation must preserve the structure needed for the decision, not merely produce a cleaner-looking form. Information loss must be visible, not hidden. Critical subgroup, safety, legal, or domain distinctions must not be silently merged away.

The method must match the preservation target. A reduction that preserves variance may fail to preserve predictive performance. A reduction that preserves similarity may fail to support causal interpretation. A reduction that supports public communication may be too crude for technical diagnosis.

Users must also remember that the reduced representation is an approximation of the original system. It should support action, not replace judgment about what has been compressed.

prose_target_outcomes:
A successful reduction makes structure visible. It reduces noise, redundancy, and cognitive load. It helps people compare cases, monitor systems, discover latent patterns, build more robust models, and communicate complex evidence without drowning in variables.

It should also improve governance. A well-designed reduction tells users why dimensions were removed or transformed, what information was preserved, what was lost, and where the reduced representation should not be trusted.

prose_parameter_dimensions:
Important tuning dimensions include the number of retained dimensions, the preservation target, the accepted information-loss threshold, the choice between selection and transformation, the balance between interpretability and performance, the preprocessing rules, the stability requirement, the validation task, and the escalation path back to the full feature set.

A reduction can be tuned conservatively by keeping more dimensions, prioritizing interpretability, and preserving drill-down access. It can be tuned aggressively by compressing more heavily, using learned representations, and accepting opacity in exchange for performance. High-stakes contexts usually require stronger auditability and weaker compression.

prose_variants_and_near_names:
Recognized variants include **Linear Projection for Variance**, **Feature Selection for Traceability**, **Embedding Projection for Similarity**, **Summary Index Reduction**, and **Supervised Signal Compression**. They differ mainly by what relation they preserve and what governance burden they create.

Near names include signal-preserving dimension reduction, feature-space compression, latent structure reduction, high-dimensional signal extraction, purpose-validated dimension reduction, PCA-like reduction, embedding projection, feature selection, latent variable modeling, and dashboard dimension reduction.

The policy for variants is conservative. Preserve a variant only when it changes the preservation target, interpretability burden, accountability risk, or validation logic. Collapse ordinary method names into mechanism records.

Linear Projection for Variance

short_definition: Reduce correlated variables into fewer linear axes that preserve major directions of variation.

distinctive_feature: It preserves dominant linear variation rather than selecting original variables or optimizing directly for a downstream task.

distinct_from_parent: The parent includes many reduction logics; this variant names the variance-preserving linear projection family.

still_same_parent_because: It still requires purpose, loss, interpretability, and validation checks to function as the archetype.

use_when: Variables are correlated and the main goal is to summarize variance structure.

use_when: A relatively transparent linear transformation is acceptable.

use_when: The reduced axes can be inspected through loadings or back-projection.

example: Many attitude items are reduced into a smaller number of factors for group comparison.

domain: finance

example: Correlated exposures are reduced into market, credit, and liquidity factor dimensions.

failure_modes: Treating high explained variance as proof of decision relevance.

failure_modes: Giving latent axes overconfident semantic names.

Feature Selection for Traceability

short_definition: Reduce dimensionality by keeping a smaller subset of original variables so decisions remain easier to trace.

distinctive_feature: It reduces by selection rather than transformation, preserving original variable meanings.

distinct_from_parent: The parent may create new latent dimensions; this variant deliberately keeps original features.

still_same_parent_because: It still compresses a feature space for a task and must measure lost information or performance.

use_when: Direct interpretability matters more than latent compression.

use_when: The full feature set is too large but some original variables can stand on their own.

use_when: Auditability or regulatory explanation requires variables that retain their original meaning.

example: A diagnostic rule keeps five measurable inputs instead of hundreds of possible predictors.

domain: operations

example: A monitoring system uses a small set of representative sensors with high traceability.

failure_modes: Dropping interacting or rare-case variables that matter.

failure_modes: Choosing familiar variables rather than validated ones.

Embedding Projection for Similarity

short_definition: Map complex objects into a lower-dimensional or learned space so similarity, neighborhood, or semantic relations can be used.

distinctive_feature: It emphasizes relational geometry and semantic neighborhood preservation, often with learned or nonlinear representations.

distinct_from_parent: The parent includes all governed dimension reductions; this variant names similarity-preserving embeddings.

still_same_parent_because: It still requires preservation targets, loss checks, interpretability or opacity governance, and task validation.

use_when: Objects are complex and direct feature comparison is difficult.

use_when: The important relation is similarity, neighborhood, retrieval, or clustering.

use_when: Users can tolerate some opacity if evaluation and monitoring are strong.

domain: search

example: Documents are embedded so semantically similar items can be retrieved even when words differ.

domain: visualization

example: High-dimensional image features are projected to inspect clusters and outliers.

failure_modes: Mistaking plotted proximity for causal or categorical truth.

failure_modes: Embedding drift under new data distributions.

Summary Index Reduction

short_definition: Combine many indicators into one or a few scores for monitoring, comparison, communication, or prioritization.

distinctive_feature: It often creates an artifact used for communication or ranking, so weighting and accountability become central.

distinct_from_parent: The parent may produce latent dimensions for analysis; this variant produces summary indexes for use by people or institutions.

still_same_parent_because: It is still a reduction of many indicators into fewer dimensions with explicit loss and validation requirements.

use_when: Many indicators must be communicated to nontechnical stakeholders.

use_when: A compact score will guide monitoring, prioritization, or comparison.

use_when: Weights, omitted variables, and subgroup implications can be documented and audited.

example: A vulnerability index combines infrastructure, health, and climate indicators.

domain: management

example: A scorecard consolidates many operating metrics into health dimensions.

failure_modes: Ranking entities on a score whose weights hide contested values.

Supervised Signal Compression

short_definition: Reduce dimensions to preserve performance on a downstream supervised task rather than preserving general variance or interpretability.

distinctive_feature: The preservation target is task performance, so validation must guard against overfitting and subgroup degradation.

distinct_from_parent: The parent includes unsupervised and communicative reductions; this variant is tied to labeled or task-defined outcomes.

still_same_parent_because: It still compresses the feature space and must manage information loss and interpretation limits.

use_when: The reduction is justified by a specific prediction, classification, detection, or ranking task.

use_when: General structure is less important than downstream task performance.

use_when: Holdout, drift, and subgroup validation are available.

example: A detection model compresses thousands of behavioral signals into a compact representation validated on new cases.

failure_modes: Optimizing away meaningful but rare signals.

failure_modes: Encoding historical bias in compressed features.

near_names:
Principal Component Analysis
Embedding Projection
Feature Selection
Latent Variable Modeling
Dashboard Dimension Reduction
Signal-Preserving Dimension Reduction


Dimensioned Comparison Framing

batch: Batch 08

canonical_family: Levels, Scale & Decomposition

aliases:
Shared Comparison Frame Design
Comparative Frame Alignment
Commensurate Comparison Framing
Structured Comparison Design
Common-Dimension Comparison
Comparison Basis Alignment
Dimensioned Comparative Evaluation
Relation-Readable Comparison Design

source_primes: comparison frame_of_reference commensurability measurement

related_primes: comparative_method contrast analogy baseline_deviation control_sample effect_size joint_vs_separate_evaluation juxtaposition value_commensuration classification interpretation self_checking relation representation scale order bias boundary calibration uncertainty confounding equivalence_relation context invariance decision abstraction measurement_uncertainty

slug: comparison

slug: commensurability

slug: measurement

slug: contrast

slug: analogy

slug: juxtaposition

slug: classification

slug: interpretation

slug: relation

slug: order

slug: bias

slug: boundary

slug: calibration

slug: confounding

slug: context

slug: invariance

slug: decision

essence_one_line: Make comparison legitimate by aligning the items, dimensions, scales, context, and relation-readout rule before drawing conclusions.

compression_statement: Dimensioned Comparison Framing is the solution pattern for situations where relation-reading depends on how items are placed into a shared frame. It defines the comparison question, comparands, scope, dimensions, units, scales, baselines, normalization rules, context boundaries, ordering, and readout criteria so the resulting similarity, difference, ranking, contrast, equivalence, deviation, or trade-off is interpretable rather than accidental.

core_intuition: Comparison is not a neutral glance between things. The frame decides what counts as the same kind of thing, which dimensions matter, how scale is handled, and what relation is being read. Good comparison therefore designs the frame before treating the result as evidence.

canonical_formula: comparands + purpose + shared_frame + selected_dimensions + scale_or_unit_rules + context_boundaries + relation_readout -> interpretable_comparison

structural_problem: People, teams, models, dashboards, institutions, or evaluation systems draw conclusions from items that have not been made comparable. Hidden dimensions, mismatched units, different contexts, stale baselines, unequal evidence quality, order effects, or unspoken value weights turn the comparison into an artifact of framing rather than a reliable relation between the items.

trigger_conditions: A decision depends on choosing, ranking, prioritizing, judging, diagnosing, teaching, validating, benchmarking, or explaining relations among multiple items.

trigger_conditions: The items differ across scale, context, timing, category, population, measurement method, evidence quality, or value dimensions.

trigger_conditions: Stakeholders disagree not only about the answer but about what should be compared and along which dimensions.

trigger_conditions: A dashboard, rubric, table, benchmark, trial, case method, or review process appears objective but hides the comparison basis.

trigger_conditions: One option looks better only because the baseline, comparator set, ordering, or metric was selected opportunistically.

trigger_conditions: The purpose of comparison is unclear: similarity mapping, difference finding, evaluation, ranking, causal inference, transfer, teaching, or trade-off analysis are being mixed.

symptoms: Apples-to-oranges objections recur after conclusions are announced.

symptoms: Changing the comparator set or dimensions reverses the conclusion.

symptoms: A single salient dimension dominates despite other relevant dimensions.

symptoms: Stakeholders accept the data but reject the comparison as unfair or irrelevant.

symptoms: Items are ranked although some are non-commensurable, in different contexts, or measured on incompatible scales.

symptoms: Presentation order, default baselines, or visual layout changes perceived relation more than substantive evidence.

symptoms: Comparison collapses into contrast, benchmarking, analogy, or counterfactual reasoning without declaring which operation is intended.

root_tension: Decision and learning require compression across items, but compression becomes distortion when the comparison frame silently decides what counts as relevant sameness, difference, scale, and value.

anti_signatures: The main intervention is to validate a claim against a gold standard or benchmark suite; use comparative_benchmark_validation.

anti_signatures: The main task is estimating what would have happened under an alternative causal path; use counterfactual_comparison.

anti_signatures: The main need is to emphasize discriminating differences between similar items; use contrastive_differentiation.

anti_signatures: The core mechanism is co-placement to evoke analogy, surprise, or contrast; use strategic_juxtaposition unless a full dimensioned comparison frame is required.

anti_signatures: The comparison is already well-formed and the problem is quantifying standardized magnitude; use effect_size_standardization.

anti_signatures: The main issue is making unlike values commensurable in a common valuation unit; use value_commensuration unless the broader comparison frame is the intervention.

anti_signatures: The items genuinely cannot share a meaningful frame and no decision or interpretation requires making them comparable.

structural_intervention: Turn comparison from an implicit act into an explicit designed artifact. Name the comparison purpose, select legitimate comparands, define the shared frame and scope, choose dimensions and scales, normalize or mark non-commensurable dimensions, state the relation-readout rule, check confounding and context boundaries, and present conclusions with sensitivity to alternative frames.

action_logic: State the comparison question and the action, inference, learning, or decision it must support.

action_logic: Name the comparands and justify why they belong in the same comparison set.

action_logic: Define the shared frame of reference: category, time horizon, population, setting, scale, role, task, purpose, and scope.

action_logic: Select dimensions that are relevant to the question and explicitly exclude dimensions that are irrelevant or unsafe to compare.

action_logic: Specify units, scales, measurement methods, missing-data rules, and normalization or commensuration rules.

action_logic: Choose the readout rule: similarity, difference, ranking, dominance, threshold crossing, equivalence, deviation from baseline, trade-off, or non-comparability.

action_logic: Control for order effects, salient defaults, cherry-picked baselines, category errors, confounding context, and unequal evidence quality.

action_logic: Run a sensitivity check using alternative dimensions, weights, comparator sets, baselines, or scale transformations.

action_logic: Present the result with its scope limits, non-comparable dimensions, uncertainty, value choices, and consequences for action.

action_logic: Record the comparison frame so future users can audit whether the same conclusion still follows under changed context.

decision_rules: If changing dimensions changes the conclusion, report the dimension sensitivity rather than only the preferred result.

decision_rules: If items differ by scale, context, or measurement process, normalize or declare the comparison partial before ranking.

decision_rules: If stakeholders contest relevance, revisit the comparison question and dimension selection before debating scores.

decision_rules: If one dimension is decisive, explain why it legitimately dominates rather than letting it crowd out hidden trade-offs.

decision_rules: If a comparison is being used for causal claims, route the causal portion through counterfactual_comparison or control_condition_specification.

decision_rules: If values cannot be reduced to a common metric without loss, preserve plural dimensions and mark non-commensurability.

decision_rules: If presentation order affects judgment, counterbalance, randomize, or make the order rationale explicit.

decision_rules: If the result will trigger resource allocation, accountability, safety decisions, or public claims, require auditability of comparator selection and frame assumptions.

target_invariants: The comparison question remains explicit.

target_invariants: Comparands are justified as belonging in the same frame or marked as partial/non-comparable.

target_invariants: Units, scales, baselines, and normalization rules are inspectable.

target_invariants: Relation readout is not conflated with raw co-presence.

target_invariants: Context boundaries and confounding risks are recorded.

target_invariants: Value weights and non-commensurable dimensions are not hidden.

target_invariants: Conclusions remain linked to the frame under which they were produced.

expected_outcomes: Fewer unfair, irrelevant, or apples-to-oranges comparisons.

expected_outcomes: More transparent rankings, trade-off discussions, benchmark decisions, and instructional examples.

expected_outcomes: Improved ability to explain why a comparison does or does not support a conclusion.

expected_outcomes: Better detection of frame manipulation, cherry-picked baselines, and metric domination.

expected_outcomes: Cleaner handoff to specialized neighbors such as counterfactual comparison, contrastive differentiation, benchmark validation, and effect-size standardization.

prose_essence:
Dimensioned Comparison Framing treats comparison as a designed relation-reading system rather than a neutral act of looking at things side by side. It is useful when the result of a comparison depends on what is included, which dimensions are chosen, how scale is handled, and what kind of relation is being read.

The pattern is intentionally broader than benchmark validation, counterfactual comparison, contrastive differentiation, or strategic juxtaposition. Those are important neighbors. This archetype supplies the shared-frame machinery that many of them use, while remaining distinct when the main problem is comparability itself.

Pairwise Comparison Framing

short_definition: A two-item version that stabilizes dimensions and readout before comparing one item against another.

distinctive_feature: Controls relation-reading at the simplest pair level.

distinct_from_parent: Narrower than the parent because the parent can include multi-item, multi-level, and plural-frame comparisons.

still_same_parent_because: It uses the same frame, dimension, scale, and readout logic.

use_when: A later ranking or preference aggregation depends on many pairwise judgments.

example_domains: procurement education product_design

domain: procurement

example: Two vendors are compared under the same security, support, cost, and integration dimensions.

failure_modes: pairwise local wins fail to produce coherent global ranking.

Multi-Criteria Comparison Framing

short_definition: A variant that compares options across several dimensions while preserving weights, trade-offs, and non-commensurable values.

distinctive_feature: Explicitly manages multiple dimensions and weights.

distinct_from_parent: More decision-analytic than the parent general comparison pattern.

still_same_parent_because: It is still frame-and-dimension design for relation-reading.

use_when: Stakeholders disagree about which dimensions should dominate.

example_domains: policy healthcare strategy

domain: policy

example: Policy alternatives are compared across cost, rights, implementation, distribution, and time horizon.

failure_modes: single composite score hides plural values.

short_definition: A variant that keeps dimensions separate when forcing a common metric would distort value or meaning.

distinctive_feature: The comparison design explicitly refuses false commensuration.

distinct_from_parent: It emphasizes preservation of plural dimensions rather than producing a single relation readout.

still_same_parent_because: It remains a comparison-frame decision about how relation may be read.

use_when: Important values cannot be safely reduced to one score.

use_when: The comparison is ethically, legally, or politically sensitive.

example_domains: bioethics public_policy law

example: Housing options are compared without converting displacement risk and budget cost into a single opaque score.

failure_modes: plural dimensions become too complex for action.

near_names:
Comparison Frame Design
Structured Comparison Design
Comparison Matrix
Scorecard