Goal Congruence Alignment

batch: First Iteration/Batch 33

Goal Alignment

notes: Common shorthand. Use the canonical archetype only when the intervention explicitly aligns local objectives with whole-system outcomes.

Strategic Alignment

notes: Often a broader management phrase. Collapse here only when strategy is translated into local goals, metrics, incentives, and conflict rules.

Objective Alignment

notes: Names the same local/system goal congruence problem in many domains, but can also point to Objective Function Alignment when the issue is defining an optimization target.

KPI Alignment

notes: A metric-level implementation name; not the full archetype unless it changes local behavior against system outcomes.

OKR Alignment

notes: An OKR implementation variant or mechanism under this archetype, not a standalone archetype.

slug: accountability

slug: optimization

slug: feedback

slug: holism

components:
Local Goal Map
System Goal Model
Misalignment Diagnosis
Metric Redesign
Incentive Alignment
Conflict Resolution Rule
System Outcome Monitor
Goal Cascade Trace
Externality Register
Goal Owner Network
Countermetric Guardrail

mechanisms:
OKR Alignment Process
Shared Metric Design
Balanced Scorecard
Incentive Redesign
Cross-Functional Goal Setting
Principal–Agent Contracting
Metric Gaming Review
Strategy Deployment / Hoshin Kanri
System Outcome Dashboard

essence_one_line: Align local objectives, metrics, and incentives with system-level goals so units do not optimize against the whole.

compression_statement: When individuals, teams, units, agents, or subsystems pursue local goals that conflict with system outcomes, redesign objectives, metrics, incentives, accountability, and feedback so local success contributes to whole-system success.

core_intuition: People and units usually respond to the goals and signals immediately around them. If those local signals are misaligned, rational local behavior creates system-level failure. Goal Congruence Alignment changes the definition of local success so contributing to the whole becomes the normal path, not an exceptional act of altruism.

canonical_formula: local goal map + system goal model + misalignment diagnosis + metric/incentive redesign + conflict rule + outcome monitor -> local success supports system success

structural_problem: Subunits optimize their own targets while damaging broader outcomes, creating cross-unit conflict, metric gaming, externalities, or drift from the system mission.

trigger_conditions: Different roles, teams, units, vendors, agents, or automated subsystems are evaluated by different goals or metrics.

trigger_conditions: Local success can be achieved while the whole system performs worse, becomes riskier, or shifts burden elsewhere.

trigger_conditions: System outcomes require joint contribution, but accountability and rewards remain isolated by function, department, contract, or time period.

trigger_conditions: A performance metric has become the target and has started to distort behavior away from the intended outcome.

trigger_conditions: Leaders announce a system goal, but budgets, promotions, incentives, review routines, or operational dashboards continue to reward the old local priorities.

trigger_conditions: Cross-unit tradeoffs are real but unmanaged, so actors resolve them through informal bargaining, escalation avoidance, blame transfer, or hidden workarounds.

trigger_conditions: The desired outcome spans time horizons, but local actors are rewarded for short-term throughput, cost reduction, or visible activity.

symptoms: Every unit can show green metrics while customers, citizens, patients, users, or the system as a whole experience poor outcomes.

symptoms: Teams protect their scorecards by passing cost, risk, delay, or rework to another team.

symptoms: People game indicators, cherry-pick cases, defer hard work, or optimize what is easy to measure rather than what matters.

symptoms: Strategic priorities are repeatedly translated into disconnected local targets that do not add up to the intended outcome.

symptoms: Cross-functional initiatives stall because each participant is accountable to a different local boss, metric, or incentive.

symptoms: Budget, contract, or promotion incentives pull against stated mission, quality, safety, equity, reliability, or long-term capacity goals.

symptoms: No one has authority or incentive to resolve conflicts among locally reasonable goals.

root_tension: Local optimization is necessary because actors need concrete goals, but local goals are incomplete approximations of system value. The system must give local actors actionable targets without allowing those targets to become isolated proxies that undermine the whole.

anti_signatures: The local goals already support the system outcome and the main issue is lack of capacity or capability rather than incongruence.

anti_signatures: The problem is primarily unclear decision authority rather than conflicting goals; Decision Rights Clarification is a closer fit.

anti_signatures: The issue is a hidden task dependency rather than a goal or incentive conflict; Task Interdependence Mapping is closer.

anti_signatures: The main problem is broad structural, technical, or boundary mismatch across the whole system, not specifically local goal congruence; Whole-System Alignment may be broader.

anti_signatures: The intervention only creates an OKR, KPI, or dashboard artifact without changing local incentives, review criteria, conflict resolution, or feedback loops.

anti_signatures: The system goal itself is undefined or contested; Objective Function Alignment or Structured Sensemaking may be needed first.

structural_intervention: Map local and system goals, diagnose where local optimization conflicts with whole-system outcomes, redesign metrics and incentives, add conflict-handling rules, and monitor whether local success now produces system success.

action_logic: State the system goal in outcome terms, including protected constraints and unacceptable externalities.

action_logic: Map the local goals, metrics, incentives, review criteria, informal rewards, and decision constraints facing each relevant actor or unit.

action_logic: Compare local success definitions with the system goal to locate conflicts, gaps, time-horizon mismatches, controllability problems, and externalized costs.

action_logic: Redesign metrics so they track contribution to the system outcome, including shared measures, countermetrics, weighting changes, and retirement of misleading proxies.

action_logic: Redesign incentives and accountability so locally viable behavior also supports the whole, including recognition, budget flows, contracts, promotions, autonomy, and risk exposure.

action_logic: Define conflict-resolution and escalation rules for cases where local goals remain in tension or where system goals trade off against each other.

action_logic: Monitor system outcomes and gaming signals, then adjust the goal architecture when behavior changes in unexpected ways.

decision_rules: Use shared metrics when multiple units jointly determine an outcome and isolated metrics create handoff blame or burden shifting.

decision_rules: Use countermetrics when a target can be improved by damaging quality, safety, equity, resilience, learning, trust, or long-term capacity.

decision_rules: Use incentive redesign when actors know the desired outcome but are rewarded or protected for doing something else.

decision_rules: Use goal-cascade traceability when strategic intent is lost as goals move across organizational levels.

decision_rules: Use conflict-resolution rules when goals cannot be fully harmonized and actors need an explicit way to make tradeoffs.

decision_rules: Avoid individual accountability for outcomes that actors cannot substantially influence; pair shared goals with contribution visibility and controllability checks.

target_invariants: Local actors retain enough clarity to act without needing to constantly recompute the whole system.

target_invariants: Measured success remains causally connected to real system outcomes, not merely to proxy improvement.

target_invariants: Alignment does not erase legitimate local expertise, constraints, or context.

target_invariants: Incentives do not reward concealment, gaming, blame shifting, unsafe speed, or externalized harm.

target_invariants: Conflict among goals is surfaced and governed rather than hidden in workarounds.

target_invariants: The alignment mechanism remains revisable as strategy, environment, and behavior change.

expected_outcomes: Local and system performance move in the same direction more often.

expected_outcomes: Cross-unit conflict and blame caused by incompatible goals decrease.

expected_outcomes: Metric gaming and proxy optimization become easier to detect and correct.

expected_outcomes: Strategic priorities translate into operational behavior rather than slogans.

expected_outcomes: Actors can see how their work contributes to the whole and what tradeoffs require escalation.

expected_outcomes: System-level outcomes improve without requiring constant heroic coordination from leaders.

prose_essence:
Goal Congruence Alignment is the intervention pattern for cases where local success and whole-system success have drifted apart. It does not ask people to ignore their local goals; it redesigns those goals, metrics, incentives, and review rules so locally rational behavior becomes system-supporting behavior.

The archetype is especially important when every subunit appears to be performing well on its own scorecard while the customer, user, citizen, patient, ecosystem, or organization experiences poor outcomes. In those cases, the problem is rarely individual bad faith. The structure of success has been mis-specified.

prose_when_to_use:
Use this archetype when individuals, teams, departments, vendors, agents, or subsystems pursue goals that are locally reasonable but globally damaging. It is appropriate when performance metrics, incentive plans, budgets, promotion criteria, service-level agreements, or review rituals pull actors away from the system goal.

It is not enough that goals are merely different. The key signal is incongruence: local optimization creates externalities, gaming, conflict, burden shifting, short-termism, or system-level underperformance.

prose_structural_problem:
The structural problem is a mismatch between the success function at the local level and the success function at the system level. Local actors are asked to act, decide, and prioritize with partial information and concrete targets. If those targets omit quality, resilience, safety, trust, user burden, long-term capacity, downstream rework, or cross-unit effects, then local excellence can accumulate into system failure.

This pattern often appears as green dashboards with unhappy users, fast throughput with high rework, low purchase price with high lifecycle cost, rapid case closure with rising appeals, or aggressive growth with declining trust.

