Technical Debt Containment

batch: First Iteration/Batch 19/Wave 2

Accumulated Shortcut Debt Containment

notes: Broader cross-domain framing that makes the archetype less software-specific while preserving the familiar technical debt term.

Shortcut Debt Governance

notes: Emphasizes that locally convenient shortcuts create future obligations that need governance.

Debt Repayment Governance

notes: Useful but slightly narrower because the archetype also governs intake, caps, visibility, and closure.

Technical Debt Management

notes: Common software-oriented label. The draft keeps it as an alias and recognized variant, not the only meaning of the archetype.

Maintenance Debt Management

notes: Useful where deferred upkeep becomes future drag, but it risks confusion with Preventive Maintenance Cadence.

Opportunity Cost

role: Debt represents future options, time, reliability, adaptability, or comprehension consumed by past expedience.

Entropy

role: Unmaintained systems tend toward disorder, complexity, and loss of usable structure unless cleanup and simplification are funded.

Accountability

slug: accountability

role: Debt containment requires owners for shortcuts, repayment decisions, caps, and closure; otherwise debt becomes everyone’s concern and no one’s responsibility.

Resource Management

role: Repayment capacity, debt budgets, and cleanup effort must be allocated against new work and ongoing maintenance.

Constraint

role: Caps and intake rules limit how much future burden the system is allowed to accumulate.

Observability

slug: observability

role: Hidden debt must become visible through registers, scans, metrics, reviews, or user-facing drag signals.

Threshold

role: Debt caps, severity thresholds, and escalation triggers determine when repayment or work stoppage is required.

Feedback

role: Debt drag and repayment outcomes should feed back into intake decisions and prioritization rules.

Scheduling

role: Repayment requires recurring capacity, review windows, cleanup cycles, or event-triggered work blocks.

State and State Transition

role: Debt changes system state from flexible to constrained, from comprehensible to opaque, or from cheap-to-change to expensive-to-change.

Adaptive Capacity

role: The key loss from debt is often reduced ability to change safely when conditions shift.

Resilience

role: Debt containment protects the system’s ability to recover, maintain function, and absorb change without collapse.

Trade-offs

role: The archetype treats some shortcuts as legitimate tradeoffs while preventing those tradeoffs from becoming hidden permanent burdens.

Layering

role: Debt often accumulates in layers of decisions, exceptions, dependencies, and deferred explanations that interact over time.

Time Value of Money

role: The debt metaphor uses an interest-like idea: delayed repayment can become more expensive as dependencies and expectations grow.

components:
Debt Definition Boundary
Shortcut Intake Rule
Debt Register
Severity Classification
Debt Budget or Cap
Interest or Drag Signal
Repayment Cadence
Repayment Priority Rule
Accountable Debt Owner
Closure or Reclassification Rule
Debt Heatmap
Exception Record
Repayment Backlog
Debt-Service Ratio
Decision Postmortem Loop

mechanisms:
Technical Debt Register
Debt Severity Rubric
Refactoring or Cleanup Sprint
Debt Budget Review
Architecture or Process Decision Record
Quality or Health Scan
Debt-Service Dashboard
Repayment Reserve
Sunset or Replacement Plan
Exception Expiry Date

essence_one_line: Limit and repay accumulated shortcuts before they degrade adaptability, reliability, or comprehension.

compression_statement: When local expedience creates future obligations, make the debt stock visible, classify its severity, cap further accumulation, reserve repayment capacity, and close or reclassify debt before hidden drag compounds into fragility or blocked change.

core_intuition: A shortcut can be rational in the moment and still become costly later. Technical Debt Containment does not forbid shortcuts; it prevents them from becoming invisible promises that future actors must pay with confusion, rework, risk, slower delivery, or lost options.

canonical_formula: expedient shortcut + deferred cleanup + hidden future drag + no repayment rule => accumulating debt; visible stock + cap + owner + repayment cadence => contained debt

structural_problem: A system repeatedly accepts shortcuts, exceptions, undocumented decisions, compatibility burdens, brittle workarounds, or deferred cleanup to preserve short-term speed. Over time those local choices accumulate into a stock of future obligation that consumes capacity, slows change, increases fragility, and makes the system harder to understand or repair.

description: The system has legitimate pressure to deliver quickly, bypass ideal design, or defer cleanup, but the deferred obligations are growing.

description: The cost of shortcuts appears later as rework, slower decisions, defects, support burden, training difficulty, or blocked change rather than at the moment the shortcut is chosen.

description: Multiple shortcuts combine so that each new change becomes harder, riskier, or more dependent on undocumented context.

description: Cleanup is acknowledged informally but routinely loses to new work because no protected capacity or trigger exists.

description: No one can clearly say who owns the debt, who may accept new debt, who can close it, or when escalation is required.

symptom: Change becomes slower even though effort is high

interpretation: Past shortcuts are consuming current capacity through rework, coordination, deciphering, exception handling, or brittle dependency management.

symptom: Teams avoid touching certain areas

interpretation: A surface has become debt-heavy: people fear that small changes will trigger unexpected consequences.

symptom: Cleanup is always important but never urgent

interpretation: The system lacks a cap, repayment cadence, or escalation threshold that would convert acknowledged debt into scheduled work.

symptom: New work creates repeated exceptions

interpretation: The intake rule may be too permissive, letting new shortcuts enter without explicit future obligation or repayment plan.

symptom: Knowledge lives in a few experts

interpretation: Deferred documentation, unclear ownership, and tacit workaround memory have become comprehension debt.

symptom: Reported velocity hides deferred costs

interpretation: Metrics reward output while pushing cleanup, support, quality, or adaptation costs into the future.

root_tension: The system needs the option to take shortcuts under pressure, but every ungoverned shortcut can become a claim on future capacity. The archetype manages the tension between useful expedience now and preserved adaptability later.

reason: Use Deterioration Monitoring or Preventive Maintenance Cadence when the main issue is physical or operational deterioration without an accumulated shortcut obligation.

reason: A one-off defect does not require debt containment unless it represents a broader pattern of deferred obligation.

reason: A known design tradeoff is not debt if its future cost is accepted, bounded, and incorporated into the system’s normal operating model.

reason: Use Accumulation Compaction when the dominant issue is compressing, summarizing, or pruning accumulated records while preserving recoverability.

reason: Visibility alone may become performative if the system has no authority, capacity, or willingness to act on the debt stock.

structural_intervention: Define what counts as shortcut debt, expose the current debt stock, classify severity and drag, assign owners, cap additional accumulation, reserve repayment capacity, and close or reclassify items through explicit decision rules.

description: State which shortcuts, workarounds, exceptions, undocumented decisions, compatibility burdens, and deferred cleanups count as debt in this context.

description: Create a debt register or equivalent visibility mechanism that records owner, affected surface, origin, severity, expected drag, and repayment options.

description: Estimate how debt consumes future capacity through rework, delay, defects, support burden, complexity, safety risk, or reduced options.

description: Define how much debt is tolerable, when new debt may be accepted, who approves it, and what repayment obligation accompanies it.

description: Rank debt by severity, compounding rate, upcoming dependencies, safety impact, opportunity cost, and ease of repayment.

description: Allocate recurring or threshold-triggered capacity to reduce debt rather than relying on leftover time.

description: Mark debt as repaid, intentionally accepted, transferred, split, escalated, or targeted for replacement when local repayment is no longer economical.

description: Use repayment outcomes and drag signals to improve future shortcut decisions and prevent avoidable debt creation.

description: A shortcut may be accepted when speed, emergency, experimentation, or transition value exceeds future cost, but the obligation must be visible and assigned.

description: When debt exceeds the agreed cap, the system should reserve capacity for repayment, reject additional shortcuts, or require leadership-level exception approval.

description: Old debt is not always urgent; debt that blocks future change, threatens reliability, or spreads through dependencies may deserve earlier repayment.

description: If the same exception recurs, either repay it by redesigning the system or intentionally convert it into a governed standard.

description: When local cleanup cannot reduce the debt economically, trigger migration, redesign, or creative-destruction-style replacement planning.

invariant: Shortcuts remain visible as obligations.

description: A shortcut may be allowed, but it should not disappear from institutional memory before its future cost is addressed.

invariant: Future adaptability is not spent unknowingly.

description: Teams should know when they are trading future change capacity for present speed.

invariant: Debt ownership is explicit.

description: Every significant debt item or class has someone accountable for review, repayment, or formal acceptance.

invariant: Repayment capacity is protected.

description: Debt reduction should not depend entirely on unused leftover effort after new work.

invariant: Debt language is not punitive by default.

description: The archetype should make tradeoffs governable, not create shame that drives shortcuts underground.

outcome: Reduced hidden drag

description: Change, coordination, and support become less burdened by unexplained workarounds and brittle dependencies.

outcome: Improved adaptability

description: The system regains options because future changes no longer have to pay for every unexamined past shortcut.

outcome: More honest delivery tradeoffs

description: Speed gained through shortcuts is reported with its future cost rather than mistaken for free velocity.

outcome: Better prioritization of cleanup

description: Repayment focuses on debt with high drag, high compounding risk, or strategic importance rather than cosmetic cleanup.

outcome: Lower fragility and comprehension burden

description: Fewer hidden dependencies, unclear exceptions, and undocumented decisions make the system safer to operate and change.

prose_essence:
Technical Debt Containment governs the stock of future obligations created by expedient shortcuts. A shortcut may be reasonable at the time it is taken, but it becomes dangerous when the future cost is hidden, unowned, and allowed to compound. The archetype makes those obligations visible, limits further accumulation, and reserves repayment capacity before the debt quietly becomes fragility, delay, or loss of adaptability.

