Cross-Scale Causal Mapping

batch: First Iteration/Batch 35

Local/Global Causal Mapping

notes: Simplified two-level name for the parent pattern.

Micro/Meso/Macro Causal Mapping

notes: Common three-level representation of the parent pattern.

source_primes: scale teleconnection downward_causation

slug: scale

slug: teleconnection

components:
Scale Layer Map
Upward Causal Path
Downward Causal Path
Cross-Scale Mediator
Intervention Scale Choice
Scale Transition Boundary
Cross-Scale Side-Effect Review

mechanisms:
Micro/Meso/Macro Causal Map
Multi-Level Policy Analysis
Ecological Scale Mapping
Organizational Level Mapping
Local-to-Global Risk Map
System-of-Systems Causal Mapping
Cross-Scale Impact Review

essence_one_line: Map how causes and effects move between local, intermediate, and system-wide scales.

compression_statement: When local actions create system-level effects or macro conditions shape local behavior, map cross-scale causality so interventions target the level where causes, mediators, leverage, and consequences actually operate.

core_intuition: Many failed interventions act at the level where a symptom is easiest to see. Cross-scale causal mapping asks whether the symptom is generated, mediated, constrained, or amplified at another level, then makes those level transitions explicit before choosing an intervention.

canonical_formula: scale layers + upward paths + downward paths + mediators + intervention-scale choice -> cross-scale causal diagnosis

structural_problem: A system is analyzed at one level while important causes, constraints, mediators, or effects operate at another level.

condition: Local actions appear harmless or ineffective in isolation.

why_it_matters: Their effect may aggregate, amplify, or cascade at a higher scale.

condition: Macro rules or system conditions are treated as background context.

why_it_matters: They may actively shape local options, incentives, timing, or behavior.

condition: Different stakeholders explain the same problem at different levels.

why_it_matters: The disagreement may reflect a real cross-scale causal structure rather than mere framing conflict.

condition: A proposed intervention is repeatedly applied where symptoms are visible but does not change outcomes.

why_it_matters: The actionable cause or mediator may sit at another scale.

condition: A local optimization creates system-level side effects, or a system-level optimization creates local brittleness.

why_it_matters: The intervention may be shifting burden across scale boundaries.

symptom: Wrong-level intervention

diagnostic_meaning: Action is aimed at the symptom scale while causal leverage sits higher, lower, or between levels.

symptom: Local/global explanation conflict

diagnostic_meaning: One account blames local behavior while another blames system conditions, and both may be partly true through different pathways.

symptom: Delayed or distributed consequences

diagnostic_meaning: Effects are not visible where the cause originates because they travel through mediators or accumulate over scale transitions.

symptom: Invisible constraint

diagnostic_meaning: Local actors appear unconstrained from outside analysis, but a higher-level rule, resource structure, or norm is narrowing their action space.

root_tension: The level at which a system is easiest to observe is often not the level at which the causal structure is generated or best changed.

case: Same-scale causality is already sufficient.

why_not_this: If causes, mediators, and effects all occur at one level, ordinary causal mapping is enough.

case: The task is only to change perspective or zoom level.

why_not_this: Scale reframing may help see the issue, but this archetype requires explicit causal pathways across levels.

case: The output is only a diagram of levels.

why_not_this: A level diagram without directional causal links, mediators, and intervention implications is a mechanism or visualization, not the archetype.

case: The issue is only remote coupling without scale transition.

why_not_this: Teleconnection mapping may be the better archetype when distance and shared dynamics matter more than vertical scale movement.

structural_intervention: Identify the relevant scales, trace upward and downward causal pathways, locate the mediators that carry effects across levels, and use the map to choose where intervention should occur.

logic: Separate local, intermediate, and system-wide levels so analysis does not flatten distinct causal arenas.

logic: Ask how local states, choices, events, or failures aggregate, amplify, combine, or transform into larger-scale outcomes.

logic: Ask how system-level rules, resources, norms, constraints, or structures shape local options and behavior.

logic: Name the concrete channels, signals, institutions, flows, networks, interfaces, or rules that move causality across scale boundaries.

logic: Mark where causality changes form, gains delay, becomes nonlinear, or loses strength while crossing levels.

logic: Select the level where action can alter the causal pathway without merely shifting burden to another level.

logic: Check whether local, intermediate, or system-level action creates unintended consequences at another scale.

rule: Map both directions before selecting action.

reason: Local-to-system and system-to-local causality can coexist; choosing too early may reproduce the wrong-level intervention.

rule: Do not accept a cross-scale causal claim without a mediator.

reason: The mediator is what turns a vague multi-scale story into an actionable pathway.

rule: Treat scale transition as a possible transformation, not just a larger version of the same process.

reason: A behavior can aggregate, amplify, dampen, invert, or become nonlinear when it crosses levels.

rule: Prefer the lowest scale that can change the relevant mediator without externalizing harm upward or downward.

reason: This preserves local autonomy when possible while avoiding underpowered local action.

meaning: The map must distinguish upward, downward, and bidirectional causal movement.

meaning: Levels must remain analytically distinct rather than being collapsed into a generic system map.

meaning: Every cross-scale claim should name the channel, rule, signal, flow, or relation that carries it.

meaning: The map should guide action selection, not merely describe complexity.

meaning: The analysis should reveal whether intervention at one level creates fragility, cost, or risk at another.

description: Action is aimed at the causal scale or mediator rather than the most visible symptom.

description: Teams stop treating local behavior and system structure as mutually exclusive explanations.

description: Actors at different levels can see how their actions constrain, amplify, or enable one another.

description: Potential upward or downward consequences are identified before implementation.

description: Patterns learned in one domain can transfer when the cross-scale structure, not only the domain vocabulary, matches.

prose_essence:
Cross-Scale Causal Mapping is the discipline of asking, “At what level is this cause operating, at what level is the effect appearing, and what carries influence between those levels?” It is useful when a local explanation and a systemic explanation both seem plausible, or when action taken at the visible symptom level repeatedly fails.

The archetype does not merely zoom in or zoom out. It keeps multiple scales in view at once and traces the causal traffic between them. A local behavior can aggregate into a system-wide pattern. A system-wide policy can constrain local behavior. An intermediate layer can translate, buffer, amplify, or distort influence. The map becomes useful when it identifies these pathways clearly enough to guide intervention.

prose_when_to_use:
Use this archetype when the problem cannot be explained well at only one level. Typical triggers include local actions producing surprising system-level effects, macro policies shaping local choices, remote or higher-level conditions appearing as local symptoms, or repeated wrong-level interventions. It is especially valuable when stakeholders disagree about whether the “real” cause is individual, organizational, systemic, environmental, or infrastructural.

Do not use it for every complex problem. If the relevant cause and effect occur at the same level, ordinary causal mapping is more economical. If the work is only to create a local/global diagram or a dashboard, that is a mechanism, not the archetype.

prose_structural_problem:
The structural problem is scale mismatch. The system is being interpreted at one level while meaningful causes, constraints, mediators, or consequences operate at another. This creates predictable errors: local actors are blamed for choices shaped by higher-level constraints; system-level designers overlook how rules become distorted locally; small actions are dismissed because their aggregate consequences are invisible; and interventions are aimed where symptoms appear rather than where leverage exists.

The deepest tension is that the most visible level is not always the most causal level. A symptom may be local, the mediator may be institutional, and the leverage point may be regional or system-wide. Conversely, a system-level pattern may be generated by repeated local actions that no single local actor experiences as consequential.

prose_intervention_logic:
The intervention begins by naming the relevant scale layers. These may be individual, team, organization, sector, region, ecosystem, platform, infrastructure layer, or any other levels that are structurally meaningful in context. The point is not to create a universal list of levels; it is to prevent the analysis from flattening them.

Next, trace upward causal paths. Ask how local events, behaviors, failures, or decisions aggregate, amplify, combine, or transform into larger-scale outcomes. Then trace downward causal paths. Ask how system-level rules, resource environments, norms, metrics, or constraints shape local possibilities.

The most important move is to identify cross-scale mediators. A mediator might be a policy, incentive, signal, transport route, ecological flow, reporting process, platform rule, interface, supply chain, social norm, or governance layer. Without a mediator, a cross-scale causal claim is usually too vague to act on.

