Cautious Pattern Completion

batch: First Iteration/Batch 37

Guarded Reconstruction

notes: Use when the emphasis is reconstructing an event, design, history, or meaning from incomplete traces.

Uncertainty-Marked Completion

notes: Use when the emphasis is visibly marking which parts of the completion are inferred rather than observed.

Gap Filling with Verification

notes: Readable near-name for the same intervention logic.

slug: observability

slug: probability

components:
Partial Input
Candidate Completion
Assumption Marker
Missing Evidence Marker
Uncertainty Label
Verification Step
Conclusion Hold-or-Release Gate
Alternative Completion Set
Source Trace
Disconfirmation Probe
Confidence Update Record
Risk-Weighted Action Threshold

mechanisms:
Hypothesis List
Assumption Log
Diagnostic Differential
Reconstruction Note
Uncertainty Tagging
Hallucination Check
Disconfirming Evidence Search
Source-Tracing Table
Withhold-Conclusion Checkpoint

essence_one_line: Fill gaps in partial information while marking what is inferred and what remains unverified.

compression_statement: When incomplete inputs invite premature completion, reconstruct the likely whole with explicit assumptions, missing evidence, uncertainty labels, disconfirming checks, and verification steps before treating the completion as fact.

core_intuition: Pattern completion is useful because action often cannot wait for perfect information. It is dangerous because coherent stories feel more complete than the evidence behind them. This archetype keeps the productive ability to infer a whole from fragments while preventing the inferred whole from gaining the authority of observed fact.

canonical_formula: partial input + candidate completion(s) + assumption markers + missing-evidence markers + uncertainty label + disconfirmation probe + verification gate = bounded completion

structural_problem: A person, team, model, or organization infers a coherent whole from partial evidence and then risks treating that inferred completion as if it were fully observed or verified.

trigger_conditions: The available evidence is partial, ambiguous, noisy, truncated, indirect, or drawn from only one perspective.

trigger_conditions: A plausible story, diagnosis, reconstruction, or interpretation can be generated before enough verification is available.

trigger_conditions: Waiting for complete evidence is costly, but acting on an unsupported completion is also risky.

trigger_conditions: Fluent outputs, familiar patterns, strong priors, or organizational pressure make the completion feel more certain than it is.

trigger_conditions: Different completions would imply different actions, owners, risks, or ethical obligations.

symptoms: Inferred details are repeated later as facts without their original uncertainty labels.

symptoms: A team fills a narrative gap because the story feels coherent, not because the missing evidence was found.

symptoms: Generated text, diagnostic labels, or incident timelines contain unsupported specifics that no one can source.

symptoms: Only one plausible completion is discussed even though the input is compatible with several alternatives.

symptoms: People ask for confirmation evidence but do not search for evidence that would break the completion.

symptoms: Decisions are made from a reconstruction whose missing pieces are known but undocumented.

root_tension: The system needs enough completion to orient action under uncertainty, but enough humility to avoid laundering assumptions into facts. Too little completion creates paralysis; too much completion creates hallucination, premature closure, and false confidence.

anti_signatures: The input is complete enough and the task is simply applying a known rule; use deductive or procedural validation instead.

anti_signatures: The main issue is detecting whether a recurring pattern is real; use Pattern Detection with Validation rather than completion from partial input.

anti_signatures: The task is to test a specific causal hypothesis after it has already been stated; use a hypothesis-testing frame as the primary archetype.

anti_signatures: The problem is primarily missing or corrupted source records; use data integrity or evidence-preservation patterns before completion.

anti_signatures: The stakes are low and the completion will not be stored, communicated, or acted on as knowledge.

structural_intervention: Make the completion process explicit: identify the partial input, generate one or more candidate completions, separate evidence from assumptions, mark missing evidence, assign uncertainty, seek disconfirmation, and gate action or communication based on verification status.

Bound the partial input

logic: State exactly what is known, observed, measured, provided, or recovered, and identify the limits of that input.

Generate candidate completions

logic: Create one or more plausible wholes, reconstructions, explanations, or interpretations that could fit the partial input.

Separate evidence from assumption

logic: Mark which parts of each completion are directly supported, indirectly inferred, assumed from priors, estimated, or invented as placeholders.

Mark missing evidence

logic: Name the specific evidence, observations, perspectives, records, tests, or feedback that would be needed to verify or narrow the completion.

Assign uncertainty and action status

logic: Label confidence and state whether the completion is a speculation, working hypothesis, provisional reconstruction, action guide, or verified claim.

Probe for disconfirmation

logic: Ask what observation would make the completion wrong, then look for the most informative disconfirming or distinguishing evidence available.

Hold, release, revise, or reject

logic: Decide whether to withhold the conclusion, use it for reversible action, escalate for verification, revise it, or reject it as unsupported.

rule: If the completion contains details not present in the input, tag those details as inferred, assumed, or unverified until checked.

rule: If several completions fit the same partial input, keep alternatives visible until discriminating evidence narrows them.

rule: If acting on a completion is irreversible, consequential, or reputation-sensitive, require stronger verification than if the action is reversible and low-risk.

rule: If a completion is produced by a fluent generative system or confident expert, do not let fluency substitute for source traceability.

rule: If missing evidence cannot be obtained, preserve a bounded conclusion rather than upgrading the completion to fact.

rule: If disconfirming evidence appears, update confidence and scope rather than patching the completion to preserve the original story.

target_invariants: Observed evidence remains distinguishable from inferred or assumed content.

target_invariants: Missing evidence is visible rather than silently filled in.

target_invariants: Uncertainty travels with the completion when it is stored, communicated, or used for action.

target_invariants: Alternative completions are not prematurely suppressed when the partial input supports them.

target_invariants: Verification requirements scale with stakes, irreversibility, and harm from being wrong.

target_invariants: New evidence can revise or reject the completion without reputational penalty for updating.

expected_outcomes: Fewer unsupported details are treated as facts.

expected_outcomes: Teams can act under uncertainty while preserving epistemic caution.

expected_outcomes: Incident reconstructions, diagnoses, generated outputs, and interpretations become easier to audit.

expected_outcomes: Premature closure decreases because alternatives and missing evidence stay visible.

expected_outcomes: Verification work becomes targeted at the most important missing or fragile links.

expected_outcomes: Confidence is calibrated to evidence rather than to narrative coherence.

prose_essence:
Cautious Pattern Completion is the discipline of filling gaps without hiding the fact that gaps were filled. It is useful when a person, team, or system has enough fragments to form a plausible whole, but not enough evidence to treat that whole as settled. The archetype permits provisional reconstruction while preserving the difference between evidence, inference, assumption, and verified conclusion.

The central move is not “never infer.” In many settings, diagnosis, triage, design recovery, intelligence analysis, and AI-assisted interpretation require inference before all evidence is available. The central move is to make the inference legible, bounded, revisable, and properly authorized.

prose_when_to_use:
Use this archetype when incomplete information invites a coherent story: a partial incident timeline, an early diagnosis, a fragmentary historical record, a sparse customer interview set, a generated summary, a corrupted data record, or a design rationale recovered from traces. It is especially important when the completed story will guide action, travel to other readers, or become part of institutional memory.

Do not reserve it only for high-stakes domains. Lightweight versions are useful whenever a plausible completion could be mistaken for a fact. Stronger versions are needed when completions affect safety, rights, reputations, clinical decisions, legal analysis, financial action, or public claims.

prose_structural_problem:
The structural problem is that pattern-completing minds and systems prefer coherent wholes. Once a coherent whole exists, it becomes cognitively easier to remember, repeat, and defend than the messy partial input that produced it. This can convert missing evidence into assumed detail and assumed detail into apparent fact.

The risk is not merely being wrong. The deeper risk is loss of traceability: later users cannot tell which parts were observed, which were inferred, and which were never checked. The completion becomes hard to revise because it no longer carries its uncertainty with it.

prose_intervention_logic:
The intervention turns completion into a controlled sequence. First, bound the partial input. Then state one or more candidate completions. Next, mark the assumptions that bridge the gap between input and completion. Identify missing evidence that would confirm, reject, or narrow each completion. Label uncertainty in a way that travels with the claim. Search for disconfirming evidence. Finally, decide whether the completion should be withheld, used only for reversible action, escalated for verification, revised, or released as a stronger claim.

The point is to keep useful inference available without granting it more authority than it has earned. A completion can be good enough to guide a reversible next step while still being too uncertain to publish as fact or use for an irreversible decision.

prose_key_components:
### Partial Input

`partial_input` is the part of the archetype that defines the incomplete, ambiguous, truncated, noisy, or one-sided evidence from which a fuller interpretation might be inferred. The component keeps the draft grounded in what is actually known. Without it, the completion can drift into free-form speculation because there is no explicit boundary around the available input.