A broader plain-language name for the same pattern is **Accumulated Shortcut Debt Containment**. The familiar software term "technical debt" is retained because it is widely understood, but this draft treats the pattern as cross-domain: process debt, documentation debt, policy debt, organizational debt, infrastructure workaround debt, and software technical debt are all possible instances.

prose_when_to_use:
Use this archetype when a system has gained short-term speed by taking shortcuts that now impose future drag. The most important signal is not imperfection; it is an accumulated obligation that someone will have to pay through rework, cleanup, lost options, coordination burden, additional risk, or reduced comprehension.

It is especially useful when cleanup is acknowledged but never scheduled, when delivery velocity hides deferred costs, when teams avoid touching certain areas, when undocumented workarounds become normal, or when change becomes slow because every change must first pay for past expedience.

Do not use it for every flaw. A simple design that remains fit-for-purpose is not debt. Normal physical wear is usually Deterioration Monitoring or Preventive Maintenance Cadence. Record overload without shortcut-created obligation is closer to Accumulation Compaction.

prose_structural_problem:
The structural problem is a growing stock of future obligations. Local actors choose speed, continuity, emergency response, or convenience now. Those choices defer cleanup, explanation, simplification, migration, or standardization. Over time the deferred obligations form a hidden stock: brittle dependencies, undocumented assumptions, obsolete exceptions, manual workarounds, unclear ownership, stale policies, and process exceptions.

The root tension is that shortcuts can be useful and sometimes necessary, but ungoverned shortcuts spend future capacity without making that spending explicit. The future cost appears later as rework, defects, onboarding difficulty, coordination burden, slower change, support load, compliance confusion, or loss of strategic options.

prose_intervention_logic:
The intervention is debt-stock governance:

1. Define what counts as debt in the current context.
2. Record known debt items with owners, affected surfaces, severity, and expected drag.
3. Measure how unpaid debt consumes capacity or increases risk.
4. Set caps and intake rules for new shortcuts.
5. Prioritize repayment by compounding risk and strategic importance, not just by age or convenience.
6. Reserve repayment capacity.
7. Close, reclassify, accept, or escalate debt items explicitly.
8. Feed repayment lessons back into future shortcut decisions.

This archetype does not demand zero debt. It demands that debt be visible, bounded, owned, and repayable. A temporary shortcut with an owner, expiry date, and repayment plan may be healthy. A hidden shortcut that becomes a permanent dependency is the failure case.

prose_key_components:
### Debt Definition Boundary

This component defines what counts as debt: an expedient shortcut, workaround, deferred cleanup, unclear record, brittle dependency, or compatibility burden that creates future cost beyond normal operation. The boundary keeps the archetype from becoming a generic label for every imperfection.

### Shortcut Intake Rule

The intake rule determines when a new shortcut may be accepted, who may approve it, and what repayment obligation it creates. Debt containment is strongest at the moment debt is created, because invisible debt becomes harder to find later.

### Debt Register

The debt register maintains a visible inventory of known debt items. It records source, owner, affected surface, severity, expected drag, and repayment path. The register is a component, not the archetype itself; without caps and repayment capacity it becomes passive documentation.

### Severity Classification

Severity classification ranks debt by risk, reversibility, dependency breadth, affected users, and compounding potential. It prevents all cleanup from looking equally important.

### Debt Budget or Cap

A debt cap sets the amount of accumulated obligation the system is willing to carry. It can cap high-severity items, deferred cleanup time, exception volume, or debt-service burden. Without a cap, debt can be acknowledged but still grow without restraint.

### Interest or Drag Signal

This signal measures how unpaid debt consumes future capacity: slower change, more rework, recurring defects, expert bottlenecks, support burden, coordination overhead, or lost adaptability. It translates the debt metaphor into observable cost.

### Repayment Cadence

A repayment cadence allocates recurring or triggered capacity to reduce debt. It may be tied to releases, quarterly reviews, maintenance windows, migration milestones, or threshold breaches. The cadence prevents cleanup from depending on leftover time.

### Repayment Priority Rule

This rule decides which debt to repay first. It should prioritize compounding risk, dependency centrality, safety impact, upcoming change, and opportunity cost rather than whichever cleanup is easiest.

### Accountable Debt Owner

Every significant debt item or debt class needs an accountable owner. Ownership connects the debt record to action, review, escalation, and closure.

### Closure or Reclassification Rule

Debt needs endings. The closure rule defines when debt is repaid, accepted as a permanent tradeoff, transferred, split, escalated, or no longer relevant. Without closure, a debt register becomes a graveyard.

prose_common_mechanisms:
### Technical Debt Register

A technical debt register is an inventory artifact for known debt. It is useful when paired with owners, severity, repayment capacity, and closure criteria. A register alone does not contain debt.

### Debt Severity Rubric

A severity rubric classifies debt by impact, urgency, reversibility, dependency breadth, and compounding risk. It helps avoid the common failure mode where easy cleanup displaces high-drag cleanup.

### Refactoring or Cleanup Sprint

A cleanup sprint reserves time for repayment. In software this may mean refactoring. In other domains it may mean process simplification, policy cleanup, documentation repair, or exception retirement. The sprint is a mechanism, not the archetype.

### Debt Budget Review

A debt budget review compares the current debt stock, new debt intake, repayment progress, and debt cap. It works best when the review has authority to slow new work, reject new shortcuts, or reserve cleanup capacity.

### Architecture or Process Decision Record

A decision record captures why a shortcut was taken and what future obligation it creates. It is especially useful when the shortcut is legitimate but should not become invisible.

### Quality or Health Scan

A scan surfaces possible debt: code smells, stale records, process exceptions, obsolete policies, dependency risks, or manual workarounds. Scans provide signals, but human judgment still defines what counts as debt.

### Debt-Service Dashboard

A dashboard can show drag indicators such as rework rate, defect recurrence, lead time, exception volume, support burden, or cleanup backlog age. It should connect to decisions rather than serve as passive reporting.

### Repayment Reserve

A repayment reserve protects a portion of capacity for debt reduction. This can be a budget share, release allocation, review cycle, maintenance window, or staffing commitment.

### Sunset or Replacement Plan

When debt is too structural for local cleanup, the right repayment path may be replacement, migration, or sunset. This mechanism connects the archetype to Creative Destruction Management without collapsing into it.

### Exception Expiry Date

An expiry date prevents temporary shortcuts from becoming permanent hidden debt. It requires the exception to be repaid, renewed, or formally accepted.

prose_failure_modes:
**Debt theater** occurs when registers and dashboards exist but repayment capacity is not funded.

**Debt normalization** occurs when debt stays visible for so long that people stop expecting action.

**Punitive debt culture** occurs when debt language is used to blame teams rather than expose tradeoffs and system pressures.

**Cleanup capture by easy items** occurs when low-impact cleanup displaces high-drag structural debt.

**False velocity** occurs when delivery measures reward output while hiding the debt created by that output.

**Overzealous zero-debt policy** occurs when leaders prohibit useful temporary shortcuts and reduce adaptive capacity.

**Unbounded repayment scope** occurs when cleanup becomes a vague perfection campaign without closure criteria.

**Structural debt misclassified as local cleanup** occurs when an obsolete system should be replaced, but leaders keep treating it as a list of small cleanup tasks.

prose_neighbor_distinctions:
**Deterioration Monitoring** observes slow decline. Technical Debt Containment governs shortcut-created obligations. Monitoring can supply signals, but containment adds intake rules, caps, ownership, and repayment.

**Preventive Maintenance Cadence** schedules upkeep before predictable degradation becomes failure. Technical Debt Containment specifically manages a debt stock created by past expedience.

**Layered Record Accumulation** preserves layers of history. Technical Debt Containment may record layers of debt creation, but its goal is to reduce future drag, not preserve layers for interpretability.

**Accumulation Compaction** compresses or summarizes accumulated records. Technical Debt Containment repays accumulated obligations.

**Cumulative Exposure Budgeting** limits total exposure to risk or harm. Technical Debt Containment limits and repays obligations created by shortcuts.

**Compounding Control** manages growth dynamics. Debt containment may track compounding debt interest, but it also includes concrete debt items, owners, caps, and closure.

**Backlog Visibility** exposes pending work. Debt containment uses backlog-like visibility but adds the future-cost definition, intake rules, repayment priority, and caps.

prose_cross_domain_examples:
In **software engineering**, a team caps high-severity architectural debt and reserves release capacity for refactoring brittle dependencies before they block migration.

In **operations**, a service team treats recurring manual exceptions as process debt, ranks them by customer impact and training burden, and redesigns the highest-drag handoffs.

In **public policy**, emergency exemptions are given expiry dates and reviewed as policy debt before they become permanent administrative complexity.

In **knowledge management**, a research group treats undocumented assumptions and stale summaries as knowledge debt, then repays the highest-drag items before onboarding and review costs rise.

In **organizational design**, a fast-growing team maps coordination debt from informal heroics and unclear roles, then redesigns handoffs before scaling amplifies the burden.

prose_non_examples: A simple design that remains fit for its purpose is not debt merely because it is simple. A single bug fixed immediately is not debt. Normal wear on a machine is not debt unless it reflects a deferred obligation created by a known shortcut. A large archive that needs summarization is accumulation compaction, not debt containment, unless the archive burden comes from deferred cleanup obligations.

prose_tradeoffs: The main tradeoff is speed now versus adaptability later. Debt containment can slow visible new output in the short term because it makes hidden future costs explicit. It also creates measurement and governance overhead. Strong intake rules may reduce useful flexibility if applied rigidly. The debt metaphor itself is powerful but imperfect; not every future burden behaves like financial debt.