Finally, choose the intervention scale. The map should clarify whether action belongs locally, at an intermediate coordination layer, at a system-wide design layer, or across several levels at once. It should also check whether intervention at one scale shifts risk, cost, or fragility to another.

prose_key_components:
### Scale Layer Map

A Scale Layer Map identifies the local, intermediate, and system-wide levels that matter for the problem. It prevents “the system” from becoming a vague container. A good layer map names what is different at each level: actors, resources, decision rules, constraints, time horizons, and observable outcomes.

### Upward Causal Path

An Upward Causal Path explains how local events become larger-scale consequences. This may happen through accumulation, contagion, aggregation, amplification, normalization, or repeated interaction. The key is not simply to say “local affects global,” but to explain the route by which it does so.

### Downward Causal Path

A Downward Causal Path explains how system-level conditions shape local behavior. Policies, budgets, norms, metrics, standards, architectures, and resource constraints can make some local actions easy and others nearly impossible. This component guards against over-blaming local actors for behavior produced by their operating environment.

### Cross-Scale Mediator

A Cross-Scale Mediator is the channel that carries influence across levels. It is often the difference between a useful causal map and a vague multi-scale story. In an organization, the mediator might be a reporting process or incentive system. In ecology, it might be water flow or habitat connectivity. In infrastructure, it might be network topology or control logic.

### Intervention Scale Choice

Intervention Scale Choice translates the map into action. Once the path and mediator are visible, the team can decide whether to intervene locally, at an intermediate layer, system-wide, or through a coordinated multi-level package. The choice should be based on causal leverage, feasibility, side effects, and respect for local knowledge.

### Optional: Scale Transition Boundary

A Scale Transition Boundary marks where causality changes form as it crosses levels. A process may be linear locally but nonlinear in aggregate, fast locally but delayed system-wide, or reversible locally but irreversible at a larger scale.

### Optional: Cross-Scale Side-Effect Review

A Cross-Scale Side-Effect Review asks whether intervention at one level shifts burden to another. This is especially important when a system-level policy creates local brittleness or a local optimization creates system-level fragility.

prose_common_mechanisms:
### Micro/Meso/Macro Causal Map

A Micro/Meso/Macro Causal Map is a common artifact for implementing the archetype. It represents individual, group or subsystem, and whole-system levels. It only counts as an implementation of this archetype when it includes directional causal paths and mediators, not merely three columns.

### Multi-Level Policy Analysis

Multi-Level Policy Analysis examines how a rule or policy behaves at household, community, institutional, regional, and national levels. It implements the archetype by showing how policy intent becomes local incentive, behavior, burden, or benefit.

### Ecological Scale Mapping

Ecological Scale Mapping applies the same structure to organism, habitat, watershed, regional, and climate-linked processes. It helps avoid treating local ecological action as isolated from larger flows and constraints.

### Organizational Level Mapping

Organizational Level Mapping traces links between individuals, teams, departments, governance layers, and enterprise outcomes. It is useful when local workarounds, incentives, metrics, or leadership rules generate effects that appear at another level.

### Local-to-Global Risk Map

A Local-to-Global Risk Map shows how local events can accumulate or propagate into larger risk. It is a mechanism under this archetype when it explicitly shows the scale transition and the mediator, not just a list of consequences.

### System-of-Systems Causal Mapping

System-of-Systems Causal Mapping is useful when the “parts” of a system are themselves complex systems. It implements the archetype by showing how subsystem autonomy, coupling, interfaces, and governance produce whole-system behavior.

### Cross-Scale Impact Review

A Cross-Scale Impact Review is a procedure for reviewing proposed action at levels above and below the immediate target. It helps prevent local fixes that create system-level harm, and system-level rules that create local overload.

prose_failure_modes:
Scale flattening occurs when the map lists multiple levels but treats them as interchangeable. The mitigation is to require each level to have distinct actors, constraints, processes, or outcomes.

Mediator omission occurs when the analysis jumps from a local cause to a global effect without explaining what carries influence. The mitigation is to reject cross-scale claims until a channel, flow, signal, rule, or relation is named.

Directionality confusion occurs when upward causation, downward causation, and feedback are blended into one vague story. The mitigation is to draw those paths separately before synthesizing them.

Wrong-level intervention occurs when the team maps the scales but still acts where it has habit, authority, or visibility rather than where leverage exists. The mitigation is to make intervention scale choice an explicit output.

Analysis paralysis occurs when the map grows without decision boundaries. The mitigation is to define the decision the map must support and stop adding levels that do not change action.

prose_neighbor_distinctions:
Cross-Scale Causal Mapping is distinct from Scale Reframing. Scale Reframing changes the level of attention; Cross-Scale Causal Mapping traces causal movement between levels.

It is distinct from Whole-System Impact Mapping. Whole-system mapping asks broadly about system consequences; this archetype requires explicit scale layers, directional paths, mediators, and intervention implications.

It is distinct from Teleconnection Mapping. Teleconnection Mapping focuses on distant systems linked by shared dynamics. Cross-Scale Causal Mapping can include remote coupling, but it also covers local-to-system and system-to-local causality without distance.

It is distinct from Downward Constraint Design. Downward Constraint Design creates or adjusts constraints. Cross-Scale Causal Mapping diagnoses how constraints already shape local behavior.

It is distinct from Cross-Scale Intervention Matching. Intervention matching chooses the level of action. Cross-Scale Causal Mapping produces the causal diagnosis that makes such matching possible.

prose_cross_domain_examples:
In public health, missed appointments might look like individual noncompliance. A cross-scale map may reveal transportation systems, clinic scheduling rules, payer incentives, regional provider shortages, and household constraints. The intervention may belong in scheduling policy or transport access, not only reminders.

In an organization, a team’s quality-process bypass might look like local negligence. A cross-scale map may show that enterprise metrics reward speed, departmental planning overloads the team, and reporting rules hide early uncertainty. The intervention may belong in portfolio intake, escalation, or metric design.

In ecology, local restoration may fail because site-level improvements are overwhelmed by watershed flows or regional land-use patterns. The map helps decide whether local practice, upstream coordination, or regional governance is the relevant scale.

In infrastructure, a small equipment fault may become a large outage because of network topology, control logic, and central operating rules. The map helps locate whether the intervention should be component hardening, network segmentation, control-rule change, or operator protocol.

In education, classroom interventions may fail because district assessment policy, scheduling, family constraints, and resource allocation shape local learning conditions. The map helps avoid blaming a teacher or learner for a constraint generated elsewhere.

prose_non_examples:
A generic systems map with many boxes and arrows is not Cross-Scale Causal Mapping unless it distinguishes scale layers, directional causal paths, and mediators.

A leadership presentation that zooms from strategy to tactics is not enough. Zooming is a change of perspective; the archetype requires causal movement between levels.

A local root-cause analysis of one machine defect is not this archetype if the cause and effect remain local.

A supplier dependency list is not this archetype by itself. It becomes relevant only when it explains how dependency, distance, and scale transitions shape local or system-level outcomes.

prose_tradeoffs:
The main tradeoff is diagnostic depth versus map complexity. More levels can improve explanation, but only up to the point where the map still supports action. There is also a tradeoff between local specificity and transferability: detailed mediators make action easier, but a very local map may not generalize.

Another tradeoff is speed versus precision. Cross-scale mapping takes time, so urgent situations may need a quick version first. System-level action can be powerful but may reduce local autonomy. Local action can preserve autonomy but may be too weak if the causal mediator sits higher up.

prose_invariants_to_preserve:
Preserve directional causal clarity. Upward, downward, and bidirectional paths should not be blurred into a generic “everything affects everything” diagram.

Preserve scale distinction. Each level should have a reason to exist in the map. If levels are merely labels, the map is decorative.

Preserve mediator explicitness. Every scale-crossing causal claim should name what carries influence across the boundary.

Preserve intervention relevance. The map should change what the team would do, where it would intervene, or what it would monitor.

Preserve burden-shift visibility. If action at one level creates cost, fragility, or risk at another, the map should reveal it.

prose_target_outcomes:
The target outcome is better intervention targeting. The team should understand whether to act locally, at an intermediate coordination layer, at a system-wide rule layer, or through a multi-level package.

A second outcome is reduced scale blindness. Local and systemic explanations can stop competing and start connecting. A third outcome is improved cross-level coordination, because actors can see how their actions enable, constrain, or amplify one another. A fourth outcome is earlier side-effect detection, especially when local optimization or system-level standardization has hidden cross-scale consequences.

