Preventive Maintenance Cadence

batch: First Iteration/Batch 19

Scheduled Upkeep

notes: Plain-language label for recurring upkeep before deterioration becomes failure.

Preventive Maintenance

notes: Common phrase for the action family; this draft emphasizes the cadence, governance, and escalation structure.

Planned Maintenance

notes: Often used in operations; may be broader than deterioration prevention if it includes upgrades or ordinary work planning.

Maintenance Scheduling

notes: Useful retrieval phrase but too mechanism-like unless connected to degradation prevention, scope, thresholds, and ownership.

Routine Maintenance

notes: Routine work is only this archetype when it intentionally prevents gradual deterioration and has a response path for missed or failed upkeep.

source_primes: scheduling resilience

Scheduling

slug: scheduling

role: The archetype turns upkeep into a governed recurring pattern rather than a reaction to crisis.

Resilience

role: Preventive upkeep preserves recoverability and reduces the probability that small degradation becomes catastrophic failure.

Periodicity

slug: periodicity

role: Many cadences recur at regular intervals, cycles, seasons, or review rhythms.

Half-Life

role: Decay-rate estimates can inform how often maintenance, review, or refresh should occur.

Threshold

slug: threshold

role: Cadences require triggers for escalation when ordinary maintenance is too late, missed, or insufficient.

Feedback

role: Inspection results and post-maintenance verification feed back into cadence adjustment.

Resource Management

role: Preventive maintenance requires reserved time, budget, parts, attention, and authority before crisis consumes them.

Accountability

slug: accountability

role: Someone must own the cadence, verify completion, and escalate missed or inadequate maintenance.

Homeostasis

slug: homeostasis

role: Maintenance keeps critical system condition variables within tolerable ranges rather than letting them drift until failure.

Fault Tolerance

role: Upkeep preserves safety margins and reduces the load placed on redundancy or emergency fallback systems.

Observability

slug: observability

role: Condition evidence helps tune the cadence and verify that maintenance actions actually preserve the system.

Opportunity Cost

role: Deferred upkeep creates future costs through emergency repair, lost trust, downtime, and reduced adaptability.

Constraint

slug: constraint

role: The cadence constrains how long upkeep can be deferred and how much deterioration can accumulate before action.

Adaptive Capacity

role: A well-tuned cadence preserves the capacity to adjust, renew, and improve rather than spending all capacity on failure response.

components:
Deterioration Model
Maintenance Interval
Inspection Cadence
Service Scope
Repair Threshold
Maintenance Owner
Maintenance Capacity Budget
Missed Maintenance Escalation
Maintenance Record
Condition Trigger
Maintenance Window
Post-Maintenance Verification

mechanisms:
Preventive Inspection Schedule
Scheduled Service Window
Refactoring Cadence
Infrastructure Upkeep Cycle
Policy Review Cycle
Knowledge-Base Cleanup Rotation
Health Checkup Schedule
Relationship Maintenance Ritual
Maintenance Backlog Review

essence_one_line: Schedule small, recurring upkeep actions before accumulated deterioration forces large repair, crisis response, or failure.

compression_statement: When a system predictably or observably degrades with time, use, neglect, environmental exposure, or accumulated shortcuts, define a maintenance cadence with scope, owner, capacity, verification, and escalation so preventive work happens before breakdown.

core_intuition: The cheapest repair is often the one performed before the system demands attention. Preventive Maintenance Cadence converts invisible future failure into visible recurring commitments: small service now, fewer emergencies later.

canonical_formula: expected deterioration + maintenance interval + defined service scope + accountable owner + reserved capacity + escalation for missed upkeep => preserved function before failure

structural_problem: A system degrades through use, time, drift, deferred cleanup, environmental exposure, changing context, or repeated small exceptions. Because the decline is gradual, actors postpone upkeep until failure, crisis, unreliability, safety risk, or loss of trust makes repair more expensive and disruptive.

description: There is enough knowledge of decay rate, use intensity, condition signals, or historical failure patterns to plan upkeep before breakdown.

description: Emergency repair, outage, replacement, lost trust, safety risk, or institutional damage would be more costly than recurring preventive work.

description: Visible demand repeatedly consumes the same capacity needed for routine service, cleanup, review, or repair.

description: There is a practical set of recurring actions that can preserve function, restore condition, or slow deterioration.

description: Skipped maintenance does not merely delay a task; it increases future failure probability, repair cost, operational burden, or loss of adaptability.

symptom: Repairs are mostly emergency-driven

interpretation: The system waits for breakdown to create urgency instead of reserving capacity for preventive upkeep.

symptom: Known cleanup is repeatedly deferred

interpretation: Delivery, production, or crisis work is consuming the time needed to preserve the system that supports it.

symptom: Minor defects recur and slowly become normal

interpretation: Small deterioration signals are being normalized rather than triggering a regular service response.

symptom: Maintenance tasks exist but are vague or symbolic

interpretation: The cadence lacks explicit scope, verification, owner, or escalation.

symptom: The same component fails after missed service intervals

interpretation: The maintenance interval or missed-maintenance escalation is absent, too weak, or ignored.

symptom: Backlogs of upkeep become permanent

interpretation: Maintenance is recorded as need but not protected as work with authority and capacity.

description: Clarify which asset, capability, relationship, record system, process, or institution needs recurring upkeep.

description: Identify how the system degrades, how quickly, what signs appear, what failure costs, and what response lead time is needed.

description: Set the cadence by time, usage, condition, risk level, season, review cycle, or a hybrid of these.

description: Specify what each maintenance event includes and what evidence counts as completion.

description: Assign responsibility and protect budget, time, tools, authority, and access so the cadence can actually happen.

description: Record work performed, condition observed, exceptions, deferred items, and verification results.

description: Treat skipped maintenance, repeated findings, or failed verification as risk signals requiring action beyond ordinary scheduling.

description: Adjust interval, scope, or priority as deterioration rate, use intensity, risk, resources, or context changes.

prose_essence:
Preventive Maintenance Cadence is the pattern of protecting a system through recurring upkeep before failure makes upkeep unavoidable. It applies when deterioration is predictable, inspectable, or costly enough that small planned work is better than large emergency repair.

The archetype is not simply “having a schedule.” A useful cadence names what is being preserved, why it deteriorates, how often upkeep should happen, what the service includes, who owns it, what capacity is reserved, how completion is verified, and what happens when maintenance is missed or insufficient.

prose_when_to_use:
Use this archetype when a system degrades through time, use, environmental exposure, stale knowledge, deferred cleanup, unresolved friction, or accumulated shortcuts. It is especially valuable when urgent visible work repeatedly crowds out quiet preservation work.

It fits physical infrastructure, software platforms, knowledge bases, governance systems, teams, relationships, and personal practices. The common structure is that small maintenance now prevents larger future loss.