prose_invariants_to_preserve: The system must preserve visibility: shortcuts remain visible as obligations. It must preserve adaptability: future change capacity is not spent unknowingly. It must preserve ownership: debt has accountable stewards. It must preserve repayment capacity: cleanup is not left to leftover time. It must also preserve psychological safety: debt language should reveal tradeoffs, not punish people for constraints they inherited.

prose_target_outcomes: The intended outcomes are reduced hidden drag, improved adaptability, more honest tradeoffs, better cleanup prioritization, and lower fragility. A successful implementation does not necessarily eliminate all debt. It changes the system from unmanaged debt accumulation to governed debt stock: visible, bounded, owned, and deliberately repaid or accepted.

prose_parameter_dimensions:
**Debt tolerance** sets how much accumulated future obligation the system can carry before adaptability or reliability is materially impaired.

**Repayment cadence** determines how often cleanup capacity is reserved.

**Severity threshold** defines when a debt item triggers escalation or repayment ahead of new work.

**Intake strictness** determines how easily new shortcuts can enter the system.

**Interest model** estimates the future drag of unpaid debt, such as slower lead time, rework, recurring incidents, support cost, or lost options.

**Closure standard** defines the evidence needed to mark debt as repaid, accepted, transferred, or obsolete.

prose_variants_and_near_names:
The most important variant is **Software Technical Debt Containment**, where the debt surface is code, architecture, tests, dependencies, data models, or platform operations. **Process Debt Containment** applies to accumulated workflow exceptions and workarounds. **Policy Debt Containment** applies to temporary rules, exemptions, and unresolved institutional compromises. **Documentation / Knowledge Debt Containment** applies to deferred explanation and stale knowledge structures. **Organizational Debt Containment** is a candidate variant for role ambiguity, informal heroics, and unresolved coordination obligations.

Near names include technical debt, accumulated shortcut debt containment, shortcut debt governance, debt repayment governance, process debt, maintenance debt management, and cleanup backlog management. Mechanism names such as technical debt register, refactoring sprint, code linter, and cleanup checklist should point back to this archetype rather than become standalone archetypes.

Software Technical Debt Containment

short_definition: Contain shortcuts in code, architecture, tests, dependencies, infrastructure, or data models before they slow delivery or increase fragility.

distinctive_feature: The debt surface is technical in the software/platform sense, and mechanisms often include refactoring plans, architecture decision records, dependency cleanup, test debt reduction, and code-quality scans.

distinct_from_parent: The parent archetype covers accumulated shortcut debt across domains; this variant uses software-specific language and mechanisms.

still_same_parent_because: The structural logic is still debt-stock governance: intake discipline, visibility, caps, repayment, and drag monitoring.

use_when: Code or architecture choices were made for speed and now increase rework, defect risk, or change difficulty.

use_when: Teams repeatedly defer refactoring, dependency cleanup, test coverage, or documentation needed for future change.

use_when: Delivery velocity appears high because cleanup cost is hidden outside the release measure.

example: A team reserves release capacity to retire brittle integration code before it blocks a platform migration.

example: A data team records and repays schema shortcuts that repeatedly break downstream reports.

failure_modes: Refactoring theater without reducing future drag

failure_modes: Registers filled with code smells but no prioritization or owner

Process Debt Containment

short_definition: Contain accumulated workarounds, exceptions, informal handoffs, and outdated procedures before they create operating drag or quality loss.

distinctive_feature: The debt is embedded in workflow behavior rather than code or physical assets.

distinct_from_parent: It emphasizes operating routines, handoffs, exceptions, and informal norms as the debt surface.

still_same_parent_because: The intervention remains visibility, owner assignment, caps, repayment, and prevention of hidden compounding.

use_when: A process has many exceptions that workers must remember manually.

use_when: Workarounds are faster locally but make coordination, training, compliance, or quality harder later.

failure_modes: Workers hide workarounds because debt governance is punitive

failure_modes: Cleanup removes useful local adaptation without replacing it with a better standard

Policy Debt Containment

short_definition: Contain accumulated policy exceptions, obsolete rules, unresolved tradeoffs, and temporary reforms that create future governance drag.

distinctive_feature: The debt is embedded in rules, precedents, exceptions, and institutional commitments.

distinct_from_parent: It emphasizes legitimacy, fairness, interpretation, and administrative burden as repayment concerns.

still_same_parent_because: The central work is still to expose, bound, prioritize, and repay future obligations created by past expedience.

Precedent

slug: precedent

use_when: Temporary policies or exemptions become normal without explicit review.

use_when: Past compromises make future policy change harder, less legible, or less fair.

failure_modes: Debt governance becomes a justification for abrupt policy removal without transition support

name: Documentation / Knowledge Debt Containment

short_definition: Contain deferred explanation, stale records, missing provenance, and undocumented decisions before they damage comprehension and transfer of knowledge.

distinctive_feature: The debt manifests as comprehension drag, onboarding burden, duplicated inquiry, and fragile institutional memory.

distinct_from_parent: It names the knowledge-management surface of accumulated shortcut debt.

still_same_parent_because: The same containment logic applies: define debt, make it visible, prioritize repayment, and prevent new hidden accumulation.

use_when: Teams rely on oral memory or heroic experts because records are stale or absent.

use_when: Documentation cleanup is repeatedly deferred while confusion and onboarding cost grow.

failure_modes: Cosmetic documentation updates that do not restore interpretability

failure_modes: Over-documentation that adds new cognitive burden

Organizational Debt Containment

short_definition: Contain accumulated role ambiguity, unresolved conflicts, informal dependencies, and unmanaged exceptions that reduce organizational adaptability.

distinctive_feature: The debt lives in roles, norms, coordination pathways, and unresolved organizational commitments.

distinct_from_parent: It stresses people, authority, culture, and coordination rather than artifacts or code.

still_same_parent_because: It still involves accumulated local expedience becoming future drag, requiring visibility, ownership, limits, and repayment.

use_when: A group keeps shipping work by relying on unclear roles, tacit heroics, or unresolved coordination debt.

use_when: Past shortcuts make future reorganization, delegation, or scaling harder.

failure_modes: Using debt language to blame people rather than redesign structures

failure_modes: Repayment efforts that disrupt needed informal coordination without replacement

near_names:
Technical Debt
Accumulated Shortcut Debt Containment
Debt Repayment Governance
Cleanup Backlog Management
Maintenance Debt Management
Refactoring Budget
Process Debt


Teleconnection Mapping

type: archetype

source: generated

batch: First Iteration/Batch 09

Distal Driver Mapping

notes: Emphasizes the remote-driver part of the archetype.

Remote Causal Mapping

notes: Useful when the distant relation is framed causally, but should still require a mediating dynamic and impact pathway.

Distant Dependency Mapping

notes: Helpful when dependency is the visible form of the teleconnection, but narrower than the parent.

Telecoupling Mapping

notes: Domain-adjacent terminology for distant coupled systems, especially human-environment contexts.

Ripple Effect Mapping

notes: Near name when the emphasis is on consequences propagated from distant dynamics.

source_primes: teleconnection relation network

related_primes: coupling observability causality foreseeing scale cross_impact_analysis feedback

slug: teleconnection

slug: relation

slug: network

slug: coupling

slug: causality

slug: foreseeing

slug: scale

slug: feedback

components:
Local Condition Anchor
Remote Driver Set
Mediating Dynamic
Transmission Pathway
Lag Structure
Coupling Strength Estimate
Distal Signal Set
Local Impact Pathway
Boundary Expansion Rule
Confidence and Uncertainty Note
Response Translation Rule
Scenario Branch Set
Cross-Boundary Owner Map
Rival Explanation Check

mechanisms:
Teleconnection System Map
Distal Driver Scan
Lagged Indicator Analysis
Propagation Pathway Model
Cross-Boundary Dependency Workshop
Remote Leading Indicator Dashboard
Scenario Teleconnection Brief
Climate Teleconnection Index

essence_one_line: Map distant but dynamically connected phenomena so local action can account for remote causes, risks, opportunities, and ripple effects.

compression_statement: When a local condition is shaped by remote dynamics that are invisible inside the local boundary, identify the distant drivers, shared mediating dynamics, lag structures, transmission pathways, and local impact routes so the system can explain, monitor, and respond to remote coupling rather than treating local symptoms as isolated.

core_intuition: Some causes are not nearby. A local problem may be the downstream expression of an oceanic circulation, supply-chain dependency, market contagion, migration path, political shock, upstream infrastructure failure, or distant narrative shift. Teleconnection Mapping works by expanding the causal boundary just enough to include the remote dynamic that actually carries influence into the local system.

canonical_formula: local condition + remote driver + mediating dynamic + lagged transmission pathway → actionable remote-local map

structural_problem: A local outcome, risk, failure, opportunity, or pattern is affected by distant events or system states that are not visible within the local boundary. Local actors therefore misdiagnose the situation, monitor the wrong signals, react too late, or optimize locally while ignoring the remote dynamics that shape their real conditions.

condition: Local-only explanations keep failing.

diagnostic_question: Do local interventions underperform because they address symptoms while a remote driver keeps reshaping the local condition?

condition: A distant shock produces local consequences.

diagnostic_question: Can a remote event, market, climate pattern, policy, conflict, infrastructure state, or ecological change plausibly propagate into the local system?

condition: The local system has hidden upstream, downstream, or cross-boundary dependencies.

diagnostic_question: Would a disruption or shift outside the local boundary alter local supply, demand, behavior, risk, resources, obligations, or operating conditions?