prose_parameter_dimensions:
The first tuning dimension is scale granularity: how many levels to distinguish. Too few levels hide mediators; too many levels create an unusable map. The second is causal direction emphasis: whether the map focuses on upward causation, downward causation, or bidirectional loops. Overemphasizing one direction often turns the map into a blame narrative.

Mediator specificity is another key dimension. A vague mediator makes the map unactionable, while excessive detail can overfit one domain. Time-lag resolution also matters because effects often appear later at another scale. Finally, intervention scale bias should be monitored: teams often prefer the level they control, even when the causal map points elsewhere.

prose_variants_and_near_names:
Bottom-Up Causal Mapping focuses on local-to-system movement: aggregation, amplification, accumulation, or contagion. Top-Down Constraint Mapping focuses on macro-to-local influence: rules, incentives, resource conditions, norms, or architectures that shape local behavior.

Bidirectional Cross-Scale Loop Mapping captures recursive situations where local action changes system conditions, which then reshape local action. This may later connect strongly to Nested Feedback Alignment if feedback-specific components such as gain, latency, and target alignment become central.

Teleconnected Cross-Scale Driver Mapping is marked for merge review. It covers remote drivers that affect local conditions through shared large-scale dynamics, but much of that may already belong under Teleconnection Mapping.

Near names such as Local/Global Causal Mapping, Micro/Meso/Macro Causal Mapping, Local/Global Map, and Cross-Scale Impact Diagram should be retained for retrieval. Local/global maps and diagrams are mechanisms or artifacts, not standalone archetypes.

Bottom-Up Causal Mapping

short_definition: A directional variant that focuses on how local behavior, events, or failures aggregate into higher-scale outcomes.

distinctive_feature: The main causal direction is upward, from local units toward intermediate or system-level consequences.

distinct_from_parent: The parent maps upward and downward causality; this variant isolates upward causality when macro outcomes emerge from local behavior.

still_same_parent_because: It still requires explicit scale layers, scale-crossing mediators, and causal movement across levels.

source_primes: scale bottom_up_perspective causality

use_when: A small or local change may produce larger systemic effects through aggregation, amplification, contagion, or accumulation.

use_when: Decision makers are underestimating local action because its larger-scale effect is delayed, distributed, or indirect.

Scale Layer Map

role: Defines the levels across which local effects move.

Upward Causal Path

role: Traces aggregation, amplification, or accumulation.

Cross-Scale Mediator

role: Identifies the relay that carries local effects upward.

Local-to-Global Risk Map

role: Shows local-to-system propagation paths.

Micro/Meso/Macro Causal Map

role: Places local causes inside intermediate and aggregate levels.

example: Individual behavior changes aggregate through contact patterns into community-level risk.

domain: organization

example: Local exception-handling norms accumulate into enterprise-wide operational risk.

failure_modes: Treating aggregation as automatic when mediators are missing.

failure_modes: Ignoring downward constraints that shape the local behavior being mapped.

Top-Down Constraint Mapping

short_definition: A directional variant that focuses on how macro structures, policies, norms, or resource environments shape local behavior.

distinctive_feature: The main causal direction is downward, from system conditions toward local behavior and local possibility spaces.

distinct_from_parent: The parent can map both directions; this variant isolates downward causation and constraint formation.

still_same_parent_because: It remains a cross-scale causal map rather than a design pattern for imposing constraints.

use_when: Local actors appear to make bad choices, but those choices may be shaped by higher-level constraints.

use_when: A system-level rule or resource condition changes what local units can perceive, afford, or do.

Scale Layer Map

role: Separates macro conditions from local behavior.

Downward Causal Path

role: Traces macro-to-local influence.

Cross-Scale Mediator

role: Names the rule, resource flow, or signal that carries the constraint.

Multi-Level Policy Analysis

role: Shows how high-level rules change local incentives or options.

Organizational Level Mapping

role: Links enterprise policies to team-level and individual behavior.

domain: education

example: A system-level accountability metric shapes classroom-level teaching choices.

example: A centralized approval rule changes how local teams prioritize work.

failure_modes: Over-attributing local behavior to macro constraints while ignoring local agency.

failure_modes: Collapsing into downward constraint design rather than staying diagnostic.

Bidirectional Cross-Scale Loop Mapping

short_definition: Maps recursive loops where local behavior changes system conditions, which then reshape local behavior again.

distinctive_feature: The causal relationship loops across levels rather than running only upward or downward.

distinct_from_parent: The parent can include any cross-scale direction; this variant emphasizes recurrent feedback between levels.

still_same_parent_because: The key object remains a causal map across scale layers, not a full feedback-control redesign.

source_primes: scale feedback circular_causality

use_when: Local and system-level dynamics reinforce or counteract each other over time.

use_when: A one-direction causal account misses feedback, lag, or recursive adjustment across levels.

Upward Causal Path

role: Traces local-to-system contribution.

Downward Causal Path

role: Traces system-to-local influence.

Scale Transition Boundary

role: Marks where feedback changes form across levels.

Micro/Meso/Macro Causal Map

role: Represents recurring loops across levels.

System-of-Systems Causal Mapping

role: Handles nested systems that reshape each other.

domain: ecology

example: Local land-use choices alter watershed conditions, which then constrain future local land use.

domain: platform governance

example: User behavior changes platform rules, which then reshape future user behavior.

failure_modes: Drawing every possible loop until the map loses decision value.

failure_modes: Missing time lag and feedback gain, causing mistaken intervention timing.

name: Teleconnected Cross-Scale Driver Mapping

short_definition: Maps remote drivers whose effects reach a local system through shared large-scale dynamics, mediators, and lags.

distinctive_feature: The relevant cross-scale cause is also distant or remote, not merely above or below the local level.

distinct_from_parent: The parent is broader; this variant adds remote coupling, lag, and distant-driver monitoring.

still_same_parent_because: It still uses scale layers, mediators, and causal pathways, but the canonical teleconnection_mapping entry may be the better home.

source_primes: teleconnection network scale

use_when: Local outcomes depend on remote events or conditions that are not visible inside the local boundary.

use_when: The important scale transition includes geographic, network, or systemic distance as well as level difference.

Cross-Scale Mediator

role: Identifies the remote linkage or shared dynamic.

Scale Layer Map

role: Separates local, remote, and system-level layers.

Cross-Scale Impact Review

role: Reviews distant effects on local options.

domain: supply chain

example: A remote production bottleneck changes local service capacity through shared logistics networks.

failure_modes: Duplicating teleconnection_mapping rather than using it as the canonical remote-coupling archetype.

near_names:
Local/Global Causal Mapping
Micro/Meso/Macro Causal Mapping
Local/Global Map
Cross-Scale Impact Diagram
Teleconnection Impact Mapping


Cross-Scale Intervention Matching

type: archetype

source: generated

Intervention Scale Selection

notes: Plain-language alias for choosing the scale at which to act.

Right-Level Intervention

notes:
Useful shorthand, but too slogan-like unless backed by cross-scale causal and feasibility
analysis.

Leverage-Scale Matching

notes:
Emphasizes leverage, but the canonical archetype also includes authority, transition
pathway, and side-effect review.

Level-of-Intervention Matching

notes:
Near alias for organizational and policy settings where levels are the natural language for
scale.

source_primes: scale leverage_points causality

related_primes: downward_causation feedback coupling boundary constraint goal_congruence complexity nonlinearity adaptation

slug: causality

slug: feedback

slug: coupling

slug: boundary

slug: constraint

slug: complexity

slug: nonlinearity

slug: adaptation

components:
Symptom Scale
Cause Scale
Leverage Scale
Intervention Scale Choice
Scale Transition Pathway
Actor Authority Map
Feasibility-by-Scale Assessment
Cross-Scale Side-Effect Review
Outcome Scale Metric
Escalation / Devolution Rule
Multi-Scale Intervention Portfolio
Temporal Lag Profile
Distributional Scale Check
Evidence Confidence by Scale

mechanisms: Individual / Team / Organization Level Selection

essence_one_line:
Match intervention scale to the scale at which the problem is generated or can be most
effectively changed.

compression_statement:
When symptoms appear at one level but causes, leverage, authority, or side effects sit at
another, compare candidate scales of action and choose the level or coordinated set of
levels most likely to change the causal pattern without exporting harm elsewhere.