prose_structural_problem:
Gradual deterioration is easy to ignore because each small loss looks tolerable. A road cracks a little more, a software dependency ages, a knowledge-base article becomes slightly wrong, a relationship accumulates unspoken friction, or a policy drifts out of fit with reality. None of these events may be dramatic enough to force immediate action.

The structural failure is that the system waits for breakdown to create urgency. By then, the repair is more expensive, options are narrower, and the damage may already include outage, safety risk, lost trust, institutional decay, or reduced adaptability.

prose_intervention_logic:
The intervention converts future failure risk into present recurring commitments. First, define the maintained system and its deterioration model. Then choose a cadence basis: time, usage, condition, risk, season, event, or a hybrid. Next, define the service scope and reserve the necessary capacity. Assign an owner, verify completion, record findings, escalate missed or failed maintenance, and periodically retune the cadence.

A strong cadence does not blindly repeat. It learns from failures, missed intervals, inspection findings, condition changes, and changing risk.

prose_key_components:
### Deterioration Model
`deterioration_model` — Names the expected modes, rate, and consequences of degradation so upkeep is tied to real loss processes rather than habit or calendar folklore.

The model can be quantitative, qualitative, or experience-based, but it must explain why maintenance is needed before visible failure.

### Maintenance Interval
`maintenance_interval` — Defines the recurring time, usage, condition, or event interval at which upkeep should occur.

Intervals should reflect decay speed, use intensity, safety margin, recovery lead time, and the cost of missed upkeep.

### Inspection Cadence
`inspection_cadence` — Sets when the system is examined to confirm condition, detect changing maintenance needs, and verify that the cadence remains appropriate.

Inspection can be lighter than full maintenance; it is the feedback source that keeps the cadence from becoming blind routine.

### Service Scope
`service_scope` — Specifies what the maintenance action actually includes: cleaning, patching, tuning, replacement, refactoring, review, replenishment, repair, or relationship upkeep.

Without a defined scope, recurring maintenance becomes a vague appointment that can be skipped, shortened, or performed symbolically.

### Repair Threshold
`repair_threshold` — Defines the condition, trend, missed-interval count, or risk level that triggers additional repair, escalation, replacement, or redesign beyond ordinary upkeep.

Thresholds prevent the cadence from treating serious deterioration as routine maintenance when deeper intervention is needed.

### Maintenance Owner
`maintenance_owner` — Assigns clear accountability for scheduling, performing, verifying, and escalating preventive upkeep.

A cadence without ownership becomes calendar decoration; ownership connects the schedule to authority, capacity, and follow-through.

### Maintenance Capacity Budget
`maintenance_capacity_budget` — Reserves time, attention, budget, tools, parts, or decision bandwidth for upkeep before crisis work consumes all available capacity.

Preventive maintenance often fails because capacity is promised in principle but repeatedly cannibalized by urgent visible work.

### Missed Maintenance Escalation
`missed_maintenance_escalation` — Defines what happens when a scheduled maintenance action is skipped, deferred, incomplete, or repeatedly postponed.

Missed intervals should become risk signals rather than disappearing into a backlog that no one reviews.

### Maintenance Record
`maintenance_record` — Preserves what was inspected, serviced, deferred, discovered, and changed so future cadence decisions are evidence-based.

The record supports accountability, trend interpretation, auditability, and later redesign of the maintenance regime.

prose_common_mechanisms:
These mechanism families instantiate the archetype in specific domains. They should not be confused with the archetype itself: a refactoring sprint, health check, service window, or cleanup rotation only counts as Preventive Maintenance Cadence when it is embedded in the larger structure of degradation logic, service scope, ownership, reserved capacity, verification, and escalation.

### Preventive Inspection Schedule
`preventive_inspection_schedule` (procedure) implements the archetype by runs inspections at a defined interval so incipient deterioration is noticed while routine upkeep is still possible.

### Scheduled Service Window
`scheduled_service_window` (workflow) implements the archetype by allocates protected time for repairs, patching, replacement, cleanup, or adjustment without competing directly with normal demand.

### Refactoring Cadence
`refactoring_cadence` (workflow) implements the archetype by sets aside recurring software or process cleanup to reduce accumulated complexity before it causes fragility or slow change.

### Infrastructure Upkeep Cycle
`infrastructure_upkeep_cycle` (procedure) implements the archetype by cycles through inspection, minor repair, resurfacing, replacement, and condition verification for physical or civic assets.

### Policy Review Cycle
`policy_review_cycle` (ritual) implements the archetype by revisits rules, procedures, or governance documents on a regular cadence so they do not drift out of fit with reality.

### Knowledge-Base Cleanup Rotation
`knowledge_base_cleanup_rotation` (workflow) implements the archetype by rotates through documentation, FAQs, templates, or precedent libraries to remove stale guidance and repair broken references.

### Health Checkup Schedule
`health_checkup_schedule` (test_or_assessment) implements the archetype by applies recurring screening or condition review to people, teams, assets, or systems where early intervention can prevent larger harm.

### Relationship Maintenance Ritual
`relationship_maintenance_ritual` (ritual) implements the archetype by uses recurring check-ins, repair conversations, appreciation practices, or expectation resets to prevent trust erosion.

### Maintenance Backlog Review
`maintenance_backlog_review` (ritual) implements the archetype by periodically reviews deferred upkeep and known repair needs so preventive work does not disappear behind urgent delivery tasks.

prose_failure_modes:
The most common failure mode is calendar theater: the schedule exists, but the tasks do not restore condition. Another is maintenance starvation, where urgent work repeatedly steals the capacity reserved for upkeep. A stale cadence can persist long after use, risk, or environment has changed. Threshold blindness occurs when routine maintenance continues even though evidence shows that deeper repair or replacement is required.

The archetype also fails when ownership is unclear, deferred items are hidden, or maintenance windows are rejected because immediate demand always feels more urgent.

prose_neighbor_distinctions:
Deterioration Monitoring detects and interprets decline; Preventive Maintenance Cadence schedules and governs upkeep action. Many real systems need both.

Adaptive Scheduling adjusts timing in general; Preventive Maintenance Cadence adjusts timing for the specific purpose of preventing deterioration.

Resilience Capacity Building broadens a system's ability to absorb shocks; Preventive Maintenance Cadence preserves the condition of existing capabilities.

Half-Life-Based Timing can inform interval design, but this archetype includes service scope, ownership, capacity, verification, and escalation.

Technical Debt Containment is broader than cleanup cadence when it includes debt visibility, caps, budgets, and repayment policy.

A maintenance schedule, calendar reminder, health check, or refactoring sprint is a mechanism, not the full archetype.

prose_cross_domain_examples:
In infrastructure, bridge or road maintenance prevents small cracks, drainage problems, corrosion, or surface wear from becoming closure-level failures.

In software, recurring dependency updates, broken-test repair, documentation cleanup, and refactoring preserve reliability and change capacity.