condition: Remote indicators move before local symptoms appear.

diagnostic_question: Are there distal signals that provide earlier evidence than local metrics?

condition: Effects appear delayed, indirect, or transformed.

diagnostic_question: Does the remote dynamic reach the local system through lags, intermediaries, flows, institutions, markets, networks, or feedback loops?

condition: A local action may create remote consequences that later return.

diagnostic_question: Could local optimization displace costs, risks, or pressures into a remote system that eventually feeds back?

symptoms: Local teams are surprised by disruptions that were visible elsewhere earlier.

symptoms: Root-cause analyses stop at the local boundary even when upstream or distant factors are repeatedly implicated.

symptoms: Risk registers mention global, regional, or cross-sector forces but do not show how those forces reach local operations.

symptoms: Forecasts miss turning points because they track local lagging indicators instead of remote leading dynamics.

symptoms: Separate organizations each see part of the pathway, but no one has an integrated remote-local picture.

symptoms: Local policy, planning, or investment decisions unintentionally amplify remote exposure.

symptoms: Correlations are noticed between remote and local events, but the mediating mechanism is unclear or contested.

root_tension: The local boundary is useful for ownership and action, but it is too narrow for explanation. Expanding the boundary improves causal understanding, yet overexpanding it can turn the map into an everything-affects-everything narrative. The archetype must include enough remote structure to explain local conditions without losing practical focus.

anti_signatures: The relevant cause is fully local and no remote driver or cross-boundary pathway is needed.

anti_signatures: The relation is merely long-distance communication or transport, with no shared dynamic, lag structure, or local impact pathway requiring analysis.

anti_signatures: The task is general horizon scanning for emerging trends rather than mapping a specific remote-local linkage.

anti_signatures: The evidence is only a superficial correlation and no plausible mediating dynamic can be described or tested.

anti_signatures: The problem is simply an undocumented dependency; Dependency Exposure may be sufficient if distance, lag, and dynamic propagation are not central.

anti_signatures: The desired output is a real-time alerting system without a structural map; Remote Signal Early Warning or observability instrumentation may be more precise.

structural_intervention: Expand the analysis boundary from the local condition to the remote dynamics that shape it, then build a map that connects remote drivers, mediating dynamics, transmission pathways, lags, coupling strength, local impact routes, and decision implications.

step: Anchor the local condition.

logic: Name the local outcome or decision that needs better explanation, monitoring, or intervention so the map has a practical focus.

step: Identify candidate remote drivers.

logic: Look for distant shocks, states, flows, policies, markets, ecologies, infrastructures, actors, or narratives that could shape the local condition.

step: Specify the mediating dynamic.

logic: Describe the shared process that carries influence across distance, such as atmospheric circulation, supply flow, financial exposure, migration, information diffusion, epidemiological spread, ecological connectivity, or institutional rule transmission.

step: Trace the transmission pathway.

logic: Map how the remote driver moves through intermediaries, dependencies, transformations, and boundaries until it reaches the local system.

step: Estimate lags and coupling strength.

logic: Record how long propagation takes, how reliable the link is, which conditions amplify or dampen it, and where uncertainty remains.

step: Select distal signals.

logic: Choose remote indicators that are observable, meaningful, and tied to the mapped pathway rather than collecting distant metrics indiscriminately.

step: Translate to local impact and action.

logic: Identify local groups, assets, decisions, thresholds, or interventions affected by the teleconnection and specify how the map should alter local planning or response.

step: Review and update the map.

logic: Revisit the map as evidence changes, pathways shift, remote systems evolve, or local decisions alter exposure.

rule: Require a mediating dynamic, not just distance.

rationale: The archetype depends on an explainable remote-local pathway. A distant fact with no transmission mechanism is background context, not a teleconnection.

rule: Expand the boundary only as far as the local decision requires.

rationale: Unbounded mapping creates analytical overload. The map should include the remote dynamics that materially affect local action.

rule: Separate evidence strength from narrative plausibility.

rationale: Remote links can sound convincing. Confidence notes and rival explanations keep the map from becoming speculative storytelling.

rule: Represent lag explicitly.

rationale: Remote dynamics often matter because they move before local symptoms appear or because local consequences arrive after a delay.

rule: Translate the map into local implications.

rationale: A teleconnection map is useful only when it changes explanation, monitoring, preparedness, coordination, investment, or intervention design.

rule: Treat signals as pathway-dependent.

rationale: A remote metric becomes meaningful when the map explains why it should affect the local condition.

invariant: Remote-local pathway explicitness

why_it_matters: Every important link should show how influence travels rather than merely naming distant causes.

invariant: Local action relevance

why_it_matters: The map must stay tied to decisions, risks, outcomes, or interventions that local actors can use.

invariant: Boundary discipline

why_it_matters: The analysis boundary must expand enough to include real drivers but not so far that the map loses discrimination.

invariant: Lag visibility

why_it_matters: Timing determines whether the map supports explanation, early preparation, or retrospective accountability.

invariant: Uncertainty traceability

why_it_matters: Decision-makers need to know which links are observed, inferred, contested, or speculative.

invariant: Pathway updateability

why_it_matters: Remote dynamics and local exposure change; a static map eventually becomes misleading.

outcome: Improved local diagnosis

description: Local symptoms can be explained through remote drivers and pathways rather than misattributed to nearby causes only.

outcome: Earlier recognition of change

description: Distal signals and lag structures make it possible to notice approaching local effects before direct local indicators move.

outcome: Better preparedness and resilience

description: Local actors can plan for remote disruptions, opportunities, or cascading effects before they arrive.

outcome: More coherent cross-boundary coordination

description: Actors who see different parts of the pathway can coordinate around a shared map of remote-local coupling.

outcome: Reduced surprise from indirect effects

description: The system becomes less vulnerable to hidden upstream, downstream, or cross-scale dependencies.

outcome: More targeted monitoring

description: Monitoring shifts from generic dashboards to signals that are structurally connected to local outcomes.

prose_essence:
Teleconnection Mapping is the move of looking beyond the local boundary when the local condition is being shaped elsewhere. It asks: what distant driver is connected to this local outcome, what dynamic carries the influence, how long does it take to arrive, and what local decisions should change because of it?

The archetype is not simply “consider the wider context.” It requires a remote-local pathway. The useful map names the local condition, the distant driver, the mediating dynamic, the transmission route, the lag structure, the strength and uncertainty of the coupling, and the local impact pathway.

prose_when_to_use:
Use this archetype when local-only explanation is too narrow. Typical signals include repeated surprise from remote disruptions, local interventions that fail because they do not address upstream drivers, or risk planning that mentions global forces without showing how they become local effects.

It is especially useful when remote indicators appear before local symptoms, when dependency pathways cross organizational or jurisdictional boundaries, or when a local decision could create consequences elsewhere that later feed back. The archetype is weakest when the remote relation is speculative, when the relevant causes are fully local, or when the user only needs a generic trend scan.

prose_structural_problem:
The structural problem is a boundary mismatch. The local system is the place where effects are observed and decisions must be made, but the drivers sit partly outside that local frame. Because the causal boundary is too small, local actors misdiagnose symptoms, monitor lagging signals, or react after the remote driver has already propagated into local exposure.

Teleconnections are also easy to overstate. Distant events can be rhetorically convenient explanations. A good map therefore distinguishes actual pathways from loose associations and separates observed evidence from plausible but unconfirmed hypotheses.

prose_intervention_logic:
The intervention is to expand the analytical boundary just enough to include the remote dynamic that matters. Start with the local condition, then identify candidate remote drivers. For each driver, ask what mediating dynamic could carry influence across distance: a supply flow, price mechanism, migration route, ecological connection, information network, legal rule, atmospheric circulation, or feedback loop.

The map then traces the transmission pathway and lag. It records where the remote signal appears, how it changes as it moves, when local effects become visible, and which groups or assets experience them. Finally, it translates the map into local decisions: monitoring priorities, preparedness moves, escalation paths, investment choices, or coordination needs.

prose_key_components:
### Local Condition Anchor

`local_condition_anchor` — Defines the local outcome, risk, behavior, or state that needs explanation or intervention. Teleconnection mapping begins with a grounded local question. Without a local anchor, the map drifts into broad environmental scanning rather than explaining how remote dynamics matter here.

### Remote Driver Set

`remote_driver_set` — Identifies distant events, states, actors, flows, shocks, or patterns that may influence the local condition. A remote driver is not merely far away. It must plausibly participate in a dynamic that can transmit influence across distance, scale, institution, market, ecology, network, or time.

### Mediating Dynamic

`mediating_dynamic` — Specifies the shared process, circulation, flow, rule, market, network, ecology, contagion, narrative, or feedback structure that connects distant phenomena. This is the central differentiator from ordinary relation mapping. The link should be carried by a dynamic, not asserted as a loose association.

### Transmission Pathway

`transmission_pathway` — Shows how influence moves from the remote driver through mediators, intermediaries, flows, dependencies, prices, norms, organisms, messages, or infrastructures into the local system. The pathway may include multiple hops and transformations. It should be explicit enough that assumptions can be tested and responsibility can be assigned.

### Lag Structure

`lag_structure` — Represents the time delay between remote change, intermediate propagation, local detection, and local impact. Teleconnections often become actionable because the remote signal appears before the local consequence. Lag structure prevents both premature reaction and late recognition.

### Coupling Strength Estimate

`coupling_strength_estimate` — Assesses how strongly, reliably, and conditionally the remote dynamic affects the local condition. The estimate may be quantitative, qualitative, scenario-based, or expert-assessed. Its purpose is to avoid treating every distant relation as equally important.