core_intuition:
Problems often invite action where they are easiest to see, not where they are easiest to
change. This archetype separates the scale of visibility from the scale of causation and
leverage, then makes the intervention level an explicit design choice rather than an
unexamined default.

canonical_formula:
symptom_scale ≠ assumed_action_scale; choose intervention_scale = f(cause_scale,
leverage_scale, authority, feasibility, transition_pathway, side_effects)

structural_problem:
A problem is treated at the scale where it is visible, politically salient, or
administratively convenient even though the causal pattern or practical leverage operates at
a different scale.

condition: Repeated local fixes produce short-lived relief while the problem returns.

why_it_matters: Recurrence suggests that the chosen intervention scale is downstream of the generator.

condition:
Stakeholders disagree about whether the issue is individual, local, organizational,
systemic, or environmental.

why_it_matters: Disagreement may reflect real cross-scale causality rather than mere framing conflict.

condition:
Aggregate metrics improve while local harm persists, or local metrics improve while
aggregate risk grows.

why_it_matters: Single-scale measurement is masking cross-scale side effects.

condition: The actor asked to solve the problem lacks authority over the conditions that produce it.

why_it_matters: Authority mismatch makes the visible scale a poor action scale.

condition: Interventions at one level cause rebound, displacement, or compensation at another level.

why_it_matters: Side effects indicate that the selected level is not aligned with the system dynamics.

symptom: Blame is concentrated at the most local level despite evidence of higher-level constraints.

diagnostic_hint:
Look for incentives, defaults, resource allocation, infrastructure, or policy conditions
that shape local behavior.

symptom:
Broad systemic reforms are proposed even when the decisive variation is local and context-
specific.

diagnostic_hint: Check whether local knowledge, local adaptation, or local capacity is the actual leverage.

symptom:
Every problem receives the same scale of intervention because that is the scale the
organization controls.

diagnostic_hint: Administrative convenience has replaced structural matching.

symptom: Metrics are defined at only one level, creating false success or false failure.

diagnostic_hint: Add outcome measures at symptom, cause, and leverage scales.

symptom:
The intervention solves one unit’s problem by shifting cost, risk, or complexity to another
level.

diagnostic_hint: Run a cross-scale side-effect review before treating the intervention as successful.

root_tension:
The scale at which a problem is visible, the scale at which it is caused, the scale at which
actors can intervene, and the scale at which effects are judged often diverge.

case: The symptom, cause, authority, and leverage all sit at the same level.

why_not_this: Ordinary local problem solving or standard process improvement may be sufficient.

case: The main uncertainty is what is causing the problem at all, not where to intervene.

why_not_this: Use causal diagnosis or cross-scale causal mapping before choosing an intervention scale.

case: The task is only to change analytical perspective without selecting an action level.

why_not_this: That is closer to scale reframing.

case: The task is to find a high-leverage point inside one already-fixed scale.

why_not_this: That may be leverage-point intervention without cross-scale matching.

structural_intervention:
Make the intervention scale explicit by mapping the symptom scale, cause scale, leverage
scale, authority, feasibility, transition pathway, and side effects, then choose a single
level or coordinated multi-level action that best fits the causal structure.

step: Name the symptom scale.

logic: Begin where the problem is observed so stakeholders understand what needs to change.

step: Locate the cause scale.

logic: Ask which level generates, reinforces, or constrains the recurring pattern.

step: Identify candidate leverage scales.

logic:
Compare where small or feasible changes can alter the causal pathway, not merely where the
problem is visible.

step: Map authority and feasibility by scale.

logic:
A structurally ideal intervention may fail if no actor can legitimately act at that level or
if coordination burden is too high.

step: Describe the scale transition pathway.

logic:
Explain how action at the chosen level will reach the symptom scale and what lags or
mediators are expected.

step: Review side effects across levels.

logic:
Prevent the selected intervention from shifting harm, fragility, workload, or accountability
to another scale.

step: Choose the intervention scale and monitoring metrics.

logic:
Record the rationale and define measures at all relevant levels so the choice can be tested
and revised.

step: Define escalation or devolution triggers.

logic:
If the chosen level fails, specify when action should move upward, downward, or into a
multi-level portfolio.

rule: Do not act at the symptom scale by default.

rationale:
The visible level may need relief, but it should not monopolize the intervention unless it
is also causal or high leverage.

rule: Prefer the lowest scale that can change the causal pattern without exporting risk.

rationale:
Lower-level action can be faster and more adaptive, but only if it reaches the generator and
avoids displacement.

rule: Escalate when local actors lack authority over the generator.

rationale: Responsibility without authority produces blame, burnout, and repeated local failure.

rule: Devolve when centralized action is too blunt for material local variation.

rationale:
Scale matching can move downward when local information and adaptation are the true
leverage.

rule: Use a portfolio only when distinct levels contribute distinct causal leverage.

rationale: Multi-level action should be designed, not used as a substitute for choosing.

invariant: Causal fit

description:
The chosen intervention scale must connect to the generator of the problem, not only the
place where symptoms are seen.

invariant: Authority fit

description:
The actors assigned to intervene must have authority, legitimacy, and capacity at the
selected scale.

invariant: Cross-scale accountability

description:
Success cannot be claimed at one level while costs or risks are silently displaced to
another.

invariant: Revisability

description:
The scale choice must be open to escalation, devolution, or portfolio redesign when evidence
changes.

outcome: Fewer wrong-level interventions

description: Resources are not repeatedly spent on visible symptoms that the chosen scale cannot alter.

outcome: Better leverage-to-effort ratio

description: Action occurs where a feasible change can affect the causal pathway.

outcome: Reduced blame displacement

description:
Local actors are not held solely responsible for patterns created at higher or adjacent
levels.

outcome: Improved system learning

description:
Monitoring across symptom, cause, and leverage scales reveals whether the intervention
choice was correct.

outcome: Lower cross-scale harm

description: Side effects are visible enough to prevent local success from becoming broader fragility.

prose_essence:
Cross-Scale Intervention Matching is the discipline of not acting only where a problem is easiest to see. It asks: at what scale is the symptom visible, at what scale is it generated, at what scale can leverage be applied, and at what scale will side effects be felt?

The archetype is useful whenever a local problem may be caused by system-level constraints, or a system-level problem may be changed only through local or intermediate action. It turns multi-scale diagnosis into a practical intervention choice.

prose_when_to_use:
Use this archetype when the level of observation and the level of action are likely to diverge. It is especially relevant when local fixes keep failing, when broad reforms are proposed without local fit, when the actor asked to solve the problem lacks authority over the generator, or when improvement at one level seems to worsen conditions at another.

It is also useful when stakeholders are arguing in different scale languages: one group sees individual behavior, another sees team process, another sees institutional incentives, and another sees broader policy or infrastructure. The archetype does not assume one side is right. It asks which scale explains recurrence, which scale offers leverage, and which scale can act without exporting harm.

prose_structural_problem:
The structural problem is wrong-level action. A system treats a problem at the symptom scale because that is where the harm is visible, politically urgent, administratively convenient, or emotionally salient. Yet the generator may sit above, below, beside, or between the visible level.

A clinic may see repeated illness that is generated by housing exposure. A manager may see employee errors that are generated by workflow and incentive design. A platform may see unsafe user behavior that is generated by interface defaults. A watershed may show local pollution whose generator is regional land use. In each case, symptom-scale action may be necessary but insufficient.

The deeper mismatch is that symptom scale, cause scale, leverage scale, authority scale, and measurement scale can all be different.

prose_intervention_logic:
The intervention begins by naming the symptom scale. This anchors the problem in observable harm rather than abstract system talk.

Next, locate the cause scale: the level where the recurring pattern is produced, reinforced, or constrained. Then identify candidate leverage scales: places where feasible action could change the causal pathway. A cause may sit at a broad scale while leverage sits at an intermediary boundary or local rule; these should not be confused.

After that, map authority and feasibility. A technically correct scale choice fails if no actor can legitimately act there. Then describe the scale transition pathway: how action at the chosen level will affect the symptom scale, through what mediators, and after what lag.

Finally, run a cross-scale side-effect review. The chosen intervention should not improve one level by shifting cost, risk, workload, or fragility to another. The output is an explicit intervention scale choice, supported by metrics at the symptom, cause, and leverage levels.