In knowledge management, rotating through high-use articles prevents stale instructions, broken links, and contradictory guidance.

In organizations, recurring role reviews, retrospectives, and relationship repair rituals keep trust and coordination from eroding silently.

In public administration, periodic rule and form cleanup prevents obsolete procedures from accumulating into administrative burden.

prose_non_examples:
A one-time repair after an outage is reactive repair, not preventive cadence.

A dashboard that shows deterioration but triggers no upkeep is closer to Deterioration Monitoring.

A calendar reminder with no service scope, owner, capacity, or verification is only a prompt.

A weekly status meeting is not maintenance unless it performs real upkeep that prevents deterioration.

A migration away from an obsolete system is closer to Creative Destruction Management or Legacy Sunset and Migration.

prose_tradeoffs:
Preventive maintenance consumes resources before visible failure occurs, so it can look inefficient in the short term. The benefit is often an avoided event that never appears.

Fixed intervals are easy to govern but can be too rigid. Condition-based cadence is more responsive but requires trustworthy signals and interpretation. Planned downtime may be unpopular, but unplanned downtime is usually worse. Strong verification improves quality but adds friction. Over-maintenance can waste resources or disturb systems unnecessarily; under-maintenance allows hidden damage to compound.

prose_invariants_to_preserve:
The cadence must remain preventive. It should act before failure, not merely organize repair after failure.

The cadence must remain tied to deterioration dynamics. Timing, scope, and priority should reflect decay rate, use intensity, condition evidence, and failure consequence.

The work must be actionable and verifiable. A completed maintenance event should leave evidence of what was inspected, repaired, refreshed, cleaned, replaced, deferred, or escalated.

Missed maintenance must remain visible. Skipped upkeep is a risk signal, not just an administrative delay.

Maintenance capacity must be protected. Without reserved resources, the cadence loses to urgent work.

prose_target_outcomes:
The archetype aims to reduce emergency repairs, preserve reliability, lower lifecycle cost, maintain safety margins, slow hidden damage accumulation, and keep upkeep accountability visible.

It also protects adaptive capacity. Systems that never make time for maintenance eventually spend their flexibility on crisis response.

prose_parameter_dimensions:
The most important tuning dimension is the maintenance interval: too sparse and deterioration compounds; too frequent and the system wastes capacity or disrupts normal operation. The interval can be based on calendar time, usage, condition, risk, season, or events.

Service scope is another key parameter. Light maintenance may keep a system clean and visible, while deep maintenance may require downtime, specialized labor, or replacement. The cadence also needs a protected capacity fraction, a verification standard, and an escalation threshold for missed or failed upkeep.

Cadence recalibration matters because deterioration dynamics change. A schedule inherited from an earlier context can become under-maintenance, over-maintenance, or pure ritual.

prose_variants_and_near_names:
Fixed-Interval Maintenance performs upkeep on a calendar or regular cycle. Condition-Based Maintenance adjusts timing when deterioration indicators cross warning thresholds. Usage-Based Maintenance schedules service after cycles, miles, requests, transactions, or other use counts. Risk-Weighted Maintenance Cadence prioritizes critical systems more tightly than low-consequence systems. Debt Repayment Cadence reserves recurring time to pay down accumulated shortcuts and deferred cleanup, but remains merge-sensitive with Technical Debt Containment.

Near names include Preventive Maintenance, Planned Maintenance, Scheduled Upkeep, Maintenance Scheduling, Service Cadence, and Routine Maintenance. These should point back to the parent archetype unless they refer only to a mechanism or domain-specific procedure.

Fixed-Interval Maintenance

short_definition: Performs maintenance at regular calendar intervals regardless of current condition.

distinctive_feature: The schedule itself is the main trigger: monthly, quarterly, yearly, or otherwise fixed.

distinct_from_parent: The parent can use time, usage, condition, risk, or event triggers; this variant relies primarily on time-based intervals.

still_same_parent_because: The intervention still prevents deterioration through recurring upkeep before visible failure.

use_when: Degradation is predictable enough that time is a useful proxy for risk.

use_when: Inspection cost is high relative to routine service cost.

use_when: Operational simplicity and compliance matter more than fine-grained optimization.

example_domains: facilities documentation compliance personal_health

domain: Facilities

example: HVAC filters are replaced every quarter to preserve air flow and equipment life.

domain: Governance

example: A policy manual is reviewed every year so outdated procedures are corrected before they create operational confusion.

failure_modes: The interval remains fixed after conditions change.

failure_modes: The schedule becomes a checkbox exercise with no verification of restored condition.

Condition-Based Maintenance

short_definition: Triggers preventive upkeep when condition indicators show deterioration approaching a threshold.

distinctive_feature: Observed condition, not only the calendar, adjusts when maintenance happens.

distinct_from_parent: The parent includes several cadence types; this variant explicitly combines monitoring signals with maintenance timing.

still_same_parent_because: The core intervention remains recurring upkeep before breakdown, with signals used to tune timing.

use_when: Useful condition signals are available before failure.

use_when: Usage intensity varies enough that fixed intervals would over- or under-maintain the system.

use_when: Maintenance capacity should be focused where deterioration is actually emerging.

domain: Manufacturing

example: Machine vibration trends trigger service before bearing failure.

domain: Cloud operations

example: Rising error rates trigger dependency upgrades and cleanup before a major outage.

failure_modes: Condition signals are treated as complete even when they miss hidden damage.

failure_modes: Thresholds are tuned to conserve budget rather than preserve safety or reliability.

Usage-Based Maintenance

short_definition: Schedules upkeep after a defined amount of use, load, exposure, or activity rather than after elapsed time alone.

distinctive_feature: The cadence is tied to cycles, hours, transactions, miles, requests, or accumulated use.

distinct_from_parent: The parent cadence can be set in many ways; this variant uses exposure or utilization as the pacing variable.

still_same_parent_because: The purpose remains prevention of accumulated deterioration through timely upkeep.

use_when: Wear is driven more by usage than by calendar time.

use_when: Usage can be counted or estimated reliably.

use_when: The system experiences uneven load across units, teams, or locations.

domain: Fleet management

example: Vehicles receive service after mileage thresholds rather than only by date.

domain: Software

example: High-change modules receive cleanup after a threshold number of changes or defects.

failure_modes: Usage counters become stale or incomplete.

failure_modes: Low-use items are neglected even though they deteriorate with time or environment.

Risk-Weighted Maintenance Cadence

short_definition: Prioritizes preventive upkeep according to failure consequence, exposure, criticality, and recoverability.

distinctive_feature: Cadence is tuned by consequence and criticality, not just decay rate or convenience.

distinct_from_parent: The parent sets a recurring upkeep pattern; this variant adds portfolio prioritization by risk and criticality.