### Distal Signal Set

`distal_signal_set` — Selects observable remote indicators that can reveal movement in the distant driver or mediating dynamic. Signals are useful only when they are tied back to a mapped pathway. A dashboard of remote indicators without a teleconnection model is monitoring, not this archetype by itself.

### Local Impact Pathway

`local_impact_pathway` — Translates remote dynamics into concrete local effects, affected groups, operational thresholds, risk concentrations, or decision points. This component keeps the map actionable. It asks what changes locally, who experiences the effect, and where intervention becomes possible.

### Boundary Expansion Rule

`boundary_expansion_rule` — Defines when the analysis boundary must expand beyond the local system because important causes, constraints, or effects originate elsewhere. The rule prevents two errors: local-only explanations that miss remote causes, and unbounded maps that absorb every global factor without discriminating relevance.

### Confidence and Uncertainty Note

`confidence_and_uncertainty_note` — Records evidence quality, uncertainty, rival explanations, missing data, and confidence in each remote-local link. Remote couplings are easy to overclaim. Explicit uncertainty makes the map usable for decision-making without pretending that all pathways are proven.

### Response Translation Rule

`response_translation_rule` — Connects mapped teleconnections to local decisions, preparedness moves, monitoring priorities, governance escalation, or intervention choices. Teleconnection mapping should not end at explanation. The response rule says how the map changes local action without collapsing into an early-warning or control system.

Optional components such as scenario branches, cross-boundary owner maps, and rival-explanation checks make the core map safer and more useful when the pathway is uncertain or politically distributed.

prose_common_mechanisms:
Mechanisms are implementations of Teleconnection Mapping, not substitutes for it. A mechanism should help discover, represent, test, communicate, or monitor the remote-local pathway.

### Teleconnection System Map

`teleconnection_system_map` (artifact) — A visual or structured map that links remote drivers, mediating dynamics, transmission pathways, lags, and local impacts. This mechanism implements the archetype by making the remote-local structure inspectable; it is not the archetype itself because the same logic can be implemented through models, workshops, dashboards, or scenario briefs.

### Distal Driver Scan

`distal_driver_scan` (method) — A structured search for remote events, policies, markets, ecologies, social dynamics, or infrastructure states that may shape the local condition. The scan supplies candidate remote drivers. It must be followed by pathway testing or it becomes general horizon scanning.

### Lagged Indicator Analysis

`lagged_indicator_analysis` (method) — An analysis that compares remote indicators, intermediate changes, and local outcomes across time windows to estimate delay and sequence. This mechanism is useful when data exist, but qualitative lag estimates may be enough in domains where formal time series analysis is impossible.

### Propagation Pathway Model

`propagation_pathway_model` (method) — A causal, network, process, or flow model that simulates or traces how remote changes propagate toward local consequences. The model helps test whether the proposed pathway is coherent and where intervention points lie.

### Cross-Boundary Dependency Workshop

`cross_boundary_dependency_workshop` (ritual) — A facilitated session where participants from different parts of the pathway identify remote dependencies, weak links, handoffs, lags, and local exposure. Useful when no single actor sees the whole pathway. It implements the archetype socially by integrating distributed knowledge.

### Remote Leading Indicator Dashboard

`remote_leading_indicator_dashboard` (metric_or_dashboard) — A monitoring display that tracks selected distal signals once the teleconnection map has identified which signals matter. The dashboard is a mechanism under this archetype or under Remote Signal Early Warning. Without a mapped dynamic, it is merely a collection of remote metrics.

### Scenario Teleconnection Brief

`scenario_teleconnection_brief` (document) — A concise decision document describing how alternative remote developments could affect local choices, thresholds, and preparedness options. This mechanism is useful when the map must inform leadership, governance, policy, or operational planning rather than remain a technical artifact.

### Climate Teleconnection Index

`climate_teleconnection_index` (metric_or_dashboard) — A domain-specific indicator, such as a climate pattern index, used as a distal signal for climate-related teleconnection analysis. Reconciliation controls classify this as mechanism/component material, not a standalone solution archetype. It can instantiate the distal-signal part of the map.

prose_failure_modes: Common failures include mistaking correlation for teleconnection, expanding into an everything-affects-everything map, misestimating lags, skipping mediators, attributing too much to remote drivers, allowing the map to go stale, or producing a technically accurate map that decision-makers cannot use. Each failure is mitigated by pathway discipline, rival-explanation checks, explicit lag ranges, ownership for updates, and response translation rules.

prose_neighbor_distinctions:
Teleconnection Mapping is distinct from Relation Mapping because it is not any relation; it is distant linkage through a mediating dynamic. It is distinct from Dependency Exposure because it is not only a hidden dependency; it emphasizes remote propagation, lag, and local impact. It is distinct from Whole-System Impact Mapping because the direction of analysis starts with remote drivers shaping a local condition, though the two can be combined.

It also differs from Horizon Scanning. Horizon scanning looks broadly for emerging external change; Teleconnection Mapping explains how selected remote changes reach the local system. Remote Signal Early Warning is a likely subtype or successor: it uses the map to select distal indicators, thresholds, and preparedness actions.

prose_cross_domain_examples: In climate adaptation, the map can connect a distant ocean-atmosphere pattern to seasonal rainfall, reservoir levels, agricultural demand, and emergency planning. In supply-chain resilience, it can connect a remote factory or port disruption to inventory buffers and local customer commitments. In finance, it can connect remote credit conditions to local borrowing costs and project viability. In public health, it can connect outbreak trends in travel-connected regions to staffing, supplies, and care capacity. In ecology, it can connect upstream land use or migratory species pathways to local restoration outcomes. In geopolitical planning, it can connect distant conflict to energy routes, insurance, vendor reliability, and continuity decisions.

prose_non_examples: A global office map is not Teleconnection Mapping unless it shows dynamic pathways. A quarterly list of international news items is horizon scanning, not a teleconnection map. A local maintenance checklist does not need this archetype if the cause is local. A supplier dependency matrix becomes this archetype only when it includes remote drivers, propagation, timing, and local impact. A dashboard of unexplained remote metrics is monitoring, not mapping.

prose_tradeoffs:
The main tradeoff is explanatory reach versus practical focus. Expanding the boundary makes diagnosis more realistic, but too much expansion creates an unmanageable map. Distal signals create early awareness, but they also raise false-alarm risk. Rich pathways improve causal understanding, but they may require evidence that is incomplete or distributed across actors who do not normally coordinate.

Another tradeoff is actionability versus oversimplification. Decision-makers need a clear map, but the map should not erase uncertainty, mediators, or distributional effects simply to look decisive.

prose_invariants_to_preserve: Preserve remote-local pathway explicitness: each important link should say how influence moves. Preserve local action relevance: the map must stay tied to decisions. Preserve boundary discipline: include remote dynamics that matter without absorbing everything. Preserve lag visibility, because timing determines whether the map supports explanation, anticipation, or response. Preserve uncertainty traceability, so users can see which links are observed, inferred, contested, or speculative.

prose_target_outcomes: A successful Teleconnection Mapping draft improves local diagnosis, reduces surprise from indirect effects, helps actors notice remote change earlier, and makes cross-boundary coordination more coherent. It also shifts monitoring from generic external metrics toward selected distal signals that are structurally tied to local outcomes.

prose_parameter_dimensions:
Important tuning dimensions include the local anchor, distance definition, boundary width, pathway granularity, coupling strength, lag window, signal reliability, confidence level, update cadence, and response threshold. A map for emergency preparedness may need shorter lags and clearer triggers; a map for strategic planning may tolerate broader scenarios and lower confidence if it preserves useful options.

Scale is another tuning dimension. The “remote” side may be geographically distant, institutionally distant, temporally upstream, economically upstream, or located at a different system scale. The right map names which kind of distance matters and why.

prose_variants_and_near_names:
`remote_signal_early_warning` is a strong promotion candidate when the map becomes an alert-and-response system. `teleconnection_impact_mapping` is captured as merge-review material because it appears to name the same parent pattern with an emphasis on local consequences. `teleconnection_risk_mapping` is a risk-focused variant useful when the purpose is exposure, contingency, and resilience planning.

Near names include distal driver mapping, remote causal mapping, distant dependency mapping, telecoupling mapping, and ripple effect mapping. These should point back to the parent when they require a remote driver, mediating dynamic, lag, and local impact pathway.

Remote Signal Early Warning

short_definition: Monitor distal signals that reveal approaching local change before direct local indicators appear.

distinctive_feature: Turns the map into an alerting and preparedness function by emphasizing signal thresholds and response timing.

distinct_from_parent: Teleconnection Mapping explains and represents remote-local coupling. Remote Signal Early Warning operationalizes selected distal signals so local actors can prepare before local symptoms arrive.

still_same_parent_because: It relies on a teleconnection map to know which remote signals are meaningful and what local consequences they imply.

source_primes: teleconnection observability foreseeing

use_when: The remote-local pathway is established enough that distal indicators can trigger preparation.

use_when: Local symptoms appear too late for effective response.

use_when: Action depends on thresholds, alerts, escalation, or preparedness rather than only structural explanation.

Distal Signal Set

role: Selects observable remote indicators tied to the mapped pathway.

Lag Structure

role: Defines how much warning time the remote signal provides.

Response Translation Rule

role: Connects signals to preparation, escalation, or local action.

Remote Leading Indicator Dashboard

role: Tracks selected distal indicators after the pathway has been mapped.

Threshold Alert Rule

role: Specifies when a signal should trigger investigation or response.

example_domains:
supply-chain resilience
climate risk
public health preparedness
financial contagion monitoring