### Candidate Completion

`candidate_completion` is the part of the archetype that states a possible coherent whole, explanation, reconstruction, or interpretation generated from the partial input without treating it as verified fact. Candidate completions should usually be plural when stakes are high. A single completion can become a premature closure point unless alternatives are named or actively ruled out.

### Assumption Marker

`assumption_marker` is the part of the archetype that labels the inferred links, defaults, priors, or background expectations used to connect the partial input to a candidate completion. This component separates evidence from connective tissue. It is especially important when the completion feels obvious because obviousness often hides assumptions.

### Missing Evidence Marker

`missing_evidence_marker` is the part of the archetype that identifies the specific observations, tests, records, perspectives, or constraints that would be needed to confirm, reject, or narrow the candidate completion. The marker prevents the inferred whole from becoming self-sealing. It tells users what would make the completion less provisional.

### Uncertainty Label

`uncertainty_label` is the part of the archetype that communicates the confidence, evidence status, and verification state of the completion so inferred content is not mistaken for observed content. The label should be visible wherever the completion is used. It can be qualitative, quantitative, staged, or tied to action thresholds.

### Verification Step

`verification_step` is the part of the archetype that specifies how the candidate completion will be checked against new evidence, source records, independent review, disconfirming observations, or real-world feedback. Verification is the difference between useful provisional completion and unchecked fabrication. It may be immediate, deferred, sampled, or conditional on stakes.

### Conclusion Hold-or-Release Gate

`conclusion_hold_or_release_gate` is the part of the archetype that determines whether the completion can be acted on, escalated, communicated, held as a hypothesis, or rejected given its uncertainty and risk. This gate prevents a useful inference from being used at the wrong authority level. High-stakes completions may remain watch items until verification improves.

prose_common_mechanisms:
Mechanisms are implementation forms. They make the archetype easier to practice, but none of them is the archetype by itself. A checklist, table, or protocol only instantiates Cautious Pattern Completion when it preserves the evidence/inference distinction and connects completion status to verification and action authority.

### Hypothesis List

`hypothesis_list` is a template that implements the archetype by helping teams control completion from partial evidence. Its role is to creates a structured list of possible completions so the first plausible story does not become the only story. It should not be confused with the archetype itself; it is one way to operationalize the evidence labeling, verification, or action-gating logic.

### Assumption Log

`assumption_log` is a document that implements the archetype by helping teams control completion from partial evidence. Its role is to records the inferred premises, defaults, and guesses used to build a completion from incomplete inputs. It should not be confused with the archetype itself; it is one way to operationalize the evidence labeling, verification, or action-gating logic.

### Diagnostic Differential

`diagnostic_differential` is a method that implements the archetype by helping teams control completion from partial evidence. Its role is to maintains several possible explanations while seeking evidence that distinguishes among them. It should not be confused with the archetype itself; it is one way to operationalize the evidence labeling, verification, or action-gating logic.

### Reconstruction Note

`reconstruction_note` is a document that implements the archetype by helping teams control completion from partial evidence. Its role is to documents what is known, what is inferred, what is missing, and what would verify a reconstructed sequence or whole. It should not be confused with the archetype itself; it is one way to operationalize the evidence labeling, verification, or action-gating logic.

### Uncertainty Tagging

`uncertainty_tagging` is a template that implements the archetype by helping teams control completion from partial evidence. Its role is to labels parts of a completion as observed, inferred, assumed, estimated, unverified, contested, or verified. It should not be confused with the archetype itself; it is one way to operationalize the evidence labeling, verification, or action-gating logic.

### Hallucination Check

`hallucination_check` is a protocol that implements the archetype by helping teams control completion from partial evidence. Its role is to reviews generated or inferred content for unsupported details, fabricated links, and overconfident completions. It should not be confused with the archetype itself; it is one way to operationalize the evidence labeling, verification, or action-gating logic.

### Disconfirming Evidence Search

`disconfirming_evidence_search` is a procedure that implements the archetype by helping teams control completion from partial evidence. Its role is to actively looks for observations or sources that would break the current completion. It should not be confused with the archetype itself; it is one way to operationalize the evidence labeling, verification, or action-gating logic.

### Source-Tracing Table

`source_tracing_table` is a artifact that implements the archetype by helping teams control completion from partial evidence. Its role is to maps each element of a completion to direct evidence, indirect evidence, assumption, or missing source. It should not be confused with the archetype itself; it is one way to operationalize the evidence labeling, verification, or action-gating logic.

### Withhold-Conclusion Checkpoint

`withhold_conclusion_checkpoint` is a ritual that implements the archetype by helping teams control completion from partial evidence. Its role is to creates a decision pause where the group decides whether evidence is sufficient to release the completion as a claim. It should not be confused with the archetype itself; it is one way to operationalize the evidence labeling, verification, or action-gating logic.

prose_failure_modes:
Narrative laundering occurs when a provisional completion is repeated without labels until it becomes accepted as fact. Single-story lock-in occurs when the first plausible completion suppresses alternatives. Decorative uncertainty occurs when labels exist but do not change decisions. Confirmation-only verification occurs when teams seek support for the favored completion but do not look for evidence that would break it.

AI and expert contexts add a fluency-trust failure mode. Polished text, confident tone, or authoritative presentation can make unsupported completion feel verified. The mitigation is source tracing, disconfirmation, and explicit hold-or-release gates.

prose_neighbor_distinctions:
Cautious Pattern Completion is distinct from Pattern Detection with Validation. Pattern Detection asks whether a repeated or candidate pattern is real. Cautious Pattern Completion asks how to infer a missing whole from fragments without treating the result as fully observed.

It is distinct from Hypothesis Testing Frame. Hypothesis testing evaluates a stated claim; this archetype often generates and bounds the provisional claim before formal testing.

It is distinct from Uncertainty Explicitness. Uncertainty labels are necessary here, but the archetype also requires candidate completions, missing evidence markers, disconfirmation probes, and action gates.

It is distinct from Deductive Chain Validation. Deduction checks whether conclusions follow from rules and premises. Cautious completion works where the evidence is incomplete and the missing whole must be inferred.

Abductive reasoning is a close neighbor and proposed-prime candidate. In this draft it is not treated as canonical; it is noted as a reasoning-family neighbor that may require ontology review.

prose_cross_domain_examples:
In incident analysis, a team reconstructs an outage timeline from partial logs and marks which intervals are inferred. The team can use the timeline to guide investigation while withholding final root cause until a missing trace is checked.

In medical or technical diagnosis, early signals may suggest a likely explanation, but the practitioner keeps a differential visible and seeks exclusion evidence before closing the case.

In AI-assisted research, a generated summary may fill gaps in a source document. The user applies a hallucination check and source-tracing table so unsupported additions are not carried into the final report.

In product discovery, a small interview set may suggest user needs. The team labels those needs as hypotheses and schedules validation before committing roadmap resources.

In software maintenance, engineers infer legacy design intent from old comments, tests, and behavior. They distinguish confirmed constraints from guessed rationale so future maintainers do not inherit speculation as architecture truth.

prose_non_examples: A fictional story that invents missing details for entertainment is not this archetype because no one is treating the completion as factual knowledge. A complete verified record processed by a rule engine is not this archetype because the main task is rule application rather than gap-filling. A dashboard that imputes missing values while hiding which values are imputed is not a successful use; it is a failure case. A group choosing the most appealing explanation without evidence labels or disconfirmation is premature closure, not cautious completion.

prose_tradeoffs:
The main tradeoff is speed versus verification. Fast completion helps orient action, but unchecked completion can create confident error. Another tradeoff is clarity versus complexity: a single story is easier to communicate than a carefully labeled reconstruction. There is also a traceability burden. Source tracing, alternative lists, and uncertainty tags add work, so the process should be scaled to risk.

Caution can also become paralysis. The answer is not to require perfect certainty before every action; it is to match action type to confidence. Watching, reversible action, and information gathering can proceed under weaker confidence than irreversible commitment or public assertion.

prose_invariants_to_preserve:
The primary invariant is that observed evidence must remain distinguishable from inferred content. A second invariant is that missing evidence remains visible rather than silently patched over. A third is that uncertainty travels with the completion across documents, meetings, dashboards, summaries, model outputs, and decisions.

The archetype also preserves revisability. New evidence should be allowed to narrow, weaken, or reject a completion without requiring people to defend the original story. Finally, action authority must remain proportionate to confidence and stakes.

