Blocking Design

aliases:
Randomized Block Design
Blocked Randomization Design
Matched-Block Experimental Design
Stratified Randomization Design

slug: variability

slug: balance

slug: stratification

slug: decomposition

slug: invariance

components: Admissibility and Post-Treatment Exclusion Rule

components: Block Size, Overlap, and Feasibility Design

components: Within-Block Assignment and Probability Rule

components: Treatment Coverage and Cell Completeness

components: Allocation Concealment and Implementation Integrity

components: Missing Units, Broken Pairs, and Deviation Policy

components: Precision, Power, and Design-Effect Assessment

components: Heterogeneity, Interaction, and Transport Review

components: Prespecification, Audit, and Reporting Contract

mechanisms:
Matched-Pair Randomization
Randomized Complete-Block Design
Stratified Randomization Schedule
Permuted-Block Sequence
Incomplete-Block Design
Cluster or Site Blocking
Covariate-Adaptive Randomization
Time, Batch, Run, or Location Block
Block-Adjusted Effect Estimator
Within-Block Randomization Inference

essence_one_line: Group similar experimental units before assignment and compare treatments within blocks so nuisance variation does not obscure the effect being studied.

compression_statement: Identify strong pretreatment sources of nuisance variation; form feasible, auditable blocks; randomize conditions within blocks with concealed probabilities; preserve treatment coverage and measurement parity; analyze according to the implemented block structure; and disclose exclusions, deviations, precision, heterogeneity, and transport limits.

core_intuition: Comparisons are more informative when units facing each other differ less on outcome-predictive background conditions. Blocking moves known nuisance differences out of the treatment contrast without pretending the blocks are perfectly homogeneous.

canonical_formula: blocked comparison = pretreatment similarity + within-block chance assignment + treatment coverage + design-consistent analysis + integrity audit

structural_problem: Random assignment can leave important prognostic factors uneven, especially in small or heterogeneous samples. Uncontrolled variation inflates noise, weakens power, and can create fragile comparisons. Post hoc adjustment cannot always recover a poor assignment architecture.

trigger_conditions: strong pretreatment predictors are known

trigger_conditions: units arrive by site, batch, period, field, or cluster

trigger_conditions: treatments must be compared under shared conditions

trigger_conditions: operational constraints prevent complete unrestricted randomization

symptoms: chance imbalance threatens interpretation

symptoms: analysis relies heavily on uncertain adjustment

root_tension: Finer grouping can improve comparability and precision, but excessive or unsafe blocking fragments the sample, reveals allocation, narrows transport, and complicates analysis.

anti_signatures: blocking information is measured after treatment

anti_signatures: no prognostic pretreatment variation exists

anti_signatures: blocks cannot support the intended contrast

anti_signatures: sampling representation rather than treatment assignment is the primary problem

anti_signatures: different treatment by subgroup is the intervention objective

structural_intervention: Create a prespecified pretreatment partition or matched-set structure, assign conditions by a protected chance mechanism within that structure, and carry the block design through measurement, analysis, interpretation, and reporting.

decision_rules: prioritize variables with strong outcome relevance and reliable availability

decision_rules: do not create finer blocks than treatment coverage permits

decision_rules: match the assignment level to the experimental unit

decision_rules: analyze the chance mechanism actually used

decision_rules: treat block interactions as separate hypotheses

target_invariants: causal contrast and estimand remain explicit

target_invariants: block variables remain pretreatment and auditable

target_invariants: within-block assignment probabilities remain known

target_invariants: treatment coverage supports target contrasts

target_invariants: measurement and follow-up remain comparable

target_invariants: missingness and deviations remain visible

target_invariants: fairness and privacy constrain block construction

expected_outcomes: less dependence on fragile post hoc adjustment

expected_outcomes: clearer treatment heterogeneity boundaries

prose_essence:
Blocking Design groups comparable experimental units before assignment and makes treatment comparisons within those groups so known nuisance variation does not obscure the effect under study.

It is prospective experimental architecture. It does not merely inspect a baseline table after randomization, harmonize measurement, or add a block term after outcomes are known. The grouping rule, chance mechanism, treatment coverage, concealment, analysis, exclusions, and reporting form one contract.

prose_when_to_use:
Use blocking when strong pretreatment predictors, sites, clusters, batches, periods, locations, or operating conditions create material heterogeneity and unrestricted assignment may yield noisy or fragile comparisons. It is especially valuable in small samples and constrained operations.

Do not block on post-treatment information, create cells too small to support contrasts, or use sensitive attributes without purpose and safeguards. When the goal is representative sampling or different treatment by subgroup, use the corresponding neighbor.

prose_structural_problem:
Chance assignment protects against systematic bias in expectation, but a realized sample can still be uneven on important prognostic factors. Known nuisance variation inflates residual noise, weakens power, and makes small-sample effects unstable.

Blocking improves the design by comparing like with like, but overblocking fragments evidence, can reveal allocations, excludes unmatched units, and complicates the estimand. Mature design balances similarity, coverage, concealment, and transport.

prose_intervention_logic:
1. **Causal Question, Estimand, and Contrast.** Defines the effect, comparison, population, treatment versions, and decision for which blocking should improve precision or credibility. Blocking is not an end in itself. The chosen blocks must support the intended contrast and must not silently change the target population or estimand.
2. **Experimental Unit and Assignment Level.** Identifies the unit independently assigned, the unit measured, clustering, interference, and the level at which treatment is delivered. Blocking individuals cannot repair an intervention assigned by site, classroom, batch, or household. Unit structure determines valid randomization and analysis.
3. **Nuisance Variation and Confounding Map.** Maps pretreatment factors expected to predict outcomes or distort comparison without being the intervention of interest. Useful blocking factors explain material variation, differ across units, are available before assignment, and can be measured consistently.
4. **Pretreatment Block-Variable Contract.** Defines each blocking variable, measurement rule, categories or distance, provenance, missingness, timing, and rationale before outcomes are inspected. Post-treatment or manipulable variables can introduce bias. The contract prevents opportunistic regrouping after results appear.
5. **Admissibility and Post-Treatment Exclusion Rule.** Excludes variables affected by treatment, colliders, unstable proxies, leakage, protected-attribute misuse, and factors unavailable at assignment. A predictive variable is not automatically safe. Causal timing, fairness, privacy, and operational integrity constrain block construction.
6. **Block Construction and Similarity Rule.** Specifies exact strata, matched sets, distance rules, coarsening, hierarchy, or domain categories used to group comparable units. Similarity should be meaningful for outcome variation and assignment feasibility, not manufactured by opaque algorithms or arbitrary cutoffs.
7. **Block Size, Overlap, and Feasibility Design.** Ensures each block contains enough eligible units and treatment capacity for the planned contrast without excessive exclusion. Overly fine blocks create singletons, empty treatment cells, delays, and lost generalizability. Coarse blocks leave avoidable imbalance.
8. **Within-Block Assignment and Probability Rule.** Defines treatment probabilities, ratios, sequence generation, restrictions, and chance mechanism separately within each block. The assignment mechanism must remain genuinely random or explicitly controlled; blocking must not become discretionary placement.
9. **Treatment Coverage and Cell Completeness.** Checks that required treatment conditions occur within blocks or that incomplete-block structure remains connected for the intended contrasts. A block with no relevant contrast contributes no direct within-block comparison and may make effects unidentified.
10. **Allocation Concealment and Implementation Integrity.** Protects block definitions and assignment sequences from prediction, manipulation, substitution, rerandomization, and selective enrollment. Small blocks can make future assignments guessable. Concealment, audit, and separation of enrollment from allocation preserve validity.
11. **Measurement and Follow-Up Parity.** Keeps outcome construct, instrument, timing, administration, retention, and deviation handling comparable across treatments within blocks. Blocking baseline variation does not repair differential measurement or attrition after assignment.
12. **Block-Aware Analysis and Weighting Plan.** Specifies how block indicators, assignment probabilities, weights, paired differences, clustering, and finite-sample uncertainty enter analysis. Ignoring blocks can waste precision or misstate uncertainty; weighting blocks incorrectly can change the estimand.
13. **Missing Units, Broken Pairs, and Deviation Policy.** Defines handling of unmatched units, missing block variables, broken pairs, empty cells, dropout, crossover, and protocol deviations. Post hoc deletion of inconvenient blocks or incomplete pairs can introduce selection bias and hide implementation failure.
14. **Precision, Power, and Design-Effect Assessment.** Estimates expected variance reduction, degrees-of-freedom cost, sample requirements, and sensitivity to block quality. Blocking can improve power when blocks are predictive, but unnecessary or fragmented blocks can reduce efficiency.
15. **Heterogeneity, Interaction, and Transport Review.** Examines whether effects differ across blocks and whether block construction limits transport to excluded or sparse populations. Blocks are nuisance controls by default, not automatic subgroups for causal storytelling. Interaction claims require evidence and multiplicity discipline.
16. **Prespecification, Audit, and Reporting Contract.** Publishes the rationale, algorithm, variables, block sizes, assignment probabilities, deviations, exclusions, analysis, diagnostics, and limitations. Transparent reporting enables reproduction and distinguishes blocking from post hoc matching or cosmetic baseline tables.