prose_key_components:
### Symptom Scale

`symptom_scale` names the level where the problem is most visible. This is where complaints, harms, dashboards, incidents, or political pressure often appear. It is the starting point, not automatically the action point.

### Cause Scale

`cause_scale` identifies the level that generates or maintains the recurring pattern. It may be a higher-level policy, a lower-level interaction, a network condition, an incentive structure, or a boundary between levels.

### Leverage Scale

`leverage_scale` locates where intervention can most effectively change the causal pathway. It may differ from the cause scale because the cause may be hard to change directly while a boundary condition, default, interface, rule, or intermediary layer is more tractable.

### Intervention Scale Choice

`intervention_scale_choice` is the selected level or coordinated set of levels where action will occur. It should include the rationale for why that scale fits the problem better than acting only where the symptom appears.

### Scale Transition Pathway

`scale_transition_pathway` explains how action at one level affects another. This is the bridge between diagnosis and expected outcome. Without it, the chosen intervention scale is only an assertion.

### Actor Authority Map

`actor_authority_map` links possible action scales to the actors who can actually act there. It asks who has legitimacy, jurisdiction, resources, and operational control at each candidate level.

### Feasibility-by-Scale Assessment

`feasibility_by_scale_assessment` compares cost, speed, political viability, coordination burden, and technical capacity across scales. It prevents the archetype from choosing a scale that is causally elegant but practically unreachable.

### Cross-Scale Side-Effect Review

`cross_scale_side_effect_review` checks whether the intervention displaces risk, cost, workload, or accountability to another level. It is what prevents local success from becoming system fragility or system efficiency from becoming local harm.

### Outcome Scale Metric

`outcome_scale_metric` defines success at more than one level. The archetype needs symptom-level relief metrics, cause-level change metrics, and side-effect metrics at affected adjacent scales.

### Escalation / Devolution Rule

`escalation_devolution_rule` specifies when to move action upward, downward, or into a multi-level portfolio. It keeps the chosen intervention scale revisable as evidence changes.

prose_common_mechanisms:
### Upstream Intervention Selection

Upstream intervention selection implements the archetype when local symptoms are downstream of broader causes. It moves action from the visible harm toward the policy, infrastructure, incentive, or environmental condition that repeatedly produces the harm. It is a mechanism, not the archetype itself, because cross-scale matching can also move downward or laterally.

### Local-vs-Systemic Policy Choice

Local-vs-systemic policy choice is a policy mechanism for comparing local programs, system-wide rules, and mixed approaches. It implements the archetype in governance settings where the wrong choice can either overburden local units or impose blunt central rules.

### Individual / Team / Organization Level Selection

This mechanism applies the archetype inside organizations. It asks whether a problem should be addressed through individual coaching, team process redesign, management routines, organizational structure, or external coordination.

### Clinical / Social-Determinant Matching

Clinical / social-determinant matching applies the archetype in health contexts. It distinguishes cases that require direct treatment from cases where household, neighborhood, economic, environmental, or policy conditions are the true leverage.

### Infrastructure-vs-Behavior Intervention Comparison

This mechanism asks whether a problem should be solved by changing behavior or by changing the environment that shapes behavior. It is especially useful when education and reminders keep failing because the leverage scale is actually infrastructure, interface design, defaults, or logistics.

### Ecological Intervention Level Choice

Ecological intervention level choice applies the archetype across organism, site, habitat, watershed, landscape, and regional scales. It prevents local treatment from missing broader source populations or regional propagation pathways.

### Leverage-Point Screening Matrix

A leverage-point screening matrix scores candidate action scales by causal proximity, leverage, feasibility, latency, authority, and side-effect risk. It is a decision aid for the archetype, not a substitute for reasoning.

### Scale-Matrix Decision Workshop

A scale-matrix workshop helps stakeholders articulate which level they believe matters and why. It is useful when disagreements arise because each group sees a different part of the cross-scale structure.

### Cross-Scale Side-Effect Table

A side-effect table records benefits and harms above, below, and adjacent to the chosen intervention scale. It implements the archetype’s requirement that success not be claimed at one level by exporting damage to another.

### Authority Escalation Pathway Design

Authority escalation pathway design defines how a problem moves to a broader level when local action lacks authority, or back down to local adaptation when central action is too blunt.

prose_failure_modes:
The most common failure mode is symptom-scale capture. Harm is visible at one level, so all resources go there even when the generator lies elsewhere.

The opposite failure mode is over-systemizing. A team assumes every problem requires broad reform, ignoring local variation and locally available leverage.

Authority mismatch occurs when the selected scale is structurally right but not actionable by the responsible actors. Scale displacement occurs when intervention improves one level by exporting cost, risk, or fragility to another. Portfolio sprawl occurs when teams intervene at every level without distinct causal roles.

Lag misreading is also common: a long-horizon structural intervention is evaluated using short-term local metrics, or a quick local relief measure is mistaken for causal change.

prose_neighbor_distinctions:
Cross-Scale Causal Mapping often comes before this archetype. It tells you how causes and effects move across levels. Cross-Scale Intervention Matching decides where to act.

Leverage Point Intervention overlaps but is not identical. A leverage point can exist within one scale; this archetype compares scales of symptom, cause, leverage, authority, feasibility, and side effects.

Scale Reframing changes how people see the problem. Cross-Scale Intervention Matching changes the action level. Whole-System Diagnosis examines broad system structure; this archetype makes a scale-specific intervention decision. Scale-Appropriate Modeling chooses a representation scale; this archetype chooses an action scale.

prose_cross_domain_examples:
In public health, repeated asthma admissions may be visible in emergency rooms, but leverage may lie in housing quality, pollution exposure, insurance design, or neighborhood support. The archetype helps distinguish clinical treatment from environmental or policy intervention without denying immediate care.

In organizational change, repeated errors by frontline staff may be caused by staffing ratios, handoff design, incentives, or software defaults. The intervention scale might be individual training, team redesign, management process, or enterprise policy.

In software security, account takeovers may look like user mistakes, but the leverage may sit in authentication architecture, interface defaults, abuse-detection systems, or ecosystem policy.

In ecology, a local invasive-species outbreak may require site removal, corridor management, regional transport controls, or land-use change depending on source dynamics.

In supply chains, local stockouts may originate in store practices, regional replenishment, supplier concentration, contract terms, or global logistics. The visible plant or store is not automatically the right action scale.

prose_non_examples:
A local mechanical failure repaired by fixing the broken part is not this archetype because symptom, cause, authority, and action scale coincide.

A workshop that merely asks people to think at multiple levels is not this archetype unless it selects an action scale. A generic call for systemic change is not this archetype if it bypasses local evidence, authority, feasibility, and side effects.

A multi-level intervention bundle is not this archetype when it simply acts everywhere. The portfolio must be justified by distinct causal roles at each level.

prose_tradeoffs:
Cross-scale matching often reveals a tradeoff between immediate relief and structural change. Local action may help quickly but fail to alter recurrence; broader action may alter recurrence but take longer.

There is also a tradeoff between precision and coordination burden. Local action fits context but can fragment; broad action coordinates many units but can become blunt. A third tradeoff is authority fit versus causal fit: the level that can solve the problem may not be controlled by the actor currently responsible for it.

A multi-level portfolio can address several dimensions at once, but it increases governance and measurement burden. It should be used when levels contribute distinct causal leverage, not when the team cannot decide.

prose_invariants_to_preserve: The archetype must preserve causal fit: the chosen level of action must connect to the generator of the problem. It must preserve authority fit: actors must have the legitimacy and capability to act at the selected scale. It must preserve cross-scale accountability: success at one level cannot be counted while harm is hidden at another. It must also preserve revisability: the intervention scale can change when evidence shows that the original match was wrong.

prose_target_outcomes:
The primary outcome is fewer wrong-level interventions. Resources move away from repeated symptom treatment when symptoms are downstream of a different generator.

A second outcome is better leverage-to-effort ratio. Action occurs where feasible change can alter the causal pathway. A third outcome is reduced blame displacement: local actors are not held responsible for problems produced by higher-level constraints, and central authorities are not blamed for problems better solved through local adaptation.

The archetype should also improve learning. Because metrics are collected at multiple levels, the organization can see whether the scale choice worked, merely shifted effects, or needs escalation or devolution.

prose_parameter_dimensions:
### Scale Granularity