prose_target_outcomes:
A successful application produces provisional interpretations that are useful but not overconfident. It improves auditability because others can inspect what was known, what was inferred, and what still needs checking. It reduces premature closure by keeping alternatives and disconfirming probes visible. It also makes verification work more efficient because the missing evidence markers show exactly where the completion is fragile.

At organizational scale, the archetype improves learning from incidents, research, customer signals, generated outputs, and incomplete records. It helps knowledge systems remember uncertainty rather than just storing the neat story that came after it.

prose_parameter_dimensions:
Completion aggressiveness determines how much of the missing whole is inferred now. Conservative completion leaves more unknowns visible; aggressive completion is useful for fast triage but increases overcompletion risk.

Alternative breadth determines how many plausible completions remain visible. Keeping more alternatives helps avoid premature closure, but too many can slow action. The right breadth depends on ambiguity, stakes, and the cost of missing a different explanation.

Uncertainty granularity determines whether labels are attached to the whole completion, specific claims, data fields, causal links, source passages, or action thresholds. More granular labels improve auditability but add workflow load.

Verification burden determines how much checking is required before the completion can guide action. The burden should rise with irreversibility, harm from being wrong, reputational risk, and the chance that unsupported detail will spread.

Communication authority determines how the completion may be described: speculation, working hypothesis, provisional reconstruction, recommendation, or verified conclusion. Much failure comes from using cautious language internally and confident language externally.

prose_variants_and_near_names:
Diagnostic Completion with Differential keeps several possible explanations visible until discriminating evidence is found. Source-Traced Reconstruction focuses on mapping each element of a reconstructed whole to evidence or assumption status. AI Completion Hallucination Guard applies the same logic to generated or AI-assisted completions, where fluent unsupported details can appear authoritative. Missing-Data Completion with Review applies the pattern to imputed, estimated, or proxy-filled data fields.

Near names include Guarded Reconstruction, Uncertainty-Marked Completion, and Gap Filling with Verification. Mechanism-like near names include Hypothesis List, Assumption Log, Diagnostic Differential, Reconstruction Note, Uncertainty Tag, and Hallucination Check. These are preserved as mechanisms or variants rather than drafted as separate parent archetypes.

Diagnostic Completion with Differential

short_definition: Completes a likely diagnosis, fault explanation, or cause from partial symptoms while keeping alternative explanations and exclusion evidence visible.

distinctive_feature: The completion is organized around a differential set: the intervention preserves multiple candidate explanations until discriminating evidence is found.

distinct_from_parent: The parent covers any partial-input completion. This variant specifically uses competing explanations and exclusion criteria to avoid diagnostic closure.

still_same_parent_because: It still depends on partial input, candidate completion, missing evidence markers, uncertainty labels, and verification gates.

use_when: Symptoms, traces, incident signals, or user reports are incomplete but action requires a working explanation.

use_when: Several plausible explanations fit the observed input and premature closure would create safety, cost, or credibility risk.

Alternative Completion Set

role: Keeps competing explanations visible.

Missing Evidence Marker

role: Identifies discriminating evidence.

Conclusion Hold-or-Release Gate

role: Controls when a working diagnosis can guide action.

Diagnostic Differential

mechanism_type: method

role: Maintains plausible alternatives and exclusions.

Disconfirming Evidence Search

mechanism_type: procedure

role: Looks for evidence that would undermine the favored completion.

example: An incident team names two plausible outage narratives, marks missing log evidence, and withholds the final cause until one narrative survives verification.

domain: medicine

example: A clinician keeps a differential diagnosis visible when early symptoms suggest one condition but exclusion tests have not yet returned.

failure_modes: The first plausible diagnosis crowds out alternatives.

failure_modes: The differential becomes a static list rather than a guide to discriminating evidence.

Source-Traced Reconstruction

short_definition: Reconstructs a missing sequence, design, event history, or textual meaning while tracing every reconstructed element to evidence or assumption status.

distinctive_feature: The variant emphasizes traceability from each reconstructed element back to source evidence or explicit assumption.

distinct_from_parent: The parent may use any verification method. This variant makes source trace the central control on completion authority.

still_same_parent_because: The reconstruction remains a candidate completion constrained by missing evidence markers, uncertainty labels, and verification steps.

use_when: A coherent history, incident sequence, design rationale, narrative, or record must be reconstructed from incomplete traces.

use_when: Readers or decision makers need to know which parts of the reconstruction are observed, inferred, estimated, or unknown.

Source Trace

role: Connects claims to evidence or assumption status.

Partial Input

role: Defines the incomplete trace set.

Uncertainty Label

role: Marks provisional reconstruction elements.

Source-Tracing Table

mechanism_type: artifact

role: Maps elements to sources.

Reconstruction Note

mechanism_type: document

role: Records known, inferred, and unknown parts.

example: Engineers reconstruct why an old module behaves oddly by separating code facts, commit evidence, and inferred design intent.

domain: history

example: A researcher reconstructs a likely sequence of events while marking which links rest on primary sources and which remain interpretive.

failure_modes: Trace labels are added after the story is already settled.

failure_modes: The source trace becomes decorative and does not change confidence or action.

AI Completion Hallucination Guard

short_definition: Controls generated completions from AI or automated systems by requiring source checks, uncertainty labels, and explicit separation of generated detail from verified fact.

distinctive_feature: The overcompletion risk is intensified by fluent generation and model opacity, so verification and source separation must be made explicit.

distinct_from_parent: The parent covers human and organizational pattern completion as well. This variant focuses on machine-generated or AI-assisted completions.

still_same_parent_because: It still uses partial input, candidate completion, assumption markers, missing evidence markers, uncertainty labels, and verification gates.

use_when: A generative system fills in missing facts, citations, requirements, explanations, code behavior, or narrative details.

use_when: The output is fluent enough that unsupported completions may be mistaken for verified knowledge.

Source Trace

role: Separates supported details from generated additions.

Uncertainty Label

role: Communicates evidence status of generated claims.

Verification Step

role: Checks generated content before use.

Hallucination Check

mechanism_type: protocol

role: Finds unsupported generated claims.

Source-Tracing Table

role: Maps output claims to evidence.

example: A user asks an AI to summarize a sparse document and then checks every added detail against the source before treating it as fact.

example: Developers ask an AI to infer legacy code behavior, then tag inferred behavior separately from behavior verified by tests.

failure_modes: Verification is applied only to citations while unsupported causal or contextual claims remain unchecked.

Missing-Data Completion with Review

short_definition: Uses estimates, imputations, or proxy values to fill missing data while marking imputation status and checking whether conclusions depend on those fills.

distinctive_feature: The completion is data-field oriented and must preserve the distinction between observed values and imputed or estimated values.

distinct_from_parent: The parent includes qualitative and conceptual completion. This variant focuses on missing data, imputation status, and sensitivity to filled values.

still_same_parent_because: It still relies on partial input, candidate completion, uncertainty labels, missing evidence markers, and verification or sensitivity checks.

use_when: A dataset, record, forecast, or evidence base contains missing fields that must be interpreted or temporarily filled.

use_when: Downstream decisions may treat filled values as if they were observed.

Missing Evidence Marker

role: Marks absent records or fields.

Uncertainty Label

role: Shows imputed or estimated status.

Confidence Update Record

role: Updates conclusions when missing data is later observed.

Uncertainty Tagging

mechanism_type: template

role: Marks imputed values.

Sensitivity Review

role: Checks whether conclusions change under different completions.

example_domains: analytics forecasting survey_research operations finance public_health

domain: analytics

example: An analyst fills missing customer fields for a model but tags imputed values and reruns conclusions with and without them.

failure_modes: Imputed values are exported without provenance.

failure_modes: The completion method embeds bias that is invisible to downstream users.

near_names:
Guarded Reconstruction
Uncertainty-Marked Completion
Gap Filling with Verification
Fill-in-the-Gap Reasoning Check
Hallucination Check


Central Reserve Redeployment

type: archetype

source: generated

batch: Batch 15

canonical_family: Topology, Reserve Mobility, and Multi-Front Response

aliases:
Interior-Line Response Design
Interior-Line Maneuver
Short-Path Reserve Reallocation
Centralized Multi-Front Response
Topology-Leveraged Reserve Reallocation
Central Reserve Concentration

slug: concentration

slug: reserve

slug: maneuver

slug: latency

slug: coordination

slug: network

slug: topology

slug: path

slug: allocation

slug: prioritization

slug: scheduling

slug: flow

slug: uncertainty

slug: feedback

slug: constraint

slug: bottleneck

slug: resilience

slug: teleconnection

slug: demand

slug: decision

slug: controllability