prose_intervention_logic:
The intervention begins by making both sides explicit. First, state the system goal in outcome terms. Then map the local goals and the actual signals around each actor: metrics, incentives, budget pressures, status rewards, review criteria, contracts, and informal expectations. Next, diagnose where local and system success diverge. Finally, redesign the goal architecture: change metrics, adjust incentives, add shared outcomes or countermetrics, clarify tradeoff rules, and monitor whether the redesign actually changes system outcomes.

The central move is not communication; it is structural signal redesign. People should not need to perform heroic interpretation of the system mission every day. Their local goals should make system-supporting behavior practical, visible, and rewarded.

prose_key_components:
- **Local Goal Map** (`local_goal_map`): Identifies the objectives, targets, incentives, constraints, and success definitions used by each role, unit, team, agent, vendor, or subsystem. This component reveals what people are actually optimizing locally. It should capture explicit metrics, informal expectations, budget pressures, review criteria, risk avoidance incentives, and prestige signals, not only official strategy statements.
- **System Goal Model** (`system_goal_model`): States the intended whole-system outcomes, value priorities, constraints, and unacceptable externalities against which local goals should be tested. The model does not need to be mathematically complete, but it must be concrete enough to evaluate whether local success contributes to the whole. It can include mission outcomes, viability thresholds, fairness constraints, service quality, risk limits, and long-term capacity health.
- **Misalignment Diagnosis** (`misalignment_diagnosis`): Compares local goals with system goals to identify where local optimization damages, ignores, delays, or displaces whole-system outcomes. Useful diagnoses distinguish metric conflict, incentive conflict, time-horizon mismatch, cross-unit externality, gaming opportunity, resource competition, and authority-goal mismatch. The aim is to locate the structural cause of incongruence rather than blaming local actors for following the signals they were given.
- **Metric Redesign** (`metric_redesign`): Changes what is measured, weighted, reviewed, and displayed so local evaluation tracks contribution to system outcomes rather than isolated activity. Metric redesign may add shared metrics, paired counter-metrics, leading and lagging indicators, quality thresholds, system-outcome monitors, or metric retirement rules. It should explicitly guard against Goodharting, tunnel vision, and measurement overload.
- **Incentive Alignment** (`incentive_alignment`): Adjusts rewards, penalties, budget flows, recognition, promotion criteria, contracts, or accountability structures so local self-interest supports system goals. Incentives include more than money. They include status, autonomy, access, career progression, risk exposure, workload, political credit, customer feedback, and psychological safety. Alignment should make desired system-supporting behavior locally viable, not heroic.
- **Conflict Resolution Rule** (`conflict_resolution_rule`): Defines how conflicts among local goals, shared metrics, and system-level outcomes are surfaced, adjudicated, escalated, or traded off. Goal congruence does not eliminate all conflict. This component prevents unresolved tensions from being hidden in local workarounds, metric gaming, resource hoarding, or blame transfer. It should specify decision rights and escalation paths when goals collide.
- **System Outcome Monitor** (`system_outcome_monitor`): Tracks whether redesigned goals and incentives actually improve whole-system outcomes and whether new local distortions emerge. Monitoring should include lagging outcomes, leading signals, unintended side effects, distributional impacts, gaming indicators, and cross-unit consequences. The monitor closes the loop so alignment stays adaptive rather than becoming a frozen scorecard.

prose_common_mechanisms:
The following mechanisms can implement the archetype, but none of them is the archetype by itself. They become Goal Congruence Alignment only when they help local success definitions support system success.

- **OKR Alignment Process** (`okr_alignment_process`, planning_and_review_process): Translates system objectives into local objectives and key results while checking whether local key results contribute to the whole. OKRs are an implementation mechanism, not the archetype. They help only when the translation, conflict review, and system-outcome checks are real.
- **Shared Metric Design** (`shared_metric_design`, measurement_design): Assigns a common outcome measure to multiple units whose work jointly determines the result. Shared metrics reduce purely local optimization but can become vague or unfair unless paired with contribution visibility and controllability checks.
- **Balanced Scorecard** (`balanced_scorecard`, measurement_framework): Represents multiple goal dimensions so financial, operational, customer, learning, quality, or risk outcomes are not optimized in isolation. A balanced scorecard is a mechanism for keeping multiple outcomes visible. It does not by itself align incentives, authority, or conflict resolution.
- **Incentive Redesign** (`incentive_redesign`, incentive_mechanism): Changes compensation, recognition, penalties, budget allocation, promotion criteria, contract terms, or status rewards so local effort follows system priorities. Use carefully: incentive redesign can create gaming, inequity, or risk concealment unless monitored with countermetrics and qualitative review.
- **Cross-Functional Goal Setting** (`cross_functional_goal_setting`, coordination_process): Brings interdependent units into a shared goal-setting process so local targets are negotiated against the same system outcome. This mechanism works well when no single function can achieve the outcome alone and local targets otherwise create handoff conflict.
- **Principal–Agent Contracting** (`principal_agent_contracting`, governance_or_contract_mechanism): Uses contracts, service-level agreements, monitoring, and accountability clauses to align delegated agents with a principal or system objective. This is a narrower governance mechanism inside the archetype when the misalignment is a principal-agent problem. It should not collapse the parent archetype into that neighbor.
- **Metric Gaming Review** (`metric_gaming_review`, review_and_audit_mechanism): Checks whether actors are improving metrics by bypassing the intended system outcome or shifting costs elsewhere. Gaming review protects the invariant that measured improvement must remain causally connected to real system improvement.
- **Strategy Deployment / Hoshin Kanri** (`strategy_deployment_hoshin_kanri`, planning_cascade_mechanism): Cascades strategic priorities into coordinated local objectives, reviews catchball feedback, and reconciles bottom-up feasibility with top-down goals. Use as a mechanism when the core challenge is translating a few strategic priorities into operational commitments across levels.
- **System Outcome Dashboard** (`system_outcome_dashboard`, monitoring_artifact): Makes whole-system outcomes and cross-unit effects visible during review, governance, or operational decision cycles. A dashboard is only useful when connected to action rules, conflict handling, and metric interpretation; otherwise it becomes performance theatre.

prose_failure_modes:
Common failure modes include proxy optimization, cascading distortion, diffuse responsibility, incentive backlash, alignment theatre, local expertise suppression, and concealed goal conflict. Proxy optimization occurs when the measure becomes the target. Cascading distortion occurs when a strategic goal loses meaning as it travels through layers. Diffuse responsibility occurs when a shared goal is assigned without contribution visibility. Alignment theatre occurs when the organization creates OKRs or dashboards but leaves the real rewards and decisions unchanged.

The mitigation is to treat alignment as a feedback loop. Redesign the signal, observe behavior, check system outcomes, and revise when the signal begins to distort.

prose_neighbor_distinctions: Goal Congruence Alignment is narrower than Whole-System Alignment, which can redesign many structural relationships beyond goals and incentives. It is downstream of Objective Function Alignment when the system goal itself is ambiguous. It overlaps with Incentive-Compatible Rule Design when formal incentives are the core lever, but it also covers metrics, accountability, goal cascade, and cross-unit conflict. It includes principal-agent cases but is not limited to principal-agent delegation. It differs from Task Interdependence Mapping because the latter maps workflow dependencies; this archetype maps and redesigns success definitions.

prose_cross_domain_examples:
- **software reliability**: Release teams and operations teams share a customer-impact metric and review feature velocity alongside incidents, rollback rate, and support burden.
- **hospital operations**: Discharge throughput goals are paired with readmission, medication reconciliation, and patient comprehension measures.
- **sales organization**: Sales incentives reward retained, high-fit customers rather than bookings that create churn and support overload.
- **public administration**: Case-processing teams are measured on durable resolution and appeal reduction, not only closure count.
- **supply chain**: Procurement success shifts from lowest unit cost to total lifecycle cost, supplier reliability, and operational downtime impact.
- **education**: School performance goals combine learning growth, attendance, well-being, and post-course readiness so test preparation does not crowd out broader learning.

prose_non_examples:
- **A department adopts OKRs because the organization wants better planning.** No local/system conflict is diagnosed and no incentives or conflict rules change.
- **A dashboard lists every team metric in one place.** Visibility is not congruence unless the metrics and reviews are redesigned around the system goal.
- **A manager tells teams to stop acting in silos.** The structural signals that made silo behavior rational are still intact.
- **A team has poor morale because errors are punished.** Psychological Safety Enablement may be needed before goal congruence can reveal real system problems.

prose_tradeoffs:
The archetype trades simplicity against completeness. Simple local goals are actionable, but they can become misleading. Richer goal models protect system value, but they add cognitive and administrative load. Shared metrics promote cooperation, but they can blur accountability. Strong incentives focus attention, but they increase gaming risk. Central alignment protects system outcomes, but too much centralization can suppress local learning and contextual judgment.

The practical design question is not whether to align goals perfectly. Perfect alignment is rarely available. The question is which incongruences are most damaging and which signals can be redesigned without creating worse distortions.