The analysis can distinguish a few broad levels or many fine-grained levels. Too little granularity hides useful leverage; too much granularity creates complexity without improving action.

### Intervention Breadth

The chosen action can be narrow and local, broad and systemic, or a coordinated portfolio. Breadth should match the causal structure, not the ambitions of the intervention team.

### Authority Distance

Authority distance measures how far the chosen action scale is from the actors currently responsible. Greater distance may require escalation, coalition-building, mandate change, or staged implementation.

### Time Lag

Some scale choices produce immediate symptom relief; others change deeper structures slowly. The evaluation horizon should match the expected lag rather than prematurely declaring success or failure.

### Side-Effect Tolerance

Every intervention shifts some burden. The tuning question is which side effects are acceptable, which must be mitigated, and which invalidate the chosen scale.

### Local Adaptation Freedom

Centralized interventions may need local adaptation to avoid bluntness. Local interventions may need guardrails to avoid fragmentation. The right amount depends on variation across contexts.

prose_variants_and_near_names:
Upstream Scale Matching is the most common variant. It selects a broader or earlier-generating scale when local symptoms are downstream.

Downward Constraint Matching selects a higher-level rule, boundary, default, or infrastructure condition when macro structure shapes local behavior. Local Autonomy Matching moves action downward when local variation makes centralized action too blunt.

Multi-Level Portfolio Matching coordinates several levels when no single scale has enough leverage. Lag-Aware Scale Matching makes time delays part of the scale choice so short-term relief and long-term structural change are not confused.

Near names include Intervention Scale Selection, Right-Level Intervention, Leverage-Scale Matching, Scale-Appropriate Intervention, and Level-of-Intervention Matching. These names are acceptable as aliases, but the canonical archetype should retain the full matching logic.

Upstream Scale Matching

short_definition:
Select an intervention at a broader or earlier-generating scale when local symptoms are
downstream effects.

distinctive_feature:
The intervention deliberately moves upstream from the visible symptom scale to the causal or
constraint-setting scale.

distinct_from_parent:
The parent includes upward, downward, and lateral scale choices; this variant focuses on
downstream symptoms whose leverage lies upstream.

still_same_parent_because:
It still follows the core matching logic: symptom scale, cause scale, leverage scale,
feasibility, and side-effect review.

condition: Local fixes repeatedly produce temporary relief but not durable change.

condition:
The causal pattern is produced by policy, infrastructure, incentives, norms, or resource
allocation above the local unit.

Symptom Scale

role: Marks the downstream manifestation.

Cause Scale

role: Names the upstream generator.

Scale Transition Pathway

role: Explains how upstream change reaches local symptoms.

Upstream Intervention Selection

role: Moves action to an earlier-generating level.

Local-vs-Systemic Policy Choice

role: Compares local program action with systemic policy change.

example:
Treating recurrent heat illness by changing cooling infrastructure and labor rules rather
than only distributing advice.

domain: operations

example:
Reducing repeated warehouse errors by redesigning inventory process constraints rather than
retraining one worker at a time.

failure_modes: Over-upstreaming: delaying necessary local relief while waiting for structural reform.

Downward Constraint Matching

short_definition:
Select a higher-level rule, boundary, default, or constraint when local behavior is shaped
by macro structure.

distinctive_feature: The intervention works by altering the higher-level conditions that channel local action.

distinct_from_parent:
The parent includes any scale match; this variant specifically emphasizes downward causation
from system structure to local behavior.

still_same_parent_because: It is still a selected scale match, not a general theory of downward causation.

source_primes: scale downward_causation constraint

condition:
Local actors are blamed for behavior that is strongly induced by system-level defaults or
constraints.

condition:
Changing the macro rule would allow many local units to improve without bespoke local
intervention.

Cause Scale

role: Identifies the constraint-setting level.

Actor Authority Map

role: Finds who can change the rule or default.

Cross-Scale Side-Effect Review

role: Checks how local units are affected.

role: Tests whether behavior change should be replaced by environment change.

example:
Changing the default privacy setting rather than asking each user to make a complex safe
choice.

failure_modes: Over-centralization: imposing a uniform constraint that erases necessary local adaptation.

Local Autonomy Matching

short_definition:
Move intervention authority downward when local variation makes centralized action too blunt
or slow.

distinctive_feature:
The match selects a smaller action scale because contextual specificity is part of the
leverage.

distinct_from_parent:
The parent can choose any scale; this variant specifically validates deliberate devolution
to local action.

still_same_parent_because:
The variant still requires cause/leverage mapping and side-effect review rather than
assuming local is always better.

source_primes: scale boundary adaptation

condition: The system-level rule produces uneven effects because local contexts differ materially.

condition: Local actors have better information and sufficient safeguards to adapt the intervention.

Feasibility-by-Scale Assessment

role: Compares local capacity with centralized capacity.

Escalation / Devolution Rule

role: Defines when authority moves down or back up.

Authority Escalation Pathway Design

role: Creates a reversible governance path.

example: Allowing schools to adapt implementation while preserving system-level outcome standards.

failure_modes: Fragmentation: devolved action creates inequity or incompatible local practices.

Multi-Level Portfolio Matching

short_definition:
Coordinate complementary interventions at several levels when the causal pattern cannot be
changed from one scale alone.

distinctive_feature: The match is not a single scale choice but a designed combination of scale-specific actions.

distinct_from_parent:
The parent usually chooses the best intervention scale; this variant chooses a portfolio
while retaining explicit scale rationale for each action.

still_same_parent_because: It still depends on symptom/cause/leverage matching and cross-scale side-effect review.

source_primes: scale leverage_points coupling

condition:
The symptom is maintained by mutually reinforcing dynamics at local, intermediate, and
systemic levels.

condition: Single-level intervention produces rebound, displacement, or partial improvement.

Multi-Scale Intervention Portfolio

role: Coordinates multiple action levels.

Outcome Scale Metric

role: Tracks results at each level.

Leverage-Point Screening Matrix

role: Chooses which levels belong in the portfolio.

example:
Combining street redesign, enforcement policy, community support, and regional transport
planning to reduce crashes.

failure_modes:
Coordination overload: too many levels are activated without clear division of
responsibility.

Lag-Aware Scale Matching

short_definition:
Choose the intervention scale while accounting for different delays between action and
visible effects at each level.

distinctive_feature: The variant treats time lag as part of scale matching rather than as an afterthought.

distinct_from_parent: The parent does not always require explicit temporal lag modeling; this variant does.

still_same_parent_because:
Lag only modifies the scale-selection logic; it does not create a separate intervention
family.

source_primes: scale feedback causality

condition: Local symptoms require immediate relief but structural changes are slower.

condition:
Short-term metrics risk discrediting a higher-level intervention before its effects can
arrive.

Temporal Lag Profile

role: Estimates cross-scale effect delays.

Outcome Scale Metric

role: Separates short-term relief from long-term structural change.

Scale-Matrix Decision Workshop

role: Makes lag assumptions explicit in the decision process.

example:
Pairing immediate erosion control with landscape-level restoration whose benefits arrive
over several seasons.

failure_modes: Patience error: using lag as an excuse to persist with an ineffective broad intervention.

near_names:
Intervention Scale Selection
Right-Level Intervention
Leverage-Scale Matching
Scale-Appropriate Intervention
Level-of-Intervention Matching


Cross-Side Platform Balancing

batch: Batch 14

aliases:
two-sided platform balancing
two-sided market design
multi-sided platform balancing
cross-side network-effect management
platform liquidity balancing
platform marketplace balancing
cross-side demand balancing
marketplace side-balancing

slug: liquidity

slug: competition

slug: interoperability

slug: externality

slug: coordination

slug: equilibrium

slug: threshold

slug: demand

slug: allocation

slug: monopoly

slug: trust

slug: governance

slug: network

components:
Side Pair Definition
Cross-Side Value Map
Side-Specific Demand Curve
Liquidity and Thickness Threshold
Cross-Side Price and Subsidy Rule
Quality and Trust Filter
Same-Side Congestion Guardrail
Matching and Discovery Surface
Governance and Rule-Change Process
Side Balance Feedback Loop
Anchor-Side Strategy
Market-Maker or Seed Supply
Multihoming and Switching-Friction Map
Trust, Safety, and Dispute Boundary
Surplus Distribution Account
Interoperability or Portability Path