domain: Supply chain

example: Monitoring upstream port congestion as an early warning for local inventory shortages.

domain: Public health

example: Tracking outbreak indicators in connected regions before local case counts rise.

failure_modes: False alarms when distal signals are weakly coupled to the local outcome.

failure_modes: Late action when lag assumptions are wrong or thresholds are too conservative.

Teleconnection Impact Mapping

variant_type: subtype

short_definition: Map distant but dynamically linked systems so remote drivers and ripple effects can be anticipated locally.

distinctive_feature: Emphasizes impact translation and consequence pathways rather than the general remote-local mapping frame.

distinct_from_parent: It may be only a renamed emphasis within Teleconnection Mapping unless it develops unique impact-assessment components or governance requirements.

still_same_parent_because: The core intervention remains mapping distant dynamic linkage, remote drivers, lags, and local impact pathways.

source_primes: teleconnection network scale

use_when: The emphasis is on how a remote driver creates local consequences across scales or system layers.

use_when: Impact pathways, affected groups, and downstream consequences matter more than ongoing monitoring.

Local Impact Pathway

role: Shows who or what is affected locally by the remote dynamic.

Coupling Strength Estimate

role: Assesses how material the remote-local impact is likely to be.

Scenario Teleconnection Brief

role: Summarizes possible remote-impact pathways for decisions.

example_domains:
climate adaptation
geopolitical risk
market contagion
ecological connectivity

Teleconnection Risk Mapping

short_definition: Map distant dynamic linkages primarily to reveal local risk exposure before direct local evidence appears.

distinctive_feature: Emphasizes exposure, risk concentration, and contingency implications.

distinct_from_parent: The parent can map opportunity, explanation, coordination, or risk; this variant is specifically risk-oriented.

still_same_parent_because: It still uses the same remote-driver, mediating-dynamic, lag, and local-impact structure.

source_primes: teleconnection foreseeing boundary

use_when: The local system is exposed to remote shocks, disruptions, or cascading effects.

use_when: The desired output is risk visibility, contingency planning, or resilience investment.

Local Impact Pathway

role: Connects remote shocks to local exposure.

Confidence and Uncertainty Note

role: Prevents overconfident risk narratives.

Cross-Boundary Dependency Workshop

role: Surfaces hidden dependencies across organizations or jurisdictions.

example_domains:
supply-chain resilience
infrastructure planning
financial risk
food security

failure_modes: Overexpanding risk maps until every remote event appears urgent.

near_names:
Distal Driver Mapping
Remote Causal Mapping
Ripple Effect Mapping
Telecoupling Mapping
Distant Dependency Mapping


Tempo-Matched Response Governance

batch: Batch 11

canonical_family: Rate & Duration Mismatch

aliases:
Response Tempo Alignment
Two-Clock Response Alignment
Right-Time Response Design
Cadence-to-Environment Matching
Environmental Clock Alignment
Stale Decision Prevention
Decision Freshness Governance
Action-Environment Tempo Fit
Timing-Window Response Design
Pace-Matched Intervention Design

source_primes: tempo_mismatch temporal_dynamics feedback observability scheduling adaptation requisite_variety controllability decision coupling

slug: scheduling

slug: adaptation

slug: controllability

slug: decision

slug: time

slug: latency

slug: flow

slug: queueing

slug: buffering

slug: threshold

slug: monitoring

slug: uncertainty

slug: risk

slug: stationarity

slug: periodicity

slug: intermittency

slug: synchronization

components:
Environmental Clock Profile
Response Cycle Inventory
Freshness Validity Window
Action Lead-Time Map
Readiness and Expiry Window Register
Tempo-Fit Threshold
Decision Latency Budget
Preauthorization Envelope
Deliberate Wait Gate
Stale Decision Revalidation Gate
Cadence Adaptation Rule
Tempo Owner and Exception Path
Tempo Sandbox
Absorptive Capacity Monitor
Tempo Exception Audit Trail

mechanisms:
Environmental Time-Constant Estimate
Decision Latency Scorecard
Freshness Timer or Timestamp Badge
Event-Triggered Escalation Rule
Preapproved Response Playbook
Readiness Gate
Hold-and-Revalidate Protocol
Rolling Forecast Resynchronization
Queue-Jump Authority
Takt or Cadence Board
Lead-Time Decomposition Map
Slow-Release or Phased Absorption Plan

essence_one_line: Make the response clock fit the environment clock so correct decisions arrive while they are still useful and not before the target is ready.

compression_statement: Tempo-Matched Response Governance applies when a system can produce correct decisions or capable actions but at the wrong pace relative to the environment. It makes the external clock explicit, inventories the internal response cycle, defines freshness and readiness windows, assigns decision-latency budgets, and creates fast lanes, slow gates, preauthorization envelopes, and stale-decision revalidation so action lands inside the window where it can still change outcomes.

core_intuition: Good content is not enough. A decision has a half-life, an action has a lead time, and the world has its own rhythm. When those clocks diverge, the system either arrives after the opportunity closes or pushes before the environment can absorb the move. The repair is not simply to go faster; it is to govern the relation between clocks.

canonical_formula: internal_response_clock != environmental_change_clock -> correct_action_wrong_time; environmental_clock_profile + response_cycle_inventory + freshness_window + readiness_window + latency_budget + acceleration_or_hold_rule + stale_revalidation -> right_time_response

structural_problem: A system senses, decides, approves, mobilizes, or acts on a cadence that is out of phase with the environment it must influence. Decision content may be correct and resources may be adequate, but outcomes degrade because the state being acted on has changed, the opportunity window has closed, the target is not yet ready, or the action propagates after the relevant condition has moved elsewhere.

condition: External state changes faster or slower than the internal process

description: The environment has a meaningful time constant, readiness window, or expiry window that differs from ordinary decision cadence.

condition: Decision freshness matters

description: Observed state, forecasts, approvals, or selected actions lose validity if execution is delayed.

condition: Action lead time is nontrivial

description: The intervention requires preparation, authorization, transport, adoption, propagation, or recovery time before it affects outcomes.

condition: The same action has different effects at different moments

description: Early action is premature, late action is irrelevant, and right-time action is effective.

condition: Governance cadence is inherited rather than designed

description: Meetings, approval chains, release trains, budgets, or policy cycles run on tradition rather than on the clock of the problem.

condition: Operators improvise around the clock mismatch

description: Front-line workarounds, unofficial fast paths, or shadow delays appear because the formal system is too slow or too early.

symptoms: Reports are accurate when written but stale when action begins.

symptoms: Teams repeatedly say the right decision was made too late.

symptoms: Urgent issues wait in ordinary queues while low-tempo issues receive excessive attention.

symptoms: Actions are launched before receiving systems, users, markets, ecosystems, or institutions are ready.

symptoms: Escalation happens only after the opportunity or threat has changed phase.

symptoms: Fast execution is celebrated even when it overloads absorption capacity.

symptoms: Repeated rework occurs because the world changes during approval.

symptoms: Policy, release, or budgeting cycles miss the actual field rhythm.

root_tension: The system optimizes decision quality, procedural legitimacy, resource efficiency, or coordination on one clock while outcome causality unfolds on another clock.

anti_signatures: The problem is only poor decision content, not timing.

anti_signatures: The environment is slow and stable enough that ordinary cadence remains valid.

anti_signatures: The issue is generic handoff synchronization among recurring cycles rather than action-environment phase fit.

anti_signatures: The core failure is amount or capacity shortage rather than the time at which capacity becomes useful.

anti_signatures: The system needs more observation resolution but action timing is already adequate.

anti_signatures: The action has no meaningful expiry, readiness, or lead-time dependence.

structural_intervention: Create a governed timing interface between the internal response cycle and the external environmental clock. Measure both clocks, identify freshness and readiness windows, budget decision and action latency, install acceleration paths when the environment is faster than ordinary governance, install hold gates when the system is faster than environmental readiness, and require revalidation when decisions age past their useful window.

action_logic: Name the environmental clock: change rate, hazard growth, demand window, readiness interval, competitor movement, ecological threshold, or institutional absorption pace.

action_logic: Map the internal response cycle from sensing through realized effect, not merely through decision approval.

action_logic: Define when evidence, decisions, forecasts, and authorizations expire or require revalidation.

action_logic: Compare total response lead time with opportunity, readiness, and expiry windows.

action_logic: Classify the mismatch: too slow, too early, jittery, over-synchronized, under-sampled, approval-bound, or propagation-bound.

action_logic: Redesign the clock relation using fast lanes, preauthorized moves, smaller reversible actions, staged release, deliberate waiting, buffering, or cadence changes.

action_logic: Assign ownership for invoking tempo exceptions and resolving speed-versus-safety tradeoffs.

action_logic: Monitor whether actions actually land inside the useful window and adjust the tempo rule after feedback.

rule: Freshness rule

logic: Do not execute a decision whose evidence or assumptions have exceeded the defined validity window without revalidation.

rule: Acceleration rule

logic: Use a preauthorized fast path when projected response lead time exceeds the remaining useful window and bounded action is safer than waiting.

rule: Hold rule

logic: Delay or phase the action when the environment is not yet ready to absorb it and premature release would waste capacity, create backlash, or cause instability.

rule: Lead-time inversion rule

logic: Move irreversible approvals earlier only when later action cannot catch the window and the precommitment remains bounded and reversible enough.

rule: Cadence adaptation rule

logic: Change meeting, observation, staffing, or release cadence when the environmental time constant shifts beyond the tempo-fit threshold.

rule: Post-window rule

logic: If the window has closed, do not continue executing the original plan merely because sunk approval effort exists; reframe the problem.