components:
Multi-Front State Map
Interior Path-Time Model
Central-Position Viability Criterion
Reservable Resource Pool
Mobile-Resource Eligibility Profile
Protected Capacity
Reserve Owner or Steward
Minimum Local-Cover Rule
Front Priority Rule
Response Timing Window
Reserve-Release Authority
Route Capacity and Health Map
Multi-Front Operating State
Dependency and Constraint Map
Simultaneous-Demand Guardrail
Deployment-Turnaround Budget
Replenishment Rule
Hub Capacity and Resilience Plan
Topology-Reassessment Cadence
Forecast or Risk Signal
Tiered Reserve Structure
Prepositioned Response Capacity
Fallback Direct Channel

mechanisms:
Dispatch Center
Network Capacity Dashboard
Reserve Release Playbook
Dynamic Staffing Schedule
Incident Command Structure
Prepositioned Resource Cache
Mutual-Aid Dispatch Board
Rapid Status Broadcast and Stop Signal
Logistics Routing Plan
Standby Transport Corridor
Strategic Reserve
Travel-Time Matrix
Multi-Front Dispatch Board
Reserve Readiness Rotation
Sequential Concentration Drill
Recall and Reconstitution Protocol
Simultaneous-Front Stress Test
Capacity-Aware Dispatch Optimizer

essence_one_line: Hold a mobile shared reserve where paths to several fronts are short, then shift and concentrate it fast enough to create local advantage before dispersed alternatives can coordinate.

compression_statement: A system faces several geographically, organizationally, or logically separated fronts. Fully duplicating scarce capacity at every front is wasteful, but leaving each front to negotiate lateral support is too slow. The intervention verifies that one position or tier has shorter effective paths to the front set; protects a genuinely mobile reserve there; maps front states, response windows, routes, dependencies, and minimum local cover; gives a bounded authority a common operating picture and a front-priority rule; packages and deploys the reserve to the front where temporary concentration has the highest consequence-adjusted leverage; preserves recall and alternate-path capability; and restores the pool after use. The pattern creates tempo from topology, not merely from owning more resources.

core_intuition: A shared reserve can act like more capacity than its static quantity suggests when it can reach several possible needs faster than those needs can coordinate equivalent support from elsewhere. The advantage is lost if decision delay, route fragility, setup cost, simultaneous demand, or poor reconstitution consumes the time saved by central position.

canonical_formula: For reserve location c and front i, define response time T_c,i = T_detect,i + T_decide + T_move(c,i) + T_setup,i. Let T_alt,i be the earliest credible arrival of equivalent dispersed support, W_i the remaining opportunity window, L_i the minimum local cover, x_i the reserve committed, and G_i(x_i) the consequence-adjusted gain from concentration. An interior-line deployment is eligible only when T_c,i < min(T_alt,i, W_i), all local-cover and compatibility constraints hold, and G_i(x_i) exceeds transit, disruption, uncovered-front, and reconstitution costs. The architecture remains viable only if correlated-demand and route-failure tests leave sufficient residual reserve and recovery margin.

structural_problem: Several fronts compete for scarce capacity. Each front has some local ability, but none can economically hold every specialist, asset, authority, spare, or surge unit it may need. Lateral coordination among peripheral fronts is slow, fragmented, or based on incompatible information. A centrally positioned actor or tier has shorter effective paths to the front set, yet the potential advantage is unrealized because the reserve is not protected, mobile, visible, preauthorized, route-ready, or recoverable.

trigger_conditions: At least two fronts can plausibly require the same scarce capability within overlapping planning horizons.

trigger_conditions: A candidate central position or tier has shorter effective response paths than lateral or external coordination alternatives.

trigger_conditions: The resource can be transferred, packaged, credentialed, or translated quickly enough to become useful after arrival.

trigger_conditions: Demand is uncertain or bursty enough that full duplication at every front has poor utilization or prohibitive cost.

trigger_conditions: Temporary concentration at one front can change the outcome more than even distribution would.

trigger_conditions: Each front can maintain a bounded minimum local capability until reinforcement arrives.

trigger_conditions: Front state, route health, reserve readiness, and decision authority can be made observable.

trigger_conditions: The reserve can be recalled, replenished, rested, repaired, or retasked after deployment.

trigger_conditions: Competing fronts can be prioritized under legitimate, reviewable criteria.

trigger_conditions: Simultaneous peak demand is possible but not so dominant that one shared reserve is structurally inadequate.

symptoms: Scarce specialists or assets sit underused in one unit while a neighboring front fails for lack of the same capability.

symptoms: Every site tries to build a small local reserve, producing high fixed cost and shallow expertise.

symptoms: Cross-front support requires improvised negotiation after the response window has already begun to close.

symptoms: Resources arrive without dependencies, credentials, context, transport, or local handoff and therefore become useful late.

symptoms: Several units count the same shared capacity as available because commitments are not visible in one place.

symptoms: The central pool is repeatedly consumed by routine work and cannot respond when a decisive need appears.

symptoms: Resources are dispatched to the loudest requester rather than the front where timely concentration has greatest leverage.

symptoms: The central site appears close on a map but congestion, approval delay, or route failure makes it operationally distant.

symptoms: A deployment solves the first incident but leaves the reserve exhausted, stranded, or unmaintained for the next one.

symptoms: Local teams distrust central help because dispatch decisions ignore context or strip them below safe operating floors.

root_tension: Decentralized duplication gives immediate local control and resilience but fragments scarce capacity, raises fixed cost, and prevents decisive concentration. Central pooling improves utilization and maneuver but adds transit, authority, information, and single-point risks. The design must capture the path-time advantage of central position without turning the periphery into an under-resourced dependency or the center into an overloaded bottleneck.

anti_signatures: All fronts are likely to peak simultaneously and the shared pool cannot meet aggregate minimum demand.

anti_signatures: The candidate center has no durable path-time advantage after decision, transit, setup, handoff, and degraded-route time are included.

anti_signatures: Resources are fixed, legally nontransferable, highly local, or too context-dependent to become useful within the response window.

anti_signatures: The requirement is steady and predictable enough that dedicated local capacity is cheaper and safer.

anti_signatures: The main problem is reducing pairwise communication links; use Hub-and-Spoke Coordination.

anti_signatures: The main problem is holding capacity for future use without multi-front movement; use Capacity Reservation.

anti_signatures: The main problem is a static optimization among uses; use Constrained Resource Allocation.

anti_signatures: The main problem is continuous flow routing through network edges; use Network Flow Optimization.

anti_signatures: The desired outcome is even distribution of workload rather than deliberate temporary concentration; use Load Balancing.

anti_signatures: The main problem is responding at one advancing edge rather than choosing among multiple fronts; use Wavefront Propagation Management.

anti_signatures: Local regulation, sovereignty, safety, or community responsibility forbids central authority or cross-boundary deployment.

structural_intervention: Build a governed central or tiered reserve architecture that converts short effective paths into response tempo. Make fronts, routes, local coverage, reserve readiness, compatibility, priorities, authority, and recovery visible; protect a mobile pool; precompute deployment packages and alternate paths; concentrate the pool temporarily at the highest-leverage front; retain stop, recall, and degraded-mode options; then reconstitute the reserve and reassess whether the topology still creates advantage.

action_logic: Define the front set, the outcomes at stake, response windows, and what counts as equivalent support.

action_logic: Map local capacity, minimum coverage, active commitments, uncertainty, and dependencies at every front.

action_logic: Measure full response time from candidate reserve positions, including detection, decision, transit, setup, credentialing, and handoff.

action_logic: Compare central response time with lateral, local, and external alternatives under normal and degraded conditions.

action_logic: Select a central or tiered location only where path-time advantage and route resilience are durable enough to justify pooling.

action_logic: Create a reservable resource pool and specify which units are mobile, compatible, ready, recovering, or unavailable.

action_logic: Protect the pool from routine capture and name a steward responsible for readiness and reconstitution.

action_logic: Define front priorities, minimum local cover, release authority, simultaneous-demand limits, and human override or appeal paths.

action_logic: Build a common operating picture with data age, confidence, route health, reserve state, and competing commitments.

action_logic: Preassemble deployment packages, permissions, interfaces, context, transport, and alternate paths.

action_logic: Commit the smallest sufficient package that can create decisive local improvement inside the response window.

action_logic: Monitor movement, setup, front evolution, uncovered risk, and the remaining concentration window; redirect, split, or recall when rules require.

action_logic: Handoff authority and context at the receiving front without erasing legitimate local command or expertise.

action_logic: After use, return, rest, repair, replenish, reconcile state, and restore the reserve before counting it available again.

action_logic: Review outcomes, priority fairness, near misses, route failures, and topology changes; relocate or tier the reserve when the original center is no longer interior.