prose_invariants_to_preserve: The system must preserve a real connection between measured success and actual outcome improvement. It must also preserve local usability: goals should be concrete enough for actors to make decisions without constant central interpretation. Alignment should not erase legitimate local constraints, stakeholder needs, or professional judgment. Finally, goal conflicts should be surfaced rather than hidden. Some goals cannot be perfectly harmonized; the archetype requires a way to govern those tradeoffs.

prose_target_outcomes: Successful Goal Congruence Alignment makes local performance and system performance move together. It reduces cross-unit blame, hidden externalities, and metric gaming. It makes strategy operational rather than rhetorical. It helps actors understand how their work contributes to the whole and when a conflict requires escalation. In mature forms, the system can adapt its metrics and incentives as behavior changes, preventing yesterday's alignment mechanism from becoming tomorrow's distorted proxy.

prose_parameter_dimensions:
The main tuning dimensions are the level of alignment, the strength of incentives, the granularity of metrics, and the degree of shared accountability. Alignment can target individuals, teams, units, vendors, or entire portfolios. Incentives can be weak signals such as recognition or strong signals such as compensation, budget, contract terms, or promotion. Metrics can be simple enough for daily action or rich enough to prevent proxy distortion. Shared accountability can encourage cooperation, but it needs contribution visibility so nobody becomes responsible for outcomes they cannot influence.

Other tuning choices include the balance between leading and lagging indicators, the time horizon of evaluation, the frequency of review, the amount of local autonomy preserved, the use of countermetrics, and the threshold for escalating goal conflicts.

prose_variants_and_near_names:
- **Metric Congruence Alignment** (`metric_congruence_alignment`): Aligns local performance metrics with system outcomes so measurement does not reward behavior that undermines the whole. It remains under the parent because Metric congruence still serves the broader aim of making local success support system goals.
- **Incentive Congruence Alignment** (`incentive_congruence_alignment`): Adjusts reward, penalty, accountability, recognition, or resource-allocation signals so local actors gain by supporting system goals. It remains under the parent because The incentive redesign is judged by whether local success becomes congruent with system success.
- **Cross-Unit Goal Congruence Alignment** (`cross_unit_goal_congruence_alignment`): Aligns goals across interdependent units so one unit does not win by making another unit or the whole system worse. It remains under the parent because The core intervention remains mapping local goals, diagnosing conflict, and redesigning local success to support system success.
- **Goal Cascade Alignment** (`goal_cascade_alignment`): Preserves meaning as high-level goals are translated into lower-level objectives, commitments, and review criteria. It remains under the parent because It still applies the local-goal/system-goal comparison and redesign logic of the parent archetype.

Near names include goal alignment, strategic alignment, KPI alignment, OKR alignment, incentive alignment, shared metrics, and balanced scorecard. These should usually collapse into the parent or a recognized variant unless future reconciliation finds a distinct intervention form.

Metric Congruence Alignment

distinctive_feature: The primary lever is measurement design: selecting, weighting, pairing, retiring, or interpreting metrics so they represent system contribution.

distinct_from_parent: The parent includes metrics, incentives, goals, authority, and feedback. This variant focuses on metric structure as the dominant source of incongruence.

still_same_parent_because: Metric congruence still serves the broader aim of making local success support system goals.

source_primes: goal_congruence feedback optimization

use_when: Local teams are hitting their metrics while system outcomes stagnate or decline.

use_when: A single metric has become a proxy for success and is now distorting behavior.

use_when: A high-level objective has been translated into many operational indicators with unclear causal connection to the outcome.

Metric Redesign

role: Replaces or reweights misaligned measures.

Countermetric Guardrail

role: Detects side effects of optimizing the target metric.

System Outcome Monitor

role: Tests whether metric improvement reflects real system improvement.

example_domains:
customer support operations
public-sector service delivery
healthcare quality improvement
software reliability

domain: customer support

example: A team pairs average handle time with first-contact resolution and customer harm review so calls are not rushed at the expense of outcomes.

domain: healthcare

example: A hospital links discharge-speed goals to readmission and patient-safety countermetrics.

failure_modes: Adding more metrics without changing the incentive or review process that determines behavior.

Incentive Congruence Alignment

distinctive_feature: The main lever is not just saying what matters, but changing what pays, protects, recognizes, or burdens local actors.

distinct_from_parent: The parent covers any local/system goal congruence problem. This variant focuses on reward and accountability architecture.

still_same_parent_because: The incentive redesign is judged by whether local success becomes congruent with system success.

use_when: People know the system goal but are rewarded for different local results.

use_when: Budget, promotion, recognition, contract, or workload incentives conflict with stated priorities.

use_when: Actors rationally shift costs, hide risk, or optimize a narrow target because the incentive structure makes that behavior locally viable.

Incentive Alignment

role: Adjusts rewards and penalties.

Misalignment Diagnosis

role: Classifies which incentives conflict.

Externality Register

role: Reveals costs shifted outside the local target.

example_domains:
sales compensation
public procurement
platform governance
healthcare payment design

domain: sales

example: Compensation rewards retained, high-fit customers rather than gross bookings alone.

domain: procurement

example: Vendor incentives include lifecycle reliability and transition support rather than lowest initial cost.

failure_modes: Creating incentives that are easy to game because they over-specify one measurable proxy.

Cross-Unit Goal Congruence Alignment

short_definition: Aligns goals across interdependent units so one unit does not win by making another unit or the whole system worse.

distinctive_feature: The alignment challenge is horizontal and cross-boundary, not only vertical cascade from leadership to teams.

distinct_from_parent: The parent also covers individual, agent, portfolio, and metric alignment. This variant focuses on units with linked outcomes and conflicting local objectives.

use_when: Multiple units own different pieces of a shared outcome.

use_when: Local scorecards create cross-unit conflict, handoff blame, or resource hoarding.

use_when: The system needs integrated performance but each unit is managed as if it were independent.

Local Goal Map

role: Shows each unit’s targets and constraints.

Goal Owner Network

role: Identifies cross-unit accountability relationships.

Conflict Resolution Rule

role: Handles goal conflicts between units.

example_domains:
product and engineering organizations
supply chains
hospitals
public programs

domain: software operations

example: Feature delivery and reliability teams share customer-impact targets so releases are not optimized against stability.

domain: public program

example: Eligibility processing and case support share outcome targets so rapid closures do not increase appeals and rework.

failure_modes: Creating shared accountability so diffuse that nobody can see their controllable contribution.

Goal Cascade Alignment

short_definition: Preserves meaning as high-level goals are translated into lower-level objectives, commitments, and review criteria.

distinctive_feature: The risk is translation loss across levels: each layer receives a plausible but partially wrong version of the goal.

distinct_from_parent: The parent includes horizontal, incentive, metric, and agent alignment. This variant is about vertical translation across organizational layers.

still_same_parent_because: It still applies the local-goal/system-goal comparison and redesign logic of the parent archetype.

source_primes: goal_congruence accountability feedback

use_when: Strategic goals become distorted as they cascade into departmental or individual targets.

use_when: Teams can explain their local goals but cannot show how those goals contribute to system outcomes.

use_when: Different levels interpret the same strategic priority differently.

Goal Cascade Trace

role: Shows goal translation across levels.

System Goal Model

role: Preserves the original outcome intent.

System Outcome Monitor

role: Checks whether cascaded goals deliver the intended outcome.

example_domains:
large enterprises
universities
military planning
public agencies

domain: enterprise strategy

example: A customer-retention strategy is translated into team objectives without turning into a narrow call-volume target.

domain: university administration

example: A student-success goal cascades into advising, curriculum, and financial-aid targets that share retention and learning outcomes.

failure_modes: Cascading goals mechanically while avoiding hard tradeoffs and conflicts between goals.

near_names:
Goal Alignment
Strategic Alignment
KPI Alignment
OKR Alignment
Incentive Alignment
Shared Metrics
Balanced Scorecard


type: archetype

source: generated

name: Goal Valence Decomposition and Separation

batch: Second Iteration/Pilot

aliases:
approach-avoidance decomposition
mixed-valence goal separation
goal polarity decomposition
benefit-barrier separation
approach and avoidance pathway design
ambivalent goal decomposition
motivational polarity separation

Approach-Avoidance Conflict

role: Names the mixed motivational state in which the same goal, option, or transition has both attractive and aversive force.

Decomposition

slug: decomposition

role: Names the structural act of splitting the mixed goal into analyzable sub-pulls, sub-concerns, and sub-interventions.

Decision

slug: decision

Framing

slug: framing

Attention

slug: attention

Prioritization

slug: prioritization

Boundary

slug: boundary

Constraint

slug: constraint

Observability

slug: observability

Scaffolding

slug: scaffolding

Sequencing

slug: sequencing

Reactance

slug: reactance

Consent

slug: consent

components:
Target Goal Unit
Approach Driver Map
Avoidance Driver Map
Valence Separation Boundary
Avoidance Legitimacy Filter
Paired Intervention Paths
Recomposition Decision Rule
Dual-Channel Feedback
Stakeholder-Specific Valence Profiles
Temporal Valence Gradient
Threshold or Reversibility Safeguard