target_invariants: Action must be tied to current or explicitly refreshed environmental state.

target_invariants: Speed must not erase safety, legitimacy, accountability, or reversal boundaries.

target_invariants: Waiting must be a governed timing choice, not disguised avoidance.

target_invariants: Authority to accelerate or hold must be bounded and reviewable.

target_invariants: The external clock remains the reference, not internal convenience alone.

target_invariants: Feedback from landed actions updates the tempo model.

expected_outcomes: Fewer premature releases into unready environments.

expected_outcomes: Lower reliance on shadow workarounds for urgent timing.

expected_outcomes: Clearer distinction between action quality and action timing.

expected_outcomes: More appropriate use of preauthorization, queue jumping, staging, and revalidation.

expected_outcomes: Improved alignment between observation cadence, decision cadence, and action-effect cadence.

Crisis Response Tempo Matching

short_definition: A crisis-centered variant that compresses sensing, authorization, and action so response arrives before the hazard state changes beyond usefulness.

distinctive_feature: The main design pressure is safe acceleration without abandoning authority, verification, or accountability.

distinct_from_parent: The parent covers fast and slow timing mismatches; this variant emphasizes rapid response under hazard or incident pressure.

still_same_parent_because: The core logic remains matching the internal response clock to the external event clock.

use_when: The environment is changing faster than ordinary governance can respond.

use_when: Delay converts correct analysis into ineffective action.

use_when: Preauthorization can be bounded by clear risk, legality, or safety constraints.

domain: cybersecurity

example: A team isolates a host under a preapproved playbook when lateral movement indicators cross a threshold, rather than waiting for the full weekly change board.

failure_modes: Speed becomes an excuse for unbounded authority.

failure_modes: Escalation thresholds are set so high that the fast lane never activates.

Readiness-Window Pacing

short_definition: A slow-down variant that delays or phases an otherwise correct action until the receiving environment can absorb it.

distinctive_feature: The repair is pacing and readiness verification rather than faster decision-making.

distinct_from_parent: The parent includes both early and late mismatch; this variant focuses on premature-action failure.

still_same_parent_because: It still aligns the action clock to the environmental absorption clock.

use_when: The system can act faster than the target can receive or stabilize the action.

use_when: Premature release wastes attention, capacity, trust, or biological/social readiness.

use_when: Waiting must be governed rather than confused with inaction.

example: A platform delays a migration until customer tooling, support coverage, and data-readiness indicators reach a defined threshold.

failure_modes: Readiness criteria are vague and become political vetoes.

Market or Opportunity-Window Timing

short_definition: A strategic variant that matches release, investment, offer, or negotiation timing to a closing or opening opportunity window.

distinctive_feature: It makes opportunity expiry and readiness the primary design object.

distinct_from_parent: The parent is cross-domain; this variant uses market, strategic, and release-window language.

still_same_parent_because: The action must still be matched to an external tempo rather than optimized only for internal readiness.

source_primes: tempo_mismatch risk uncertainty scheduling

use_when: Value depends on acting inside a time-limited opportunity or readiness window.

use_when: The same action has different effects before, during, and after the window.

use_when: Internal approval or production cycles are misaligned with external demand or competitor movement.

example: A release train splits a feature so the minimum credible response ships before a competitor-induced demand window closes.

failure_modes: Urgency is manufactured to bypass scrutiny.

failure_modes: The window is inferred from wishful forecasts rather than evidence.

Bureaucratic Clock Realignment

short_definition: A governance variant that changes review, approval, consultation, and escalation rhythms when formal procedure runs on a slower or faster clock than operational reality.

distinctive_feature: The main design surface is authority cadence and procedural timing.

distinct_from_parent: The parent covers any action-environment tempo mismatch; this variant focuses on formal governance clocks.

still_same_parent_because: The problem remains that correct action degrades when the decision process arrives at the wrong time.

use_when: Formal decision routines are out of phase with field conditions.

use_when: Operators bypass procedure because the official clock cannot meet the work clock.

example: A hospital creates a short-cycle staffing exception path for surge conditions while retaining post-hoc review and safety constraints.

failure_modes: Exception paths become permanent shadow governance.

failure_modes: Procedure is blamed for every failure even when the environmental clock was slow enough for ordinary review.

near_names:
Response Tempo Alignment
Two-Clock Response Alignment
Cadence-to-Environment Matching
Stale Decision Prevention
Right-Time Response Design


name: Temporal Discounting and Present-Value Framework Selection

batch: Second Iteration/Batch 07

aliases:
Intertemporal Valuation Framework
Discount-Rate Selection Protocol
Present-Value Basis Selection
Temporal Cost-Benefit Framework
Long-Horizon Discounting Protocol
Temporal Valuation Framework Selection

slug: probability

slug: irreversibility

slug: optimization

slug: equity

slug: presentism

components:
Decision Horizon Definition
Consequence Timing Profile
Temporal Unit and Value-Basis Alignment
Discount-Rate Rationale
Present-Value Conversion Rule
Sensitivity and Threshold Test
Distributional Weighting Rule
Real/Nominal Indexing Basis
Option-Value and Irreversibility Flag
Non-Discountable Constraint Register

mechanisms:
Net Present Value Model
Discounted Cash-Flow Table
Social Discount-Rate Schedule
Declining Discount-Rate Schedule
Scenario Sensitivity Grid
Real/Nominal Adjustment Worksheet
Payback and Break-Even Cross-Check
Real-Options Cross-Check

essence_one_line: Choose, justify, and stress-test how future costs and benefits are converted to present decision weight before judging an option.

compression_statement: This archetype turns intertemporal comparison into an explicit design choice. It defines the relevant horizon, times each consequence, aligns value units, chooses a defensible discounting or present-value framework, tests how conclusions change under alternative rates or horizons, and keeps ethical or irreversible constraints visible rather than letting a hidden rate decide the case.

core_intuition: A future benefit is not automatically equivalent to a present benefit, but neither should the future disappear because a spreadsheet used a convenient rate. The archetype works by making the time-value assumption inspectable, contestable, and robust enough for the decision at hand.

canonical_formula: PV(option) = Σ_t [(benefits_t - costs_t) / (1 + r_t)^t], interpreted only after horizon, timing, value basis, rate rationale, sensitivity range, and non-discountable constraints have been declared.

structural_problem: A decision has consequences distributed across time, but the evaluation either treats all periods as equivalent, hides the discounting assumption, truncates the horizon, or lets a single unjustified rate reverse the decision without scrutiny.

trigger_conditions: Costs and benefits occur in different years, phases, generations, or budget cycles.

trigger_conditions: A present expenditure is justified by future savings, risk reduction, learning, resilience, revenue, or avoided harm.

trigger_conditions: A short-term option and long-term option look different depending on discount rate, horizon, or timing assumptions.

trigger_conditions: Real, nominal, inflation-adjusted, currency, or index-based values are being mixed.

trigger_conditions: Long-horizon, irreversible, or intergenerational effects could be suppressed by ordinary compounding.

trigger_conditions: Stakeholders disagree about whether the decision should prioritize near-term affordability, long-term value, or future obligations.

symptoms: Decision reports show a net present value but do not explain the discount rate or horizon.

symptoms: A project appears good or bad only because the analysis uses one convenient hurdle rate.

symptoms: Future maintenance, climate, health, safety, or decommissioning costs are treated as negligible without explicit justification.

symptoms: Nominal cash flows are discounted with real rates, or inflation-adjusted values are mixed with nominal assumptions.

symptoms: The analysis reports one answer even though plausible discount-rate choices would reverse the conclusion.

symptoms: Long-term stakeholders or future users are effectively absent from the valuation frame.

root_tension: Present action must be chosen now, but the value, risk, and moral weight of consequences unfold over time. The evaluator must compare across time without pretending that the discounting convention is neutral, certain, or ethically complete.

anti_signatures: All material consequences occur at the same time and no temporal comparison is needed.

anti_signatures: The decision is governed by a hard safety, rights, legal, or ethical constraint that should not be reduced to discounted net value.

anti_signatures: The main uncertainty is causal attribution, not temporal valuation; use evidence, inference, or sensitivity methods first.

anti_signatures: The issue is only short-term present bias correction without a valuation framework; Present-Bias Countermeasure is the closer archetype.

anti_signatures: The issue is only real/nominal or currency consistency; use the inflation/currency adjustment neighbor or the basis-alignment variant.

structural_intervention: Declare and test the temporal valuation framework before making the decision: define the horizon, map consequences by time, align value units, choose and justify the discounting logic, compute present-value or equivalent intertemporal scores, test rate/horizon sensitivity, and disclose constraints that should not be silently discounted away.

action_logic: Scope the decision and identify whose costs, benefits, risks, and obligations count.

action_logic: Set the decision horizon long enough to capture delayed benefits, maintenance obligations, tail risks, and end-of-life consequences.

action_logic: Build a timing profile that places each consequence in the period where it plausibly occurs.

action_logic: Align value basis across cash flows, prices, currencies, real/nominal assumptions, and measurement units.

action_logic: Choose a discount-rate family or present-value method and document why it fits the decision context.

action_logic: Compute the present-value comparison or equivalent intertemporal score while preserving raw time-profile visibility.

action_logic: Run sensitivity, threshold, and scenario checks over plausible rates, horizons, timings, and value assumptions.

action_logic: Report conclusions with non-discountable constraints, irreversible effects, and distributional effects separated from the net score.

decision_rules: Use this archetype whenever a decision could reverse because of discount rate, horizon, or timing assumptions.

decision_rules: Require rate and horizon justification before presenting a net present value as decisive.