still_same_parent_because: The intervention still uses planned upkeep to prevent deterioration from becoming failure.

use_when: Not all parts of the system have equal failure consequences.

use_when: Maintenance capacity is scarce and must be allocated by risk.

use_when: Critical units require tighter intervals, stronger verification, or more redundancy.

domain: Public infrastructure

example: Critical bridges receive more frequent inspections and repairs than low-risk structures.

domain: Security

example: High-risk dependencies receive accelerated patch and review cadence.

failure_modes: Risk ratings become political and hide vulnerable low-visibility assets.

failure_modes: Low-priority items are deferred indefinitely until they become crises.

Debt Repayment Cadence

short_definition: Creates recurring time to pay down accumulated shortcuts, cleanup backlogs, or process debt before they degrade adaptability.

distinctive_feature: The maintained object is accumulated debt or shortcut burden rather than an asset with ordinary wear.

distinct_from_parent: The parent schedules upkeep generally; this variant focuses on recurring repayment of accumulated shortcuts and deferred cleanup.

still_same_parent_because: It still prevents deterioration through protected recurring upkeep before accumulated burden causes failure.

use_when: Shortcuts or deferred cleanup are accumulating as future drag.

use_when: Urgent delivery pressure repeatedly crowds out cleanup.

use_when: A separate Technical Debt Containment draft may later govern caps, budgets, and repayment policy.

example_domains: software operations policy knowledge_management

example: A team reserves every fifth sprint for refactoring and dependency cleanup.

domain: Policy

example: An agency schedules periodic repeal, consolidation, and cleanup of obsolete procedures.

failure_modes: Debt cleanup is treated as optional when delivery pressure rises.

failure_modes: The cadence repairs symptoms without limiting new debt creation.

near_names:
Preventive Maintenance
Planned Maintenance
Maintenance Scheduling
Scheduled Upkeep
Service Cadence
Routine Maintenance


Price Signal Design

type: archetype

source: generated

batch: First Iteration/Batch 14

slug: feedback

slug: externality

slug: equity

slug: equilibrium

components:
Signal Target Definition
Scarcity or Value Measure
Price Signal
Response Path Map
Elasticity and Behavior Estimate
Adjustment Rule
Fairness and Access Review
Transparency and Explanation
Monitoring and Safeguard Loop
Access Floor or Lifeline Rule
Credit, Rebate, or Voucher Channel
Anti-Arbitrage Rule
Price Cap or Volatility Guardrail
Nonmonetary Price-Like Token
Appeals and Exception Process

mechanisms:
Congestion Pricing
Time-of-Use Pricing
Surge Pricing
Dynamic Pricing
Usage-Based Pricing
Carbon Pricing
Internal Transfer Pricing
Shadow Pricing
Rebate or Credit Scheme
Price Cap or Floor

essence_one_line: Use prices or price-like signals to communicate scarcity, value, or priority and coordinate decentralized decisions.

compression_statement: When many actors make local choices without a shared view of scarcity, value, cost, priority, or congestion, price signal design creates a credible price or price-like signal that guides allocation and behavior while preserving access, fairness, and protected constraints.

core_intuition: A price is not only a charge; it is a compressed message about tradeoffs. When the signal is trustworthy and the affected actors can respond, local choices can shift demand, reveal preferences, fund capacity, or conserve scarce resources without requiring a planner to decide every allocation. The archetype works only when the signal is tied to the right underlying condition and surrounded by safeguards for people or values that should not simply be priced out.

canonical_formula: distributed_decision_makers + opaque_scarcity_or_value + adjustable_signal -> price_or_price_like_signal + response_path + feedback_adjustment + fairness_guardrails -> coordinated_behavior_without_full_central_control

structural_problem: Many actors make decentralized decisions, but the scarcity, value, cost, congestion, or priority information needed to coordinate those decisions is hidden, delayed, distorted, or communicated only through central instruction. As a result, resources are overused, underused, consumed at the wrong time, misallocated to low-priority uses, or allocated by queues, politics, habit, or unmanaged congestion.

condition: Local actors can adjust consumption, timing, routing, quantity, priority, or substitution when given a meaningful signal.

why_it_matters: A price signal is useful only if recipients have some practical response path.

condition: The relevant scarcity or value varies across time, location, quantity, priority, actor, or context.

why_it_matters: Static rules often fail when the underlying condition changes faster than governance can micromanage.

condition: Central planners cannot observe or optimize every local tradeoff directly.

why_it_matters: The archetype delegates adjustment to local actors while using price-like information as the coordination medium.

condition: The current decision environment hides the true cost, scarcity, congestion, or opportunity cost of use.

why_it_matters: Hidden costs produce overconsumption, low-priority use, budget surprises, or congestion.

condition: The system can monitor outcomes and adjust the signal when behavior, demand, or capacity changes.

why_it_matters: A price signal without feedback can become stale, manipulative, or disconnected from reality.

condition: Access, dignity, safety, or legal constraints can be protected separately from the pricing signal.

why_it_matters: Essential goods and protected rights cannot be governed by willingness to pay alone.

symptom: Congestion, shortages, backlogs, or overload persist even though some demand could shift.

interpretation: The system is not communicating scarcity or peak load in a way that changes behavior.

symptom: Users treat a shared resource as free at the point of use even when it has real opportunity cost.

interpretation: The decision boundary hides costs that matter to the larger system.

symptom: Allocation is handled through ad hoc rationing, queue jumping, political escalation, or managerial intervention.

interpretation: The system lacks a stable signal for priority or willingness to trade off.

symptom: Demand spikes create crisis responses, but routine periods show unused capacity.

interpretation: The timing dimension of scarcity is not being communicated or priced.

symptom: Teams or users optimize their own budgets while imposing costs on shared infrastructure.

interpretation: The cost signal is outside the actor’s decision boundary.

symptom: A fixed price or rule produces excess demand in one context and underuse in another.

interpretation: The signal does not track relevant variation in scarcity, cost, or value.

symptom: Price changes provoke confusion, distrust, or accusations of gouging.

interpretation: The signal may be opaque, unfair, poorly explained, or tied to the wrong measure.

root_tension: The system needs decentralized actors to make locally informed choices, but those actors lack a credible, interpretable, and fair signal of the system-level tradeoffs their choices create.

case: The desired behavior is legally or ethically mandatory regardless of willingness to pay.

why_not: Rights, safety duties, and basic access floors need governance constraints; pricing may support but should not replace them.

case: Actors cannot respond to the signal because alternatives, timing flexibility, or substitutes are absent.

why_not: A price increase without a response path functions as extraction or exclusion rather than coordination.

case: The scarce resource cannot be measured or proxied with sufficient reliability.

why_not: Bad measures create bad prices, misallocation, and legitimacy failure.

case: The main problem is strategic gaming, not unclear scarcity or value.

why_not: Incentive-compatible rule design or anti-gaming controls may be primary.