mechanisms: Anchor User or Anchor Supplier Recruitment

mechanisms: Portability or Interoperability Commitment

essence_one_line: Design a platform market by balancing the two sides whose participation creates value for one another.

compression_statement: A two-sided market fails when designers optimize one participant side in isolation. Cross-Side Platform Balancing maps side-specific demand and cross-side value, then tunes pricing, subsidies, access, quality filters, liquidity thresholds, matching, governance, and feedback so both sides remain viable together.

core_intuition: A platform is not just a bigger marketplace. It is a coupled system: more riders can attract drivers, more developers can attract users, and more buyers can attract sellers, but only if quality, price, trust, and congestion are balanced on both sides. The right price for one side may be low or negative because that side creates value elsewhere in the system.

canonical_formula: Value_A = f(Size_B, Quality_B, Trust_B, Friction_A, Price_A); Value_B = g(Size_A, Quality_A, Trust_A, Friction_B, Price_B). Balance requires choosing rules and prices jointly, not side by side.

structural_problem: A platform mediates two distinct participant groups, and each group’s willingness to join, remain, transact, or contribute depends on the size, quality, trustworthiness, price, and accessibility of the other group.

trigger_conditions: One side waits for the other side to arrive before joining or engaging.

trigger_conditions: Participation growth on one side creates value for the other side, but same-side crowding or low quality can reduce value.

trigger_conditions: The platform must set asymmetric prices, subsidies, commissions, or frictions across sides.

trigger_conditions: Search, matching, ranking, trust, or fraud controls determine whether nominal participation becomes usable liquidity.

trigger_conditions: A side that creates major cross-side value is too expensive, too scarce, or too risky to recruit without subsidy.

trigger_conditions: Network effects are strong enough that cold start, tipping, lock-in, or winner-take-all dynamics are plausible.

trigger_conditions: A rule change on one side rapidly changes participation, quality, or welfare on the other side.

symptoms: Many users join but few successful matches or transactions occur.

symptoms: One side is oversupplied while the other side is scarce, causing waiting time or low conversion.

symptoms: Lowering price on one side increases participation but decreases quality, trust, or counterpart value.

symptoms: A platform overcharges the side with weaker bargaining power and eventually loses ecosystem health.

symptoms: Marketing spend attracts one side, but the other side churns because liquidity or quality is inadequate.

symptoms: Growth produces spam, fraud, congestion, or attention dilution.

symptoms: The platform reaches critical mass in one geography, category, or cohort but fails when generalized too early.

root_tension: The platform must optimize a coupled cross-side system while each side experiences local price, friction, quality, and trust conditions differently. Maximizing direct revenue from one side can destroy the other side’s willingness to participate, and maximizing raw participation can destroy quality or liquidity.

anti_signatures: The platform only serves one homogeneous user group with no cross-side value loop.

anti_signatures: The problem is purely internal scale economy or shared-service consolidation, not cross-side market balancing.

anti_signatures: The main task is stable pairing between two sides under preferences; use Two-Sided Matching unless platform pricing/liquidity governance is central.

anti_signatures: The problem is a generic hub-and-spoke coordination topology without side-specific demand, price, or network-effect dynamics.

anti_signatures: The issue is only network-effect cold start; use Network Effect Bootstrapping if ongoing cross-side balancing is not the center.

structural_intervention: Model the platform as coupled participant sides, then tune cross-side pricing, subsidies, access, quality controls, matching, trust, liquidity, and governance through continuous side-balance feedback.

action_logic: Define the sides, the value each side receives from the other, and the transactions or interactions the platform enables.

action_logic: Map each side’s demand drivers: price, friction, quality, trust, expected wait time, counterpart availability, and outside options.

action_logic: Estimate the liquidity or thickness threshold needed for each side in each category, location, or cohort.

action_logic: Identify cross-side and same-side externalities: who creates value, who imposes congestion, and who bears risk.

action_logic: Choose pricing, subsidy, commission, access, matching, quality, and trust mechanisms jointly rather than side by side.

action_logic: Sequence launch by cohort, geography, category, or anchor side to reach local liquidity before scaling.

action_logic: Monitor side ratios, conversion, wait times, churn, quality, fraud, surplus distribution, and trust shocks.

action_logic: Revise rules and governance when growth changes bargaining power, congestion, quality, or lock-in risk.

decision_rules: Subsidize the side that creates high cross-side value, is scarce, or has high adoption friction, even if direct revenue comes from the other side.

decision_rules: Do not count participation as liquidity unless counterpart discovery, matching, and trust conditions make interaction likely.

decision_rules: If one side is abundant but low quality, tighten quality filters before spending to recruit more counterpart volume.

decision_rules: If both sides wait for the other, use anchor participants, staged launch, market making, seed supply, or threshold commitments.

decision_rules: If same-side congestion reduces value, add ranking, quotas, segmentation, category boundaries, or differentiated access.

decision_rules: If network effects are creating lock-in or power concentration, add portability, interoperability, governance appeal, or competition safeguards.

decision_rules: Treat any major pricing or ranking change as a cross-side intervention that requires side-effect review.

target_invariants: Both sides remain explicitly represented in metrics and governance.

target_invariants: Cross-side value is measured separately from same-side crowding or congestion.

target_invariants: Price, subsidy, and access decisions are justified by side-specific elasticity and value contribution.

target_invariants: Growth does not bypass quality, safety, fraud, or trust controls.

target_invariants: The platform retains a legitimate process for rule changes, disputes, removal, and appeal.

target_invariants: Cold-start tactics transition into sustainable governance rather than permanent unsustainable subsidy.

expected_outcomes: The platform reaches and maintains usable liquidity on both sides.

expected_outcomes: Participant acquisition, pricing, quality, and trust controls reinforce rather than undermine one another.

expected_outcomes: Side imbalances are detected early through waiting time, conversion, churn, and quality metrics.

expected_outcomes: Subsidies or fees are easier to justify because cross-side value is explicit.

expected_outcomes: The platform avoids brittle cold-start failure, one-sided extraction, lock-in backlash, and fraud-driven collapse.

prose_essence:
A two-sided market is a coupled system. One side joins because the other side is present, useful, trustworthy, and discoverable. The platform succeeds only when both sides find enough value at the same time. **Cross-Side Platform Balancing** makes that coupling explicit and governs it through side-specific pricing, subsidies, access, quality filters, matching, trust, and feedback.

The core mistake is optimizing one side in isolation. More buyers do not help if sellers are absent. More drivers do not help if riders are scarce. More advertisers can hurt if the audience leaves. More developers can hurt if quality, malware, or compatibility problems overwhelm users.

Marketplace Liquidity Balancing

distinctive_feature: Fill rate, waiting time, inventory depth, and transaction conversion dominate.

Advertiser-Audience Platform Balancing

distinctive_feature: One side pays for access to attention while excessive monetization can degrade the other side.

Developer-User Ecosystem Balancing

distinctive_feature: Developer supply creates user value while user scale attracts developers.

Labor Platform Side Balancing

distinctive_feature: Labor welfare, classification, safety, and surge incentives are central.

Payment Network Acceptance Balancing

distinctive_feature: Acceptance ubiquity and user adoption reinforce each other through network effects.

near_names:
Two-Sided Market Design
Two-Sided Platform Balancing
Multi-Sided Platform Balancing
Platform Liquidity Balancing
Cross-Side Network-Effect Management


Cue-Triggered Intention Execution

batch: Batch 09

aliases:
prospective memory design
cue-bound future intention execution
event-triggered intention recall
deferred intention retrieval
cue-contingent action execution
future-action reminder architecture

related_primes: memoing replay habit goal_shielding knowledge_action_gap scheduling attention salience delegation_of_authority cue_outcome_decoupling context observability threshold foresight commitment_device preparation feedback latency conditional_probability affordance

slug: callback

slug: script

slug: monitoring

slug: validation

slug: memoing

slug: replay

slug: habit

slug: scheduling

slug: attention

slug: salience

slug: context

slug: observability

slug: foresight

slug: preparation

slug: feedback

slug: latency

slug: affordance

components:
Future Intention Payload
Triggering Cue Specification
Cue-Action Binding
Latent Intention Store
Parallel Cue Monitor
Retrieval and Execution Gate
Action Closure Signal
Missed-Cue Recovery Path
Cue Salience Amplifier
Context Reinstatement Prompt
Conflict and Priority Filter
Delegated Trigger Owner
Expiry and Staleness Rule