mechanisms:
Approach-Avoidance Elicitation Protocol
Benefit-Barrier Split Matrix
Paired Message Frame
Barrier-to-Support Conversion
Staged Commitment Ladder
Dual-Valence Metric Dashboard
Concern Validity Review
Recomposition Commitment Review

essence_one_line: When one goal both attracts and repels, split the approach pull from the avoidance pull and intervene on each separately.

compression_statement: Goal Valence Decomposition and Separation treats ambivalent inaction, half-hearted adoption, or oscillating commitment as a fused-valence problem. It decomposes the goal into positive approach drivers, negative avoidance drivers, legitimate constraints, imagined threats, and stakeholder-specific valence differences; then it amplifies or clarifies the approach path while reducing, respecting, or redesigning the avoidance path.

core_intuition: People and systems often do not simply want or reject a goal. They want the benefits and avoid the burdens at the same time. If the mixed goal is handled as one object, encouragement can intensify threat and barrier removal can lose sight of the attraction. Splitting the valences lets each side receive the right kind of intervention.

canonical_formula: mixed goal -> approach drivers + avoidance drivers + legitimacy filter + separate interventions + recomposed action path

structural_problem: A goal, option, change, treatment, policy, or action is simultaneously attractive and aversive. The attractive side creates aspiration, value, or opportunity, while the aversive side creates fear, cost, identity threat, effort, uncertainty, obligation, loss, or risk. Because both pulls are fused under one label, actors oscillate, delay, comply superficially, resist covertly, or overcorrect toward one side. Generic persuasion, generic risk reduction, or generic decomposition fails because the system has not separated what should be amplified from what should be mitigated, respected, or redesigned.

trigger_conditions: A goal is endorsed in principle but repeatedly postponed, avoided, or pursued inconsistently.

trigger_conditions: People describe the same option with both strong attraction and strong concern.

trigger_conditions: Persuasive messaging increases interest but also increases anxiety, reactance, or defensive interpretation.

trigger_conditions: Barrier-removal efforts reduce difficulty but fail to preserve the original reason the goal mattered.

trigger_conditions: Stakeholders disagree because each notices a different positive or negative valence of the same goal.

trigger_conditions: A change is framed only as benefit, while unspoken loss, effort, identity threat, or uncertainty drives resistance.

trigger_conditions: A decision cannot be made because benefits and costs are not commensurable until they are separated into clearer categories.

symptoms: Oscillation between enthusiasm and avoidance.

symptoms: Repeated statements like “I know this is good, but …” without a structured account of the “but.”

symptoms: Superficial agreement followed by low uptake, delay, or quiet noncompliance.

symptoms: Single-score evaluations that hide the reason a goal remains blocked.

symptoms: Interventions that either sell harder or remove barriers but do not do both in a coordinated way.

symptoms: Conflict between advocates who emphasize benefits and skeptics who emphasize risks, with little shared map of the goal.

symptoms: A goal is abandoned even though a narrower redesign could preserve its positive pull while addressing the negative pull.

root_tension: The system treats the goal as a unitary object, but the motivational and evaluative structure is not unitary. Attraction and avoidance are coupled in the same target while requiring different evidence, safeguards, supports, sequencing, and communication.

anti_signatures: The goal is simply unclear rather than mixed-valence.

anti_signatures: Actors lack the capability or resources to act, and there is no meaningful approach/avoidance conflict to decompose.

anti_signatures: The main problem is cross-unit goal alignment rather than mixed pull inside a single goal or option.

anti_signatures: The option is unsafe, coercive, or illegitimate; avoidance should not be reduced merely to increase uptake.

anti_signatures: The situation calls for a formal multiobjective optimization or weighting process rather than qualitative valence decomposition.

anti_signatures: The positive and negative aspects are already explicitly separated and independently managed.

structural_intervention: Create an explicit mixed-valence map for the target goal. Separate approach drivers from avoidance drivers, classify each avoidance driver as legitimate constraint, modifiable barrier, uncertainty, identity threat, effort cost, social risk, or misappraisal, and design paired intervention paths that preserve the positive reason for action while reducing or respecting the negative pull.

action_logic: Define the target goal, option, or action narrowly enough that its valence can be assessed.

action_logic: Elicit approach drivers: benefits, values, identity fit, gains, curiosity, status, relief, mastery, belonging, or opportunity.

action_logic: Elicit avoidance drivers separately: loss, fear, uncertainty, effort, conflict, stigma, obligation, risk, distrust, reversibility concern, or resource burden.

action_logic: Prevent premature aggregation; do not collapse mixed valence into one pro/con score before the structure is visible.

action_logic: Classify each avoidance term as a legitimate constraint, a barrier to reduce, a concern to answer, a condition to sequence, or a signal that the goal should be redesigned.

action_logic: Design approach-side interventions that clarify, strengthen, or make salient the positive pull without denying the negative pull.

action_logic: Design avoidance-side interventions that reduce friction, add safeguards, build support, preserve autonomy, or change the goal design where needed.

action_logic: Recompose the action path: decide whether to proceed, stage, redesign, defer, reject, or offer differentiated options.

action_logic: Monitor both valence channels separately after implementation so rising avoidance is not hidden by apparent commitment or rising enthusiasm.

decision_rules: Use this archetype when the same target evokes both “toward” and “away from” signals, and treating it as a single attitude produces confusion or stalemate.

decision_rules: Keep approach and avoidance drivers separate until each has a plausible intervention path.

decision_rules: Do not treat all avoidance as irrational resistance; some avoidance terms are legitimate constraints or safety signals.

decision_rules: Do not treat all approach as sufficient justification; benefits may be real while the goal remains poorly designed or unfairly burdensome.

decision_rules: Use separate metrics for positive pull and negative pull when possible; a single average can hide ambivalence.

decision_rules: Prefer staged or reversible commitment when avoidance is driven by uncertainty, irreversibility, or trust deficits.

decision_rules: Use consent-preserving communication when the intervention affects autonomy, identity, health, or livelihood.

target_invariants: The target goal remains explicitly defined; the archetype does not dissolve into generic motivation work.

target_invariants: Positive and negative valences are not prematurely aggregated or allowed to erase each other.

target_invariants: Legitimate avoidance constraints remain visible and respected.

target_invariants: Approach amplification does not become manipulation, denial, or coercive pressure.

target_invariants: Avoidance reduction does not strip away the goal’s purpose or make uptake the only success metric.

target_invariants: Stakeholder-specific valence differences are preserved when aggregation would hide inequity or risk.

target_invariants: The recomposed plan can be traced back to the separated valence map.

expected_outcomes: Clearer diagnosis of why a desired goal remains blocked despite apparent endorsement.

expected_outcomes: More targeted interventions: benefit clarification for approach pull, support or redesign for avoidance pull.

expected_outcomes: Lower ambivalence, delay, avoidance, or covert resistance when legitimate barriers are addressed.

expected_outcomes: More honest communication because benefits and burdens are both represented.

expected_outcomes: Better redesign decisions when the negative valence reveals real constraints.

expected_outcomes: Higher-quality commitments because actors know what they are moving toward and what has been mitigated.

prose_essence:
Goal Valence Decomposition and Separation is used when one goal both attracts and repels. The intervention separates the positive pull toward the goal from the negative pull away from it, classifies the negative pull, designs paired intervention paths, and then recomposes a decision or staged plan.

In compressed form:

```text
mixed goal -> approach drivers + avoidance drivers + legitimacy filter + paired interventions + recomposed action path
```

prose_when_to_use:
Use it when actors endorse a goal in principle but delay, avoid, oscillate, quietly resist, or comply only superficially. It is especially useful when one side keeps saying “the benefits are obvious” while another side keeps saying “the concerns are real,” and both are partly right.

Do not use it to override legitimate refusal, safety constraints, consent boundaries, or rights-protecting resistance. The valid output may be redesign, staging, deferral, or rejection rather than uptake.

prose_structural_problem: A goal is being treated as one object, but its motivational structure is split. The same target contains benefits, values, aspirations, rewards, or identity fit, while also containing cost, risk, effort, uncertainty, loss, threat, stigma, or distrust. Because the positive and negative valences are fused, teams either sell harder, remove generic barriers, or aggregate everything into one score. Those moves hide the structure that actually determines action.

prose_intervention_logic: First define the target goal narrowly. Then elicit approach drivers separately from avoidance drivers. Hold those two maps apart long enough to understand them. Classify avoidance terms as legitimate constraints, modifiable barriers, uncertainty, identity threat, social risk, misappraisal, or design defect. Design the approach-side intervention and the avoidance-side intervention separately, then recompose the plan into a decision, staged path, redesign, differentiated option, or refusal.