case: The main intervention is fixed contribution funding for a non-excludable shared good.

why_not: Public goods provision is the parent pattern when the central problem is underfunding rather than decentralized demand coordination.

case: Distributional consequences dominate efficiency concerns and cannot be safeguarded.

why_not: A price signal that excludes protected users or essential needs violates the archetype’s invariants.

structural_intervention: Define what scarcity, value, cost, priority, or congestion must be communicated; construct a price or price-like signal linked to that condition; ensure actors can understand and respond to it; add fairness, access, and anti-gaming safeguards; and close the loop through monitoring and adjustment.

step: Identify the coordination target.

logic: Clarify whether the signal should reduce peak demand, reveal willingness to pay, fund capacity, conserve a resource, allocate priority, internalize a cost, or make opportunity cost visible.

step: Map decision makers and response options.

logic: Determine who receives the signal, what choices they can change, and whether those choices are realistic for low-power or constrained actors.

step: Choose the scarcity or value measure.

logic: Tie the signal to a credible measure such as congestion, marginal cost, capacity utilization, emissions, delay, service level, or priority.

step: Design the signal form.

logic: Select a monetary price, internal charge, credit, token cost, budget shadow price, priority price, surcharge, rebate, or price-like indicator that actors can compare.

step: Add safeguards before deployment.

logic: Protect minimum access, essential use, vulnerable users, fairness, due process, transparency, privacy, and legal constraints.

step: Monitor behavioral response.

logic: Measure whether demand, timing, quantity, allocation, or conservation changes in the intended direction without unacceptable harms.

step: Adjust and explain the signal.

logic: Update prices or rules as scarcity and behavior change, and explain changes enough to preserve trust and legitimacy.

rule: Use price signals when decentralized adjustment is valuable and actors have meaningful alternatives.

rationale: Pricing works best when recipients can choose timing, quantity, substitution, routing, or priority.

rule: Use non-price governance when the resource is a right, safety requirement, or essential floor.

rationale: Price can coordinate marginal use but should not determine basic entitlement where access must be protected.

rule: Prefer simple and stable signals when predictability matters more than marginal precision.

rationale: Highly dynamic prices can improve responsiveness but reduce trust and planning ability.

rule: Add credits, rebates, caps, exemptions, or public funding when access effects are unacceptable.

rationale: Efficiency gains are not valid if they depend on excluding protected or low-power users.

rule: Escalate to incentive-compatible rule design when actors can manipulate the measure behind the price.

rationale: If the signal is gamed, the rule environment needs strategic robustness, not merely a different price.

rule: Treat taxes, subsidies, price floors, and ceilings as mechanisms or instruments, not the archetype itself.

rationale: The archetype is the design of a decision-facing signal and response loop; instruments are implementations.

invariant: The signal remains tied to a legitimate scarcity, value, cost, priority, or congestion measure.

why: Untethered price changes become arbitrary extraction or manipulation.

invariant: Actors have a feasible response path.

why: Without alternatives, the signal punishes rather than coordinates.

invariant: Protected access floors are preserved.

why: Essential goods, rights, safety, and dignity should not be allocated solely by ability to pay.

invariant: Signal changes are explainable enough to maintain trust.

why: Opaque pricing erodes legitimacy and invites accusations of exploitation.

invariant: The feedback loop detects harms, gaming, and distributional effects.

why: Behavioral response can create unintended effects that must be corrected.

invariant: The signal does not pretend that all values are commensurable.

why: Some priorities require qualitative safeguards or separate governance rules.

outcome: Better decentralized coordination.

indicator: Actors shift demand, timing, priority, or quantity in response to a shared signal.

outcome: Reduced congestion or overuse.

indicator: Peak load, queue length, delay, or depletion falls without eliminating essential access.

outcome: More visible opportunity costs.

indicator: Users and teams see the system cost of choices that previously looked free.

outcome: Improved allocation to higher-value or higher-priority uses.

indicator: Scarce capacity moves toward uses with stronger value, urgency, or justified willingness to trade off.

outcome: More adaptive demand management.

indicator: The system adjusts signals as scarcity, capacity, and behavior change.

outcome: More legitimate pricing governance.

indicator: Stakeholders understand the purpose of the signal and can challenge unfair or erroneous cases.

prose_essence:
Price Signal Design is the pattern of using a price or price-like signal to coordinate decentralized choices. The signal can be money, credits, internal chargebacks, priority costs, rebates, or shadow prices. What makes it this archetype is not the presence of money alone; it is the deliberate use of a comparable signal to communicate scarcity, value, cost, congestion, or priority at the moment actors make choices.

The core intuition is simple: people and organizations often treat hidden costs as if they do not exist. A road looks free until it is congested, a cloud job looks free until the infrastructure bill arrives, and a shared service looks unlimited until the queue collapses. A well-designed price signal makes the tradeoff visible without requiring a central planner to decide every case.

The archetype is ethically fragile. A price signal coordinates only when actors have feasible ways to respond and when basic access, safety, dignity, and fairness are protected. Without those guardrails, the same mechanism can become exclusion, gouging, or opaque extraction.

prose_when_to_use:
Use this archetype when many actors make local decisions and those decisions need a shared signal of scarcity, value, cost, congestion, or priority. It is especially useful when demand can shift across time, quantity, route, intensity, or substitute options; when shared resources are overused because they appear free; or when local teams cannot see the opportunity cost they impose on a larger system.

Good use cases include congestion pricing, time-of-use electricity rates, usage-based cloud charges, internal transfer prices, carbon pricing, and price-like credits for scarce platform capacity. In each case the design task is broader than changing a number. The designer must define what the signal should communicate, who sees it, how they can respond, how the signal changes, and which access or fairness limits cannot be violated.

Do not use this archetype as the sole answer when the relevant good is a right, when users have no alternatives, when the measurement behind the price is untrustworthy, or when ability to pay is a poor proxy for priority. In those cases, price signal design may need to be subordinated to public goods provision, resource rationing, priority-based admission, direct regulation, or equity-centered access rules.

prose_structural_problem:
The structural problem is decentralized choice under hidden scarcity. Many actors consume, request, schedule, route, emit, or prioritize locally, but the system-level cost of those choices is not visible at the point of decision. The result can be congestion, shortages, queues, overload, excess emissions, budget leakage, low-priority use of scarce capacity, or repeated escalation to managers and regulators.

The problem is not merely that something is expensive. It is that the relevant tradeoff is not encoded in the decision environment. If a team can run compute-heavy workflows without seeing the cost, a commuter can drive into a congested road without seeing the delay imposed on others, or a department can demand unlimited shared service support without seeing the opportunity cost, local rationality produces system-level strain.