The design must carry through analysis. A grouping used in assignment but ignored in estimation, weighting, or uncertainty is only partially implemented.

prose_key_components:
### Causal Question, Estimand, and Contrast (`causal_question_estimand_and_contrast`)

Defines the effect, comparison, population, treatment versions, and decision for which blocking should improve precision or credibility.

Semantic canonical mapping retained the complete legacy component record: {"slug":"causal_question_estimand_and_contrast","name":"Causal Question, Estimand, and Contrast","role":"Defines the effect, comparison, population, treatment versions, and decision for which blocking should improve precision or credibility.","notes":"Blocking is not an end in itself. The chosen blocks must support the intended contrast and must not silently change the target population or estimand.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Experimental Unit and Assignment Level (`experimental_unit_and_assignment_level`)

Identifies the unit independently assigned, the unit measured, clustering, interference, and the level at which treatment is delivered.

Semantic canonical mapping retained the complete legacy component record: {"slug":"experimental_unit_and_assignment_level","name":"Experimental Unit and Assignment Level","role":"Identifies the unit independently assigned, the unit measured, clustering, interference, and the level at which treatment is delivered.","notes":"Blocking individuals cannot repair an intervention assigned by site, classroom, batch, or household. Unit structure determines valid randomization and analysis.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Nuisance Variation and Confounding Map (`nuisance_variation_and_confounding_map`)

Maps pretreatment factors expected to predict outcomes or distort comparison without being the intervention of interest.

Semantic canonical mapping retained the complete legacy component record: {"slug":"nuisance_variation_and_confounding_map","name":"Nuisance Variation and Confounding Map","role":"Maps pretreatment factors expected to predict outcomes or distort comparison without being the intervention of interest.","notes":"Useful blocking factors explain material variation, differ across units, are available before assignment, and can be measured consistently.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Pretreatment Block-Variable Contract (`pretreatment_block_variable_contract`)

Defines each blocking variable, measurement rule, categories or distance, provenance, missingness, timing, and rationale before outcomes are inspected.

Semantic canonical mapping retained the complete legacy component record: {"slug":"pretreatment_block_variable_contract","name":"Pretreatment Block-Variable Contract","role":"Defines each blocking variable, measurement rule, categories or distance, provenance, missingness, timing, and rationale before outcomes are inspected.","notes":"Post-treatment or manipulable variables can introduce bias. The contract prevents opportunistic regrouping after results appear.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Admissibility and Post-Treatment Exclusion Rule (`admissibility_and_posttreatment_exclusion_rule`)

Excludes variables affected by treatment, colliders, unstable proxies, leakage, protected-attribute misuse, and factors unavailable at assignment.

Semantic canonical mapping retained the complete legacy component record: {"slug":"admissibility_and_posttreatment_exclusion_rule","name":"Admissibility and Post-Treatment Exclusion Rule","role":"Excludes variables affected by treatment, colliders, unstable proxies, leakage, protected-attribute misuse, and factors unavailable at assignment.","notes":"A predictive variable is not automatically safe. Causal timing, fairness, privacy, and operational integrity constrain block construction.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Block Construction and Similarity Rule (`block_construction_and_similarity_rule`)

Specifies exact strata, matched sets, distance rules, coarsening, hierarchy, or domain categories used to group comparable units.

Semantic canonical mapping retained the complete legacy component record: {"slug":"block_construction_and_similarity_rule","name":"Block Construction and Similarity Rule","role":"Specifies exact strata, matched sets, distance rules, coarsening, hierarchy, or domain categories used to group comparable units.","notes":"Similarity should be meaningful for outcome variation and assignment feasibility, not manufactured by opaque algorithms or arbitrary cutoffs.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Block Size, Overlap, and Feasibility Design (`block_size_overlap_and_feasibility_design`)

Ensures each block contains enough eligible units and treatment capacity for the planned contrast without excessive exclusion.

Semantic canonical mapping retained the complete legacy component record: {"slug":"block_size_overlap_and_feasibility_design","name":"Block Size, Overlap, and Feasibility Design","role":"Ensures each block contains enough eligible units and treatment capacity for the planned contrast without excessive exclusion.","notes":"Overly fine blocks create singletons, empty treatment cells, delays, and lost generalizability. Coarse blocks leave avoidable imbalance.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Within-Block Assignment and Probability Rule (`within_block_assignment_and_probability_rule`)

Defines treatment probabilities, ratios, sequence generation, restrictions, and chance mechanism separately within each block.

Semantic canonical mapping retained the complete legacy component record: {"slug":"within_block_assignment_and_probability_rule","name":"Within-Block Assignment and Probability Rule","role":"Defines treatment probabilities, ratios, sequence generation, restrictions, and chance mechanism separately within each block.","notes":"The assignment mechanism must remain genuinely random or explicitly controlled; blocking must not become discretionary placement.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Treatment Coverage and Cell Completeness (`treatment_coverage_and_cell_completeness`)

Checks that required treatment conditions occur within blocks or that incomplete-block structure remains connected for the intended contrasts.

Semantic canonical mapping retained the complete legacy component record: {"slug":"treatment_coverage_and_cell_completeness","name":"Treatment Coverage and Cell Completeness","role":"Checks that required treatment conditions occur within blocks or that incomplete-block structure remains connected for the intended contrasts.","notes":"A block with no relevant contrast contributes no direct within-block comparison and may make effects unidentified.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Allocation Concealment and Implementation Integrity (`allocation_concealment_and_implementation_integrity`)

Protects block definitions and assignment sequences from prediction, manipulation, substitution, rerandomization, and selective enrollment.

Semantic canonical mapping retained the complete legacy component record: {"slug":"allocation_concealment_and_implementation_integrity","name":"Allocation Concealment and Implementation Integrity","role":"Protects block definitions and assignment sequences from prediction, manipulation, substitution, rerandomization, and selective enrollment.","notes":"Small blocks can make future assignments guessable. Concealment, audit, and separation of enrollment from allocation preserve validity.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Measurement and Follow-Up Parity (`measurement_and_followup_parity`)

Keeps outcome construct, instrument, timing, administration, retention, and deviation handling comparable across treatments within blocks.

Semantic canonical mapping retained the complete legacy component record: {"slug":"measurement_and_followup_parity","name":"Measurement and Follow-Up Parity","role":"Keeps outcome construct, instrument, timing, administration, retention, and deviation handling comparable across treatments within blocks.","notes":"Blocking baseline variation does not repair differential measurement or attrition after assignment.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Block-Aware Analysis and Weighting Plan (`block_aware_analysis_and_weighting_plan`)

Specifies how block indicators, assignment probabilities, weights, paired differences, clustering, and finite-sample uncertainty enter analysis.

Semantic canonical mapping retained the complete legacy component record: {"slug":"block_aware_analysis_and_weighting_plan","name":"Block-Aware Analysis and Weighting Plan","role":"Specifies how block indicators, assignment probabilities, weights, paired differences, clustering, and finite-sample uncertainty enter analysis.","notes":"Ignoring blocks can waste precision or misstate uncertainty; weighting blocks incorrectly can change the estimand.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Missing Units, Broken Pairs, and Deviation Policy (`missing_units_broken_pairs_and_deviation_policy`)

Defines handling of unmatched units, missing block variables, broken pairs, empty cells, dropout, crossover, and protocol deviations.

Semantic canonical mapping retained the complete legacy component record: {"slug":"missing_units_broken_pairs_and_deviation_policy","name":"Missing Units, Broken Pairs, and Deviation Policy","role":"Defines handling of unmatched units, missing block variables, broken pairs, empty cells, dropout, crossover, and protocol deviations.","notes":"Post hoc deletion of inconvenient blocks or incomplete pairs can introduce selection bias and hide implementation failure.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Precision, Power, and Design-Effect Assessment (`precision_power_and_design_effect_assessment`)

Estimates expected variance reduction, degrees-of-freedom cost, sample requirements, and sensitivity to block quality.

Semantic canonical mapping retained the complete legacy component record: {"slug":"precision_power_and_design_effect_assessment","name":"Precision, Power, and Design-Effect Assessment","role":"Estimates expected variance reduction, degrees-of-freedom cost, sample requirements, and sensitivity to block quality.","notes":"Blocking can improve power when blocks are predictive, but unnecessary or fragmented blocks can reduce efficiency.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Heterogeneity, Interaction, and Transport Review (`heterogeneity_interaction_and_transport_review`)

Examines whether effects differ across blocks and whether block construction limits transport to excluded or sparse populations.

Semantic canonical mapping retained the complete legacy component record: {"slug":"heterogeneity_interaction_and_transport_review","name":"Heterogeneity, Interaction, and Transport Review","role":"Examines whether effects differ across blocks and whether block construction limits transport to excluded or sparse populations.","notes":"Blocks are nuisance controls by default, not automatic subgroups for causal storytelling. Interaction claims require evidence and multiplicity discipline.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

### Prespecification, Audit, and Reporting Contract (`prespecification_audit_and_reporting_contract`)

Publishes the rationale, algorithm, variables, block sizes, assignment probabilities, deviations, exclusions, analysis, diagnostics, and limitations.

Semantic canonical mapping retained the complete legacy component record: {"slug":"prespecification_audit_and_reporting_contract","name":"Prespecification, Audit, and Reporting Contract","role":"Publishes the rationale, algorithm, variables, block sizes, assignment probabilities, deviations, exclusions, analysis, diagnostics, and limitations.","notes":"Transparent reporting enables reproduction and distinguishes blocking from post hoc matching or cosmetic baseline tables.","component_type":"required_structural_component","reuse_scope":"cross_domain","maturity":"provisional","host_archetypes":["blocking_design"],"evidence_expectation":"Record prespecification, provenance, timing, owner, feasibility, analysis implication, and evidence that the block reduces nuisance variation without introducing bias.","not_a_mechanism_because":"This is a persistent design responsibility, not a particular matched-pair algorithm, randomization schedule, table, model term, or software procedure."}

prose_common_mechanisms:
### Matched-Pair Randomization (`matched_pair_randomization`)

**Type:** `assignment_design`

Forms pairs of similar units and randomizes treatment within each pair.

Selection constraints and retained implementation evidence: use pretreatment information only; preserve assignment probabilities and concealment; match analysis to the implemented block structure; Complete legacy mechanism record retained: {"slug":"matched_pair_randomization","name":"Matched-Pair Randomization","mechanism_type":"assignment_design","role":"Forms pairs of similar units and randomizes treatment within each pair.","maturity":"provisional","instantiates_archetypes":["blocking_design"],"selection_constraints":["use pretreatment information only","preserve assignment probabilities and concealment","match analysis to the implemented block structure"],"not_an_archetype_because":"This is a concrete grouping, allocation, or analysis procedure within the broader blocking lifecycle."}

### Randomized Complete-Block Design (`randomized_complete_block_design`)

**Type:** `assignment_design`

Places every treatment condition within each block when capacity and unit counts permit.

Selection constraints and retained implementation evidence: use pretreatment information only; preserve assignment probabilities and concealment; match analysis to the implemented block structure; Complete legacy mechanism record retained: {"slug":"randomized_complete_block_design","name":"Randomized Complete-Block Design","mechanism_type":"assignment_design","role":"Places every treatment condition within each block when capacity and unit counts permit.","maturity":"provisional","instantiates_archetypes":["blocking_design"],"selection_constraints":["use pretreatment information only","preserve assignment probabilities and concealment","match analysis to the implemented block structure"],"not_an_archetype_because":"This is a concrete grouping, allocation, or analysis procedure within the broader blocking lifecycle."}

### Stratified Randomization Schedule (`stratified_randomization_schedule`)

**Type:** `assignment_design`

Creates categorical strata from key pretreatment variables and randomizes separately within them.

Selection constraints and retained implementation evidence: use pretreatment information only; preserve assignment probabilities and concealment; match analysis to the implemented block structure; Complete legacy mechanism record retained: {"slug":"stratified_randomization_schedule","name":"Stratified Randomization Schedule","mechanism_type":"assignment_design","role":"Creates categorical strata from key pretreatment variables and randomizes separately within them.","maturity":"provisional","instantiates_archetypes":["blocking_design"],"selection_constraints":["use pretreatment information only","preserve assignment probabilities and concealment","match analysis to the implemented block structure"],"not_an_archetype_because":"This is a concrete grouping, allocation, or analysis procedure within the broader blocking lifecycle."}

### Permuted-Block Sequence (`permuted_block_sequence`)

**Type:** `allocation`

Uses randomized treatment sequences within blocks to maintain allocation ratios during enrollment.

Selection constraints and retained implementation evidence: use pretreatment information only; preserve assignment probabilities and concealment; match analysis to the implemented block structure; Complete legacy mechanism record retained: {"slug":"permuted_block_sequence","name":"Permuted-Block Sequence","mechanism_type":"allocation","role":"Uses randomized treatment sequences within blocks to maintain allocation ratios during enrollment.","maturity":"provisional","instantiates_archetypes":["blocking_design"],"selection_constraints":["use pretreatment information only","preserve assignment probabilities and concealment","match analysis to the implemented block structure"],"not_an_archetype_because":"This is a concrete grouping, allocation, or analysis procedure within the broader blocking lifecycle."}

### Incomplete-Block Design (`incomplete_block_design`)

**Type:** `assignment_design`

Uses connected subsets of treatments within blocks when complete exposure is infeasible.

Selection constraints and retained implementation evidence: use pretreatment information only; preserve assignment probabilities and concealment; match analysis to the implemented block structure; Complete legacy mechanism record retained: {"slug":"incomplete_block_design","name":"Incomplete-Block Design","mechanism_type":"assignment_design","role":"Uses connected subsets of treatments within blocks when complete exposure is infeasible.","maturity":"provisional","instantiates_archetypes":["blocking_design"],"selection_constraints":["use pretreatment information only","preserve assignment probabilities and concealment","match analysis to the implemented block structure"],"not_an_archetype_because":"This is a concrete grouping, allocation, or analysis procedure within the broader blocking lifecycle."}

### Cluster or Site Blocking (`cluster_or_site_blocking`)

**Type:** `assignment_design`

Groups comparable clusters, sites, classrooms, batches, or communities before cluster-level assignment.

Selection constraints and retained implementation evidence: use pretreatment information only; preserve assignment probabilities and concealment; match analysis to the implemented block structure; Complete legacy mechanism record retained: {"slug":"cluster_or_site_blocking","name":"Cluster or Site Blocking","mechanism_type":"assignment_design","role":"Groups comparable clusters, sites, classrooms, batches, or communities before cluster-level assignment.","maturity":"provisional","instantiates_archetypes":["blocking_design"],"selection_constraints":["use pretreatment information only","preserve assignment probabilities and concealment","match analysis to the implemented block structure"],"not_an_archetype_because":"This is a concrete grouping, allocation, or analysis procedure within the broader blocking lifecycle."}

### Covariate-Adaptive Randomization (`covariate_adaptive_randomization`)

**Type:** `adaptive_allocation`

Adjusts assignment probabilities using accumulated pretreatment covariate balance while preserving a defined chance mechanism.

Selection constraints and retained implementation evidence: use pretreatment information only; preserve assignment probabilities and concealment; match analysis to the implemented block structure; Complete legacy mechanism record retained: {"slug":"covariate_adaptive_randomization","name":"Covariate-Adaptive Randomization","mechanism_type":"adaptive_allocation","role":"Adjusts assignment probabilities using accumulated pretreatment covariate balance while preserving a defined chance mechanism.","maturity":"provisional","instantiates_archetypes":["blocking_design"],"selection_constraints":["use pretreatment information only","preserve assignment probabilities and concealment","match analysis to the implemented block structure"],"not_an_archetype_because":"This is a concrete grouping, allocation, or analysis procedure within the broader blocking lifecycle."}

### Time, Batch, Run, or Location Block (`time_batch_run_or_location_block`)

**Type:** `operational_design`

Controls nuisance variation from production runs, periods, rooms, fields, devices, operators, or locations.

Selection constraints and retained implementation evidence: use pretreatment information only; preserve assignment probabilities and concealment; match analysis to the implemented block structure; Complete legacy mechanism record retained: {"slug":"time_batch_run_or_location_block","name":"Time, Batch, Run, or Location Block","mechanism_type":"operational_design","role":"Controls nuisance variation from production runs, periods, rooms, fields, devices, operators, or locations.","maturity":"provisional","instantiates_archetypes":["blocking_design"],"selection_constraints":["use pretreatment information only","preserve assignment probabilities and concealment","match analysis to the implemented block structure"],"not_an_archetype_because":"This is a concrete grouping, allocation, or analysis procedure within the broader blocking lifecycle."}

### Block-Adjusted Effect Estimator (`block_adjusted_effect_estimator`)

**Type:** `analysis`

Combines within-block contrasts using prespecified weights and uncertainty appropriate to the assignment.

Selection constraints and retained implementation evidence: use pretreatment information only; preserve assignment probabilities and concealment; match analysis to the implemented block structure; Complete legacy mechanism record retained: {"slug":"block_adjusted_effect_estimator","name":"Block-Adjusted Effect Estimator","mechanism_type":"analysis","role":"Combines within-block contrasts using prespecified weights and uncertainty appropriate to the assignment.","maturity":"provisional","instantiates_archetypes":["blocking_design"],"selection_constraints":["use pretreatment information only","preserve assignment probabilities and concealment","match analysis to the implemented block structure"],"not_an_archetype_because":"This is a concrete grouping, allocation, or analysis procedure within the broader blocking lifecycle."}

### Within-Block Randomization Inference (`within_block_randomization_inference`)

**Type:** `analysis`

Evaluates treatment assignment permutations allowed by the actual blocked randomization mechanism.

Selection constraints and retained implementation evidence: use pretreatment information only; preserve assignment probabilities and concealment; match analysis to the implemented block structure; Complete legacy mechanism record retained: {"slug":"within_block_randomization_inference","name":"Within-Block Randomization Inference","mechanism_type":"analysis","role":"Evaluates treatment assignment permutations allowed by the actual blocked randomization mechanism.","maturity":"provisional","instantiates_archetypes":["blocking_design"],"selection_constraints":["use pretreatment information only","preserve assignment probabilities and concealment","match analysis to the implemented block structure"],"not_an_archetype_because":"This is a concrete grouping, allocation, or analysis procedure within the broader blocking lifecycle."}

prose_failure_modes:
### Posttreatment Blocking

**Cause.** A variable affected by treatment is used to form or adjust blocks.

**Mitigation.** Restrict block variables to prespecified pretreatment information with causal timing review. Recheck the assignment and analysis contract after remediation.

### Strata Explosion

**Cause.** Too many factors create tiny, empty, or singleton blocks.

**Mitigation.** Prioritize strong predictors, coarsen transparently, and test treatment coverage. Recheck the assignment and analysis contract after remediation.

### Weak Block Predictiveness

**Cause.** Blocks add complexity without explaining outcome variation.

**Mitigation.** Use substantive and pilot evidence and report expected design effect. Recheck the assignment and analysis contract after remediation.

### Assignment Predictability

**Cause.** Small or fixed sequences reveal future allocations.

**Mitigation.** Use concealed random sequences, varying sizes where appropriate, and separate enrollment from allocation. Recheck the assignment and analysis contract after remediation.

### Discretionary Placement

**Cause.** Staff override or guess assignments within blocks.

**Mitigation.** Automate or independently administer the chance mechanism and audit deviations. Recheck the assignment and analysis contract after remediation.

### Treatment Cell Failure

**Cause.** Some blocks lack treatments needed for the target contrast.

**Mitigation.** Verify completeness or connected incomplete-block estimability before launch. Recheck the assignment and analysis contract after remediation.

### Analysis Ignores Design

**Cause.** Outcomes are analyzed as if simple randomization occurred.

**Mitigation.** Use block-aware estimators, probabilities, weights, pairing, clustering, and uncertainty. Recheck the assignment and analysis contract after remediation.

### Broken Pair Deletion

**Cause.** Incomplete pairs or blocks are discarded after outcomes are known.

**Mitigation.** Prespecify missingness and deviation handling and preserve assignment-based cohorts. Recheck the assignment and analysis contract after remediation.

### Measurement Nonparity

**Cause.** Outcome timing, instruments, raters, or retention differ by treatment within blocks.

**Mitigation.** Apply measurement and follow-up parity controls. Recheck the assignment and analysis contract after remediation.

### Unfair Or Sensitive Blocking

**Cause.** Protected or sensitive attributes are used opaquely or create harmful exclusion.

**Mitigation.** Apply purpose limitation, privacy, fairness review, minimum-cell protection, and transparent rationale. Recheck the assignment and analysis contract after remediation.

### Block Interaction Storytelling

**Cause.** Noisy block-specific estimates are promoted as treatment heterogeneity.

**Mitigation.** Prespecify interactions, control multiplicity, and separate nuisance control from subgroup claims. Recheck the assignment and analysis contract after remediation.

### Transport Loss

**Cause.** Fine matching excludes units and silently narrows the population.

**Mitigation.** Report exclusions, overlap, weights, target population, and transport limits. Recheck the assignment and analysis contract after remediation.

prose_neighbor_distinctions:
### `baseline_covariate_balance_verification`

Checks whether assignment produced comparable groups after randomization. Blocking Design changes assignment prospectively to improve comparison and precision.

### `measurement_protocol_standardization`

Harmonizes instruments, timing, administration, and scoring. It complements blocking but does not form groups or randomize within them.

### `time_series_cross_section_analysis`

Analyzes cases across time and groups. Operational time or site blocks may feed that analysis, but q48 owns prospective design.

### `controlled_randomization`

Uses randomness broadly for bias reduction, fairness, or learning. Blocking adds a specific pretreatment grouping structure around the chance mechanism.

### `randomized_assignment`

Assigns units by chance. Blocking restricts or partitions that randomization using prognostic similarity.

### `representative_sampling_design`

Selects a sample to represent a population. Blocking allocates sampled units to conditions and does not ensure population representation.

### `stratified_treatment`

Deliberately applies different interventions to strata. Blocking normally compares treatments within nuisance-similar strata rather than prescribing by stratum.

### `factorial_experimental_design`

Crosses multiple treatment factors to estimate main effects and interactions. Blocking controls nuisance variation and can accompany a factorial design.

### `confounder_control`

Addresses alternative causes broadly in design or analysis. Blocking is one prospective experimental technique with its own grouping, assignment, and analysis lifecycle.

### `regression_to_mean_guardrail`

Protects attribution after extreme selection. Blocking may reduce variance but does not by itself estimate expected reversion or fix outcome-triggered entry.

### `distributional_assumption_governance`

Governs probability-model commitments. Block-aware analysis may make assumptions, while q48 primarily governs experimental architecture.

### `variance_reduction`

Names the general goal of lowering nuisance variance. Blocking Design supplies a specific causal-comparison intervention with integrity and fairness constraints.

Frozen reconciliation explicitly preserves Blocking Design as draft-ready and distinct from randomization, representative sampling, stratified treatment, and variance reduction.

prose_cross_domain_examples:
### Clinical Trials

Stratify randomization by site and baseline severity while concealing varying block sequences.

Strong prognostic factors and sequential enrollment threaten small-sample balance.
 The record preserves pretreatment timing, treatment coverage, chance assignment, parity, analysis, and deviations.

### Agriculture

Randomize treatments within field zones sharing soil and slope conditions.

Spatial nuisance variation can overwhelm treatment differences.
 The record preserves pretreatment timing, treatment coverage, chance assignment, parity, analysis, and deviations.

### Manufacturing

Distribute process settings within production runs, machines, or material batches.

Run and batch effects are operational nuisance sources.
 The record preserves pretreatment timing, treatment coverage, chance assignment, parity, analysis, and deviations.

### Education

Pair or stratify schools by prior outcomes and size before assigning rollout timing.

Cluster heterogeneity and small site counts reduce unrestricted-randomization precision.
 The record preserves pretreatment timing, treatment coverage, chance assignment, parity, analysis, and deviations.

### Digital Experiments

Block by market, device class, or enrollment cohort before randomized exposure.

Large contextual differences can inflate variance and interact with implementation.
 The record preserves pretreatment timing, treatment coverage, chance assignment, parity, analysis, and deviations.

### Sensory And Product Testing

Use incomplete connected blocks when each participant cannot evaluate every product.

Burden limits complete treatment coverage within each block.
 The record preserves pretreatment timing, treatment coverage, chance assignment, parity, analysis, and deviations.

### Extended multisite example

A multisite service trial expects baseline severity and site capacity to dominate outcomes. Designers define the person-level estimand but acknowledge site-level delivery. Before enrollment, they specify severity bands, site blocks, missing-variable rules, treatment ratios, concealed varying sequences, and minimum cell sizes. Enrollment staff cannot view upcoming assignments. Outcomes use the same instrument and timing. Analysis includes site and severity blocks, assignment probabilities, clustering, broken-pair and dropout policies, and transport limits for sparse sites. Baseline balance is checked as validation, not used to rewrite blocks after outcomes. The result gains precision without claiming that blocks eliminate every confounder.

prose_non_examples:
- Creating blocks after seeing outcomes
- Using strata to deliver different treatment by design
- Reporting only a baseline table
- Matching and deleting inconvenient units after results
- Ignoring blocks in analysis
- Treating site-specific noise as causal heterogeneity

A post hoc adjustment, baseline table, matched sample, or site label is not the full archetype unless it belongs to a prespecified blocked assignment and analysis lifecycle.

prose_tradeoffs:
- **Finer similarity versus sparse cells:** resolve using estimand, predictor strength, treatment coverage, concealment, power, feasibility, fairness, and transport.
- **Precision gain versus degrees-of-freedom cost:** resolve using estimand, predictor strength, treatment coverage, concealment, power, feasibility, fairness, and transport.
- **Allocation balance versus concealment:** resolve using estimand, predictor strength, treatment coverage, concealment, power, feasibility, fairness, and transport.
- **Matching quality versus population exclusion:** resolve using estimand, predictor strength, treatment coverage, concealment, power, feasibility, fairness, and transport.
- **Fixed blocks versus adaptive enrollment:** resolve using estimand, predictor strength, treatment coverage, concealment, power, feasibility, fairness, and transport.
- **Operational feasibility versus statistical ideal:** resolve using estimand, predictor strength, treatment coverage, concealment, power, feasibility, fairness, and transport.
- **Simple analysis versus design fidelity:** resolve using estimand, predictor strength, treatment coverage, concealment, power, feasibility, fairness, and transport.
- **Block homogeneity versus transportability:** resolve using estimand, predictor strength, treatment coverage, concealment, power, feasibility, fairness, and transport.
- **Automation versus auditability:** resolve using estimand, predictor strength, treatment coverage, concealment, power, feasibility, fairness, and transport.
- **Privacy versus prognostic detail:** resolve using estimand, predictor strength, treatment coverage, concealment, power, feasibility, fairness, and transport.
- **Within-block balance versus global balance:** resolve using estimand, predictor strength, treatment coverage, concealment, power, feasibility, fairness, and transport.
- **Prespecification versus unforeseen logistics:** resolve using estimand, predictor strength, treatment coverage, concealment, power, feasibility, fairness, and transport.

prose_invariants_to_preserve:
- Causal contrast and estimand remain explicit.
- Block variables remain pretreatment and auditable.
- Within-block assignment probabilities remain known.
- Treatment coverage supports target contrasts.
- Enrollment cannot manipulate assignment.
- Measurement and follow-up remain comparable.
- Analysis respects blocks and clustering.
- Missingness and deviations remain visible.
- Population exclusions remain disclosed.
- Fairness and privacy constrain block construction.

Blocking improves a chance mechanism; it never proves that all confounding, interference, measurement error, or attrition has disappeared.

prose_target_outcomes:
- Lower nuisance variance.
- Better baseline comparability.
- Greater precision and power.
- More credible causal contrasts.
- Transparent assignment probabilities.
- Less dependence on fragile post hoc adjustment.
- Clearer treatment heterogeneity boundaries.
- More reproducible experimental design.

Success is a more informative and reproducible comparison, not simply prettier baseline balance.

prose_parameter_dimensions:
- **Block predictor strength:** Expected outcome variation explained.
- **Granularity:** Similarity gained versus sparse cells.
- **Block size:** Units and treatments per block.
- **Treatment ratio:** Within-block allocation probabilities.
- **Arrival process:** Batch or sequential enrollment.
- **Concealment strength:** Resistance to prediction and manipulation.
- **Assignment level:** Individual, cluster, site, or batch.
- **Completeness:** All treatments or connected subsets.
- **Distance rule:** Exact, coarsened, or continuous similarity.
- **Missingness policy:** Unknown block variables and broken sets.
- **Analysis weighting:** Contribution of blocks to the estimand.
- **Clustering:** Dependence within assignment or measurement units.
- **Power target:** Precision gain and degrees-of-freedom cost.
- **Transport scope:** Population retained after matching.
- **Fairness/privacy:** Permissible sensitive information.
- **Audit depth:** Traceability of schedules and deviations.

prose_variants_and_near_names:
### Matched-Pair Blocking Design

Create two-unit or small matched sets and randomize within them when close pretreatment comparability is available.

Makes match distance, pair completeness, broken-pair policy, and paired analysis central. Pretreatment grouping, within-block assignment, block-aware analysis, and integrity remain shared.

Use it when sample is modest; and strong predictors support close matches; and treatment ratio fits pair or set size. Risks include bad matches, broken pairs, hidden exclusion, pair label leakage.

### Stratified-Randomization Blocking Design

Define a manageable cross-classification of key pretreatment factors and randomize separately within each stratum.

Centers category definition, sparse-cell control, allocation ratios, and stratum-weighted analysis. It uses the same nuisance map, prespecification, assignment, integrity, analysis, and reporting contract.

Use it when few categorical prognostic factors dominate variation; and stratum membership is available at assignment; and each stratum can support treatment coverage. Risks include strata explosion, empty cells, misclassification, predictable assignment.

### Incomplete and Connected Blocking Design

Distribute subsets of many treatments across blocks while preserving a connected comparison graph for target contrasts.

Makes incidence structure, connectivity, concurrence, estimability, and weighting load-bearing. The design still groups nuisance-similar units and makes comparisons through prespecified within-block exposure.

Use it when not every block can receive every treatment; and treatment set is large; and connectivity and estimability can be verified. Risks include disconnected treatment graph, nonestimable contrast, unequal concurrence, opaque weights.

### Operational Time, Space, and Batch Blocking

Block by run, batch, period, location, device, operator, field, or site to prevent operational variation from obscuring treatment contrast.

Centers scheduling, carryover, contamination, position, drift, and operational feasibility. It retains pretreatment grouping, within-block assignment, parity, analysis, and audit.

Use it when conditions vary systematically across time or space; and treatments can be represented within operational groups; and block effects are nuisance rather than the primary target. Risks include carryover, time-treatment confounding, site contamination, schedule leakage.

Randomized block design, stratified randomization, and matched design are near names or variants; schedules, algorithms, estimators, and tables remain mechanisms.

Matched-Pair Blocking Design

variant_type: subtype

distinct_from_parent: The parent also covers categorical strata, complete and incomplete blocks, clusters, batches, and adaptive designs.

use_when:
sample is modest
strong predictors support close matches
treatment ratio fits pair or set size

example_domains: medicine education agriculture policy

failure_modes:
bad matches
broken pairs
hidden exclusion
pair label leakage

distinct_from_parent: The parent also supports distance-based, continuous, incomplete, cluster, and operational blocks.

use_when: few categorical prognostic factors dominate variation

use_when: stratum membership is available at assignment

use_when: each stratum can support treatment coverage

failure_modes:
strata explosion
empty cells
misclassification
predictable assignment

name: Incomplete and Connected Blocking Design

distinct_from_parent: Complete blocks contain all relevant treatments and require less connectivity governance.

use_when: not every block can receive every treatment

use_when: connectivity and estimability can be verified

failure_modes:
disconnected treatment graph
nonestimable contrast
unequal concurrence
opaque weights

name: Operational Time, Space, and Batch Blocking

distinct_from_parent: Other blocking uses person-level prognostic variables or abstract similarity rather than operating conditions.

use_when: conditions vary systematically across time or space

use_when: treatments can be represented within operational groups

use_when: block effects are nuisance rather than the primary target

example_domains: manufacturing agriculture laboratories software_experiments

failure_modes:
carryover
time-treatment confounding
site contamination
schedule leakage


Bottleneck Capacity Shadowing

type: archetype

source: generated

batch: First Iteration/Batch 31/Wave 2

related_primes: optimization resource_management sensitivity_analysis trade_offs opportunity_cost robustness uncertainty flow queueing feedback observability coupling threshold

slug: constraint

slug: optimization

slug: robustness

slug: uncertainty

slug: flow

slug: queueing

slug: feedback

slug: observability

slug: coupling

slug: threshold

components:
Binding Constraint
Shadow Value
Relaxation Option
Relief Priority
Constraint Migration Monitor
Baseline Solution
Marginal Response Range
Relief Cost Model
Downstream Effect Audit

mechanisms:
Shadow Price Analysis
Constraint Sensitivity Report
Capacity Investment Analysis
Bottleneck Valuation Map
Marginal Capacity Value Review
Before/After Constraint Monitoring

essence_one_line: Identify which constraint most limits the objective and how much value is gained by relaxing it.

compression_statement: When a system is constrained by several limits, estimate the marginal value of relaxing each binding constraint so relief effort targets the constraint that most improves the objective rather than the most visible, politically salient, or easiest-to-describe bottleneck.

core_intuition: A bottleneck is not automatically the best place to invest. The useful question is what changes if that constraint is relaxed by a small, plausible amount. Shadowing the bottleneck means looking behind the visible limit to estimate its marginal value and to watch for the next limit that appears after relief.

canonical_formula: Given objective O, current feasible solution S, constraints C, candidate relaxation options R_i, and expected response ΔO_i, estimate shadow value V_i = ΔO_i / ΔR_i for binding constraints, prioritize relief by value, cost, risk, and feasibility, then monitor whether the binding constraint migrates after intervention.

structural_problem: A system is constrained by multiple limits, but actors do not know which constraint most restricts the objective or how much benefit would result from relaxing each one.

condition: Several constraints appear to be limiting performance.

why_it_matters: Without valuation, teams may chase the most visible constraint rather than the one whose relief would most improve the objective.

condition: Relief options require scarce investment, time, political capital, or operational disruption.

why_it_matters: The intervention matters when not every constraint can be relaxed at once.

condition: A model, process map, or operational record can estimate response to constraint relaxation.

why_it_matters: The archetype depends on comparing marginal value, not just naming a bottleneck.

condition: The bottleneck may migrate after relief.

why_it_matters: A one-time relief action can lose value if the next constraint immediately becomes binding.

condition: A current allocation, flow, policy, or process already has an explicit objective.

why_it_matters: Shadow value is meaningless unless there is a target outcome to improve.

symptom: Teams repeatedly add capacity where complaints are loudest but overall performance barely improves.

interpretation: Visible pain may not correspond to the highest marginal value of relief.

symptom: Different departments argue that their own resource cap is the true bottleneck.

interpretation: The system lacks a shared method for comparing constraint relief value.

symptom: Optimization or planning results show binding constraints but no decision about which constraint to relax next.

interpretation: The model reports feasibility limits but has not been converted into an intervention priority.

symptom: Past bottleneck fixes simply moved delay, cost, or overload to the next stage.

interpretation: Constraint migration is not being monitored.

root_tension: The system needs relief from constraints, but relief itself is scarce and must be aimed at the constraint whose relaxation produces the greatest legitimate improvement in the objective.

case: Only one obvious hard constraint exists and relief is mandatory.

why_not_this: No comparative shadowing or prioritization is needed.

case: The objective is not defined or is still politically unresolved.

why_not_this: The pattern may require objective weighting governance or objective function alignment before shadow values are meaningful.

case: The issue is general bottleneck discovery without estimating the value of relief.

why_not_this: That is closer to bottleneck identification and relief.

case: The task is only to test whether conclusions change under parameter variation.

why_not_this: That is sensitivity analysis protocol unless the result drives constraint-relief prioritization.

structural_intervention: Map the current objective, constraints, and feasible solution; identify binding constraints; estimate the marginal value and cost of relaxing each candidate constraint; prioritize relief; then monitor whether the bottleneck migrates or the estimate becomes invalid after intervention.

step: Clarify the objective and current feasible state.

purpose: Shadow values are relative to a target; they cannot be interpreted without knowing what improvement means.

step: Identify binding and near-binding constraints.

purpose: Separate constraints that are actually limiting the objective from limits that merely look important.

step: Define plausible relaxation options.

purpose: Make relief concrete: more capacity, fewer restrictions, faster handoff, larger budget, different eligibility, or improved coordination.

step: Estimate marginal response and uncertainty.

purpose: Compare how the objective changes when each constraint is relaxed within a credible range.

step: Rank relief actions with cost, legitimacy, feasibility, and risk adjustments.

purpose: High shadow value alone does not justify a relief action if the intervention is infeasible, unsafe, unjust, or too expensive.

step: Monitor constraint migration after relief.

purpose: The first bottleneck may stop being limiting; the next constraint must be detected before further investment.

rule: Do not invest in a nonbinding constraint solely because it is visible.

rationale: Relieving a slack constraint generally does not improve the objective.

rule: Treat shadow values as local estimates, not universal truths.

rationale: Marginal value can change after large relaxations, demand shifts, or changes in neighboring constraints.

rule: Prioritize relief only when marginal benefit, feasibility, legitimacy, and risk align.

rationale: A constraint can be valuable to relax yet inappropriate or impractical to relax.

rule: Recompute or re-evaluate after relief.

rationale: The binding constraint may migrate, making old relief rankings stale.

rule: Document the objective and assumption range used to value relief.

rationale: Shadow values are not neutral facts; they depend on the model and objective being used.

invariant: Objective reference remains explicit.

why_it_matters: The value of relaxing a constraint must be tied to a known objective, not informal preference.

invariant: Binding status is verified before relief is prioritized.

why_it_matters: A nonbinding constraint may be annoying but not currently limiting.

invariant: Marginal estimates stay within the range where they are valid.

why_it_matters: Large changes can create nonlinear effects that invalidate a small-relaxation estimate.

invariant: Constraint migration is monitored.

why_it_matters: A successful relief action changes the system; subsequent decisions need updated bottleneck information.

invariant: Relief decisions respect safety, fairness, legality, and legitimacy constraints.

why_it_matters: An apparently high-value constraint relaxation may be unacceptable if it violates protected boundaries.

outcome: Higher-value capacity investments.

why_expected: Relief effort is directed toward constraints with the greatest expected marginal contribution.

outcome: Reduced wasted investment in slack constraints.

why_expected: The process distinguishes visible constraints from binding constraints.

outcome: Clearer tradeoff reasoning for constraint relaxation.

why_expected: Decision-makers can see which assumptions, costs, and risks justify relief priorities.

outcome: Faster detection of next bottlenecks after relief.

why_expected: Migration monitoring is part of the archetype rather than an afterthought.

outcome: Better communication between modeling and action.

why_expected: Shadow values and sensitivity results are converted into intervention priorities.

prose_essence:
Bottleneck Capacity Shadowing asks a targeted question: **which constraint is actually limiting the objective, and what would it be worth to relax it?** It is not just bottleneck detection. It is a way to convert the fact that something is constrained into a ranked decision about where capacity relief, rule relaxation, staffing, budget, automation, or coordination effort should go next.

The archetype is most useful when several limits are plausible. A team may see overloaded staff, constrained budget, long queues, slow approvals, limited machines, unavailable beds, network throughput limits, or legal restrictions. The visible pain is not always the highest-value relief point. Shadowing the bottleneck estimates the marginal response from relaxing each binding constraint and then monitors where the limiting constraint moves after intervention.

prose_when_to_use:
Use this archetype when a system is underperforming and multiple constraints could be responsible. It fits especially well when relief options are scarce or costly, when a model or operating record can estimate response, and when the organization needs a defensible priority order for capacity investments or rule changes.

Do not use it as a substitute for deciding what the objective should be. If the objective is contested, first clarify the objective and weighting logic. Do not use it to justify relaxing safety, fairness, legal, privacy, or due-process constraints simply because their relaxation appears valuable. Some constraints are protective boundaries, not ordinary capacity limits.

prose_structural_problem:
The structural problem is not merely that a bottleneck exists. The harder problem is that multiple constraints compete for attention and the organization does not know which one most limits the objective. Teams often invest where complaints are loudest, where data is easiest to see, or where a department has the strongest political claim. That can relieve a visible constraint while leaving the real limiting factor untouched.

This pattern becomes important when relief itself is scarce. If every constraint can be relaxed cheaply and safely, shadow valuation is unnecessary. But when capacity, money, time, political capital, or disruption budget is limited, the system needs a way to compare relief opportunities.

prose_intervention_logic:
The intervention begins by making the objective and current feasible state explicit. Next, identify which constraints are binding or near-binding. Then define plausible relaxation options: add capacity, shorten a handoff, simplify a rule, increase budget, reduce processing time, automate a step, or create an alternate pathway. Estimate how the objective changes when each constraint is relaxed within a credible range. Rank relief options by expected value, cost, feasibility, legitimacy, safety, and timing. After relief, monitor whether the bottleneck moved.

The loop matters. A successful intervention changes the system. The old bottleneck may stop being binding, and the next constraint may appear. A mature implementation treats bottleneck shadowing as an iterative relief-prioritization cycle rather than a one-time calculation.

prose_key_components:
### Binding Constraint

A binding constraint is a limit that currently restricts the objective or feasible solution. It may be a capacity cap, staffing limit, budget ceiling, legal rule, machine bottleneck, pathway constraint, eligibility boundary, or coordination limit. The key is binding status: an annoying constraint is not necessarily the one that limits the current objective.

### Shadow Value

A shadow value estimates what the system gains if a binding constraint is relaxed by a small, plausible amount. It may be measured formally through optimization, approximated through simulation, inferred from historical data, or estimated by expert comparison. It should be treated as a local estimate, not as a universal truth.

### Relaxation Option

A relaxation option is the concrete way a constraint could be loosened or compensated for. Examples include hiring staff, adding machine time, expanding a budget, changing eligibility rules, improving a handoff, adding a route, automating a review, or creating extra buffer capacity. Without a concrete relaxation option, shadow value remains a diagnostic observation rather than an intervention.

### Relief Priority

Relief priority turns shadow values into an action order. The highest numeric marginal value may not be the first action if it is unsafe, illegitimate, politically impossible, too expensive, too slow, or likely to create worse downstream overload. Priority combines value with actionability and guardrails.

### Constraint Migration Monitor

A constraint migration monitor tracks what happens after relief. If one bottleneck is relieved, another constraint may become binding. Monitoring prevents the organization from repeatedly investing in the old bottleneck after the system has changed.

prose_common_mechanisms:
Shadow price analysis is one mechanism for estimating the marginal value of relaxing a binding constraint. It is common in formal optimization, but it is not the archetype itself. The archetype also includes deciding whether the relief is legitimate and monitoring whether the bottleneck moves.

Constraint sensitivity reports show how outcomes respond when limits are varied. They support the archetype when they compare relief options and inform prioritization. They collapse into ordinary sensitivity analysis when they only report parameter response without a relief decision.

Capacity investment analysis compares candidate investments such as staff, machines, bandwidth, space, budget, or process changes. It implements the archetype when it ranks relief options by marginal objective value and guardrails rather than by generic return on investment alone.

Bottleneck valuation maps visualize constrained stages, estimated relief values, and migration risks. They are helpful artifacts for communication, but a map alone is not the archetype.

Marginal capacity value reviews are recurring decision rituals. Teams revisit binding constraints, update evidence, compare relief options, and decide which capacity constraint to address next.

Before/after constraint monitoring tracks whether relief actually changed performance and where the new limiting factor appears. This mechanism protects the archetype from stale shadow values.

prose_failure_modes:
A common failure mode is investing in a nonbinding constraint because it is visible or politically salient. Mitigate this by checking binding status before prioritizing relief.

Another failure mode is false precision. A shadow value may depend on assumptions, model structure, or a small-relaxation range. Mitigate this with uncertainty ranges, scenario checks, and explicit validity boundaries.

A third failure mode is ignoring constraint migration. After relief, teams may keep optimizing the old bottleneck. Mitigate this with before/after monitoring and repeated review.

A fourth failure mode is local bottleneck relief that worsens system performance. Mitigate this with downstream effect audits and system-level outcome metrics.

A fifth failure mode is objective laundering: the chosen objective hides value judgments, and the shadow value is presented as neutral. Mitigate this with objective weighting governance when values are contested.

prose_neighbor_distinctions:
**Constrained Resource Allocation** allocates resources under constraints. Bottleneck Capacity Shadowing asks which constraint should be relaxed to improve the feasible allocation or outcome.

**Network Flow Optimization** routes flow through a capacity-constrained topology. Bottleneck Capacity Shadowing may use flow models, but its decision object is relief value, not routing.

**Sensitivity Analysis Protocol** diagnoses whether assumptions materially change conclusions. Bottleneck Capacity Shadowing uses constraint response to prioritize relief actions.

**Robust Solution Selection** chooses a solution that remains acceptable across uncertainty. Bottleneck Capacity Shadowing chooses which constraint to relax in the current or modeled system.

**Bottleneck Identification and Relief** finds and addresses limiting stages. Bottleneck Capacity Shadowing adds marginal valuation, comparison among relief options, and migration monitoring.

prose_cross_domain_examples:
In hospital operations, the archetype helps compare whether imaging capacity, bed availability, discharge coordination, or transport capacity most limits patient flow.

In cloud infrastructure, it helps decide whether to add compute, memory, database connections, cache capacity, or network bandwidth.

In manufacturing, it helps compare machine time, inspection capacity, material staging, staffing, or supplier constraints.

In public benefits administration, it helps evaluate whether documentation burden, caseworker staffing, identity verification, call-center capacity, or eligibility rules most limits enrollment.

In grantmaking, it helps decide whether review speed, legal contracting, matching requirements, budget caps, or applicant support most limits disbursement to priority projects.

prose_non_examples:
A dashboard that shows a long queue is not enough. The dashboard may reveal a symptom, but it does not estimate relief value or prioritize action.

A generic list of constraints is not enough. The archetype requires binding status, relief options, marginal value estimates, priority logic, and migration monitoring.

A sensitivity analysis that varies assumptions without making a relief decision is not this archetype. It may support this archetype, but it remains diagnostic unless it guides constraint-relief prioritization.

A solver output containing shadow prices is not the archetype. The solver is a mechanism; the archetype is the intervention pattern that uses shadow values to choose and update relief actions.

prose_tradeoffs:
The archetype trades speed for defensibility. A quick fix may be faster than shadowing, but it may also relieve the wrong constraint.

It trades precision for actionability. Formal estimates may look authoritative but can be brittle; rough estimates may be more practical but need uncertainty notes and monitoring.

It trades local improvement against system effects. Relieving a local bottleneck may simply push overload downstream unless system-level consequences are checked.

It also trades optimization value against legitimacy. A high-value relaxation is not automatically acceptable if it weakens a protective rule, creates inequity, or increases safety risk.

prose_invariants_to_preserve:
The objective must remain explicit. Shadow values do not float free; they are always relative to a target outcome.

Binding status must be verified. Investing in a nonbinding constraint is one of the easiest ways to waste capacity funds.

Marginal estimates must stay within their validity range. Large interventions can create nonlinear effects, strategic behavior, or new constraints.

Constraint migration must be monitored. Relief changes the system, so the next priority should be based on the new bottleneck, not the old analysis.

Protective constraints must remain visible. Some constraints protect safety, fairness, legality, due process, resilience, or privacy. The archetype should not launder their removal through a numeric value estimate.

prose_target_outcomes:
The main target outcome is better relief prioritization. Resources go to the constraint whose relaxation is most likely to improve the objective, rather than to the loudest, most visible, or easiest-to-fix constraint.

Secondary outcomes include reduced wasted investment, clearer communication between analysts and decision-makers, better sequencing of capacity improvements, and faster recognition of new bottlenecks after relief.

A successful use also improves accountability. Decision-makers can explain why one constraint-relief action came before another and what evidence would change the priority.

prose_parameter_dimensions:
The first tuning dimension is the **objective** used to estimate value: throughput, wait time, cost, access, coverage, reliability, quality, equity, or some composite target. Different objectives can produce different relief priorities.

The second dimension is the **relaxation increment**. A small relief may have one value while a large relief changes the system enough to invalidate the estimate. The draft should define the range over which the marginal value is credible.

The third dimension is **binding threshold**. Some constraints are clearly binding, while others are near-binding or episodic. The threshold determines which constraints enter the relief comparison.

The fourth dimension is **cost and legitimacy weighting**. A relief action may be high-value but costly, risky, or illegitimate. Mature use of the archetype tunes how these considerations modify priority.

The fifth dimension is **monitoring cadence**. Fast-moving systems need frequent re-shadowing; stable systems may only need periodic review after major changes.

prose_variants_and_near_names:
Marginal Constraint-Relief Prioritization is the most direct subtype. It focuses on ranking relief actions by expected value and feasibility.

Flow Bottleneck Shadowing applies the same logic to process and network flows, such as patient movement, logistics routes, queueing systems, or data infrastructure.

Policy Constraint-Relief Shadowing applies the logic to institutional constraints such as eligibility rules, documentation requirements, staffing caps, procurement restrictions, or statutory limits. This variant is more governance-sensitive because relaxing a policy constraint may affect fairness, legitimacy, or rights.

Near names include Constraint Relief Valuation, Marginal Capacity Valuation, Bottleneck Valuation, Binding Constraint Prioritization, and Shadow Price Prioritization. Shadow price analysis should remain a mechanism name, not the archetype name, unless the work only concerns a formal optimization report.

short_definition: Prioritize constraint-relief actions by estimated marginal improvement in the target objective.

distinctive_feature: The variant emphasizes ranking relief actions rather than only diagnosing which constraint is binding.

distinct_from_parent: The parent includes diagnosis, valuation, prioritization, and migration monitoring; this variant concentrates on the prioritization step.

still_same_parent_because: It still depends on binding constraints and shadow values rather than a different intervention logic.

use_when: Several candidate relief actions are available but only some are worth funding or scheduling first.

use_when: The system objective is explicit enough that marginal relief value can be compared across constraints.

use_when: The bottleneck may move after relief, so the order of interventions matters.

Binding Constraint

role: Candidate limit whose relaxation is evaluated.

Shadow Value

role: Marginal value estimate used for ranking.

Relief Priority

role: Ordering of relief actions.

Marginal Capacity Value Review

role: Structured comparison of relief alternatives.

Capacity Investment Analysis

role: Economic or operational evaluation of relief options.

example_domains: capacity_planning operations infrastructure budgeting

domain: Service operations

example: Ranking whether to add intake staff, diagnostic capacity, or discharge coordination by marginal throughput improvement.

domain: Cloud infrastructure

example: Comparing whether storage I/O, network bandwidth, or compute quota relief most improves service performance.

failure_modes: A relief action is ranked using a stale model after demand or process structure changes.

failure_modes: Marginal value is extrapolated beyond the small range where it remains valid.

Flow Bottleneck Shadowing

short_definition: Estimate the marginal value of relieving constrained nodes, links, handoffs, or channels in a flow network.

distinctive_feature: It applies shadow-value reasoning to explicit network or process-flow bottlenecks.

distinct_from_parent: The parent is not limited to networked flow; this variant specializes the reasoning to capacity-constrained pathways.

still_same_parent_because: The central action remains valuing relief of binding constraints, not rerouting flow or solving a network model.

source_primes: network_flow_models flow constraint

use_when: The constrained object is a path, node, edge, queue, or handoff in a flow system.

use_when: The goal is throughput, cost reduction, delay reduction, or service reliability rather than only global allocation.

use_when: The limiting point may migrate after one bottleneck is relieved.

Binding Constraint

role: Constrained node, edge, queue, or handoff.

Constraint Migration Monitor

role: Detects the new limiting point after relief.

Bottleneck Valuation Map

role: Displays constrained points and relief value estimates.

Throughput Response Test

role: Checks whether relieving the bottleneck actually improves flow.

example_domains:
logistics
healthcare operations
digital infrastructure
case management

domain: Healthcare operations

example: Estimating whether bed capacity, lab turnaround, or discharge transport is the highest-value relief point.

domain: Data services

example: Estimating whether database connection limits or network egress limits constrain request throughput.

failure_modes: The variant collapses into ordinary network flow optimization if it focuses on routing rather than relief valuation.

Policy Constraint-Relief Shadowing

short_definition: Estimate which legal, budgetary, eligibility, staffing, or procedural constraint most limits a policy objective and what relief would be worth.

distinctive_feature: It makes the political or institutional cost of relaxing a constraint visible alongside marginal objective gains.

distinct_from_parent: The parent is domain-general; this variant adds legitimacy and procedural review around institutional constraints.

still_same_parent_because: The intervention still centers on valuing constraint relief and monitoring the consequences of relief.

use_when: The constraints are institutional or policy constraints rather than only physical capacities.

use_when: Constraint relief has legitimacy, fairness, compliance, or accountability consequences.

use_when: Decision-makers must decide whether the relief is worth the governance cost.

Relaxation Option

role: Proposed policy, rule, eligibility, or budget adjustment.

Relief Priority

role: Governed ranking of relief opportunities.

Constraint Sensitivity Report

role: Documents expected policy response to relaxed constraints.

Stakeholder Review Panel

role: Checks legitimacy and distributional impacts.

example_domains:
public policy
procurement
benefits administration
regulatory operations

domain: Public benefits

example: Estimating whether eligibility simplification, caseworker staffing, or documentation requirements most limits uptake.

failure_modes: A high marginal objective gain is used to justify unsafe or illegitimate constraint relaxation.

near_names:
Constraint Relief Valuation
Shadow Price Prioritization
Marginal Capacity Valuation
Bottleneck Valuation
Binding Constraint Prioritization