mechanisms:
Implementation Intention Script
Event-Based Reminder
Time-Based Reminder
Callback Registration
Environmental Prompt Placement
Deferred-Action Checklist Marker
Event Listener or Monitoring Daemon
Cue Disambiguation Test
Execution Acknowledgement Loop
Missed Trigger Review

essence_one_line: Bind an intended future action to a cue so it can sleep in the background and reappear exactly when action becomes possible.

compression_statement: Cue-Triggered Intention Execution applies when an action matters later but should not consume ongoing attention. The intervention defines the future action, chooses or constructs a triggering cue, binds the cue to the action, stores the intention latently, monitors for the cue in parallel with other work, gates execution when the cue fires, and closes the loop so the intention is not missed, duplicated, or left stale.

core_intuition: A future intention is fragile if it depends on remembering at the right moment. Pairing the intention with a future cue turns the environment, calendar, workflow, or another actor into the retrieval key. The actor does not have to rehearse the action continuously; the cue does the work of calling it back.

canonical_formula: prospective action = intention payload I + trigger cue C + cue-action binding B + latent store L + cue monitor M + execution gate G + closure signal X. Success requires C to occur, M to detect C, B to retrieve I, G to allow action, and X to record the outcome.

structural_problem: A future action is important but cannot or should not be performed now. If it remains only as a general intention, it competes with current work, decays, or fails to surface when the relevant cue appears. The system needs a way to make the future situation itself retrieve the action without continuous rehearsal.

trigger_conditions: An action must be performed later when a specific time, event, location, state, or social cue occurs.

trigger_conditions: The actor will be occupied by other tasks when the cue appears.

trigger_conditions: Continuous rehearsal would be costly, distracting, or unreliable.

trigger_conditions: The cue can be specified and detected with enough fidelity to support action.

trigger_conditions: Failure to act at cue-time would cause omission, delay, safety risk, coordination failure, or missed opportunity.

trigger_conditions: The action can be closed, rescheduled, or escalated after the cue fires.

symptoms: People say they intended to act but forgot when the moment arrived.

symptoms: Reminders fire at times disconnected from the context where action is possible.

symptoms: Tasks are recorded in a list but not linked to the event that should trigger them.

symptoms: Callbacks, alerts, or handoffs happen without enough context to know what action was intended.

symptoms: A cue is noticed but not recognized as the cue for a stored intention.

symptoms: Multiple reminders remain active after execution, causing duplicate work or alert fatigue.

symptoms: A future action is rehearsed repeatedly because no trusted cue-bound retrieval system exists.

root_tension: The intention must remain dormant enough not to monopolize attention, but accessible enough to be retrieved immediately when the right cue appears.

anti_signatures: If the goal is to keep a fading state active through repeated refresh, use threshold_refresh_state_maintenance.

anti_signatures: If the goal is to stabilize a newly encoded trace into durable long-term memory, use post_encoding_trace_stabilization.

anti_signatures: If the goal is to redesign cues that trigger habitual responses, use associative_cue_redesign.

anti_signatures: If the goal is only to record what happened, use logging or traceability patterns.

anti_signatures: If the future action is already handled by an ordinary schedule with no cue-detection problem, a simple calendar mechanism may be enough.

anti_signatures: If the cue is unknown, unknowable, or ethically inappropriate to monitor, do not use this archetype until the trigger condition is redesigned.

structural_intervention: Create a governed cue-action memory loop: specify the future action, bind it to an observable trigger cue, preserve the binding latently, monitor for the cue while other activity continues, retrieve and gate the action when the cue occurs, and close or recover the intention after the moment passes.

action_logic: Name the future action in executable terms rather than as a vague aspiration.

action_logic: Specify the trigger cue: event, time, location, state, person, threshold, message, or environmental affordance.

action_logic: Test whether the cue is discriminable, timely, and close enough to the action opportunity.

action_logic: Bind cue and action with enough context to answer why, when, who, and what counts as done.

action_logic: Choose a latent store: human memory, checklist, task system, callback registry, reminder service, workflow marker, or monitoring process.

action_logic: Set a parallel cue monitor that does not require continuous rehearsal by the actor.

action_logic: Define an execution gate that checks safety, authority, readiness, and priority when the cue fires.

action_logic: Record closure: executed, skipped, delegated, rescheduled, expired, or escalated.

action_logic: Review missed cues, false triggers, and stale intentions to improve future cue-action bindings.

decision_rules: Use event-based cues when the future action depends on a state change; use time-based cues only when time is itself the relevant trigger.

decision_rules: A cue must be observable near the action opportunity, not merely memorable at encoding time.

decision_rules: The action payload must be specific enough to execute after context has faded.

decision_rules: Do not rely on internal memory alone when the cost of omission is high and external cueing is possible.

decision_rules: Add escalation if a missed cue creates safety, compliance, or coordination risk.

decision_rules: Expire or revalidate intentions whose original cue-action context may have changed.

decision_rules: Use a human cue-bound intention when judgment at execution time matters; use automation when the cue-action relation is safe and well-specified.

decision_rules: Treat repeated false positives as cue-design failure, not user discipline failure.

target_invariants: The intended future action remains linked to a specific trigger cue.

target_invariants: The cue is detectable at or before the moment when action is still possible.

target_invariants: Latent storage does not require continuous rehearsal.

target_invariants: Execution is gated by current context rather than blindly triggered from stale intent.

target_invariants: Closure prevents both omission and duplicate execution.

target_invariants: The actor or system can distinguish missed cue, ambiguous cue, false cue, and blocked execution.

target_invariants: Safety and consent boundaries are preserved when cues are monitored or delegated.

expected_outcomes: Future actions are remembered at the moment of relevance rather than only before or after.

expected_outcomes: Attention is freed from continuous rehearsal.

expected_outcomes: Reminders, callbacks, and handoffs carry enough context to support correct action.

expected_outcomes: Omissions and duplicate executions become visible through closure signals.

expected_outcomes: Cue design can be improved from missed-trigger and false-trigger evidence.

expected_outcomes: High-value deferred actions can be governed without turning every intention into a constantly active task.

Event-Based Prospective Memory

short_definition: A variant where a future action is triggered by an external event or state change rather than by clock time.

distinctive_feature: The cue is an event in the world or workflow.

distinct_from_parent: The parent also covers time-based, social, and automated cueing; this variant emphasizes event detection.

still_same_parent_because: It uses the same cue-action binding, latent storage, monitoring, execution, and closure loop.

use_when: The relevant action opportunity appears when a condition changes.

use_when: A state, message, location, or social cue can be detected.

use_when: Action before the cue would be premature and action after the cue may be too late.

example: Run cleanup when deployment state changes to stable.

failure_modes: The event cue is too broad and fires repeatedly or too late.

Time-Based Prospective Memory

short_definition: A variant where the trigger cue is a time, deadline, interval, cadence, or calendar boundary.

distinctive_feature: The cue is clock or calendar time.

distinct_from_parent: The parent is not limited to time cues; many prospective-memory failures are event-based.

still_same_parent_because: The time cue retrieves and gates a latent future intention.

use_when: The future action depends on a time boundary.

use_when: The actor may not naturally encounter a contextual event cue.

use_when: Closure or escalation is needed after the scheduled moment.

domain: medicine

example: A patient receives a medication reminder exactly when the dose window opens and must confirm completion.

failure_modes: The alarm fires away from the action context and is dismissed.

Delegated Prospective Memory

short_definition: A variant where another actor, role, system, or service monitors the cue and returns the intended action to the original process.

distinctive_feature: Cue monitoring or reactivation is delegated.

distinct_from_parent: The parent may be entirely internal or personal; this variant makes the monitoring loop social or technical.

still_same_parent_because: The delegated monitor still preserves a latent cue-action binding and triggers future execution.

use_when: The original actor cannot monitor the cue reliably.

use_when: A role or tool can accept responsibility for cue detection.

use_when: Authority, privacy, and closure are explicit.

example: A docketing service triggers a filing-review action when a court notice arrives.

failure_modes: Responsibility diffuses and neither original actor nor delegate closes the loop.

near_names:
Prospective Memory Design
Cue-Bound Future Intention Execution
Event-Triggered Intention Retrieval
Future-Action Callback Design