prose_intervention_logic:
The intervention starts by naming the signal target. The target may be peak congestion, marginal cost, emissions, scarcity, service priority, capacity utilization, or opportunity cost. Once the target is clear, the designer chooses a credible measure, constructs a price or price-like signal, gives actors feasible response paths, adds safeguards, and monitors results.

The key causal loop is:

1. A condition such as congestion, scarcity, or hidden cost becomes measurable enough to signal.
2. The signal appears where actors make choices.
3. Actors compare the signal against their preferences, constraints, and alternatives.
4. Some behavior shifts: timing, quantity, substitution, conservation, priority, or funding.
5. The system monitors whether the shift improves outcomes without unacceptable harm.
6. The signal and safeguards are adjusted.

This is why dynamic pricing, congestion pricing, carbon taxes, usage fees, rebates, or transfer prices are mechanisms rather than the archetype itself. The archetype is the signal-governance loop that makes those mechanisms legitimate and effective.

prose_key_components:
### Signal Target Definition

A price signal must say what it is trying to communicate. Is the signal about congestion, marginal cost, emissions, scarcity, priority, demand, or opportunity cost? Without a target definition, price changes drift toward revenue extraction or arbitrary punishment.

### Scarcity or Value Measure

The measure grounds the signal. It may be capacity utilization, delay, emissions, inventory, marginal service cost, queue length, or an internal opportunity-cost estimate. The measure need not be perfect, but it must be credible and reviewable.

### Price Signal

The signal is the decision-facing price or price-like expression: money, credits, tokens, internal charges, shadow prices, discounts, rebates, priority costs, or budget impacts. It must be salient enough to guide decisions.

### Response Path Map

The response path map identifies what affected actors can actually do. They may reduce use, shift timing, choose a substitute, accept lower priority, pay for priority, conserve, batch work, or seek an exemption. Without response paths, pricing becomes coercive rather than coordinative.

### Elasticity and Behavior Estimate

Not all actors respond in the same way. Some are flexible; others are locked into necessity, habit, contract, schedule, geography, or lack of alternatives. Estimating likely response prevents naive designs that assume everyone can adjust.

### Adjustment Rule

The adjustment rule defines when and how the signal changes. It may use fixed time bands, thresholds, algorithmic updates, public review, or emergency overrides. This component keeps the signal tied to changing conditions.

### Fairness and Access Review

Every price signal needs review for access and distributional burden. The design must ask who pays, who can shift, who cannot, and whether the signal threatens essential use, protected groups, or basic dignity.

### Transparency and Explanation

People need to know why the signal exists and what it tracks. This is especially important for dynamic prices, internal chargebacks, and environmental prices where distrust can undermine the intervention.

### Monitoring and Safeguard Loop

The monitoring loop tracks demand response, congestion, revenue, access effects, complaints, gaming, and unintended consequences. It turns price signal design from a one-time price change into an adaptive governance pattern.

Optional components include access floors, lifeline rules, credits, rebates, vouchers, anti-arbitrage rules, price caps, volatility guardrails, nonmonetary tokens, and appeals processes. These components are not decorative; in high-stakes contexts they are what separate legitimate coordination from exclusion.

prose_common_mechanisms:
### Congestion Pricing

Congestion pricing charges more for use of a congested road, facility, network, or service. It implements the archetype by making bottleneck scarcity visible. It should not be confused with the archetype itself because the broader pattern also includes time, usage, carbon, internal, and shadow price signals.

### Time-of-Use Pricing

Time-of-use pricing varies prices by predictable time bands. It works when scarcity or cost changes by time and users can shift demand. It is common in electricity, transportation, compute scheduling, and facility use.

### Surge Pricing and Dynamic Pricing

Surge and dynamic pricing update prices in response to live demand, capacity, inventory, or risk. These mechanisms can be powerful but dangerous. They require transparency, volatility limits, anti-gouging controls, and discrimination review.

### Usage-Based Pricing

Usage-based pricing links cost to quantity consumed. It works when flat or hidden costs cause overuse, such as water, compute, storage, API calls, or shared equipment. It often needs lifeline allowances or included basic use.

### Carbon Pricing and Pollution Fees

Carbon pricing and pollution fees implement price signal design at the boundary with externality internalization. They translate a spillover harm into a decision-facing cost, while externality accounting and distributional safeguards remain essential.

### Internal Transfer Pricing and Shadow Pricing

Internal transfer prices and shadow prices make hidden organizational costs visible. A department, product team, or capital project sees a price-like estimate for shared services, emissions, compute, or scarce expert capacity even when no external market transaction occurs.

### Credits, Rebates, and Vouchers

Credits, rebates, and vouchers preserve marginal price information while reducing burden for target groups. They are often needed when the price signal would otherwise exclude low-income users, essential use, or public-benefit activity.

### Price Caps and Floors

Caps and floors are guardrails or policy instruments. They can prevent volatility or protect access, but they can also hide scarcity or create shortages. They are mechanisms to govern the signal, not the archetype itself.

prose_failure_modes:
A common failure mode is regressive exclusion. The signal changes behavior by burdening people who cannot shift or pay. Lifeline access, rebates, credits, exemptions, public funding, and non-price allocation floors can mitigate this.

Another failure mode is a false scarcity signal. If the measure is wrong, stale, biased, or manipulated, actors optimize against a bad map. Auditing, transparent assumptions, operational cross-checks, and pause rules help.

Opaque dynamic pricing can provoke backlash even when the signal has a rational basis. Users need explanations, limits, and contestability.

Price gouging is a severe failure in emergencies and essential-good contexts. During crisis conditions, caps, rationing, public provision, or priority-based allocation may be more appropriate than unconstrained pricing.

Arbitrage and tier gaming occur when actors exploit price differences in ways that defeat the signal. Anti-arbitrage rules and incentive-compatible design may be needed.

Signal crowd-out occurs when pricing weakens civic duty, trust, care, or voluntary contribution. This is a warning sign in domains where norms matter more than marginal efficiency.

prose_neighbor_distinctions:
Price Signal Design is close to Elasticity-Based Leverage, but elasticity-based leverage asks where a small intervention will produce a large response. Price signal design builds the signal that may produce that response.

It overlaps with Externality Internalization when the price represents a spillover cost, such as carbon or pollution. Externality internalization is the broader responsibility-boundary pattern; price signaling is one way to implement it.

It is near Payoff Restructuring, but payoff restructuring can use many rewards and penalties. Price signal design specifically communicates scarcity, value, cost, or priority through a comparable price-like signal.

It differs from Public Goods Provision, which solves underfunding of shared benefits. A membership due or tax may fund a public good without acting as a marginal scarcity signal.

It differs from Resource Rationing, which directly sets limits or quotas. Price signal design encourages decentralized adjustment, although it may need rationing guardrails.

It differs from Incentive-Compatible Rule Design, which focuses on strategic best responses and gaming. Price signal design may need incentive-compatible safeguards when the signal can be manipulated.