decision_rules: Do not call a site central until full response time is shorter than credible alternatives for the fronts that matter.

decision_rules: Do not centralize a capability whose transfer, setup, credential, or context cost consumes the opportunity window.

decision_rules: Release reserve only when expected concentration gain exceeds movement, disruption, uncovered-front, and reconstitution costs.

decision_rules: Preserve minimum local cover and nondelegable duties at every front; apparent efficiency does not override safety or legal floors.

decision_rules: Prefer sequential concentration when one front can be materially improved before another becomes critical.

decision_rules: Refuse or tier the architecture when correlated demand makes simultaneous exhaustion likely.

decision_rules: Use the smallest sufficient package; keep residual reserve and recall margin unless the consequence justifies full commitment.

decision_rules: Treat stale or low-confidence reports as uncertainty, not as precise state; require local confirmation for irreversible moves.

decision_rules: Do not permanently assign shared reserve to a front without an explicit ownership change and capacity redesign.

decision_rules: Do not count deployed, recovering, uncredentialed, or maintenance-bound capacity as available.

decision_rules: Use alternate routes, delegated authority, or direct coordination when the central hub is degraded.

decision_rules: Recalculate centrality when front locations, organizational boundaries, demand patterns, routes, or technology change.

target_invariants: Every front retains its defined minimum local safety, continuity, and decision capacity.

target_invariants: Reserve state and commitments are counted once in an authoritative operating picture.

target_invariants: Only eligible, compatible, and ready resources are dispatched.

target_invariants: Priority criteria are legitimate, explainable, auditable, and protected from status capture.

target_invariants: Decision speed does not eliminate bounded authority, stop conditions, or post-action review.

target_invariants: The central hub has degraded-mode operation, alternate authority, and route fallback.

target_invariants: Receiving fronts retain local knowledge, lawful authority, and the ability to reject unsafe support.

target_invariants: Personnel fatigue, consent, credentials, and professional scope are respected.

target_invariants: Deployment includes return, state reconciliation, maintenance, replenishment, and readiness restoration.

target_invariants: The architecture can be decentralized, tiered, or retired when the path-time advantage disappears.

expected_outcomes: Faster response at high-consequence fronts without full duplication of scarce capacity.

expected_outcomes: Greater temporary local concentration where marginal impact is highest.

expected_outcomes: Lower idle cost and deeper expertise than fragmented local reserves can provide.

expected_outcomes: Fewer double commitments, improvised negotiations, and late-arriving incomplete support packages.

expected_outcomes: Clearer authority, route, compatibility, and handoff expectations before urgent deployment.

expected_outcomes: Better protection of local minimum coverage and strategic residual reserve.

expected_outcomes: Improved ability to respond sequentially to more than one event with the same pool.

expected_outcomes: Earlier recognition of false centrality, route fragility, and correlated-demand limits.

expected_outcomes: More reliable recovery, replenishment, and learning after each deployment.

prose_tradeoffs:
- Pooling depth and specialist quality versus immediate local availability.
- Central decision speed versus local autonomy, context, and legitimacy.
- Temporary concentration versus exposure at fronts left with minimum cover.
- Reserve readiness versus the visible cost of idle or underutilized capacity.
- Standardization and portability versus local fit and tacit knowledge.
- Shortest-route efficiency versus route diversity and hub survivability.
- Fast release authority versus deliberation, due process, and capture resistance.
- Prepositioning for response time versus duplication, maintenance, and staleness.
- Rich shared visibility versus privacy, security, and information-overload risk.
- Sequential reuse of the same pool versus fatigue, wear, context switching, and delayed recovery.

Multi-Site Incident Reserve

short_definition: Hold mobile emergency capacity at a location or tier that can reinforce several sites within their response windows.

distinctive_feature: The shared reserve must cross site and command boundaries under emergency time pressure while preserving local safety floors.

distinct_from_parent: The parent is domain-general; this variant emphasizes incident thresholds, life-safety authority, mutual aid, and recovery after emergency deployment.

still_same_parent_because: It uses the same centrality test, shared mobile pool, front prioritization, response window, local-cover rule, route plan, and reconstitution cycle.

source_primes: interior_lines reserve latency coordination risk

use_when: Multiple facilities face irregular incidents that rarely peak at all sites at once.

use_when: Specialist people or equipment are too scarce to duplicate fully at every site.

use_when: Travel, credential, staging, and handoff times can be measured and rehearsed.

use_when: Each site can maintain a minimum safe local capability until reinforcement arrives.

domain: healthcare

example: A regional critical-care transport team and equipment reserve can reinforce several hospitals, with minimum staffing floors and explicit recall conditions.

domain: utilities

example: A central line-repair and switching team is dispatched among substations after storms using route and restoration-value priorities.

failure_modes: The reserve is counted twice by multiple sites.

failure_modes: Travel or credential delays invalidate the response window.

failure_modes: Life-safety floors are sacrificed for visible but lower-value incidents.

Shared Specialist Surge Pool

short_definition: Keep scarce experts in a shared, ready pool and concentrate them temporarily where their marginal effect is highest.

distinctive_feature: The mobile resource is expertise and attention, so context-switching cost, tacit knowledge, fatigue, and local ownership are first-order constraints.

distinct_from_parent: The parent covers any mobile reserve; this variant foregrounds human skill, cognitive setup, handoff, and burnout risk.

still_same_parent_because: It still depends on a shared reserve, short internal paths, front selection, temporary concentration, minimum local cover, and reconstitution.

use_when: Specialist capability is expensive or impossible to duplicate in every team.

use_when: Requests have bounded response windows and can be compared without erasing local context.

use_when: Experts can transfer context quickly enough to create value before the window closes.

use_when: The organization can protect recovery time and prevent permanent assignment capture.

domain: cybersecurity

example: A central incident-response team reinforces the highest-consequence business unit while local teams maintain minimum containment and evidence preservation.

domain: engineering

example: A shared reliability team moves among plants for time-critical failures rather than being permanently fragmented across every site.

failure_modes: Experts become a chronic substitute for local capability building.

failure_modes: Repeated redeployment destroys focus and recovery.

failure_modes: Priority is captured by high-status requesters rather than consequence or leverage.

Nested Interior-Lines Network

short_definition: Use local, regional, and strategic reserve tiers so each scale retains short response paths while larger tiers provide backstop capacity.

distinctive_feature: The interior-line advantage is replicated at multiple scales instead of relying on one universal center.

distinct_from_parent: The parent can use one reserve and hub; this variant requires tiered centrality, escalation, and reserve handoff across nested regions.

still_same_parent_because: Every tier applies the same path-time, reserve, front-priority, minimum-cover, dispatch, and reconstitution logic.

source_primes: interior_lines network topology hierarchy reserve

use_when: One central node cannot meet all response windows or creates unacceptable single-point risk.

use_when: Fronts cluster into regions with different travel, jurisdiction, or compatibility boundaries.

use_when: Local tiers can handle common events while higher tiers absorb rare or correlated overload.

use_when: Escalation and cross-tier replenishment can be governed explicitly.

domain: cloud infrastructure

example: Zone-level spares handle common faults, regional pools absorb larger incidents, and a global reserve supports rare cross-region failures.

domain: maintenance networks

example: Local technicians cover routine service, regional specialist pools handle complex failures, and a strategic national team supports rare high-impact events.

failure_modes: Every tier assumes another tier will absorb the loss.

failure_modes: Escalation latency consumes the path-time advantage.

failure_modes: Resources are trapped by incompatible standards or jurisdictions between tiers.


Change Resistance Diagnosis and Support

batch: First Iteration/Batch 33

Change Resistance Support

notes: Shorter name that preserves the support logic but can understate the diagnostic requirement.

Adoption Barrier Diagnosis

notes: Useful when the visible symptom is low adoption rather than explicit opposition.

Change Readiness and Support Design

notes: Highlights readiness-building but should not collapse into a readiness survey mechanism.

Transition Barrier Support

notes: Emphasizes transition burden, especially when legacy routines or tools are sticky.

slug: inertia

slug: reactance

slug: legitimacy

slug: scaffolding

slug: diffusion

components:
Resistance Source Map
Barrier Classification
Legitimacy Strategy
Transition Support
Participation Boundary
Incentive and Metric Alignment
Adoption Monitoring
Relapse and Workaround Signal
Change Evidence Package
Fallback Rule
Local Adaptation Boundary

mechanisms:
Change Readiness Assessment
Barrier Interview Protocol
Participatory Design Session
Transition Support Plan
Training and Practice Program
Pilot Rollout
Trust-Building Communication
Incentive Realignment
Migration Assistance
Adoption Dashboard