prose_key_components:
- **Target Goal Unit:** the specific goal, action, change, option, or commitment being analyzed.
- **Approach Driver Map:** the reasons the target pulls actors toward it.
- **Avoidance Driver Map:** the reasons the target pushes actors away from it.
- **Valence Separation Boundary:** the rule that prevents premature averaging or collapse.
- **Avoidance Legitimacy Filter:** the classification step that distinguishes real constraints from reducible barriers or distorted appraisals.
- **Paired Intervention Paths:** separate response paths for strengthening the approach side and reducing, respecting, or redesigning the avoidance side.
- **Recomposition Decision Rule:** the rule for turning the separated map back into action.
- **Dual-Channel Feedback:** separate monitoring of approach strength and avoidance strength after intervention.

prose_common_mechanisms:
Common mechanisms include an approach-avoidance elicitation protocol, a benefit-barrier split matrix, paired message frames, barrier-to-support conversion, staged commitment ladders, dual-valence dashboards, concern validity reviews, and recomposition commitment reviews.

These mechanisms should not be confused with the archetype itself. A generic pro/con list is only a weak mechanism unless it preserves valence separation, classifies avoidance, and changes the intervention design.

prose_failure_modes:
Common failure modes include premature aggregation, avoidance invalidation, benefit over-selling, barrier-only redesign, false symmetry between valid and invalid concerns, hidden subgroup harm, and analysis without recomposition.

The most serious misuse is treating the archetype as a technique for overcoming resistance when resistance is actually a valid safety, consent, equity, or legitimacy signal.

prose_neighbor_distinctions: This archetype is distinct from `self_efficacy_scaffolding`, which builds capability belief; `affect_evidence_separation`, which separates feeling from evidence; `risk_aversion_calibration`, which adjusts downside sensitivity; `goal_congruence_alignment`, which aligns goals across actors; `objective_weighting_governance`, which legitimizes weights among already separated objectives; and `modular_decomposition`, which decomposes systems or functions rather than mixed motivational pull.

prose_cross_domain_examples: In education, a student may want the career benefits of an advanced course but avoid it because of fear of failure. In healthcare, a patient may value symptom relief while avoiding treatment because of side effects or autonomy concerns. In organizational change, employees may support the purpose of a new system while avoiding it because of workload, competence threat, or surveillance concerns. In public policy, residents may support safer streets while resisting access or parking losses. In product onboarding, users may want a feature’s value while avoiding setup because of trust or reversibility concerns.

prose_non_examples: A work breakdown structure is not this archetype unless the decomposition is about approach and avoidance valences around a goal. A one-sided persuasion campaign is not this archetype. A generic cost-benefit score is not this archetype unless it preserves the separated valence structure and changes the intervention. A hard safety stop is not a case for avoidance reduction; it may be a case for rejecting the goal.

prose_tradeoffs: This archetype can slow decisions because it legitimizes a deeper diagnostic pass. It can make concerns more visible before it makes action easier. It can also create tension between proponents who want stronger approach messaging and skeptics who want stronger avoidance protection. The benefit is that the resulting plan is less likely to be brittle, manipulative, or blind to real constraints.

prose_invariants_to_preserve: The target goal must stay explicit. Positive and negative valences must not be prematurely averaged. Legitimate constraints must remain visible. Approach amplification must not become coercion or denial. Avoidance reduction must not erase the goal’s purpose. Stakeholder-specific differences must remain visible when aggregation would hide inequity or risk.

prose_target_outcomes: Successful use produces clearer diagnosis of ambivalence, more targeted intervention, lower delay or covert resistance where avoidance is legitimately reducible, more honest communication, better redesign decisions, and higher-quality commitments.

prose_parameter_dimensions:
Important tuning dimensions include valence intensity, balance between approach and avoidance, reversibility of commitment, distance to action, stakeholder-specific valence differences, legitimacy of avoidance, cost of false uptake, cost of false rejection, and whether the right recomposition is proceed, stage, redesign, defer, differentiate, or reject.

The more safety-, consent-, health-, livelihood-, or identity-sensitive the goal is, the more strongly the archetype should protect avoidance signals rather than treating them as obstacles.

prose_variants_and_near_names:
Recognized variants include approach-avoidance decomposition, benefit-barrier separation, stakeholder valence partitioning, temporal valence gradient management, and message valence split. Near names include goal valence split, mixed-valence goal analysis, ambivalence mapping, and motivational polarity mapping.

A generic pro/con analysis should collapse into a mechanism unless it includes the full valence-separation, legitimacy-filtering, paired-intervention, and recomposition structure.

Approach-Avoidance Decomposition

short_definition: A variant focused specifically on splitting a conflicted action into approach and avoidance gradients.

distinctive_feature: Emphasizes the motivational direction of pull rather than benefit/barrier categories alone.

distinct_from_parent: The parent includes broader valence terms such as identity, burden, social risk, and stakeholder-specific appraisals.

still_same_parent_because: It uses the same separation, classification, paired intervention, and recomposition logic.

use_when: The same action is attractive at one level and aversive at another.

use_when: Delay or oscillation is caused by mixed movement toward and away from the same target.

example_domains:
behavior change
education
healthcare adherence

failure_modes: Treating avoidance as irrational resistance; hiding legitimate constraints under approach language.

Benefit-Barrier Separation

short_definition: A practical variant that separates reasons to adopt from barriers to adoption.

distinctive_feature: Uses accessible benefit/barrier language for implementation settings.

distinct_from_parent: Narrower and more operational; may not capture identity threat, social risk, or temporal gradients.

still_same_parent_because: It applies the same mixed-valence separation and paired intervention structure.

use_when: Adoption is desired but barriers remain vague or bundled with benefit messaging.

use_when: Teams need a simple template for uptake diagnosis.

example_domains:
organizational adoption
product onboarding
training design

failure_modes: Reducing the method to a generic checklist without validating which barriers are legitimate.

Stakeholder Valence Partitioning

short_definition: A multi-actor variant that maps positive and negative goal valences separately for each stakeholder group.

distinctive_feature: Partitions valence by stakeholder rather than only by feature of the goal.

distinct_from_parent: Adds cross-stakeholder fairness and legitimacy analysis.

still_same_parent_because: It still decomposes mixed valence and recomposes a redesigned or staged plan.

use_when: A policy or change has uneven benefits and burdens across groups.

use_when: Aggregated support hides subgroup-specific avoidance or risk.

example_domains:
public policy
community planning
organizational change

failure_modes: Using average sentiment to erase a minority group’s legitimate avoidance signal.

Temporal Valence Gradient Management

short_definition: A variant that tracks how approach and avoidance change as commitment becomes closer, larger, or more irreversible.

distinctive_feature: Makes time, proximity, and reversibility central tuning dimensions.

distinct_from_parent: Adds a temporal gradient map rather than only a static valence map.

still_same_parent_because: It separates and addresses approach and avoidance channels around the same target goal.

use_when: A goal is attractive far away but aversive near commitment.

use_when: Avoidance rises as deadlines, exposure, or irreversibility increase.

example_domains:
career choice
health treatment decisions
software migration

failure_modes: Assuming early enthusiasm predicts commitment-stage readiness.

Message Valence Split

short_definition: A communication variant that presents benefits and concerns as separate, acknowledged channels rather than a one-sided persuasion frame.

distinctive_feature: Focuses on communication structure and trust preservation.

distinct_from_parent: Narrower than the parent because it operates mainly through message design.

still_same_parent_because: It uses the same separated approach/avoidance map as input.

use_when: Audiences distrust benefit-only messaging.

use_when: Concerns must be acknowledged without letting the goal lose its positive purpose.

example_domains:
public health communication
change management
product trust messaging

failure_modes: Performative concern acknowledgment with no real mitigation path.

near_names:
Goal Valence Split
Mixed-Valence Goal Analysis
Pro/Con Analysis
Ambivalence Mapping
Barrier Reduction


Graceful Degradation

related_primes: resilience robustness fault_tolerance fail_safe trade_offs resource_management constraint threshold modularity flow coupling prioritization

essence_one_line: Deliberately reduce, simplify, or suspend lower-priority capabilities under stress so essential function survives instead of the whole system collapsing.

prose_failure_modes:
Common failure modes include:

- **Silent degradation** — The system provides reduced service without making that reduction visible.
- **Core function misclassification** — The wrong functions are protected while truly essential functions degrade.
- **Degraded mode becomes permanent** — Temporary reduction becomes the normal operating state.
- **Cascading dependency breakage** — A supposedly nonessential feature turns out to be required by core service.
- **Unfair degradation** — Some users, regions, teams, or classes bear disproportionate sacrifice.
- **Quality floor collapse** — The system remains technically available but below useful or safe quality.
- **Recovery neglect** — The system enters degraded mode but lacks a disciplined path back to full service.
- **Deceptive availability** — Metrics show uptime while meaningful service has failed.
- **Fallback path rot** — Rarely used degraded modes fail when needed because they were not tested.
- **Over-degradation** — The system sacrifices more than necessary.
- **Under-degradation** — The system preserves too much and still collapses.

These failure modes should be treated as part of the archetype's design space.