prose_cross_domain_examples:
In transportation, congestion pricing makes peak road use more expensive and can fund transit alternatives or rebates. The design works only if essential travel and low-alternative users are protected.

In electricity, time-of-use rates shift flexible demand away from peak periods. Lifeline rates and bill credits preserve basic access.

In cloud infrastructure, usage-based charges and internal cost dashboards help teams see the cost of compute, storage, and data transfer.

In climate policy, carbon pricing makes emissions-intensive choices more expensive. It sits at the boundary with externality internalization and needs distributional safeguards.

In organizations, internal transfer pricing for legal review, analytics, platform capacity, or shared services helps teams prioritize scarce support.

In water management, increasing block rates keep basic water use affordable while making high marginal use more expensive.

In digital platforms, rate-limit credits or paid priority queues can communicate scarce attention, moderation, or API capacity without literal open-ended monetary pricing.

prose_non_examples:
A flat membership fee is not necessarily price signal design. It may fund a service, but it does not communicate marginal scarcity.

A moral appeal to conserve is not price signal design unless paired with a price-like decision signal.

A punitive fine unrelated to measured scarcity or harm is enforcement, not this archetype.

A direct quota is rationing. It can complement a price signal but does not itself communicate scarcity through decentralized choice.

An emergency price spike for essential medicine, evacuation transport, or basic shelter is not a legitimate use of this archetype when people have no alternatives and essential access is threatened.

prose_tradeoffs:
The main tradeoff is efficiency versus access. Prices can allocate scarce capacity more smoothly, but they can also exclude people whose need is high and ability to pay is low.

Responsiveness trades off with predictability. Dynamic signals can track live scarcity, but people need stable expectations for planning and trust.

Simplicity trades off with accuracy. A simple schedule is legible; a granular algorithm may be more precise but harder to govern.

Decentralization trades off with governance burden. Price signals reduce central micromanagement, but they require measurement, safeguards, transparency, and review.

Demand shaping trades off with revenue temptation. A sponsor may begin with coordination goals and later optimize the price for extraction.

Monetary comparability trades off with value pluralism. Prices make tradeoffs visible, but not every important value should be treated as purchasable.

prose_invariants_to_preserve:
The signal must remain tied to a legitimate underlying condition. It should not become arbitrary revenue extraction.

Affected actors must have feasible response paths. A price signal without alternatives is not coordination; it is burden shifting.

Protected access floors must be preserved. Essential services, rights, safety, and dignity cannot be allocated solely by ability to pay.

The design must remain explainable enough to maintain trust. Opaque dynamic prices, inscrutable internal charges, and unexplained surcharges undermine legitimacy.

The monitoring loop must detect harms, gaming, and distributional effects. A theoretically efficient price can still fail if it produces inequitable exclusion, panic, hidden workarounds, or quality collapse.

The design must remember that not all values are commensurable. Some goals require separate governance constraints rather than conversion into a price.

prose_target_outcomes:
The intended outcomes are better decentralized coordination, reduced congestion or overuse, visible opportunity costs, more adaptive demand management, better allocation of scarce capacity, and more legitimate resource governance.

In practice, success may look like lower peak load, shorter queues, fewer low-priority requests for scarce services, reduced waste or emissions, clearer departmental tradeoffs, improved capacity planning, or fewer managerial escalations. Success should not be measured by revenue alone.

prose_parameter_dimensions:
Important tuning dimensions include signal magnitude, timing, granularity, volatility, predictability, response elasticity, user segmentation, access floor, rebate level, exemption criteria, measurement lag, update frequency, transparency level, appeals process, and revenue use.

A strong price signal is not automatically a high price. It is a well-targeted signal. Sometimes the best design is a small but salient fee, a visible credit budget, a predictable peak/off-peak schedule, a lifeline allowance with marginal charges above it, or an internal shadow price that changes planning behavior without charging customers directly.

The ethical tuning questions are as important as the economic ones. Who has alternatives? Who cannot shift demand? Who receives revenue or rebates? Can users understand the change? Can they challenge errors? Does the signal preserve minimum access? Does it create incentives to maintain scarcity?

prose_variants_and_near_names:
Recognized variants include congestion price signals, temporal price signals, dynamic price adjustment, externality price signals, internal or shadow price signals, and usage-based price signals.

Near names include scarcity pricing, demand pricing, dynamic pricing, congestion pricing, time-of-use pricing, surge pricing, carbon pricing, shadow pricing, and internal transfer pricing. These names should usually point to the parent or a variant rather than becoming separate archetypes.

Dynamic pricing is especially important to classify correctly. The reconciliation controls treat it as mechanism material under price signal design or elasticity-based leverage. It is valuable as a mechanism-family variant, but it should not be drafted as its own archetype unless future review finds a distinct cross-domain governance pattern around algorithmic pricing.

Price Discrimination / Access Design remains a promotion candidate and merge-review neighbor. It may deserve a second-wave draft if segment-specific access, fairness, anti-arbitrage, privacy, and willingness-to-pay issues prove structurally distinct enough from general price signal design.

Congestion Price Signal

short_definition: Use higher prices or price-like costs during congestion to shift or reduce demand for a shared capacity bottleneck.

distinctive_feature: The signal is tied to congestion rather than general revenue, quality tiers, or static willingness to pay.

distinct_from_parent: The parent covers any scarcity, value, cost, or priority signal; this variant focuses on bottleneck load and peak-use reduction.

still_same_parent_because: It still implements the same loop of measurement, price-like signal, response path, safeguards, and adjustment.

use_when: The scarce condition is crowding, delay, peak load, queue length, or capacity saturation.

use_when: Some users can shift time, route, quantity, mode, or priority.

use_when: The system can protect essential access and monitor distributional impact.

Scarcity or Value Measure

role: Tracks congestion, utilization, queueing, or delay.

Response Path Map

role: Identifies alternative timing, routing, or modes.

Fairness and Access Review

role: Protects essential users and low-alternative groups.

Congestion Pricing

role: Charges for peak or congested use.

Peak-Period Surcharge

role: Raises price during bottleneck windows.

Off-Peak Rebate

role: Rewards shifting away from congested periods.

example_domains:
transportation
electric grids
cloud computing
ticketing
network bandwidth

domain: Transportation

example: A city prices road access higher during rush-hour congestion.

example: Batch jobs are cheaper during low-load compute windows.

failure_modes: Congestion prices exclude essential travelers without alternatives.

failure_modes: Revenue goals override congestion reduction.

failure_modes: Users distrust the signal because measurement is opaque.

Temporal Price Signal

short_definition: Vary the effective price across time so actors shift demand toward lower-cost or lower-congestion windows.

distinctive_feature: The main design dimension is time: peak/off-peak, seasonality, urgency windows, or lifecycle timing.

distinct_from_parent: The parent includes all price-like signals; this variant names the temporal schedule form.