essence_one_line: Diagnose why people or systems resist change and provide targeted support, legitimacy, incentives, or transition design.

compression_statement: When a beneficial or required change stalls, map the sources of resistance and address them through support matched to the actual barrier: legitimacy, reduced transition cost, participation, incentives, training, staged adoption, or redesign.

core_intuition: Resistance is information. It may reflect fear, habit, overload, mistrust, identity threat, unclear benefit, rational self-protection, technical friction, or badly aligned incentives. The archetype treats resistance as a diagnostic signal and then changes the adoption conditions rather than merely demanding enthusiasm.

canonical_formula: proposed change + resistance source map + barrier classification + matched support/legitimacy/incentive response + adoption monitoring -> feasible and legitimate transition

structural_problem: A beneficial, required, or strategically chosen change is resisted because actors face cost, uncertainty, identity threat, mistrust, habit, misaligned incentives, limited capacity, or a legitimacy gap.

condition: A formally approved change is not becoming lived practice

description: The new policy, tool, workflow, role, or operating model exists on paper, but people continue using old routines, shadow processes, or partial compliance.

condition: Objections are being moralized rather than diagnosed

description: Leaders describe resistance as stubbornness, negativity, or lack of buy-in without separating capability gaps, trust gaps, incentive conflicts, and legitimate design flaws.

condition: Transition burden falls unevenly

description: The people expected to adopt the change bear extra workload, risk, confusion, or learning cost while benefits accrue elsewhere or later.

condition: The old state remains locally rational

description: Existing metrics, rewards, accountability, customer expectations, or informal norms make legacy behavior safer or more rewarded than the new behavior.

condition: Trust or legitimacy is weak

description: Affected actors doubt the motives, fairness, evidence, authority, or competence behind the change.

condition: Adoption produces relapse, workarounds, or passive compliance

description: People may appear to comply while reverting under pressure, creating unofficial fixes, or using the new system only superficially.

symptoms: Repeated communication campaigns produce agreement in meetings but little operational adoption.

symptoms: People ask for exceptions, delay migration, preserve old tools, or duplicate work in both old and new systems.

symptoms: Implementation teams blame users, while users describe the change as unrealistic, unfair, risky, or disconnected from actual work.

symptoms: Training attendance is high but practical use remains low because incentives, workload, or trust have not changed.

symptoms: Early adopters quietly absorb extra effort while late adopters are treated as disloyal rather than diagnostically interesting.

symptoms: Resistance clusters in specific roles, sites, teams, or workflow points, suggesting structural barriers rather than general opposition.

prose_essence:
Change Resistance Diagnosis and Support is the archetype for turning resistance into actionable design information. It starts from the assumption that resistance may be rational, protective, locally informed, or legitimacy-based. The intervention is not simply to persuade people to accept a change. It is to diagnose why the old state remains safer, easier, more legitimate, more rewarded, or more identity-compatible than the new state, then adjust the transition so adoption becomes feasible and defensible.

The core pattern is simple: name the change, map resistance sources, classify the barrier, match support to the barrier, and monitor adoption as a learning loop. A team may discover that the barrier is a lack of skill, but it may also discover mistrust, workload overload, incentive conflict, unclear authority, technical incompatibility, fear of public incompetence, or a proposed design that genuinely needs revision.

prose_when_to_use:
Use this archetype when a change has moved beyond abstract strategy and now requires people, teams, institutions, tools, or routines to behave differently. It is especially useful when formal approval has not translated into lived practice; when people say they support the change but keep using old routines; when resistance differs across roles or sites; or when leaders are tempted to treat non-adoption as a communication problem without diagnosing the transition burden.

It is also useful before rollout when the change is likely to create significant switching costs, identity threats, trust concerns, or local incentives that conflict with system-level goals. In those settings, diagnosis before enforcement prevents avoidable backlash and preserves the useful information embedded in objections.

Do not use the archetype to push through a harmful or poorly justified change. Some resistance is a valid signal that the change itself should be stopped, redesigned, narrowed, or delayed.

prose_structural_problem:
The structural problem is that the new state is not yet locally workable or legitimate. The old state may be inefficient from a system perspective, but it may still be familiar, rewarded, identity-safe, technically integrated, socially expected, or less risky for the people expected to change. Resistance appears when the transition asks actors to bear cost, uncertainty, exposure, status loss, cognitive load, or operational risk without enough support or legitimacy.

This problem often hides beneath the language of buy-in. A low-buy-in diagnosis is too vague. The useful question is: what makes the new behavior hard, unsafe, unrewarded, illegitimate, or low-trust compared with the old behavior?

prose_intervention_logic:
The intervention works by replacing generic persuasion with barrier-specific design. First, the change is specified as a concrete behavior, system state, role pattern, or workflow. Second, affected actors and resistance sources are mapped. Third, barriers are classified: capability, friction, legitimacy, trust, identity, incentives, workload, technical fit, habit, or design flaw. Fourth, the change team chooses a matched response: training for skill gaps, migration support for switching costs, participation for design fit and legitimacy, incentive realignment for local rationality, staged rollout for uncertainty, or redesign when resistance reveals a bad assumption.

The final step is monitoring. Adoption should be judged by lived use, quality effects, relapse, workarounds, exception patterns, and user experience, not only by attendance, sign-off, or tool logins. Monitoring turns implementation into a learning loop.

prose_key_components:
### Resistance Source Map

```yaml
component:
  slug: resistance_source_map
  name: Resistance Source Map
  role: >
    Identifies where resistance is coming from and what form it takes before choosing any response.
  notes: >
    The map should distinguish people, teams, technical systems, routines, incentives, identity commitments, legitimacy concerns, capacity constraints, and dependencies. It prevents treating all resistance as stubbornness or ignorance.
```

Resistance Source Map keeps the archetype grounded in a specific part of the transition design. In practice, it should be reviewed alongside the other components, because resistance diagnosis, support, legitimacy, and monitoring only work as a linked chain.
### Barrier Classification

```yaml
component:
  slug: barrier_classification
  name: Barrier Classification
  role: >
    Classifies resistance by causal type so the intervention matches the actual barrier.
  notes: >
    Common classes include transition cost, uncertainty, perceived unfairness, mistrust, loss of competence or status, habit, workload overload, misaligned incentives, technical incompatibility, and unclear benefit.
```

Barrier Classification keeps the archetype grounded in a specific part of the transition design. In practice, it should be reviewed alongside the other components, because resistance diagnosis, support, legitimacy, and monitoring only work as a linked chain.
### Legitimacy Strategy

```yaml
component:
  slug: legitimacy_strategy
  name: Legitimacy Strategy
  role: >
    Repairs or strengthens the perceived legitimacy of the change, the decision process, and the sponsoring authority.
  notes: >
    Legitimacy may require voice, explanation, evidence, procedural fairness, visible responsiveness, credible sponsorship, or correction of power asymmetry. It is not the same as persuasion or messaging.
```

Legitimacy Strategy keeps the archetype grounded in a specific part of the transition design. In practice, it should be reviewed alongside the other components, because resistance diagnosis, support, legitimacy, and monitoring only work as a linked chain.
### Transition Support

```yaml
component:
  slug: transition_support
  name: Transition Support
  role: >
    Reduces the practical burden of moving from the old state to the new state.
  notes: >
    Support can include training, migration assistance, temporary staffing, tool changes, protected learning time, job aids, staged adoption, and explicit fallback rules. Its purpose is to make adoption feasible, not merely encouraged.
```

Transition Support keeps the archetype grounded in a specific part of the transition design. In practice, it should be reviewed alongside the other components, because resistance diagnosis, support, legitimacy, and monitoring only work as a linked chain.
### Participation Boundary

```yaml
component:
  slug: participation_boundary
  name: Participation Boundary
  role: >
    Defines where affected actors can shape the change and where constraints are already fixed.
  notes: >
    Participation without decision relevance creates cynicism. The boundary should make clear what is open to influence, what is constrained by law, safety, budget, strategy, or timing, and how input changes the design.
```

Participation Boundary keeps the archetype grounded in a specific part of the transition design. In practice, it should be reviewed alongside the other components, because resistance diagnosis, support, legitimacy, and monitoring only work as a linked chain.
### Incentive and Metric Alignment

```yaml
component:
  slug: incentive_and_metric_alignment
  name: Incentive and Metric Alignment
  role: >
    Adjusts rewards, penalties, targets, and measurement so the desired adoption path is not punished by existing success criteria.
  notes: >
    Resistance is often rational when current metrics make old behavior safer or more rewarded than new behavior. This component makes the adoption logic visible in the operating model.
```