prose_tradeoffs:
Graceful Degradation accepts reduced service in order to avoid total failure.

Typical tradeoffs include:

- **Functionality is reduced** because some capabilities are disabled or delayed.
- **Quality or fidelity declines** because outputs may be simpler, lower resolution, less personalized, or less complete.
- **Service may slow down** because scarce capacity is reallocated.
- **Outputs may be incomplete** because nonessential steps are skipped.
- **User experience becomes uneven** because different users or classes may receive different service levels.
- **Fairness tensions increase** because priorities become visible.
- **Design complexity rises** because degraded modes must be designed, tested, and communicated.
- **Degraded mode may become normalized** if the system never restores full function.

The archetype is therefore not merely a resilience improvement. It is an explicit choice about what to preserve and what to sacrifice.

prose_invariants_to_preserve:
Graceful Degradation should preserve explicit invariants:

- **Core function remains available** — The system continues to do what matters most.
- **Degraded mode is explicit** — Users, operators, or dependent systems should not be misled.
- **Safety and integrity are not sacrificed** — Reduced service should not corrupt state, endanger users, or violate critical constraints.
- **Recovery remains possible** — The system should be able to return to full service.
- **Nonessential sacrifices do not break essential dependencies** — Disabled features should not accidentally disable core function.
- **Critical state remains consistent** — Partial operation should not create contradictions or irreversible damage.
- **Quality floor is maintained** — Degradation should remain above a defined minimum acceptable level.

If these invariants cannot be preserved, full shutdown or fail-safe behavior may be preferable.

Partial Service Preservation

short_definition: Maintain essential functions while reducing or disabling less critical functions under stress.

distinctive_feature: The distinctive feature is explicit preservation of essential functions.

distinct_from_parent: Graceful degradation is broad controlled degradation; this variant centers essential-function preservation.

still_same_parent_because: It remains graceful degradation because the system continues in reduced mode instead of failing completely.

use_when: Some functions are more critical than others.

example_domains:
software
healthcare
infrastructure
public services

failure_modes: Users are not informed about degraded mode.


Gradient Flattening

batch: First Iteration/Batch 05/Wave 2

Gradient Equalization

notes: Useful near name, but it can imply complete equality; the archetype allows partial flattening toward a target band.

Disparity Reduction

notes: Common social-policy near name when the harmful gradient is unequal access, risk, or burden.

Pressure Equalization

notes: Captured as a recognized variant and common mechanism family, not a separate draft in this pass.

Gradient Smoothing

notes: Emphasizes reducing abrupt local variation; should remain a near name unless smoothing develops distinct structure.

Gap Compression

notes: Compact name for reducing harmful spread, but too informal to use as canonical title.

related_primes: flow stratification

Gradient

slug: gradient

role: Defines the uneven field whose slope, spread, or intensity difference is being reduced.

Flow

slug: flow

role: Explains why steep differences can drive movement of people, resources, risk, workload, pressure, attention, or information.

Stratification

slug: stratification

role: Appears when gradients are measured across layers, tiers, regions, bands, or population strata.

components:
Gradient Variable
Gradient Map
Harm or Pressure Model
Flattening Target
Equalization Rule
Transfer or Buffer Path
Useful Difference Guardrail
Monitoring Feedback Loop
Floor or Ceiling Constraint
Redistribution Policy
Access Floor
Transition Cadence
Appeal or Exception Path

mechanisms:
Pressure Equalization
Progressive Redistribution
Subsidy or Equalization Fund
Access Equalization Policy
Load Equalization
Banded Floor and Ceiling Rule
Price or Friction Compression
Service Floor Upgrade
Buffer Pool or Reserve
Gradient Dashboard

essence_one_line: Reduce harmful disparities, pressure differences, or intensity gradients that drive instability, exploitation, unfairness, or destructive flow.

compression_statement: When a steep difference in pressure, access, risk, resources, incentives, attention, or burden causes harmful movement, instability, or inequity, reduce the slope or spread through redistribution, buffering, equalization, ceilings, floors, access expansion, or constraint while preserving useful differentiation.

core_intuition: A gradient is not only a measurement; it is often a force. When one side of a system is much more pressured, resourced, risky, attractive, costly, neglected, or accessible than another, movement and stress follow the difference. Gradient flattening changes that difference so the system no longer has to absorb the harmful flow or inequity it creates.

canonical_formula: gradient flattening = harmful gradient variable + field boundary + harm model + target slope/spread + equalization rule + transfer/buffer path + useful-difference guardrail + feedback monitoring

structural_problem: A steep difference across a spatial, temporal, social, economic, technical, or operational field drives harmful flow, pressure, instability, exploitation, or unfairness; the problem persists because local fixes do not change the underlying gradient.

condition: Steep harmful difference

explanation: A measurable or diagnosable gap in pressure, access, burden, risk, reward, attention, or resource level is large enough to generate negative effects.

condition: Gradient-driven movement or stress

explanation: People, materials, money, requests, risk, failures, or attention move because the gradient makes one direction too attractive, too necessary, or too pressured.

condition: Uniform treatment fails

explanation: Treating all regions equally leaves the high-pressure or low-access side unchanged and allows the gap to regenerate.

condition: Local repair keeps migrating

explanation: Interventions at individual points help temporarily, but the steep difference reappears elsewhere or drives new overloads.

condition: Disparity compounds over time

explanation: The low side of the gradient becomes less capable of recovery while the high side accumulates advantage, risk, load, or extraction power.

symptom: Pressure-driven spillover

explanation: Flow escapes, overloads, migrates, or cascades from the high-pressure region because the difference is too steep.

symptom: Persistent inequitable gap

explanation: Access, service, risk, or burden remains sharply uneven despite general improvements.

symptom: Arbitrage or extraction

explanation: Actors exploit a value or cost difference in ways that drain one region or overload another.

symptom: Overloaded high side and neglected low side

explanation: One part of the field becomes saturated while another lacks minimum support or capability.

symptom: Repeated compensatory fixes

explanation: Teams keep applying relief after the fact because the underlying gradient remains intact.

root_tension: The system needs some differentiation to function, but a particular difference has become too steep, too unfair, or too destabilizing. The design problem is to reduce harmful slope without erasing useful signal, specialization, scarcity information, or choice.

condition: The gradient is useful and not harmful

explanation: Some gradients guide attention, incentives, learning progression, or safe flow; flattening them may remove needed signal.

condition: The issue is only allocation along a gradient

explanation: If the difference is used to decide where to act but is not changed by the intervention, the better parent is gradient_guided_intervention.

condition: The issue is only distributing requests among equal nodes

explanation: That is closer to load_balancing unless the intervention explicitly reduces a harmful pressure or access gradient.

condition: The target is total uniformity by ideology rather than causal harm

explanation: Gradient flattening requires a harm model and useful-difference guardrail, not a blanket preference for sameness.

condition: The problem is a single hard bottleneck

explanation: A bottleneck may create a queue, but bottleneck identification and relief is usually the cleaner archetype when one constraint limits the whole system.

structural_intervention: Define the harmful gradient, establish a target slope or acceptable spread, and alter the system through redistribution, buffering, floor/ceiling rules, equalization mechanisms, access expansion, pressure release, or constraint so the harmful difference shrinks while useful differentiation is preserved.

step: Name the gradient variable

logic: State what difference matters and whether it is spatial, temporal, social, technical, operational, or economic.

step: Map the field and boundary

logic: Identify high and low regions, excluded regions, steep local changes, and the boundary within which intervention will be evaluated.

step: Build the harm model

logic: Explain why steepness causes instability, exploitation, overload, unfairness, or destructive flow.

step: Set the flattening target

logic: Choose a target spread, ratio, floor, ceiling, slope, or tolerance band rather than assuming zero difference is best.

step: Choose the flattening route

logic: Raise the low side, lower or cap the high side, redistribute across the field, buffer pressure, slow gradient-driven flow, or combine methods.

step: Protect useful differences

logic: Identify gradients that should remain because they reflect valid risk, need, expertise, cost, scarcity, motivation, or safety margins.

step: Monitor and revise

logic: Check whether the gradient shrinks, whether pressure migrates, whether gaming appears, and whether new inequities are created.

rule: Flatten only gradients with a causal harm model

explanation: A difference alone is not enough; the difference must be driving instability, unfairness, exploitation, overload, or destructive flow.

rule: Prefer raising floors when the low side is below a minimum viable threshold

explanation: Equity and resilience variants often need baseline access or capability, not merely reduction of high-end advantage.

rule: Use ceilings or caps when the high side generates danger or extraction

explanation: A runaway pressure, reward, price, or demand gradient may require upper limits or friction to prevent harm.

rule: Use buffers when immediate equalization would shock the system

explanation: Reserve pools, relief valves, and transitional capacity can flatten experienced pressure while structural correction catches up.

rule: Stop flattening when useful signal is lost

explanation: The useful-difference guardrail should trigger review when flattening suppresses needed incentives, expertise, triage signal, or differentiation.