still_same_parent_because: The causal logic remains signal, response, safeguards, and feedback adjustment.

use_when: The cost or scarcity of serving demand varies by time.

use_when: Users can schedule, defer, batch, store, or substitute use.

use_when: Predictability is important enough to prefer schedules or transparent rules over opaque real-time pricing.

Adjustment Rule

role: Defines time bands or temporal thresholds.

Transparency and Explanation

role: Makes temporal variation understandable.

Elasticity and Behavior Estimate

role: Estimates ability to shift timing.

Time-of-Use Pricing

role: Charges different rates by time band.

Seasonal Pricing

role: Reflects seasonal capacity or demand variation.

Scheduled Priority Credits

role: Uses credits for access during scarce windows.

example_domains:
electricity
transit
cloud computing
labor scheduling
hospital capacity

domain: Electricity

example: Off-peak power is priced lower to shift discretionary loads.

domain: Compute

example: Nonurgent jobs consume fewer credits at night.

failure_modes: Users with inflexible schedules carry disproportionate burden.

failure_modes: The schedule is too complex to guide decisions.

Dynamic Price Adjustment

short_definition: Update prices or price-like signals in near-real time as demand, capacity, cost, or risk changes.

distinctive_feature: The signal changes dynamically rather than through a stable posted schedule.

distinct_from_parent: The parent covers price signal design broadly; this variant is the algorithmic or rule-based update form.

still_same_parent_because: Dynamic adjustment is a mechanism for keeping the signal aligned with changing conditions.

use_when: Scarcity or demand changes faster than fixed schedules can represent.

use_when: Actors can see, understand, and respond to updates before committing.

use_when: Volatility, opacity, and perceived exploitation are actively governed.

Adjustment Rule

role: Defines update logic.

Price Cap or Volatility Guardrail

role: Limits unstable or exploitative movement.

Transparency and Explanation

role: Explains price changes to preserve trust.

Surge Pricing

role: Raises prices during demand spikes.

Algorithmic Price Update

role: Computes prices from live demand or capacity signals.

Inventory-Sensitive Pricing

role: Varies prices as inventory changes.

example_domains:
ride-hailing
cloud services
ticketing
energy balancing
online marketplaces

domain: Ride-hailing

example: Prices rise during a local demand spike to attract drivers and dampen marginal trips.

domain: Cloud services

example: Spot compute prices change as spare capacity changes.

failure_modes: Opaque price changes are perceived as unfair or predatory.

failure_modes: Algorithms learn discriminatory or collusive behavior.

Externality Price Signal

short_definition: Use a price or charge to make spillover costs or benefits visible inside the actor’s decision environment.

distinctive_feature: The signal communicates a third-party spillover cost or benefit rather than only private scarcity.

distinct_from_parent: The parent is about price-like coordination; this variant is the overlap zone with externality_internalization.

still_same_parent_because: A spillover price still functions as a price signal when actors adjust decentralized choices in response.

use_when: The signal is tied to pollution, emissions, congestion harms, depletion, or other external effects.

use_when: The harm or benefit can be measured or approximated well enough for governance.

use_when: The design is paired with externality-accounting, liability, or public-interest safeguards.

Signal Target Definition

role: Defines the external effect being signaled.

Scarcity or Value Measure

role: Estimates harm, emissions, or depletion.

Fairness and Access Review

role: Checks burden and use of revenues.

Carbon Pricing

role: Prices greenhouse gas emissions.

Pollution Fee

role: Charges for measured harmful discharge.

Impact Fee

role: Charges for imposed infrastructure or environmental cost.

example_domains:
climate policy
pollution control
waste management
road congestion
water depletion

domain: Climate policy

example: A carbon fee changes the relative cost of high-emission choices.

domain: Waste management

example: Per-bag fees encourage waste reduction and recycling.

failure_modes: The price is too low to change behavior.

failure_modes: The harm estimate omits affected communities.

failure_modes: Revenue use creates legitimacy conflict.

Internal or Shadow Price Signal

short_definition: Use internal charges or estimated prices to make hidden organizational opportunity costs visible in decisions.

distinctive_feature: The signal may be accounting-based or planning-based rather than an external market price.

distinct_from_parent: The parent includes public market prices; this variant is designed for internal governance and planning.

still_same_parent_because: It still communicates scarcity or value through a comparable price-like signal that changes local choices.

use_when: The resource is not bought in a visible market at the point of use.

use_when: Teams or units consume shared capacity as if it were free.

use_when: The organization wants better prioritization without fully marketizing the resource.

Price Signal

role: Presents the internal charge or shadow estimate.

Transparency and Explanation

role: Clarifies that the signal is for allocation, not punitive accounting.

Monitoring and Safeguard Loop

role: Tracks whether internal decisions improve.

Internal Transfer Pricing

role: Charges business units for shared services.

Chargeback Model

role: Allocates shared cost to users.

Shadow Carbon Price

role: Uses an internal emissions price for capital decisions.

example_domains:
corporate shared services
public-sector budgeting
cloud FinOps
capital planning
sustainability programs

domain: Cloud FinOps

example: Teams see an internal cost for compute-heavy workflows.

domain: Capital planning

example: Projects include a shadow carbon price in investment appraisal.

failure_modes: Internal prices become bureaucratic games.

failure_modes: Teams avoid valuable shared services to protect local budgets.

failure_modes: The signal is treated as exact when it is an estimate.

Usage-Based Price Signal

short_definition: Link costs or credits to actual usage so actors see the marginal burden of additional consumption.

distinctive_feature: The signal is tied to measured quantity or intensity rather than time, segment, or congestion alone.

distinct_from_parent: The parent includes many price-like signals; this variant focuses on metered marginal consumption.

still_same_parent_because: Metered usage is a common way to communicate resource cost and coordinate decentralized demand.

use_when: Flat pricing hides marginal cost or encourages inefficient overuse.

use_when: Usage can be metered reliably and privacy-sensitively.

use_when: Users can meaningfully change quantity or intensity of use.

Scarcity or Value Measure

role: Meters consumption.

Price Signal

role: Links usage to cost.

Fairness and Access Review

role: Protects basic use and privacy.

Metered Billing

role: Charges according to units consumed.

Pay-As-You-Go Pricing

role: Allows variable use with corresponding cost.

Tiered Usage Allowance

role: Combines basic included use with marginal charges.

example_domains:
utilities
cloud services
water management
software platforms
shared equipment

domain: Water management

example: Households receive increasing marginal prices after basic lifeline use.

example: API usage is priced by calls after a free allocation.

failure_modes: Users optimize around measured units while shifting unmeasured costs elsewhere.

near_names:
Scarcity Pricing
Demand Pricing
Dynamic Pricing
Congestion Pricing
Time-of-Use Pricing
Surge Pricing
Carbon Pricing
Shadow Pricing
Internal Transfer Pricing