Incentive and Metric Alignment keeps the archetype grounded in a specific part of the transition design. In practice, it should be reviewed alongside the other components, because resistance diagnosis, support, legitimacy, and monitoring only work as a linked chain.
### Adoption Monitoring

```yaml
component:
  slug: adoption_monitoring
  name: Adoption Monitoring
  role: >
    Tracks uptake, friction, relapse, local adaptation, workarounds, and unintended harms after the change begins.
  notes: >
    Monitoring should capture both formal adoption and lived use. The goal is to learn where support or redesign is needed rather than to shame non-adopters.
```

Adoption Monitoring keeps the archetype grounded in a specific part of the transition design. In practice, it should be reviewed alongside the other components, because resistance diagnosis, support, legitimacy, and monitoring only work as a linked chain.
### Relapse and Workaround Signal

```yaml
component:
  slug: relapse_and_workaround_signal
  name: Relapse and Workaround Signal
  role: >
    Detects when people revert to old practices or create shadow processes because the change has not become workable.
  notes: >
    Relapse and workarounds are diagnostic signals. They may reveal missing capability, hidden dependencies, local exceptions, trust failures, or over-optimistic implementation assumptions.
```

Relapse and Workaround Signal keeps the archetype grounded in a specific part of the transition design. In practice, it should be reviewed alongside the other components, because resistance diagnosis, support, legitimacy, and monitoring only work as a linked chain.

prose_common_mechanisms:
Mechanisms are the concrete tools and practices used to implement the archetype. They are not the archetype itself. A readiness survey, training program, pilot, or dashboard can be useful only when it traces back to a diagnosed resistance source.

### Change Readiness Assessment

```yaml
mechanism:
  slug: change_readiness_assessment
  name: Change Readiness Assessment
  mechanism_type: diagnostic_assessment
  role: >
    Surveys or interviews affected groups to identify perceived benefit, capability, trust, workload, timing, and readiness barriers before implementation.
```

This mechanism implements the archetype only when it is selected because it fits a diagnosed barrier. Used generically, it can become change-management theater; used diagnostically, it changes the adoption conditions that produced resistance.
### Barrier Interview Protocol

```yaml
mechanism:
  slug: barrier_interview_protocol
  name: Barrier Interview Protocol
  mechanism_type: qualitative_diagnostic_method
  role: >
    Elicits the reasons people expect the change to fail, harm them, overload them, or conflict with their work reality.
```

This mechanism implements the archetype only when it is selected because it fits a diagnosed barrier. Used generically, it can become change-management theater; used diagnostically, it changes the adoption conditions that produced resistance.
### Participatory Design Session

```yaml
mechanism:
  slug: participatory_design_session
  name: Participatory Design Session
  mechanism_type: collaborative_design_process
  role: >
    Brings affected actors into design decisions that can still change, converting local knowledge and ownership into better adoption conditions.
```

This mechanism implements the archetype only when it is selected because it fits a diagnosed barrier. Used generically, it can become change-management theater; used diagnostically, it changes the adoption conditions that produced resistance.
### Transition Support Plan

```yaml
mechanism:
  slug: transition_support_plan
  name: Transition Support Plan
  mechanism_type: implementation_plan
  role: >
    Specifies training, time, staffing, tools, fallback procedures, coaching, and migration assistance required for feasible adoption.
```

This mechanism implements the archetype only when it is selected because it fits a diagnosed barrier. Used generically, it can become change-management theater; used diagnostically, it changes the adoption conditions that produced resistance.
### Training and Practice Program

```yaml
mechanism:
  slug: training_and_practice_program
  name: Training and Practice Program
  mechanism_type: capability_building_routine
  role: >
    Builds skill and confidence for the new behavior through instruction, guided practice, feedback, and progressively harder use cases.
```

This mechanism implements the archetype only when it is selected because it fits a diagnosed barrier. Used generically, it can become change-management theater; used diagnostically, it changes the adoption conditions that produced resistance.
### Pilot Rollout

```yaml
mechanism:
  slug: pilot_rollout
  name: Pilot Rollout
  mechanism_type: staged_implementation_method
  role: >
    Tests the change in a bounded context to learn about resistance sources, operational fit, and support needs before broader deployment.
```

This mechanism implements the archetype only when it is selected because it fits a diagnosed barrier. Used generically, it can become change-management theater; used diagnostically, it changes the adoption conditions that produced resistance.
### Trust-Building Communication

```yaml
mechanism:
  slug: trust_building_communication
  name: Trust-Building Communication
  mechanism_type: communication_practice
  role: >
    Explains why the change is happening, what tradeoffs were considered, what is uncertain, and how feedback will alter the implementation.
```

This mechanism implements the archetype only when it is selected because it fits a diagnosed barrier. Used generically, it can become change-management theater; used diagnostically, it changes the adoption conditions that produced resistance.
### Incentive Realignment

```yaml
mechanism:
  slug: incentive_realignment
  name: Incentive Realignment
  mechanism_type: governance_or_reward_adjustment
  role: >
    Changes targets, rewards, accountability, workload credit, or penalties so the new behavior is locally rational.
```

This mechanism implements the archetype only when it is selected because it fits a diagnosed barrier. Used generically, it can become change-management theater; used diagnostically, it changes the adoption conditions that produced resistance.
### Migration Assistance

```yaml
mechanism:
  slug: migration_assistance
  name: Migration Assistance
  mechanism_type: operational_support_service
  role: >
    Provides hands-on help moving data, practices, routines, tools, or responsibilities from the legacy state to the new state.
```

This mechanism implements the archetype only when it is selected because it fits a diagnosed barrier. Used generically, it can become change-management theater; used diagnostically, it changes the adoption conditions that produced resistance.
### Adoption Dashboard

```yaml
mechanism:
  slug: adoption_dashboard
  name: Adoption Dashboard
  mechanism_type: monitoring_artifact
  role: >
    Shows uptake, support requests, exception patterns, quality effects, relapse, and unintended consequences during rollout.
```

This mechanism implements the archetype only when it is selected because it fits a diagnosed barrier. Used generically, it can become change-management theater; used diagnostically, it changes the adoption conditions that produced resistance.

prose_failure_modes:
The most common failure mode is resistance moralization: the implementation team labels non-adopters as negative or stubborn and loses the information needed to improve the transition. Another failure mode is the generic change-management package, where communication, training, champions, and dashboards are deployed without barrier diagnosis.

Readiness theater is also common. A survey or workshop collects concerns but no decision changes, support changes, or design changes follow. This makes future engagement less credible.

Training can be misused as a universal solvent. It helps when people lack skill or confidence, but it does little when the barrier is mistrust, incentives, workload, technical fit, or perceived unfairness.

Premature enforcement can turn an implementation problem into a legitimacy conflict. If actors are punished before they can realistically succeed, resistance becomes more justified.

Finally, adoption metrics can become theater. Attendance, acknowledgments, or login counts may look good while actual practice remains unchanged.

prose_neighbor_distinctions:
**Inertia Breaking** creates impetus when a system remains static. Change Resistance Diagnosis and Support starts from a proposed transition and asks why adoption is blocked.

**Path Dependence Escape** focuses on escaping lock-in from historical choices and legacy constraints. This archetype may address legacy stickiness, but its core unit is the adoption barrier and the support response.

**Frame Shift Intervention** changes how people interpret a problem. This archetype may include reframing, but only if diagnosis shows the barrier is interpretive rather than practical, legitimacy-based, or incentive-based.

**Stakeholder Mapping and Engagement** identifies affected and influential parties and designs engagement. This archetype uses stakeholder insight for the narrower purpose of diagnosing and supporting a change.

**Psychological Safety Enablement** creates conditions for speaking up without punishment. This archetype often needs psychological safety during transition, but its central aim is feasible adoption of a specific change.

**Goal Congruence Alignment** redesigns goals, metrics, and incentives so local success supports system success. This archetype may use incentive realignment when incentives are one source of resistance, but it does not always redesign the full goal system.

prose_cross_domain_examples:
In enterprise software migration, resistance may come from old macros, reporting deadlines, fear of errors, and local metrics. The solution is not just training; it may require migration assistance, fallback rules, practice environments, and workflow-specific adoption monitoring.

In healthcare, a new protocol may be clinically justified but operationally resisted because it adds documentation, threatens patient time, or exposes staff to blame. Barrier interviews, job aids, staffing adjustments, and legitimate exception review can turn resistance into safer adoption.

In municipal policy, residents and staff may resist because they distrust the decision process. Bounded participation, transparent rationale, pilot districts, and complaint-pattern monitoring can repair enough legitimacy to proceed.