invariant: Causal gradient clarity

must_preserve: The draft must keep clear which gradient is harmful and why; otherwise the intervention becomes generic balancing.

invariant: Useful differentiation

must_preserve: Differences that support safety, valid prioritization, specialization, learning, or meaningful choice should not be erased accidentally.

invariant: Minimum viability on the low side

must_preserve: Where the gradient involves access, capacity, or protection, the lower side must retain or reach a viable floor.

invariant: No exported pressure

must_preserve: Flattening inside one boundary should not simply push risk, burden, or overload outside the measured field.

invariant: Feedback visibility

must_preserve: Actors must be able to see whether the gradient is shrinking, steepening elsewhere, or creating new failure modes.

outcome: Reduced harmful flow or pressure

indicator: Spillover, panic movement, overload, migration pressure, arbitrage, or cascading stress decreases.

outcome: Greater stability

indicator: The system operates within a safer range because extreme differences no longer drive destabilizing movement.

outcome: Improved fairness or access

indicator: Low-access or high-burden regions move closer to acceptable floors or target ratios.

outcome: Lower compensatory repair load

indicator: Teams spend less effort repeatedly treating symptoms created by the same steep gradient.

outcome: More governable variation

indicator: Residual differences are explainable, bounded, monitored, and connected to legitimate purposes.

prose_essence:
Gradient flattening reduces a harmful difference across a field. The difference might be pressure, access, risk, cost, workload, funding, attention, reward, exposure, or opportunity. The key is that the steepness itself is doing causal work: it drives movement, overload, exploitation, inequity, instability, or repeated failure.

The archetype does not say every difference is bad. Many systems need gradients to guide action, preserve safety, reward effort, indicate risk, or support specialization. Gradient flattening is used when a particular gradient has become too steep for the system to remain stable, fair, safe, or governable.

prose_when_to_use:
Use gradient flattening when a steep high-low difference creates harm that local fixes cannot solve. A city might have central neighborhoods with abundant clinics and remote areas with almost none. A workflow might have one team under extreme pressure while another has unused slack. A market might have a price or friction difference that causes arbitrage and drains essential goods. An energy system might have dangerous peak demand concentrated in a narrow window.

This archetype is appropriate when the design goal is to reduce the underlying difference, not merely to observe it or target action along it. A risk heat map that sends attention to dangerous areas is gradient-guided intervention. A program that lowers the risk gap by changing access, protection, exposure, or capacity is gradient flattening.

prose_structural_problem:
The structural problem is a steep gradient that acts like a force. The high-pressure, high-reward, high-risk, low-access, or high-burden side creates movement and stress. The low-capacity or low-access side may fall further behind. The system then spends effort reacting to symptoms: spillovers, queues, migration, emergency relief, repeated exceptions, resentment, extraction, or cascading overload.

A flat response often fails because the problem is not uniform. Treating every region the same can preserve the original difference. Sometimes it worsens it, because the low side lacks the capacity to benefit equally from a nominally equal intervention.

prose_intervention_logic:
The intervention begins by naming the gradient variable and mapping the field. Designers then explain why the steep difference is harmful, set a target slope or acceptable spread, and choose a flattening route. The low side may be raised through support, access expansion, or service floors. The high side may be capped or regulated when it creates danger or extraction. Pressure may be buffered while structural changes take effect. Incentive differences may be compressed when they drive harmful behavior.

Good gradient flattening includes a useful-difference guardrail. The goal is not to erase all variation. The goal is to reduce harmful steepness while preserving valid signals, specializations, incentives, safety margins, and local adaptations.

prose_key_components:
- **Gradient Variable (`gradient_variable`)**: identifies what difference is being flattened. It may be pressure, access, workload, risk, funding, price, burden, exposure, attention, or another variable whose spread matters.
- **Gradient Map (`gradient_map`)**: shows where the gradient is steep and how the high and low regions relate. It can be a literal map, dashboard, distribution, heat map, ordered set of cases, or qualitative model.
- **Harm or Pressure Model (`harm_or_pressure_model`)**: explains why the gradient causes harm. Without this component, flattening can become vague equalization rather than a causal intervention.
- **Flattening Target (`flattening_target`)**: defines how flat is flat enough. This may be a floor, ceiling, ratio, tolerance band, target slope, maximum spread, or qualitative range.
- **Equalization Rule (`equalization_rule`)**: specifies how the difference will shrink. It says whether to raise the low side, cap the high side, redistribute across the field, buffer pressure, or combine methods.
- **Transfer or Buffer Path (`transfer_or_buffer_path`)**: supplies the practical machinery for moving resources, absorbing pressure, releasing overload, subsidizing access, or changing friction.
- **Useful Difference Guardrail (`useful_difference_guardrail`)**: protects differences that should remain because they carry legitimate information or preserve necessary function.
- **Monitoring Feedback Loop (`monitoring_feedback_loop`)**: checks whether the gradient actually shrinks, whether pressure migrates elsewhere, and whether new harms appear.

Optional components include floor or ceiling constraints, redistribution policies, access floors, transition cadences, and appeal or exception paths. These optional pieces become important when flattening affects rights, public services, safety, incentives, or politically sensitive differences.

prose_common_mechanisms:
Mechanisms implement the archetype; they are not the archetype itself. **Pressure equalization** uses regulators, valves, reserve capacity, bypasses, or release paths to reduce dangerous pressure differences. **Progressive redistribution** and **equalization funds** move support toward regions with lower capacity or higher burden. **Access equalization policies** remove barriers, add minimum service guarantees, or extend reach to underserved areas.

In operational settings, **load equalization** may compress workload or demand gradients, but it should not be confused with ordinary load balancing unless the objective is reducing harmful steepness. **Banded floor and ceiling rules** keep variation within safe or fair ranges. **Price or friction compression** reduces incentive gradients that drive arbitrage, avoidance, panic movement, or extraction. **Gradient dashboards** make steepness visible, but they must be paired with action machinery to count as gradient flattening.

prose_failure_modes:
Common failure modes include **over-flattening**, where useful gradients are erased; **cosmetic flattening**, where metrics look better but lived differences persist; **gradient migration**, where pressure moves outside the measured field; and **buffer dependency**, where temporary relief replaces structural equalization.

Other risks include gaming, threshold clustering, legitimacy backlash, and perverse equalization. Perverse equalization happens when actors reduce the high side destructively rather than raising the low side or reducing harm. Mitigations include target bands, useful-difference guardrails, multiple indicators, affected-group feedback, anti-gaming checks, and explicit review paths.

prose_neighbor_distinctions:
**Gradient-Guided Intervention** uses a gradient to decide where action should go. **Gradient Flattening** changes the harmful gradient itself. This distinction is the main boundary for the second-wave draft.

**Load Balancing** distributes current demand across capacity nodes; gradient flattening reduces a harmful spread in pressure, access, resources, or incentives. **Load Leveling / Demand Smoothing** smooths demand over time; temporal peak flattening can be a variant of gradient flattening only when the causal object is harmful temporal steepness. **Constraint Envelope Adjustment** uses floors, ceilings, or bands, but gradient flattening is the broader slope-reduction objective.

**Equilibrium Restoration** aims for stability or balance. Gradient flattening may support equilibrium, but it specifically reduces a harmful high-low difference across a field. **Externality Internalization** assigns hidden costs to responsible actors. It can flatten a cost gradient, but its central logic is responsibility for external harms. **Stratified Treatment** applies different policies by stratum; it only becomes gradient flattening when those policies are designed to reduce harmful spread.

prose_cross_domain_examples:
In physical infrastructure, regulators and storage can reduce dangerous water-pressure gradients across a network. In education policy, equalization funding can raise baseline resources for districts with a low tax base and high need. In public health, mobile clinics and transport vouchers can reduce an access gradient between central and remote communities.

In energy systems, storage and demand response can flatten a steep evening load peak. In market governance, price or fee adjustments can reduce an incentive gradient that drains essential inventory from one region. In workforce operations, a reserve staffing pool can reduce dangerous workload differences across units while preserving specialized roles.

prose_non_examples: A risk dashboard that merely ranks regions is not gradient flattening; it is measurement or gradient-guided intervention. A server load balancer is usually not gradient flattening unless the design goal is reducing a harmful structural pressure gradient rather than assigning requests among similar nodes. A strict equality rule that ignores legitimate differences is not a good use of this archetype. A one-time emergency transfer without a gradient target or monitoring loop is aid, not governed gradient flattening. A service-tier policy that intentionally preserves differences is stratified treatment unless it is designed to reduce harmful spread.

prose_tradeoffs:
The central tradeoff is stability versus signal. Flattening can make a system safer and fairer, but over-flattening can remove information about risk, scarcity, priority, effort, or local context. A second tradeoff is immediate relief versus structural correction: buffers help quickly, but they can become permanent substitutes for addressing the source of steepness.