decision_rules: Treat present value as an input to judgment, not as a substitute for ethical, legal, safety, or distributional constraints.

decision_rules: Show at least one sensitivity range when the selected rate is contestable, uncertain, or materially conclusion-changing.

decision_rules: Keep real values with real rates and nominal values with nominal rates unless a documented conversion is made.

decision_rules: Flag irreversible loss, option value, and future-rights constraints separately instead of burying them in a discounted aggregate.

target_invariants: The valuation horizon is explicit and defensible.

target_invariants: Timing assumptions are visible enough to audit.

target_invariants: Value basis, price level, currency, and discount-rate basis remain consistent.

target_invariants: The discount-rate rationale is connected to decision purpose, risk, opportunity cost, and stakeholder context.

target_invariants: Conclusion sensitivity to rate, horizon, and timing is disclosed.

target_invariants: Non-discountable constraints and irreversible consequences are not converted into invisible residuals.

expected_outcomes: Less arbitrary comparison of present costs against delayed benefits or harms.

expected_outcomes: Clearer distinction between financial time value, social time preference, risk adjustment, and ethical constraint.

expected_outcomes: Reduced rate shopping and horizon truncation.

expected_outcomes: More transparent long-horizon, intergenerational, maintenance, and lifecycle decisions.

expected_outcomes: Better communication of when a decision is robust versus when it depends on contestable temporal assumptions.

prose_essence:
Temporal Discounting and Present-Value Framework Selection is the pattern of making time explicit before comparing options. It asks: how long does the decision matter, when do consequences occur, what value basis are they stated in, which discounting or present-value logic is justified, and how fragile is the answer to those choices?

The archetype is not just net-present-value arithmetic. A spreadsheet can compute a present value while still hiding the real decision: whether the rate, horizon, value basis, and treatment of irreversible or ethical constraints fit the situation. The archetype turns those choices into inspectable parts of the intervention.

prose_key_components:
### Decision Horizon Definition

The decision horizon is the temporal boundary of the appraisal. It should be long enough to include delayed benefits, maintenance costs, replacement cycles, decommissioning obligations, and long-run risks. A horizon chosen only because it matches a budget cycle is often too short.

### Consequence Timing Profile

Consequences need to be placed in time. A cost in year one, a benefit in year ten, and a risk in year forty are structurally different. The timing profile prevents delayed consequences from being lumped into a vague future category.

### Temporal Unit and Value-Basis Alignment

Values must use compatible units. Real cash flows should be paired with real rates; nominal flows with nominal rates. Inflation, currency, purchasing-power, and indexation assumptions should be explicit. This component connects to the pilot-accepted inflation/currency neighbor but is not identical to it.

### Discount-Rate Rationale

The discount rate is not just a number. It can represent opportunity cost, time preference, risk, financing cost, social valuation, or a policy convention. The rationale should say which role the rate is playing and why that role fits the decision.

### Present-Value Conversion Rule

The conversion rule specifies how time-separated values are brought onto a common scale. It may be a standard NPV formula, a declining rate schedule, an equivalent annual value, or a different intertemporal scoring rule. The important point is that the rule is declared rather than hidden.

### Sensitivity and Threshold Test

Sensitivity testing shows whether the decision is robust or rate-dependent. It asks: at what discount rate does the decision reverse? What if the horizon is longer? What if benefits arrive later? What if a long-term risk has a larger tail?

prose_common_mechanisms:
Common mechanisms include net-present-value models, discounted cash-flow tables, social discount-rate schedules, declining discount-rate schedules, real/nominal adjustment worksheets, scenario sensitivity grids, and payback or break-even cross-checks. These are implementation tools. They should not be mistaken for the archetype itself.

A single discount-rate spreadsheet is especially easy to misuse. It may look rigorous while hiding the horizon, rate rationale, value basis, and ethical constraints. The archetype requires those assumptions to be surfaced.

prose_neighbor_distinctions: Present-Bias Countermeasure changes behavior so short-term preference does not dominate. This archetype chooses the framework for valuing consequences across time. Inflation, Currency, and Real versus Nominal Adjustment keeps value bases consistent; this archetype includes basis alignment but also covers rate, horizon, timing, and sensitivity. Opportunity Cost Surfacing reveals displaced alternatives; this archetype values time-separated consequences after the alternatives are in view. Sensitivity Analysis Protocol is a general robustness method; this archetype uses sensitivity specifically to audit temporal valuation choices.

prose_invariants_to_preserve: The valuation horizon must be explicit. The timing profile must be auditable. Real and nominal assumptions must remain consistent. The discount-rate rationale must be stated before the conclusion is presented. Sensitivity to plausible rates and horizons must be visible. Rights, safety thresholds, irreversible harms, and future obligations should not be silently buried in a discounted aggregate.

prose_target_outcomes: A successful application reduces arbitrary time comparison. It separates financial time value from ethical or public valuation. It reveals whether a decision is robust or rate-sensitive. It prevents long-term costs, maintenance, decommissioning, environmental harm, and future benefits from being excluded by omission.

name: Public-Policy Social Discount-Rate Selection

short_definition: Select and justify a discount-rate rule for public decisions whose costs and benefits fall across populations, generations, or long horizons.

distinctive_feature: It treats the discount rate as a public justification problem, not only as a financing or spreadsheet parameter.

distinct_from_parent: The variant emphasizes legitimacy, public reason, distributional sensitivity, and long-horizon disclosure.

still_same_parent_because: The core pattern remains selection of a temporal valuation framework before comparing time-separated consequences.

use_when: A policy, infrastructure, environmental, or public-health decision produces consequences over many years.

use_when: The choice of rate could reverse the conclusion or raise legitimacy concerns.

example_domains:
climate policy
public infrastructure
public health
regulation

domain: climate policy

example: A climate-impact appraisal reports results under several social discount-rate schedules and explains why long-horizon effects are not hidden by one rate.

failure_modes:
rate choice laundering
intergenerational value erasure
undisclosed distributional impact

short_definition: Evaluate projects by converting expected future cash flows into present value using a required return, cost of capital, or risk-adjusted hurdle-rate logic.

distinctive_feature: The discount rate is tied to capital opportunity cost and risk-return discipline.

distinct_from_parent: This is the private capital-allocation version rather than a public or ethical long-horizon version.

still_same_parent_because: It still requires horizon, cash-flow timing, discount-rate rationale, and sensitivity tests.

use_when: A firm, fund, household, or project team is deciding whether delayed financial returns justify present expenditure.

use_when: Risk, financing cost, and opportunity cost materially shape the decision.

example_domains:
capital budgeting
product investment
portfolio allocation

domain: infrastructure finance

example: A project is compared against alternatives using a discount rate linked to its risk-adjusted opportunity cost.

failure_modes:
hurdle-rate rigidity
risk double-counting
overprecise cash-flow projection

name: Real/Nominal Present-Value Basis Alignment

short_definition: Keep cash flows, price levels, currency assumptions, and discount rates on a consistent real or nominal basis before valuation.

distinctive_feature: The central issue is basis consistency between values and rates.

distinct_from_parent: It narrows the parent to real-versus-nominal alignment and overlaps with the pilot-accepted inflation/currency archetype.

still_same_parent_because: Basis alignment is one required subtype of temporal valuation-framework selection.

use_when: Future consequences are expressed with inflation, purchasing-power, currency, or indexation assumptions.

use_when: Mixing nominal cash flows with real rates, or the reverse, could distort present value.

example_domains:
contract valuation
infrastructure appraisal
cross-currency comparison

domain: contract valuation

example: An indexed rent stream is discounted with rate assumptions that match the inflation treatment of the projected payments.

failure_modes:
real nominal mismatch
currency basis drift
hidden index assumption

Declining-Rate Long-Horizon Discounting

short_definition: Use a rate schedule or horizon-sensitive valuation rule when uncertainty, irreversibility, or very long horizons make a single constant rate misleading.

distinctive_feature: The temporal valuation rule changes across the horizon rather than using one fixed discount rate.

distinct_from_parent: It is a specialized long-horizon subtype of the broader framework-selection pattern.

still_same_parent_because: It still depends on explicit horizon, rate logic, and sensitivity disclosure.

use_when: Consequences extend far enough that a constant compounding rate can dominate the decision.

use_when: Long-horizon uncertainty or irreversible loss should remain visible in the appraisal.

example_domains:
climate risk
nuclear decommissioning
long-lived infrastructure

domain: environmental appraisal

example: A long-term restoration plan reports results under constant and declining discount-rate schedules.

failure_modes:
ad hoc rate schedule
opaque horizon boundary
selective long-horizon framing

name: Option-Value and Irreversibility Discounting

short_definition: Treat irreversible decisions and option value separately so discounting does not erase the value of waiting, learning, or preserving future choice.

distinctive_feature: It distinguishes time value from option value and irreversible commitment.

distinct_from_parent: The variant is about preserving future optionality, not only converting flows across time.

still_same_parent_because: It remains part of temporal valuation framework selection because the discounting rule must be paired with option and irreversibility treatment.

use_when: The decision is hard to reverse and uncertainty may resolve over time.

use_when: Waiting preserves information or future choice, while acting now may lock in loss or path dependence.

example_domains:
land-use planning
platform architecture
environmental protection

domain: platform architecture

example: A team compares a cheap irreversible migration with a slower option-preserving path rather than selecting only by discounted near-term cost.

failure_modes: analysis paralysis through exaggerated option value

near_names:
Intertemporal Valuation Framework
Discount-Rate Selection Protocol
Present-Value Framework Selection
Temporal Cost–Benefit Framing
Intertemporal Value Alignment