In education technology, teachers may resist because the change threatens competence and planning routines. Peer practice, release time, local adaptation boundaries, and feedback loops make the transition identity-safe and feasible.

In manufacturing safety, operators may resist a stop-work protocol if throughput metrics punish it. Incentive and metric alignment can make the safer behavior locally rational.

prose_non_examples:
A motivational speech about embracing change is not this archetype because it does not diagnose or alter adoption barriers.

A mandatory training assigned after low adoption is not the archetype by itself. Training is a mechanism, and it only fits when the barrier is capability or confidence.

A readiness survey with no design consequence is not the archetype. It is a mechanism used performatively.

Forcing compliance with a harmful or illegitimate change is a misuse of this archetype. Valid resistance should trigger redesign or cancellation.

prose_tradeoffs:
Speed competes with legitimacy. More diagnosis and participation can slow implementation, but forced speed may create resistance that takes longer to repair.

Uniformity competes with local fit. A single implementation model is easier to govern, while local adaptation can improve feasibility. The solution is not to choose one absolutely, but to define fixed invariants and adaptable details.

Support competes with ownership. Too little support makes adoption unrealistic; too much indefinite support can prevent the new routine from becoming owned by the adopting group.

Voice competes with expectation management. People should have influence where design space exists, but participation that cannot change anything damages trust.

Incentive alignment competes with metric gaming. Adoption targets can motivate change, but narrow measures can create superficial compliance.

prose_invariants_to_preserve:
Resistance must remain diagnostically meaningful. The system should not treat objections, delay, or relapse as moral failure before asking what they reveal about feasibility and legitimacy.

Support must be matched to barrier type. Training does not repair mistrust; communication does not remove switching cost; incentives do not clarify purpose; participation does not solve technical incompatibility unless it changes design.

Affected actors should have meaningful voice where design space exists. If no material influence is possible, the process should be transparent about that constraint rather than implying co-design.

Adoption should be measured as lived behavior. Formal compliance is insufficient when people are reverting, creating shadow processes, or using the new process only when watched.

The change itself must remain revisable. A good diagnosis may show that resistance is not the problem; the proposed design is.

prose_target_outcomes:
The desired outcome is not universal enthusiasm. The target is a transition in which people can adopt the new behavior with adequate capability, trust, resources, legitimacy, and incentive alignment. Good outcomes include fewer hidden workarounds, clearer adoption barriers, safer learning during transition, improved confidence, visible responsiveness to feedback, and adoption metrics that reflect actual use and system outcomes.

A mature implementation also produces better change intelligence. Future changes become easier because the organization learns which barriers are recurring: workload constraints, legitimacy gaps, metric conflicts, low trust, weak migration support, or unclear local adaptation boundaries.

prose_parameter_dimensions:
**Diagnostic depth.** A light rollout may only need quick interviews and adoption metrics. A high-stakes change may require role-by-role resistance mapping, workflow observation, stakeholder engagement, and explicit legitimacy review.

**Participation depth.** Some changes have genuine design space; others are constrained by law, safety, budget, or strategy. The participation boundary should make this explicit so engagement does not become theater.

**Support intensity.** Support can range from job aids and office hours to staffed migration assistance, protected learning time, or parallel-run periods. More support reduces transition risk but consumes resources and may slow rollout.

**Rollout sequencing.** The change can be simultaneous, phased by site, piloted with early adopters, or staged by risk class. Sequencing should match uncertainty, support capacity, and potential harm from early failure.

**Enforcement timing.** Deadlines and accountability may be necessary, but they should follow adequate readiness, support, and legitimacy work. Premature enforcement converts transition barriers into compliance conflict.

**Local adaptation allowance.** Some elements must be invariant for safety, equity, interoperability, or strategic purpose. Others can vary locally to fit context. The adaptation boundary controls this tension.

prose_variants_and_near_names:
The main variants are transition friction reduction, legitimacy gap repair, identity-safe change support, incentive realignment for adoption, and staged adoption pathway. These are not separate top-level archetypes in this draft because they share the same parent logic: diagnose the source of resistance and match the support response.

Near names such as change management support, change readiness design, adoption support design, and transition support should point back to this archetype unless they are merely mechanisms. Change readiness assessment, training program, communication plan, and migration assistance should remain mechanisms unless future evidence shows a distinct transferable intervention structure.

Transition Friction Reduction

short_definition: A variant focused on reducing the effort, confusion, interruption, and switching costs that make adoption practically hard.

distinctive_feature: The main lever is practical enablement rather than persuasion, legitimacy repair, or incentive change.

distinct_from_parent: The parent diagnoses all resistance sources; this variant narrows to operational friction and transition burden.

still_same_parent_because: The intervention still begins from resistance diagnosis and targeted support.

use_when: people agree with the change in principle but find it too hard to execute in current conditions

use_when: legacy tools, data, routines, or workloads create high switching costs

use_when: early failures are likely because the new behavior has not yet become easy enough

example_domains:
software migration
clinical workflow redesign
public service process reform

domain: software migration

example: A team helps users move reports and macros into a new analytics platform before retiring the old one.

domain: healthcare operations

example: A clinic adds coaching shifts and job aids while staff learn a new intake protocol.

failure_modes: Treating every objection as friction when the real issue is mistrust or unfairness.

failure_modes: Removing friction so aggressively that important safeguards are bypassed.

Legitimacy Gap Repair

short_definition: A variant focused on resistance caused by perceived unfairness, exclusion, mistrust, or weak authority to impose the change.

distinctive_feature: The core move is restoring credible process and authority rather than merely explaining the change better.

distinct_from_parent: The parent can address many barrier types; this variant isolates legitimacy as the binding constraint.

still_same_parent_because: Legitimacy repair is one diagnosed support response inside the broader resistance-diagnosis pattern.

use_when: affected actors doubt the motives, fairness, or competence of the change sponsor

use_when: people believe they were excluded from decisions that materially affect them

use_when: the change may be technically sound but procedurally or politically fragile

example_domains:
workplace reorganization
municipal policy adoption
education reform

failure_modes: Using consultation as theater after the decision is already fixed.

failure_modes: Offering voice without changing any material aspect of the design or rollout.

Identity-Safe Change Support

short_definition: A variant used when resistance comes from threat to status, competence, professional identity, role meaning, or group belonging.

distinctive_feature: The intervention protects dignity, competence, and belonging while making new behavior learnable.

distinct_from_parent: The parent diagnoses resistance generally; this variant focuses on identity and capability threat.

still_same_parent_because: Identity-safe support is a targeted response to one diagnosed source of change resistance.

use_when: the old practice is tied to professional pride or group identity

use_when: people fear looking incompetent while learning the new behavior

use_when: change implies that prior work, skill, or judgment was wrong or obsolete

example_domains:
professional practice change
education technology adoption
organizational role redesign

failure_modes: Over-pathologizing resistance that is actually evidence of a bad design.

failure_modes: Using reassurance without changing the competence-building conditions.

Incentive Realignment for Adoption

short_definition: A variant used when actors resist because existing metrics, rewards, penalties, or accountability make old behavior rational.

distinctive_feature: The decisive move is changing the payoff and metric environment around adoption.

distinct_from_parent: The parent may include incentives as one barrier; this variant foregrounds incentive-compatible adoption design.

still_same_parent_because: It remains a targeted support response selected after resistance diagnosis.

use_when: the new behavior slows local metrics while improving system outcomes

use_when: people are punished for the learning curve required by adoption

use_when: units can meet their targets by ignoring or undermining the change

example_domains: cross-functional operating model changes

failure_modes: Creating narrow adoption targets that encourage box-checking without real use.

failure_modes: Replacing one misalignment with another by ignoring system-level outcomes.

Staged Adoption Pathway

short_definition: A variant that sequences change through pilots, cohorts, opt-in waves, or phased rollout to reduce uncertainty and learn before full adoption.

distinctive_feature: Time and sequencing are used as the main adoption-control levers.

distinct_from_parent: The parent includes all support types; this variant specifically shapes the adoption path over time.

still_same_parent_because: Staging remains a mechanism for diagnosing and supporting resistance during implementation.

source_primes: uncertainty risk_aversion diffusion

use_when: the consequences of full rollout are uncertain

use_when: early adopters can reveal support needs and local adaptations

use_when: forced simultaneous adoption would overwhelm support capacity or trust

example_domains:
enterprise system rollout
curriculum reform
public health program implementation

failure_modes: Letting pilots become permanent exceptions with no learning-to-scale path.

failure_modes: Selecting only unusually favorable pilots and misreading adoption readiness.

near_names:
Change Management Support
Change Readiness Design
Adoption Support Design
Transition Support
Change Readiness Assessment