There is also an equity-autonomy tradeoff. Equalization rules can raise floors, but they may constrain local discretion. Incentive compression can reduce exploitation, but it can also weaken supply, motivation, or innovation. Boundary choices make action tractable, but narrow boundaries can export pressure to places that are not being measured.

prose_invariants_to_preserve:
The most important invariant is causal clarity: the draft must keep stating which gradient is harmful and why. Another invariant is useful differentiation. Flattening should not erase valid risk signals, skill differences, local context, learning progression, or safety margins.

Where the gradient involves people or essential services, the low side must preserve or reach a minimum viable floor. Where the gradient involves pressure or risk, flattening must not simply export harm outside the measured boundary. In all cases, feedback visibility must remain intact so that actors can see whether the gradient is shrinking, migrating, or being hidden by a metric.

prose_target_outcomes:
A successful gradient-flattening intervention reduces the harmful spread that was driving instability. Spillovers, overloads, extraction, extreme queues, migration pressure, or inequitable access gaps should decrease. The system should become more stable because extreme differences no longer act as a destabilizing force.

In equity cases, the low-access or high-burden side should move closer to a viable floor or target band. In operational cases, the system should spend less effort on repeated compensatory repair. Residual differences should be explainable, bounded, monitored, and tied to legitimate purposes.

prose_parameter_dimensions:
Important tuning dimensions include the chosen gradient variable, the field boundary, the measurement resolution, the target slope or spread, the choice of raising floors versus capping extremes, the speed of transition, and the strictness of useful-difference guardrails.

Other tuning questions matter in practice. Should flattening be temporary or permanent? Should it be automatic when a threshold is crossed, or reviewed by humans? Should the system use one global target or different bands by region? How will it detect exported pressure? How much residual difference should remain to preserve incentives, safety signals, or specialized capacity?

prose_variants_and_near_names:
Recognized variants include **Pressure Equalization**, **Access Equalization**, **Incentive Gradient Compression**, and **Temporal Peak Flattening**. These variants name recurring ways the parent archetype appears, but they remain under the parent unless they develop distinct components and failure modes.

Near names include gradient equalization, disparity reduction, gradient smoothing, gap compression, and pressure equalization. Pressure equalization is especially important because the roadmap flagged it as likely to collapse into Gradient Flattening, load balancing, or equilibrium restoration rather than becoming its own draft.

raw_bundle_path: solution_archetypes/_Batches/First Iteration/Batch 05/Wave 2/gradient_flattening_solution_archetype_output_bundle.zip

Pressure Equalization

short_definition: A physical, operational, or organizational version of gradient flattening that reduces dangerous pressure differences.

distinctive_feature: The gradient is experienced as pressure that drives movement or failure unless released or equalized.

distinct_from_parent: The parent covers any harmful gradient; this variant is pressure-centered and often uses buffers, valves, reserves, or release paths.

still_same_parent_because: It remains a slope-reduction intervention rather than a separate archetype when the causal logic is simply pressure difference reduction.

Gradient

notes: Retained as the sole source prime because it is explicitly present in the Batch 005 roadmap and is central to this archetype.

use_when: A steep pressure, demand, stress, temperature, voltage, workload, or urgency gradient drives unsafe flow or overload.

use_when: The main intervention is to release, buffer, bypass, or regulate pressure until the difference falls within a safe range.

Gradient Variable

role: Specifies the difference being flattened, such as pressure, access, risk, price, attention, workload, funding, exposure, or opportunity.

Flattening Target

role: Defines the desired slope, spread, ratio, floor, ceiling, or tolerance band after intervention.

Transfer or Buffer Path

role: Provides the practical path through which resources, pressure, access, cost, demand, attention, or risk are redistributed, absorbed, subsidized, or released.

Monitoring Feedback Loop

role: Tracks whether the gradient is actually shrinking, whether pressure moves elsewhere, and whether new harms appear.

Pressure Equalization

role: Reduces dangerous pressure differences through valves, vents, regulators, reserves, bypasses, or controlled release paths.

Buffer Pool or Reserve

role: Absorbs surges or deficits while longer-term structural flattening takes effect.

Banded Floor and Ceiling Rule

role: Uses allowed ranges, minimums, maximums, or ratios to keep variation from becoming destabilizing or unfair.

domain: industrial safety

example: A pressure relief system vents excess pressure before a vessel crosses a dangerous gradient.

domain: operations

example: A shared staffing reserve relieves units with sharply higher workload pressure.

failure_modes: Equalizing only the visible pressure can hide the deeper source of generation.

failure_modes: Release paths can become new bottlenecks or externalize harm.

Access Equalization

short_definition: A fairness-centered variant that reduces harmful differences in access to services, opportunities, protection, or resources.

distinctive_feature: The low side of the gradient is raised through minimum service floors, outreach, subsidies, barrier removal, or rights guarantees.

distinct_from_parent: The parent also handles pressure, risk, and operational gradients; this variant centers access and equity.

still_same_parent_because: The structural move is still gradient reduction across a field, using access as the flattened variable.

use_when: A population or region faces sharply uneven access that compounds disadvantage or risk.

use_when: The goal is not merely targeted allocation but reduction of the access gap itself.

Access Floor

role: Guarantees a minimum level of access, service, safety, capability, or protection to the low side of an access gradient.

Equalization Rule

role: Specifies how the high-low difference will be reduced, such as by raising the low side, lowering the high side, compressing both toward a band, or slowing the gradient-driven flow.

Appeal or Exception Path

role: Allows review when the flattening rule creates unfairness, misses local context, or suppresses needed differentiation.

Access Equalization Policy

role: Reduces differences in access by standardizing minimum service, expanding reach, removing discriminatory barriers, or providing targeted support.

Service Floor Upgrade

role: Raises baseline service in low-access or high-need regions so the gap narrows without necessarily reducing service quality elsewhere.

Subsidy or Equalization Fund

role: Creates a shared pool that raises the low side of an access, capacity, or service gradient without requiring each local actor to self-fund the correction.

domain: education

example: A funding formula raises baseline resources for schools far below the system median.

example: Mobile clinics and transport vouchers reduce the access gap between central and remote patients.

failure_modes: Measurement can misclassify need or reinforce biased categories.

failure_modes: A service floor can become the ceiling if excellence is politically reframed as unnecessary.

Incentive Gradient Compression

short_definition: Reduce a cost, reward, or friction gradient that drives arbitrage, panic movement, extraction, hoarding, or avoidance.

distinctive_feature: The gradient is behavioral or economic; flattening changes the payoff landscape.

distinct_from_parent: This variant focuses on actor incentives, while the parent also covers physical pressure, access, risk, and capacity gradients.

still_same_parent_because: The causal logic remains reducing a harmful gradient to reduce harmful flow.

use_when: Actors move toward one side of a value or cost differential in a way that destabilizes the system.

use_when: The desired intervention is to reduce the incentive difference rather than punish movement after it occurs.

Harm or Pressure Model

role: Explains why the steep difference is harmful: it may drive instability, exploitation, congestion, depletion, inequitable burden, migration pressure, arbitrage, or cascading failure.

Useful Difference Guardrail

role: Protects differences that should not be flattened because they carry valid information, preserve incentives, reflect legitimate specialization, or sustain safety margins.

Price or Friction Compression

role: Reduces incentive gradients that drive arbitrage, extraction, panic movement, or avoidance behavior.

domain: markets

example: A tariff or fee adjustment reduces a sudden arbitrage gradient that drains essential goods from one region.

failure_modes: Flattening incentives too aggressively can remove useful signals and create shortages.

failure_modes: Actors may seek new margins at the boundary of the rule.

Temporal Peak Flattening

short_definition: Reduce steep temporal differences such as peaks, bursts, rushes, or lulls that overload a system.

distinctive_feature: The field is temporal; flattening changes the time profile of pressure or demand.

distinct_from_parent: The parent is broader; this variant should stay narrow and avoid duplicating load_leveling_or_demand_smoothing unless the gradient-specific causal story is clear.

still_same_parent_because: It remains a gradient-flattening move when the causal object is a harmful temporal steepness.

Flow

notes: Used as a related prime because Batch 005 includes flow and this archetype often reduces harmful flow caused by steep gradients.

use_when: The harmful gradient is distributed across time rather than space or population.

use_when: The goal is to reduce peaks or fill troughs without simply redrafting load_leveling_or_demand_smoothing.

Gradient Map

role: Represents where the gradient is steep, where the high and low regions are, and how the difference changes over the chosen field.

Transition Cadence

role: Controls how quickly flattening occurs so the system can adapt without shock, gaming, or collapse of useful capacity.

Load Equalization

role: Compresses a workload, traffic, or demand gradient by moving work, adding support, smoothing peaks, or temporarily protecting overloaded regions.

domain: energy

example: Demand response programs reduce a dangerous evening peak rather than expanding capacity for a short spike.

failure_modes: Can collapse into ordinary demand smoothing if the gradient logic is not explicit.

near_names:
Gradient Equalization
Disparity Reduction
Pressure Equalization
Load Equalization
Gradient Smoothing
Access Flooring