Lifecycle Adaptability Design

batch: Batch 22

slug: modularity

slug: versioning

slug: adaptation

slug: compatibility

slug: interoperability

slug: continuity

slug: resilience

slug: irreversibility

slug: optionality

components: Stable Core and Change-Surface Partition

components: Configuration, Lineage, and Rationale Record

mechanisms: Modular Architecture with Stable Interfaces

mechanisms: Design-for-Disassembly and Service Access

mechanisms: Replaceable Unit and Standardized Connector

mechanisms: Versioned Interface and Migration Contract

mechanisms: Spare Capacity, Port, and Space Reservation

mechanisms: Rollback Checkpoint and Containment Runbook

mechanisms: Take-Back, Recovery, and Decommission Plan

essence_one_line: Design solutions so they can be maintained, upgraded, repaired, repurposed, or decommissioned over their lifespan without repeatedly rebuilding the whole.

compression_statement: Map the lifecycle and plausible categories of change; distinguish a stable core from change-prone elements; localize change in replaceable units with explicit interfaces; preserve access, slack, compatibility, lineage, and recovery paths; define triggers, authorities, transition windows, validation tests, and end-of-life routes; and retire adaptability options whose carrying cost or risk exceeds their remaining value. Adaptability is not maximum flexibility. It is a portfolio of deliberately bounded future changes whose enabling cost is paid only where plausible change, consequence, and option value justify it.

core_intuition: A design freezes decisions long before all future requirements are known. When likely change surfaces have no seams, access paths, compatible interfaces, or transition rules, even a small upgrade becomes a whole-system replacement. Paying a measured amount up front for separability, access, slack, lineage, and safe transition converts some irreversible commitments into exercisable options.

canonical_formula: lifecycle adaptability = anticipated change portfolio + bounded change units + stable interfaces + access/slack + trigger/governance + transition/recovery path + lifecycle validation - unmanaged option carrying cost.

structural_problem: A solution is optimized for its initial state while foreseeable maintenance, upgrade, regulatory, scale, use, ownership, environmental, and end-of-life changes remain cross-cutting, inaccessible, incompatible, or irreversible.

trigger_conditions: The expected service life is long relative to technology, demand, policy, or environmental change.

trigger_conditions: Change-prone elements are tightly coupled to a stable or expensive core.

trigger_conditions: Maintenance, upgrade, repurposing, or retirement will require different actors and capabilities than initial delivery.

trigger_conditions: Downtime, replacement, stranded investment, or disposal would be costly or harmful.

trigger_conditions: Multiple future configurations are plausible but their exact sequence is unknown.

trigger_conditions: Interfaces, formats, skills, suppliers, or dependencies are likely to evolve asynchronously.

trigger_conditions: End-of-life recovery, safe dismantling, archival, or handoff obligations matter.

symptoms: Minor feature or component changes trigger whole-system redesign.

symptoms: Service work requires destructive access, specialist improvisation, or unavailable tooling.

symptoms: Old and new versions cannot coexist during migration.

symptoms: Teams cannot identify dependencies, current configuration, or the owner of a lifecycle decision.

symptoms: Capacity is exhausted exactly when an upgrade or extension becomes necessary.

symptoms: Repurposing is technically possible but blocked by interfaces, permissions, documentation, or embedded assumptions.

symptoms: Retirement is deferred because data, users, materials, obligations, or replacement paths were never planned.

symptoms: Flexibility features accumulate without tests, owners, or a plausible exercise case.

root_tension: Optimizing only for the present minimizes visible initial cost, while preparing for every imaginable future creates complexity and carrying cost. The design must buy selective option value without turning the current solution into an overgeneralized platform.

anti_signatures: A failed or degraded part only needs diagnosis and service; use repairability_and_maintainability_design.

anti_signatures: The problem is how to record and compare revisions; use versioned_evolution.

anti_signatures: The problem is coexistence between already-defined old and new versions; use compatibility_management.

anti_signatures: The task is to prepare strategies for uncertain external futures rather than embed change paths in an artifact or operating model; use scenario_portfolio_planning.

anti_signatures: The current control regime has failed and the system must reorganize now; use adaptive_reconfiguration.

anti_signatures: The objective is lifecycle environmental comparison or loop closure rather than general changeability; use lifecycle_tradeoff_evaluation or circular_economy_redesign_via_lca.

structural_intervention: Convert plausible lifecycle changes into a governed option portfolio, then embed only the seams, access, capacity, compatibility, information, transition, and end-of-life provisions needed to exercise those options while preserving critical invariants.

action_logic: Define the solution boundary, intended service life, lifecycle stages, and accountable owner.

action_logic: Identify change drivers and classify plausible changes by timing, likelihood, consequence, and lead time.

action_logic: Separate stable-core commitments from change-prone elements and uncertain assumptions.

action_logic: Choose the smallest replaceable, reconfigurable, or repurposable unit that localizes each material change.

action_logic: Specify interfaces, dependency rules, compatibility envelopes, and invariant tests around those units.

action_logic: Preserve physical, informational, contractual, organizational, and permission access needed to inspect and change them.

action_logic: Allocate justified slack in capacity, space, identifiers, ports, budget, time, or authority.

action_logic: Define trigger signals, option exercise criteria, decision rights, funding, and escalation paths.

action_logic: Design staged transition, coexistence, migration, fallback, and rollback paths before committing to the new state.

action_logic: Maintain version, configuration, dependency, rationale, and service records sufficient for future actors.

action_logic: Validate representative repair, upgrade, replacement, repurposing, and retirement scenarios before release.

action_logic: Review option value and carrying cost over time; refresh, exercise, narrow, or retire adaptability provisions.

decision_rules: Embed an option only when plausible change, avoided consequence, and lead-time value exceed carrying cost and added failure surface.

decision_rules: Put a seam at a change boundary, not merely where present-day implementation is convenient.

decision_rules: Prefer stable, narrow interfaces over general-purpose extension points with no identified use class.

decision_rules: If old and new states must overlap, specify a compatibility window and authoritative migration path.

decision_rules: If a transition can irreversibly harm critical invariants, require checkpoint, containment, staged exposure, and explicit rollback authority.

decision_rules: If future actors cannot discover configuration or rationale, treat the option as non-exercisable even when the hardware or code is technically modular.

decision_rules: If access depends on one vendor, specialist, credential, or tool, document and govern that dependency as part of lifecycle risk.

decision_rules: If an adaptability provision is untested, label it a hypothesis rather than counting it as usable flexibility.

decision_rules: If carrying cost continues but the relevant future has become implausible, retire the option deliberately.

target_invariants: Safety, legality, security, structural integrity, and essential service remain bounded through change.

target_invariants: Stable-core responsibilities and public interfaces do not drift implicitly.

target_invariants: Configuration, provenance, dependency, and decision records remain traceable.

target_invariants: A future change does not silently transfer unacceptable cost or risk to maintainers, users, communities, or the environment.

target_invariants: Rollback, coexistence, and retirement claims are tested at the scale and conditions where they will be needed.

target_invariants: Adaptability provisions have named owners, review dates, and removal criteria.

expected_outcomes: Lower cost, downtime, waste, and risk for plausible lifecycle changes.

expected_outcomes: More changes localized to bounded units instead of whole-system replacement.

expected_outcomes: Faster, safer upgrades with explicit compatibility and recovery paths.

expected_outcomes: Longer useful life and more credible repurposing, reuse, and retirement options.

expected_outcomes: Better visibility into which future options are real, conditional, expired, or prohibitively costly.

expected_outcomes: Reduced lock-in to undocumented dependencies, inaccessible assemblies, and irreversible early choices.

prose_essence:
Lifecycle Adaptability Design prepares a solution for bounded change across its useful
life. It identifies plausible categories of change, separates a stable core from faster-
changing surfaces, creates replaceable or reconfigurable units, preserves access and
capacity, and defines who may exercise each option and how transition will be validated.

The archetype is intentionally broader than maintainability. Repair restores degraded
function; lifecycle adaptability also prepares upgrades, extensions, repurposing,
ownership changes, compatibility transitions, and retirement. It is also narrower than
generic flexibility: every adaptability provision needs an identified change class,
invariant, owner, test, carrying cost, and retirement condition.

prose_when_to_use:
Use this archetype when the solution's useful life is long relative to changes in
technology, demand, regulation, ownership, environment, or use; when replacement or
downtime would be expensive or harmful; and when meaningful future changes can be grouped
into bounded classes even though exact requirements are unknown. It is especially useful
when subsystems age at different rates and future actors will inherit the ability—or the
inability—to inspect, change, transfer, repurpose, and retire the solution.

Do not use it merely because flexibility sounds desirable. A short-lived artifact may be
safer and cheaper to replace. A fully unconstrained future supplies no defensible seam.
Added interfaces or access may also create unacceptable safety and security exposure. The
archetype requires enough lifecycle ownership to preserve options, records, and validation.

prose_structural_problem:
Long-lived solutions encounter changes that their initial designers cannot specify in
detail. Technologies age at different rates. Regulations, suppliers, formats, users,
environments, and organizational responsibilities shift. A static design turns these
ordinary lifecycle events into exceptional reconstruction because change-prone elements
are embedded in expensive stable structures.

The visible symptom is often disproportionate change cost: a small requirement forces a
large redesign, or an obsolete dependency prevents an otherwise useful system from
continuing. Less visible symptoms include inaccessible assemblies, undocumented rationale,
consumed spare capacity, compatibility promises without end dates, and retirement plans
that omit users, data, materials, or residual obligations.

prose_intervention_logic:
Start with the lifecycle, not the module diagram. State how long the solution is intended
to serve, which stages and handoffs it will cross, and what remains after nominal shutdown.
Build a change portfolio around categories such as wear, technology refresh, capacity,
regulation, use conversion, ownership transfer, and end-of-life. Rank them by plausibility,
consequence, lead time, and cost of retrofitting.

Next, identify which commitments should remain stable and which elements are likely to
change. Put seams around differential change rates. A seam may be an interface, connector,
contract, team boundary, permission boundary, schema, service zone, or amendment rule. It
must localize real coupling, not merely give the design a modular appearance.

Make the option exercisable. Future actors need access, documentation, authority, tools,
capacity, compatible transition states, validation criteria, and a route back or forward
when change fails. Finally, review the option portfolio. Some options become more valuable;
others expire. Carrying cost without a remaining exercise case is technical and
institutional debt.

prose_key_components:
### Lifecycle Boundary and Stage Map

The stage map identifies creation, deployment, operation, service, upgrade, transfer,
repurposing, and retirement. It includes external dependencies and residual duties so the
design does not pretend its lifecycle ends at delivery or shutdown.

### Anticipated Change Portfolio

The portfolio describes classes of change rather than exact predictions. Each entry names
a driver, likely horizon, consequence, lead time, enabling provisions, owner, validation
need, carrying cost, and retirement condition. This disciplines “future-proofing” claims.

### Stable Core and Change-Surface Partition

The partition protects essential invariants while exposing plausible change surfaces. A
good stable core changes slowly because its responsibility is durable, not because it was
implemented first. A good change surface is bounded enough to evolve without exporting
hidden state or risk.

### Bounded Change Unit and Interface Contract

The change unit is the smallest useful unit that can be replaced, reconfigured, upgraded,
or repurposed. Its interface contract states assumptions, inputs, outputs, invariants,
compatibility rules, and breaking-change policy. Physical units need connectors and access;
organizational units need responsibilities, authority, information, and handoff rules.

### Dependency and Coupling Map

Technical diagrams routinely omit skills, vendors, credentials, permissions, standards,
data histories, social expectations, and legal obligations. The dependency map includes
these because any one can make a nominally modular change impossible.

### Lifecycle Access and Disassembly Path

An option cannot be exercised if the relevant unit cannot be reached, isolated, understood,
or safely separated. Access includes service clearances and fasteners, but also keys,
contracts, source materials, documentation, test environments, and the authority to act.

### Adaptability Capacity and Slack Budget

Some future changes require headroom: spare compute, structural capacity, ports, address
space, budget, time, or decision latitude. The budget makes that headroom explicit and
protects it from being invisibly consumed by present optimization.

### Trigger, Ownership, and Decision Rights

Adaptability needs a rule for when to exercise an option and an owner with authority and
funding. Signals might include failure rate, capacity, cost, supplier exit, regulatory
change, user harm, or environmental thresholds. The rule also says when to delay, escalate,
or retire the option.

### Transition, Coexistence, and Rollback

Change occurs through states, not by replacing a diagram. A transition path defines pilot
scope, dependency order, old/new coexistence, data or user migration, cutover criteria,
containment, fallback, and support windows. When true rollback is impossible, it states
compensating and harm-containment actions honestly.

### Configuration, Lineage, and Validation

Future actors must know what exists, why it exists, what depends on it, and how to prove a
change is acceptable. The record and validation suite therefore travel with the solution.
Representative change drills turn claimed adaptability into evidence.

### Repurpose, Recovery, and Retirement Routes

Useful life may end without all value or obligation ending. The route identifies receivers
for capability, materials, data, knowledge, and users, then closes dependencies and residual
risk. An end-of-support boundary without a migration and handoff route is abandonment, not
lifecycle design.

prose_common_mechanisms:
Modular architectures, replaceable units, standardized connectors, and design-for-
disassembly techniques create physical or logical seams. Configuration controls and stable
extension points allow bounded variation. Adapters, shims, versioned interfaces, and
migration contracts support temporary coexistence between states. Parallel operation and
staged cutover bound exposure while compatibility and invariant tests produce evidence.

Registries, decision logs, configuration records, maintenance histories, and dependency
maps preserve the knowledge needed to exercise an option. Spare capacity and reserved
space provide headroom. Lifecycle scenario drills expose options that exist only on paper.
Rollback runbooks, containment plans, take-back programs, and decommission workflows govern
the difficult transitions that optimistic design diagrams omit.

prose_failure_modes:
The most common failure is speculative flexibility sprawl: extension points everywhere,
but no identified exercise case or owner. Decorative modularity leaves hidden coupling.
Stable-core errors freeze volatile assumptions. Reserved headroom is consumed. Transition
plans remain untested. Delivery teams dissolve without transferring stewardship. Designs
promise rollback for socially, materially, or informationally irreversible changes.

Mitigation is empirical: run service, substitution, migration, repurpose, and retirement
drills; measure coupling and recovery; inspect who bears the burden; and retire provisions
that no longer justify their cost.

prose_neighbor_distinctions:
Modular Decomposition creates bounded units; Lifecycle Adaptability decides which units
must change independently over time and adds access, option, transition, and retirement
controls. Versioned Evolution preserves lineage; it cannot make an inaccessible or tightly
coupled design changeable. Compatibility Management handles old/new interaction; it does
not choose the broader option portfolio.

Scenario Portfolio Planning explores multiple plausible futures and strategic responses.
This archetype embeds change paths in a particular solution. Adaptive Reconfiguration
responds when the current control regime fails; lifecycle design prepares options before a
specific trigger. Checkpoint and Rollback protects a transition but is only one mechanism.
Creative Destruction Management governs incumbent replacement and transition harm.

Circular-Economy Redesign via LCA and Lifecycle Trade-Off Evaluation focus on environmental
burdens and loop closure. Their findings can motivate disassembly or reuse provisions, but
general lifecycle adaptability also covers technology, service, regulation, scale,
organization, and use. Scale Transition Management owns a specific cross-scale transition.

prose_cross_domain_examples:
A building with an accessible service layer, structural headroom, replaceable interiors,
and tested conversion rules demonstrates lifecycle adaptability. A building advertised as
“flexible” because it has open floor space, but whose utilities and permissions cannot
support another use, does not.

A software platform with versioned narrow contracts, dual-state migration, invariant
tests, rollback, lineage, and legacy retirement is adaptable. A codebase with many plug-in
hooks may look flexible, but the positive pattern requires a compatibility policy, named
owner, exercised migration, and retirement rule.

A public program with amendment triggers, interoperable records, beneficiary transition,
sunset review, and archival duties is lifecycle-adaptable. A manufacturing cell with
standard utilities, reconfigurable fixtures, reserved capacity, and staged qualification
can accept new product families without uncontrolled redesign.

prose_non_examples:
Unused plug-in hooks without identified change classes, owners, invariant tests, or removal
rules are not lifecycle adaptability. Keeping every legacy version forever is accumulated
support burden, not change readiness. A policy that can be rewritten in principle but has
no lawful amendment path or protection for dependent people is not adaptable. A repair
schedule for one machine is maintenance unless broader upgrade, transition, repurpose, and
retirement provisions are actually present.

prose_tradeoffs:
Adaptability is purchased with present resources and future obligations. Interfaces and
connectors add failure surfaces. Slack can be wasted. Compatibility can fossilize poor
choices. Parallel systems cost money and attention. Documentation decays. These costs are
acceptable only when tied to credible option value.

The central tradeoff is selective option value versus present efficiency and simplicity.
The design should spend on seams, access, headroom, records, and transition machinery only
where plausible change and avoided consequence justify the ongoing cost.

prose_invariants_to_preserve:
Safety, legality, security, structural integrity, accessibility, essential service, data
integrity, and traceability must remain bounded throughout change. Stable-core
responsibilities and public contracts must not drift implicitly. Configuration,
dependency, rationale, and authority need continuous provenance across handoffs.

A change must not silently transfer unacceptable cost or risk to maintainers, users,
workers, communities, or the environment. Coexistence, rollback, repurpose, and retirement
claims need representative tests. Every retained adaptability provision needs an owner,
review date, and retirement criterion.

prose_target_outcomes:
Successful use lowers cost, downtime, waste, and risk for plausible lifecycle changes. More
changes remain local to bounded units; upgrades become faster and safer; repurposing and
retirement become credible rather than aspirational; and dependency lock-in becomes
visible. The result is not limitless flexibility but a transparent portfolio of options
that are usable, conditional, expired, or consciously rejected.

prose_parameter_dimensions:
Important tuning dimensions include expected service life, change horizon, change
likelihood, consequence, lead time, unit granularity, coupling, interface stability,
compatibility-window length, reserved capacity, downtime tolerance, reversibility,
migration volume, documentation half-life, owner continuity, and option carrying cost.

No parameter should be maximized automatically. Smaller units can increase interface and
coordination cost. Longer support windows can freeze obsolete contracts. More slack can
reduce present efficiency. Tune each parameter against a named change class, its lead time,
and the consequence of discovering too late that the option is unusable.

prose_variants_and_near_names:
Service and Repair Adaptability centers degraded-part diagnosis and restoration; mature
generic cases belong to the accepted Repairability and Maintainability Design archetype.
Upgrade and Extension Adaptability centers capability evolution and compatibility.
Repurpose and Conversion Adaptability changes the use or receiving context while retaining
stable assets. Disassembly, Recovery, and Retirement Adaptability centers terminal
separation, migration, recovery, and obligation closure.

These are lifecycle emphases, not automatically separate archetypes. They should be
promoted only when they develop distinct cross-domain components, mechanisms, failure
modes, and neighbor boundaries that overload this parent. Near names such as Design for
Changeability and Design for Evolution route to the parent; Design for Disassembly routes
to the terminal variant by default and to the service subtype when repair access is primary.

Service and Repair Adaptability

short_definition: Prepares diagnosis, access, repair, replacement, and restoration paths for degradation and failure.

distinctive_feature: Centers degraded-part service and recovery.

distinct_from_parent: Narrows the lifecycle portfolio to maintenance and repair.

still_same_parent_because: It uses the same bounded-unit, access, lineage, owner, and validation contract.

use_when: Service access and restoration dominate the lifecycle risk

failure_modes:
Inaccessible service boundary
Missing spare or restoration validation

Upgrade and Extension Adaptability

short_definition: Reserves interfaces, capacity, compatibility, and migration paths for capability growth or replacement.

distinctive_feature: Centers additive or substitutive capability evolution.

distinct_from_parent: Emphasizes growth and technology refresh rather than all lifecycle stages.

still_same_parent_because: It exercises the same option portfolio and transition controls.

use_when: Stable core and change-prone extensions age at different rates

example_domains: software electronics buildings research_platforms

failure_modes:
Extension-point sprawl
Compatibility burden never retired

Repurpose and Conversion Adaptability

short_definition: Preserves the ability to convert a solution to a materially different use without discarding its stable assets.

distinctive_feature: Changes purpose or operating context, not merely version or failed parts.

distinct_from_parent: Focuses on transfer to a new use and receiver.

still_same_parent_because: Repurposing remains one planned lifecycle option exercised through bounded units and invariants.

use_when: Stable structures or capabilities outlive the original purpose

example_domains: architecture manufacturing organizations public_programs

failure_modes: Nominal convertibility without code or safety approval

name: Disassembly, Recovery, and Retirement Adaptability

short_definition: Prepares safe separation, recovery, archival, migration, and obligation closure at end of use or support.

distinctive_feature: Centers the terminal lifecycle transition and residual destinations.

distinct_from_parent: Narrows the portfolio to end-of-life and end-of-support.

still_same_parent_because: It uses the same access, ownership, transition, validation, and handoff logic.

use_when: Residual harm can persist after shutdown

example_domains: products data_systems infrastructure institutions

failure_modes:
Orphaned users or data
Unsafe residual dependencies
Recovery route without receiver

near_names:
Design for Changeability
Design for Evolution
Modularity for Lifecycle
Design for Disassembly


Lifecycle Trade-Off Evaluation

type: archetype

source: generated

batch: Second Iteration/Batch 06

aliases: Whole-Life Environmental Tradeoff Evaluation

alias_records: Whole-Life Environmental Tradeoff Evaluation

slug: externality

slug: holism

slug: uncertainty

slug: optimization

components:
Functional Unit and Comparison Frame
Lifecycle Stage Model
System Boundary Map
Inventory Flow Profile
Impact Category Vector
Stage Hotspot and Trade-Off Matrix
Assumption and Uncertainty Register
Explicit Decision Weighting Rule
Counterfactual Baseline
Allocation Rule
Sensitivity Scenario Set
Stakeholder Value Criteria

mechanisms: Environmental Product Declaration Review

essence_one_line: Compare alternatives across their full lifecycle so a gain in one stage is not mistaken for a net environmental improvement when it merely shifts burden elsewhere.

compression_statement: Lifecycle Trade-Off Evaluation turns a local improvement claim into a stage-by-stage and impact-category comparison: define a common functional unit, map lifecycle boundaries, quantify inventory flows, convert them into impact categories, identify stage-specific gains and losses, and make the decision rule explicit before accepting, rejecting, or redesigning the option.

core_intuition: Many interventions look better only because the visible stage is narrow. Lightweight materials, electrification, recycling, reuse, and outsourcing can reduce one burden while increasing another upstream, downstream, or in a less salient impact category. The archetype works by preserving lifecycle visibility long enough to see the trade before optimizing.

canonical_formula: net_lifecycle_judgment = compare_alternatives(functional_unit, Σ_stage impact_vector(stage, alternative), decision_weights, uncertainty_bounds)

structural_problem: A decision maker evaluates an intervention using a partial lifecycle view, causing environmental burdens to be hidden, displaced, or over-weighted depending on which stage is easiest to measure.

trigger_conditions: An alternative claims lower emissions, resource use, toxicity, waste, or environmental burden relative to a baseline.

trigger_conditions: The intervention changes materials, energy sources, operating efficiency, lifetime, disposal pathways, or supply-chain inputs.

trigger_conditions: Benefits and harms are distributed across different lifecycle stages, such as manufacturing, use, maintenance, transport, recycling, and end-of-life.

trigger_conditions: Several environmental impact categories matter and cannot be responsibly collapsed into a single score without explicit weights.

trigger_conditions: A decision would otherwise be made from one salient metric, one stage, or one stakeholder perspective.

symptoms: A design is praised for use-phase savings while manufacturing or extraction burdens are omitted.

symptoms: A recycling, reuse, or circular-economy option is assumed to be superior without transport, processing, contamination, or lifetime effects being checked.

symptoms: A procurement choice optimizes one metric, such as carbon, while worsening toxicity, water use, land use, or resource depletion.

symptoms: Stakeholders dispute whether a sustainability claim is real because each side cites a different lifecycle stage.

symptoms: The same intervention appears beneficial under one boundary definition and harmful under another.

root_tension: Environmental improvement is often stage-relative, but responsible selection requires whole-lifecycle comparison under multidimensional impacts and uncertain boundaries.

anti_signatures: The choice has no meaningful upstream, downstream, use-phase, maintenance, or end-of-life consequences.

anti_signatures: The decision is governed by a binding legal, safety, or ethical constraint that overrides lifecycle optimization.

anti_signatures: Only one alternative exists and the task is implementation control rather than comparative evaluation.

anti_signatures: The relevant question is how to price or regulate an externality rather than how to compare lifecycle trade-offs.

anti_signatures: The assessment is only a post-hoc reporting requirement and will not influence a design, procurement, or policy choice.

structural_intervention: Replace a single-stage improvement claim with a transparent lifecycle comparison that preserves stage boundaries, impact categories, assumptions, and decision weights until the trade-offs are explicit.

action_logic: Define the functional unit so alternatives provide comparable service, lifetime, output, or performance.

action_logic: Draw the system boundary and lifecycle stages to include upstream inputs, production, distribution, use, maintenance, reuse or recycling, and end-of-life where relevant.

action_logic: Quantify inventory flows for each stage, including materials, energy, emissions, waste, transport, and replacements.

action_logic: Translate inventory flows into impact-category vectors rather than prematurely collapsing them into a single sustainability score.

action_logic: Compare alternatives stage by stage and category by category to identify hotspots, burden shifting, and break-even conditions.

action_logic: Run sensitivity checks on uncertain assumptions such as product lifetime, grid mix, use intensity, allocation rules, and recycling rates.

action_logic: State the decision rule explicitly: dominance, threshold, weighted compromise, redesign target, or defer-for-data.

action_logic: Document residual uncertainty and what would change the conclusion.

decision_rules: Use the same functional unit and service level for every alternative unless the difference is itself the point of the decision.

decision_rules: Treat stage-level improvements as provisional until whole-lifecycle impacts and category trade-offs have been inspected.

decision_rules: Do not aggregate impact categories unless the weighting method, normative assumptions, and sensitivity to weights are visible.

decision_rules: Flag a burden shift when a gain in one stage or category creates a material worsening in another stage or category.

decision_rules: Prefer redesign or targeted mitigation when the assessment reveals a specific lifecycle hotspot rather than a uniformly superior option.

decision_rules: Escalate to review when missing data, allocation choices, or boundary assumptions could reverse the decision.

target_invariants: Alternatives remain comparable through a shared functional unit.

target_invariants: Lifecycle boundaries remain explicit and auditable.

target_invariants: Stage-specific impacts remain visible until trade-offs are understood.

target_invariants: Impact categories are not silently collapsed into a single score.

target_invariants: Assumptions and uncertainty ranges are attached to the conclusion.

target_invariants: The final recommendation traces back to the comparison rather than to a preferred narrative.

expected_outcomes: Hidden upstream or downstream burdens become visible before commitment.

expected_outcomes: Decision makers can distinguish real improvement from burden shifting.

expected_outcomes: Design teams can target lifecycle hotspots for redesign.

expected_outcomes: Sustainability claims become more defensible because boundaries, weights, and uncertainties are explicit.

expected_outcomes: Procurement and policy choices can compare alternatives without assuming one stage represents the whole system.

Circular-Economy LCA Redesign

short_definition: Use lifecycle trade-off evaluation to test whether reuse, recycling, remanufacturing, or circular redesign actually improves full-life environmental outcomes.

distinctive_feature: Focuses on circularity claims and allocation of avoided burdens.

distinct_from_parent: The parent can evaluate any lifecycle trade-off; this variant focuses on circular-material and reuse loops.

still_same_parent_because: It uses the same functional-unit, boundary, impact-category, and uncertainty reasoning as the parent.

use_when: A circular-economy intervention is proposed as environmentally superior.

use_when: Transport, cleaning, processing, recovery rates, or product lifetime could change the result.

use_when: Avoided virgin production and added circular-system burdens must be compared.

example_domains:
reusable packaging
remanufactured equipment
recycling policy

name: Use-Phase vs. Manufacturing Trade-Off Evaluation

short_definition: Compare manufacturing-stage burden increases against operational-stage burden reductions, especially for efficiency or lightweighting choices.

distinctive_feature: The central parameter is the break-even relationship between production burden and use-phase savings.

distinct_from_parent: The parent includes all lifecycle-stage conflicts; this variant names the common manufacturing/use-phase pair.

still_same_parent_because: It remains a lifecycle-stage trade-off comparison rather than a separate intervention family.

use_when: A design uses more intensive materials or production to reduce operating impacts.

use_when: The break-even point depends on lifetime, use intensity, grid mix, or maintenance.

use_when: The decision hinges on whether use-phase savings repay production-phase costs.

example_domains:
electric vehicles
building insulation
lightweight packaging

name: Lifecycle Externality Internalization Support

short_definition: Use lifecycle trade-off evaluation as the evidence layer for policies, prices, liabilities, or disclosure rules that internalize lifecycle externalities.

distinctive_feature: Connects evaluative LCA evidence to governance action.

distinct_from_parent: The parent evaluates alternatives; this variant focuses on using the evaluation to support externality governance.

still_same_parent_because: The lifecycle comparison remains the evidence-generating pattern and the governance mechanism belongs to a neighbor archetype.

use_when: The lifecycle comparison will feed a tax, fee, reporting rule, procurement standard, or liability assignment.

use_when: The main governance challenge is ensuring the internalization mechanism reflects full-life burdens.

example_domains:
eco-labeling
procurement standards
environmental fees

near_names: Whole-Life Environmental Tradeoff Evaluation


LIFO Stack Discipline

batch: Batch 02

aliases:
Nested Stack Discipline
Last-In First-Out Frame Discipline
Pushdown Context Management
Well-Nested Unwind Discipline
Stacked Context Control

related_primes: group index isomorphism measure composition hierarchy abstraction context boundary containment consistency parsing interleaving serialization algorithm iteration queueing flow dependency event_lifecycle_phases validity_ending_event information_hiding interface modularity threshold validation

slug: stack

slug: order

slug: constraint

slug: recursion

slug: group

slug: index

slug: isomorphism

slug: measure

slug: composition

slug: hierarchy

slug: abstraction

slug: context

slug: boundary

slug: containment

slug: consistency

slug: parsing

slug: interleaving

slug: serialization

slug: algorithm

slug: iteration

slug: queueing

slug: flow

slug: dependency

slug: interface

slug: threshold

slug: validation

components:
Frame Boundary
Push Admission Rule
Top-Frame Authority
Pop or Unwind Rule
Frame Payload and Local State
Depth and Overflow Guard
Exception Unwind Policy
Restoration Invariant
Peek or Inspection Rule
Frame-Type Registry
Tail or Bottom Anchor

mechanisms:
Call Stack and Activation Records
Push/Pop Interface
Parser Delimiter Stack
Resource Acquisition/Release Stack
Transaction Savepoint Stack
Undo/Redo Stack Pair
Breadcrumb Navigation Stack
Depth Limit and Stack Trace

essence_one_line: Use a last-in, first-out nesting discipline whenever safe work depends on closing the current context before returning to the one beneath it.

compression_statement: When activity opens temporary frames of context, state, resource ownership, authority, obligation, or interpretation, make each frame explicit, allow work only against the top active frame, and require closure or unwind in exact reverse order so earlier contexts resume cleanly and no dangling state remains.

core_intuition: Some work is safe only when nested. You enter a room before you leave it, acquire a lock before releasing it, call a function before returning from it, and open a parenthesis before closing it. Stack discipline turns this intuitive nesting into a governable invariant: the newest unfinished context has priority, and the older context waits unchanged underneath.

canonical_formula: push(frame_n) -> active(frame_n); pop(frame_n) only if frame_n is top; invariant: close_order = reverse(open_order) + restoration_check

structural_problem: A system creates temporary nested contexts but does not preserve the order, boundary, payload, or restoration rule that lets those contexts close safely. Work can then return to the wrong context, release resources out of order, leave obligations dangling, corrupt local state, or treat a nested interruption as if it were a flat sequence.

trigger_conditions: Actions, calls, transactions, permissions, resources, or interpretive contexts are opened inside one another.

trigger_conditions: The current task must suspend a parent context and later resume it unchanged.

trigger_conditions: Closure order matters because later frames depend on earlier frames remaining valid.

trigger_conditions: Failure or interruption can occur while multiple frames are open.

trigger_conditions: Users or operators need to know what context is currently active and what will resume next.

symptoms: Mismatched open/close markers, brackets, sessions, or scope boundaries.

symptoms: Resources, locks, permissions, or temporary overrides remain active after the work that needed them ends.

symptoms: Debugging reveals confusing hidden state, wrong return paths, or context leakage.

symptoms: Nested work is handled as a flat queue, causing premature closure or wrong-owner cleanup.

symptoms: Recursive or nested procedures fail through overflow, forgotten base cases, or unbounded depth.

root_tension: Nested work creates local freedom inside a suspended parent context, but that freedom is safe only if the system can restore the parent exactly when the child frame ends.

anti_signatures: Use a queueing or scheduling archetype when the central issue is fair service order rather than nested closure.

anti_signatures: Use index-based retrieval when the central issue is fast lookup by key or location.

anti_signatures: Use generic data-structure selection when the issue is comparing many possible representations by operation cost rather than preserving LIFO nesting.

anti_signatures: Use tolerance-stack management when the issue is cumulative deviation across composed parts, not last-opened/first-closed context.

anti_signatures: Use checkpoint and rollback logic when recovery jumps to a stored state without depending on well-nested frame closure.

structural_intervention: Represent each temporary context as an explicit frame, restrict active operations to the top frame, and enforce a pop/unwind protocol that closes frames in reverse order while validating restoration invariants.

action_logic: Name the kinds of frames the system can open and what payload each frame carries.

action_logic: Define the push condition: who or what may open a new frame, under which parent, and with which inherited constraints.

action_logic: Make the top frame the active local context for reads, writes, permissions, decisions, or returns.

action_logic: Require every close, release, return, or exit to match the current top frame before older frames resume.

action_logic: Specify abnormal unwind behavior for error, cancellation, timeout, conflict, or emergency.

action_logic: Monitor depth, overflow, empty-stack access, and mismatched-frame attempts.

action_logic: After each pop, verify that the restored parent context still satisfies its invariants.

decision_rules: Choose stack discipline when nested dependencies make out-of-order closure unsafe.

decision_rules: Do not use a stack merely because items arrive over time; use it only when later frames should complete before earlier frames.

decision_rules: Expose frame depth and top-frame identity when operators need situational awareness.

decision_rules: Set depth limits when recursive or nested processes can grow without natural bounds.

decision_rules: Permit inspection beneath the top frame only through read-only or audited mechanisms unless the whole stack invariant is redesigned.

decision_rules: Treat exception handling as part of the archetype, not as an implementation afterthought.

target_invariants: The active frame is always the most recently opened unclosed frame.

target_invariants: A frame cannot be popped unless it is the top frame or an explicit unwind policy is invoked.

target_invariants: Each frame has a declared payload, owner, lifetime condition, and restoration obligation.

target_invariants: Closing a frame restores, transfers, or validates the parent context before work continues.

target_invariants: Stack depth remains within known capacity or enters a controlled failure mode.

expected_outcomes: Nested state remains intelligible and recoverable.

expected_outcomes: Resources and obligations close in safe reverse order.

expected_outcomes: Return paths, context switches, and parser boundaries become easier to validate.

expected_outcomes: Debugging and accountability improve through explicit frame traces.

expected_outcomes: Recursive, transactional, and scoped work can fail more safely because unwind behavior is predefined.

Call Stack Management

short_definition: A software-runtime variant where nested calls, continuations, local variables, and return paths are managed as activation frames.

distinctive_feature: The payload is executable control context and local state.

distinct_from_parent: The parent covers any nested open/close discipline; this variant is specific to program execution frames.

still_same_parent_because: The core invariant remains that the latest active frame closes before its caller resumes.

source_primes: stack state_and_state_transition recursion algorithm

use_when: Execution enters nested functions, routines, handlers, or coroutines that must return in reverse order.

use_when: Local variables, permissions, or continuations should be isolated to the active call frame.

use_when: Debugging or safety requires a stack trace, depth limit, or structured unwind path.

example: Each nested function call opens an activation frame and returns control to its caller only after the callee closes.

domain: debugging

example: A stack trace exposes the active sequence of nested calls that led to a fault.

Delimited Scope Stack

short_definition: A variant where nested delimiters, scopes, sections, permissions, or contexts must close in the reverse order in which they opened.

distinctive_feature: The main object being protected is contextual meaning or scope membership rather than executable control.

distinct_from_parent: The parent includes data, resources, and control frames; this variant emphasizes matched boundaries and scope validity.

still_same_parent_because: A scope stack still preserves last-opened/first-closed nesting.

source_primes: stack parsing boundary context

use_when: The system admits nested parentheses, markup tags, code blocks, legal clauses, modes, sessions, or contexts.

use_when: A close marker, exit action, or permission release must match the current active opening marker.

use_when: Mismatched closure can leak state, corrupt interpretation, or assign action to the wrong context.

domain: parsing

example: A closing bracket must match the most recent compatible opening bracket.

example: Temporary elevated permission is pushed for a scoped task and popped before returning to ordinary context.

Resource Unwind Stack

short_definition: A variant where resources, locks, obligations, or temporary rights acquired in nested order must be released in reverse order.

distinctive_feature: The stack exists to make cleanup safe under normal and exceptional exit.

distinct_from_parent: The parent covers all LIFO nesting; this variant centers resource lifetime, cleanup, and exception safety.

still_same_parent_because: Acquisition opens frames and cleanup pops them in reverse order.

source_primes: stack containment consistency validity_ending_event

use_when: Later resources depend on earlier resources remaining valid until cleanup begins.

use_when: Failure, cancellation, or timeout can interrupt ordinary completion.

use_when: Cleanup order determines whether state remains consistent and safe.

example: Nested savepoints unwind only the latest partial change before disturbing earlier committed context.

domain: operations

example: Temporary safety bypasses are cleared in reverse order so later bypasses cannot rely on released supports.

Undo-History Stack

short_definition: A variant where recent actions are held as reversible frames so the latest change is the first available for undo.

distinctive_feature: The payload is reversible history rather than active control state.

distinct_from_parent: The parent covers nested open/close frames; this variant captures reversible event history.

still_same_parent_because: Undoing proceeds from the top of the recent-action stack backward.

use_when: Users need local reversibility without reconstructing the whole system state.

use_when: Actions can be represented as inverse operations or restorable deltas.

use_when: The most recent action is normally the safest and most meaningful first reversal.

domain: editing

example: The last edit is undone first because later edits may depend on earlier context.

near_names:
Nested Stack Discipline
LIFO Discipline
Pushdown Context Management
Call Stack
Technology Stack
Tolerance Stack


Liquidity Reserve

batch: First Iteration/Batch 12

Liquidity Buffer

alias_scope: Near-alias when the buffer is a deliberately maintained stock of readily usable resources; not a substitute for generic flow buffering.

Emergency Fund

alias_scope: Financial-domain mechanism or near-name for a cash-oriented liquidity reserve.

Rainy-Day Fund

alias_scope: Public finance or household finance name for a reserve held against shocks.

Contingency Reserve

alias_scope: Near-name when the reserve is explicitly usable on short notice for uncertain obligations.

Operational Reserve

alias_scope: Near-name when supplies, staff, compute, or other resources are held ready for urgent use.

Liquidity

slug: liquidity

role: Primary canonical prime: the archetype depends on the ease and speed with which a resource can become usable without substantial value loss.

Resource Management

role: Primary canonical prime: the archetype allocates some resource to readiness rather than immediate productive use.

Opportunity Cost

role: The reserve sacrifices yield, use, or efficiency in exchange for readiness.

Margin of Safety

role: The reserve creates a protective margin against urgent obligations or shocks.

System Slack

role: Liquidity reserves are a specific, governed form of slack; they should not be collapsed into generic excess capacity.

Fail-Safe

role: A well-designed reserve gives the system a safer fallback path when ordinary conversion or procurement channels fail.

Resilience

slug: resilience

role: The reserve improves the system's ability to absorb stress and continue critical functions.

components:
Liquid Reserve
Convertibility Pathway
Reserve Adequacy Metric
Release Condition
Replenishment Rule
Reserve Monitoring
Opportunity Cost Review
Access Authority
Stress Scenario Model
Drawdown Log
Priority of Claims

mechanisms:
Cash Reserve
Emergency Fund
Standby Credit Facility
Critical Spares Inventory
Prepositioned Supply Cache
Reserve Staffing Pool
Operational Contingency Fund
Deployable Compute Capacity
Mutual Aid Agreement

essence_one_line: Maintain readily convertible resources so urgent obligations can be met without forced liquidation, unsafe improvisation, or system disruption.

compression_statement: When valuable resources exist but are not immediately usable under stress, a liquidity reserve keeps a governed stock or access claim in a rapidly usable form, preserving response capacity and flexibility at the cost of lower yield, idle capacity, or carrying burden.

core_intuition: A resource that cannot be used in time is functionally absent at the moment of need. Liquidity reserves trade some everyday efficiency for the ability to act before slower conversion, procurement, approval, or redeployment paths break the system.

canonical_formula: readiness_need + conversion_delay_or_loss + urgent_obligation_risk -> maintained_usable_reserve + release_rule + replenishment_rule

structural_problem: The system has assets, resources, capacity, or relationships, but they are locked in forms that cannot be turned into the needed usable resource quickly enough when obligations, shocks, or opportunities arise.

condition: Obligations or opportunities arrive faster than ordinary conversion, procurement, hiring, borrowing, or reallocation can occur.

relevance: The problem is not total resource absence; it is time-to-usability under stress.

condition: Forced liquidation, emergency purchasing, or scramble redeployment would impose large losses or create operational risk.

relevance: A ready reserve prevents the system from paying the highest cost at the worst time.

condition: Resource access channels are reliable in normal times but uncertain, slow, or contested during correlated stress.

relevance: A reserve is needed because normal conversion assumptions may fail when many actors need the same resource simultaneously.

condition: Critical functions depend on a scarce resource that cannot be substituted quickly.

relevance: Reserve design protects the continuity of the function, not merely the ownership of assets.

symptom: The system owns valuable assets but still misses payments, response windows, service levels, or safety obligations.

interpretation: Value exists, but not in a liquid form.

symptom: Teams repeatedly use crisis procurement, last-minute borrowing, emergency staffing, or forced sales to meet predictable stress events.

interpretation: The recurring need is known, but no governed reserve is available.

symptom: Planning assumes resources are available because they are somewhere in the system, yet actual activation is blocked by time, location, approval, compatibility, or conversion cost.

interpretation: Nominal capacity is being mistaken for usable liquidity.

symptom: High-yield or fully utilized configurations look efficient in normal times but become brittle when demand spikes or income falls.

interpretation: Optimization has removed the readily usable margin needed for resilience.

root_tension: The system wants to maximize productive use of resources, but it also needs enough immediately usable capacity to survive stress without destroying value or interrupting critical functions.

condition: The problem is ordinary flow variability between producers and consumers.

why_not: Buffering may fit better when the main function is smoothing flow rather than preserving convertibility under stress.

condition: The primary intervention is deciding how to distribute resources across competing purposes.

why_not: Resource portfolio balancing or constrained allocation may fit better than a liquidity reserve.

condition: The resource is abundant and procurement or conversion is reliably fast under the relevant stress condition.

why_not: A reserve may create unnecessary carrying cost without meaningful readiness benefit.

condition: The system needs to transform locked resources into flexible units, not hold an already usable reserve.

why_not: Resource liquefaction is the closer pattern.

structural_intervention: Hold or secure a reserve of resources that can be made usable quickly with bounded loss, and govern it with adequacy metrics, release conditions, custody, monitoring, and replenishment rules.

action: Identify the urgent obligations, shock scenarios, or time-sensitive opportunities that create a readiness requirement.

rationale: Reserve design begins with the use case; otherwise the reserve may be large but irrelevant.

action: Determine the resource form that will be usable under those conditions.

rationale: Liquidity is contextual: a cash balance, trained person, configured server, or staged supply may each be liquid in different systems.

action: Size the reserve against plausible drawdown needs, conversion time, conversion loss, and correlated stress.

rationale: A reserve that only works in mild cases creates false confidence.

action: Define release authority, triggering conditions, priority of use, and safeguards against casual depletion.

rationale: A reserve must be available for real stress without becoming unavailable because it was spent on routine demand.

action: Monitor readiness and replenish after use or drift.

rationale: Liquidity decays through drawdown, expiration, incompatibility, inflation, staffing changes, changing demand, or hidden dependencies.

rule: Count a resource as part of the reserve only if it can become usable within the required response window and under the relevant stress scenario.

purpose: Prevents paper liquidity from being mistaken for actual readiness.

rule: Release the reserve only for conditions that meet defined urgency, priority, or continuity criteria.

purpose: Preserves the reserve for the cases it was created to handle.

rule: Replenish after drawdown to a defined adequacy threshold unless the underlying risk model has changed.

purpose: Keeps one emergency from silently eliminating protection against the next one.

rule: Review the reserve when carrying cost, risk exposure, conversion channels, or critical demand changes materially.

purpose: Prevents stale reserves, over-reserving, and under-reserving.

invariant: The reserve remains usable within the intended response window.

why_it_matters: Timeliness is the defining property; slow conversion is a different pattern.

invariant: Drawdown rules preserve access for genuinely urgent or priority needs.

why_it_matters: Routine consumption can quietly convert a reserve into ordinary inventory or budget.

invariant: Replenishment restores the reserve after use, decay, or changing exposure.

why_it_matters: A one-time reserve becomes an exhausted artifact unless its state is maintained.

invariant: The reserve's carrying cost remains explicit and justified by the protected risk.

why_it_matters: Liquidity reserves are valuable precisely because they impose opportunity cost; that cost must be governed rather than hidden.

outcome: Urgent obligations are met without forced liquidation, emergency procurement, or unsafe improvisation.

evaluation: Success appears as preserved continuity and lower stress-conversion cost.

outcome: The system can absorb shocks while keeping critical functions operational.

evaluation: Success appears as reduced outage, insolvency, service interruption, or response delay.

outcome: Decision-makers gain time and optionality during stress.

evaluation: The reserve prevents panic choices and gives slower strategic options time to mature.

outcome: Readiness is made visible as a managed state rather than assumed from nominal ownership.

evaluation: Monitoring shows whether the reserve remains liquid, accessible, and adequate.

prose_essence:
A liquidity reserve is a deliberately maintained source of usable response capacity. It exists because owning resources is not the same as being able to use them in time. The archetype applies when a system can be resource-rich but action-poor: assets, supplies, people, budget, or capacity may exist somewhere, yet the system still cannot meet an urgent obligation without delay, loss, or unsafe improvisation.

The core move is to keep some resource in a form that can be used quickly under stress. The reserve may be cash, a near-cash account, critical spare parts, staged supplies, warm compute capacity, trained backup staff, or a credible access right such as a committed facility. The archetype is not the reserve object itself. It is the structure that makes the reserve usable: a defined need, a liquid form, a release rule, monitoring, and replenishment.

prose_when_to_use:
Use liquidity reserve when the main failure is not total scarcity but delayed usability. A system may have enough value in the abstract and still fail because the needed form cannot be produced quickly enough. The pattern is especially relevant when forced conversion would be costly, ordinary procurement would be too slow, or stress conditions would make normal access channels unreliable.

This archetype is useful for households that need emergency savings, organizations that need payroll and contingency cash, hospitals that need usable supplies, cloud services that need deployable capacity, and governments that need emergency funds or staged response resources. In each case, the reserve buys time and prevents panic conversion.

Do not use this archetype simply because something is extra. Extra inventory, spare budget, unused space, or nominal capacity only counts when it is intentionally protected, usable in the relevant response window, and governed by drawdown and replenishment rules.

prose_structural_problem:
The structural problem is a mismatch between value and immediacy. A system may own valuable resources, but those resources may be locked in a form, location, contract, schedule, approval chain, or market that cannot be converted in time. Under normal conditions this may be invisible because ordinary flows work. Under stress, conversion delay becomes a critical failure.

Typical symptoms include forced sales, emergency procurement, last-minute borrowing, crisis staffing, missed obligations, or brittle dependence on ideal conditions. The deeper tension is that everyday efficiency pushes resources toward full use or higher yield, while resilience requires some resources to remain available for low-probability, high-consequence moments.

prose_intervention_logic:
The intervention begins by naming the urgent need. A reserve designed without a response window or stress scenario often becomes symbolic. Once the need is defined, the system identifies the form of resource that will actually be usable: not just money, not just inventory, not just capacity, but whatever can be turned into the needed action quickly enough.

The reserve is then sized and governed. It needs an adequacy metric so the system can tell whether the reserve is enough. It needs release conditions so routine demand does not consume it casually. It needs monitoring because liquidity decays through depletion, expiration, policy change, market stress, technical incompatibility, or forgotten dependencies. It needs replenishment because a reserve used once must be rebuilt or deliberately retired.

The intervention succeeds when the system has a credible path from reserve state to action state before stress-time losses become unacceptable.

prose_key_components:
### Liquid Reserve

The liquid reserve is the maintained stock, balance, capacity, or access claim. It is the visible center of the archetype, but it is not sufficient by itself. A resource only qualifies as liquid if it can be used within the relevant response window and under the relevant stress conditions.

### Convertibility Pathway

The convertibility pathway explains how the reserve becomes the exact needed resource. For cash, this may be payment access. For spare parts, it includes location, compatibility, and installation. For compute, it includes provisioning and traffic routing. For backup staffing, it includes training, scheduling, authority, and communication.

### Reserve Adequacy Metric

The adequacy metric states how much reserve is enough. It may be expressed as months of expenses, days of supply, minimum cash balance, surge headroom, recovery-time capacity, or scenario-based drawdown. Without an adequacy metric, the reserve is difficult to defend, adjust, or audit.

### Release Condition

The release condition governs when the reserve may be used. It protects the reserve from routine depletion while keeping it accessible in real emergencies. Good release conditions are specific enough to prevent abuse but flexible enough to handle genuine stress.

### Replenishment Rule

The replenishment rule restores the reserve after drawdown or decay. It converts a one-time stockpile into a maintained capability. Replenishment may be automatic, scheduled, event-triggered, budget-linked, or tied to post-incident review.

### Reserve Monitoring

Reserve monitoring tracks whether the reserve remains real. It checks levels, usability, expiration, access constraints, conversion cost, location, compatibility, and counterparty reliability. Monitoring is especially important because nominal liquidity often fails under the same stress that triggers the need.

### Opportunity Cost Review

The opportunity cost review keeps the reserve honest. Holding liquidity has a cost: lower yield, idle capacity, storage burden, duplicated resources, or foregone current use. This review prevents both over-reserving and excessive efficiency cuts that remove all readiness margin.

prose_common_mechanisms:
A cash reserve is a financial mechanism for preserving immediate purchasing power. It implements liquidity reserve when cash is the resource needed to meet urgent obligations. The cash balance is not the archetype; the archetype includes the decision about how much cash to hold, when to use it, and how to restore it.

An emergency fund is a named mechanism that sets money aside for unexpected needs. It often works well because the fund is legible and psychologically protected, but it fails if it is routinely raided or kept in a form that cannot be accessed during the relevant emergency.

A standby credit facility is a contingent access mechanism. Instead of holding all liquidity directly, the system secures a prearranged borrowing path. This can reduce carrying cost, but it must be stress-tested because credit lines can become unavailable, conditional, or slow when many actors are stressed at once.

Critical spares inventories and prepositioned supply caches implement operational liquidity. They work when the bottleneck is procurement lead time or physical logistics rather than money. They fail when items expire, become incompatible, are stored too far away, or lack deployment authority.

Reserve staffing pools implement liquidity for human capacity. They require trained people, scheduling rules, activation authority, and maintained skills. Merely having employees somewhere in the organization does not create a staffing reserve.

Deployable compute capacity implements liquidity in technical infrastructure. Warm capacity, reserved instances, or rapid scaling paths reduce response time during bursts or incidents. This mechanism fails when dependencies, configuration, quotas, or approvals make the nominal capacity unusable.

Mutual-aid agreements implement contingent access. They can be powerful when resource sharing is reliable, but they should not be counted as full liquidity unless the agreement remains enforceable and useful under correlated stress.

prose_failure_modes:
Paper liquidity occurs when a resource is counted as liquid because it has value, even though it cannot be used inside the response window. The mitigation is stress-specific validation: count only what can actually be drawn down, deployed, or converted when needed.

Silent depletion occurs when routine demands gradually consume the reserve. The mitigation is a release condition, drawdown log, and replenishment threshold.

Stale reserve occurs when the reserve no longer matches the need. Supplies expire, staff lose skills, software configurations drift, and credit terms change. The mitigation is monitoring, testing, rotation, and recalibration.

Over-reserving occurs when fear causes excessive idle stock, duplicated capacity, or hoarding. The mitigation is opportunity-cost review and scenario-based sizing.

Correlated-stress failure occurs when the reserve depends on a market, lender, supplier, or partner that is also impaired during the same event. The mitigation is counterparty stress testing, diversification, and skepticism toward fragile access claims.

Release capture occurs when powerful actors redefine routine preferences as emergencies. The mitigation is transparent authority, priority rules, and auditability.

prose_neighbor_distinctions:
Liquidity reserve is close to capacity reservation, but the emphasis differs. Capacity reservation protects a right or allocation for future use. Liquidity reserve asks whether the protected resource can become usable quickly under stress. Reserved capacity can still be illiquid if activation is slow or blocked.

Liquidity reserve is close to buffering, but buffering mainly smooths flow variation. A liquidity reserve is governed for urgent drawdown and replenishment. Buffers may operate automatically; liquidity reserves usually require readiness management.

Liquidity reserve is close to system slack, but slack is broader. Slack can be time, space, attention, budget, or tolerance. Liquidity reserve is a specific kind of slack: a ready, convertible stock or access path.

Liquidity reserve is close to resource portfolio balancing, but portfolio balancing concerns distribution across uses and risk-return profiles. A liquidity reserve is one deliberate allocation within that portfolio.

Liquidity reserve is close to resource liquefaction. The distinction is that resource liquefaction changes locked resources into flexible forms, while liquidity reserve maintains resources already close enough to usable form for urgent response.

prose_cross_domain_examples:
In household finance, an emergency fund prevents a temporary income shock from forcing high-cost debt or asset liquidation. The reserve is liquid because it can be accessed quickly for urgent payments.

In hospital operations, a stock of rotated critical supplies and a trained backup staffing pool preserve care continuity during spikes. The reserve is liquid because it can be deployed operationally, not because it has resale value.

In cloud infrastructure, warm spare compute capacity prevents traffic spikes from becoming outages. The reserve is liquid because it can be allocated before slower provisioning becomes a bottleneck.

In municipal government, rainy-day funds and prepositioned emergency resources prevent delayed disaster response. The reserve buys decision time and service continuity.

In manufacturing, critical spare parts avoid long downtime from supplier lead times. The reserve is useful only when parts are compatible, accessible, and governed by maintenance rules.

prose_non_examples:
A valuable but specialized building is not a liquidity reserve for payroll. It may have value, but it cannot reliably become cash in the required window.

A closet full of untested equipment is not a liquidity reserve. Without readiness monitoring, access authority, and deployment capability, it is just stored material.

A budget line called contingency is not a liquidity reserve if it is routinely spent before emergencies occur. The name does not preserve the resource.

A diversified portfolio is not automatically a liquidity reserve. It becomes relevant only if some portion is deliberately held in a form that can be drawn down quickly with acceptable loss.

A mutual-aid agreement is not automatically a liquidity reserve. It counts only if the agreement is enforceable, activation is fast, and the provider is likely to remain able to help during the same stress event.

prose_tradeoffs:
Liquidity reserve trades efficiency for resilience. Resources held ready may earn less, sit idle, require maintenance, or duplicate capacity. That cost is not a flaw; it is the price of stress-time optionality.

The archetype also trades accessibility against discipline. A reserve must be accessible in emergencies, but that accessibility makes it tempting to use for ordinary pressure. Release rules and monitoring manage this tension.

Shared reserves create another tradeoff. They reduce duplication, but they may fail when multiple users need the same resource at once. Local reserves improve certainty, but they can be expensive or inequitable.

Finally, reserves can create complacency. If every drawdown is treated as an isolated emergency rather than a signal, the reserve may hide structural fragility instead of buying time to repair it.

prose_invariants_to_preserve:
The reserve must remain usable within the intended response window. This is the defining invariant. A valuable asset that cannot be converted quickly is not liquid for this purpose.

The reserve must remain protected from ordinary consumption. If routine demand can drain it without visibility, the system will discover too late that its reserve has disappeared.

The reserve must be replenished or deliberately recalibrated after drawdown. Without this invariant, one shock silently eliminates protection against the next.

The reserve must remain matched to the current risk environment. Changes in demand, technology, regulation, supply chains, staffing, inflation, or threat conditions can make a previously adequate reserve obsolete.

The cost of the reserve must remain explicit. Liquidity is not free; the design should make the tradeoff visible rather than hiding it inside vague prudence or unmanaged hoarding.

prose_target_outcomes:
The main target outcome is continuity under stress. The system can meet urgent obligations without forced liquidation, emergency procurement, or unsafe improvisation.

A second target outcome is decision time. The reserve gives decision-makers enough room to choose deliberately instead of acting from panic.

A third outcome is reduced conversion loss. The system avoids selling, borrowing, hiring, buying, or reallocating at the worst possible moment.

A fourth outcome is visible readiness. The system can tell whether it has usable resources, not merely whether it owns assets or has theoretical capacity.

prose_parameter_dimensions:
The first tuning dimension is reserve size. Too little reserve creates false security; too much reserve creates idle cost and hoarding. Size should be tied to plausible drawdown, response window, and protected function.

The second dimension is liquidity form. Cash, near-cash instruments, staged inventory, warm capacity, trained people, and access rights all have different conversion speeds and failure modes. A form that is liquid in one domain may be illiquid in another.

The third dimension is release strictness. Loose rules make the reserve easy to spend casually; rigid rules can block legitimate use. The design should specify urgency, priority, authority, and exceptions.

The fourth dimension is replenishment speed. Some reserves must be rebuilt immediately after use; others can be restored over a budget cycle or procurement cycle. Replenishment speed should match recurrence risk.

The fifth dimension is localization. Local reserves are reliable but expensive; shared reserves are efficient but may be contested. Distributed systems often need a mix.

The sixth dimension is counterparty dependence. Directly held reserves are costly but controlled; contingent access is cheaper but vulnerable to enforceability, priority, and correlated-stress failure.

prose_variants_and_near_names:
The cash or near-cash variant includes cash reserves, emergency funds, rainy-day funds, and similar financial mechanisms. These names should usually collapse into the parent or financial variant rather than become standalone archetypes.

The operational liquidity variant includes critical spares, staged supplies, reserve staffing, and deployable compute. These mechanisms matter because operational response often fails even when money exists; the scarce thing is usable resource in the right place and form.

The contingent access variant includes standby credit, call options, priority contracts, and mutual-aid agreements. This variant is useful but merge-sensitive because it overlaps with capacity reservation and commitment mechanisms. Its key question is whether an access claim remains reliable during stress.

Near names such as liquidity buffer, contingency reserve, reserve account, and spare capacity should be interpreted carefully. They point to this archetype only when there is a maintained, usable reserve with drawdown and replenishment logic.

Cash or Near-Cash Liquidity Reserve

short_definition: Maintains cash, near-cash assets, or immediately spendable balances for obligations that cannot wait for slower liquidation.

distinctive_feature: The usable form is financial liquidity: cash, near-cash balances, or instruments that can become cash under the relevant stress conditions.

distinct_from_parent: The parent covers any rapidly usable reserve; this variant is specifically about spendable financial capacity.

still_same_parent_because: Its intervention logic is still to preserve immediate usability through a maintained reserve with drawdown and replenishment rules.

Liquidity

role: The reserve is held in money or a near-money instrument so obligations can be met quickly with limited conversion loss.

Resource Management

role: The design problem is how much usable resource to keep idle or low-yielding for readiness rather than committing it elsewhere.

condition: Obligations are denominated in money or require immediate purchasing power.

implication: Reserve adequacy should be measured by drawdown speed, expected payment demands, and conversion loss under stress.

condition: Forced asset sales would impose large losses, reputational damage, or insolvency risk.

implication: The reserve protects the system from selling valuable assets at the worst moment.

Liquid Reserve

role: Holds readily spendable or quickly convertible financial resources.

Release Condition

role: Defines when the reserve may be drawn down.

Replenishment Rule

role: Restores the reserve after drawdown.

Cash Reserve

mechanism_type: artifact

role: A balance or account maintained for rapid payment.

Emergency Fund

role: A designated financial pool for unexpected urgent needs.

Standby Credit Facility

mechanism_type: institution

role: A prearranged borrowing path that can provide liquidity when activated.

example_domains:
household finance
banking and treasury
nonprofit operations
municipal fiscal planning

domain: household finance

example: Keeping several months of expenses in readily accessible savings to avoid selling long-term assets during a job loss.

domain: municipal government

example: Maintaining a rainy-day fund for emergency expenditures and revenue shocks.

description: The reserve exists symbolically but cannot cover plausible stress obligations.

description: Assets counted as liquid become unavailable or costly to convert under the very conditions in which the reserve is needed.

Operational Liquidity Reserve

short_definition: Maintains supplies, staff, compute, equipment, or other operational resources in a form that can be deployed quickly when ordinary provisioning is too slow.

distinctive_feature: The reserve is not just money; it is a deployable operating resource kept ready for use.

distinct_from_parent: The parent is broader; this variant focuses on physical, human, digital, or logistical resources that must already be staged or configured.

still_same_parent_because: It preserves the same invariant: urgent demand can be met without forced conversion, scramble procurement, or disruption.

Liquidity

role: The reserve is operationally liquid: usable on short notice, not merely owned in principle.

Resource Management

role: The reserve is a managed stock of supplies, labor, compute, space, or other deployable operational resources.

condition: Response depends on nonfinancial resources that cannot be procured or configured quickly enough during a shock.

implication: Reserve design should emphasize readiness state, location, compatibility, and activation path.

condition: A resource shortage would interrupt critical service or force unsafe improvisation.

implication: The reserve protects continuity by making a usable stock available before the shortage reaches the critical path.

Convertibility Pathway

role: Specifies how the reserve becomes the exact working resource needed.

Reserve Monitoring

role: Tracks readiness, freshness, location, and depletion.

Access Authority

role: Defines who may activate the reserve and under what conditions.

Critical Spares Inventory

role: Maintains replacement parts or supplies that are difficult to obtain during disruption.

Reserve Staffing Pool

role: Keeps trained people available for surge or emergency deployment.

Deployable Compute Capacity

role: Maintains immediately allocable infrastructure capacity for bursts or incidents.

example_domains:
healthcare operations
emergency logistics
cloud infrastructure
manufacturing maintenance

domain: healthcare operations

example: Maintaining personal protective equipment and emergency staffing pools so urgent care can continue during demand spikes.

domain: cloud infrastructure

example: Holding warm spare compute capacity that can absorb a sudden traffic surge.

description: The reserve exists but is expired, incompatible, untrained, or not where it is needed.

description: The reserve cannot be used because activation depends on a missing credential, operator, interface, or approval.

Contingent Access Reserve

short_definition: Secures a prearranged right, credit line, option, reciprocal agreement, or call path that can become usable resource under defined conditions.

distinctive_feature: The reserve is partly a right of access rather than a fully held stock.

distinct_from_parent: The parent can hold resources directly; this variant stores a credible claim, line, or option that converts into the needed resource.

still_same_parent_because: It still solves the same readiness problem by preserving rapid usability under stress.

Liquidity

role: The design grants rapid access to usable resources when conditions trigger a draw.

Resource Management

role: The system trades carrying cost against reliability by reserving access rights rather than holding the entire resource outright.

condition: Holding a full reserve outright would be too expensive, wasteful, or impractical.

implication: The design should validate that the access right remains reliable during correlated stress, not only during normal times.

condition: Resource access can be contractually or institutionally precommitted before the urgent need occurs.

implication: Activation terms and priority rights become central components.

Activation Path

role: Specifies how the contingent right is exercised.

Reliability Check

role: Tests whether the access claim will still function during stress.

Release Condition

role: Defines when the access right may be invoked.

Standby Credit Facility

role: Provides an agreed source of financing when triggered.

Mutual Aid Agreement

role: Provides reciprocal access to resources across organizations.

Call Option or Priority Contract

mechanism_type: document

role: Gives priority access to capacity, inventory, or services under specified conditions.

example_domains:
disaster response
treasury management
cloud operations
supply chain resilience

domain: disaster response

example: A mutual-aid agreement that grants rapid access to neighboring crews and equipment after a regional emergency.

domain: treasury management

example: A committed credit facility that can be drawn when cash inflows are delayed.

description: The access provider is also stressed and cannot honor the claim.

description: The agreement looks liquid on paper but activation is slow, contested, or conditional.

near_names:
Liquidity Buffer
Cash Reserve
Emergency Fund
Rainy-Day Fund
Contingency Reserve
Standby Credit
Critical Spares Stock
Spare Capacity


aliases:
Figurative Boundary Marking
Simile Boundary Preservation
Explicit Comparison Boundarying
Like-As Transfer Guardrail
Non-Identity Comparison Framing

slug: simile

slug: analogy

slug: metaphor

slug: representation

slug: framing

slug: polysemy

slug: contrast

slug: uncertainty

slug: deixis

components:
Source–Target Comparison Pair
Explicit Figurativeness Marker
Shared Feature Selection
Non-Identity Boundary
Transfer Scope Constraint
Literalization Risk Check
Audience Interpretive Context
Non-Mapping Disclaimer
Comparison Alternative Set
Downstream Preservation Rule
Interpretive Feedback Signal

mechanisms: Translation Marker Preservation Instruction

essence_one_line: Mark a comparison as figurative and bounded so the audience can transfer the intended resemblance without importing literal identity or irrelevant source-domain implications.

compression_statement: Literal-vs-Figurative Boundary Preservation turns a potentially overextended comparison into a safe simile-like transfer: identify the source and target, state the shared feature, preserve an explicit comparison marker such as like, as, resembles, or analogous to, name the non-transferable features, and keep downstream summaries from converting the comparison into a literal equivalence claim.

core_intuition: Similes are useful because they let one domain illuminate another without saying they are the same thing. The explicit boundary is not decorative. It is the safety rail that tells the reader which inferences are invited and which ones should be left behind.

canonical_formula: bounded_figural_transfer = marker(source ≈ target, shared_feature_set) + non_identity_boundary + transfer_scope_constraint

structural_problem: A comparison intended to clarify one feature of a target is received, repeated, or operationalized as literal equivalence, causing false inference, overextended analogy, policy error, contractual ambiguity, or misreading of poetic and explanatory language.

trigger_conditions: A speaker or designer needs to use a familiar source domain to explain an unfamiliar, abstract, or complex target.

trigger_conditions: The comparison is useful because of resemblance, but source and target are not identical and should not be treated as equivalent.

trigger_conditions: Audience members may lack enough context to distinguish figurative comparison from literal claim.

trigger_conditions: The language may be quoted, summarized, translated, automated, or formalized downstream, increasing risk that the marker is stripped away.

trigger_conditions: The domain is sensitive to overclaiming, such as law, medicine, safety, science communication, public policy, education, or contracts.

trigger_conditions: A poetic, rhetorical, or pedagogical comparison must remain interpretable without being flattened into literal paraphrase.

symptoms: People object to a comparison by attacking literal differences that were never meant to transfer.

symptoms: A metaphor or analogy becomes an unexamined model and begins driving design, policy, or evaluation choices beyond its intended scope.

symptoms: A contract, requirement, or specification contains figurative language that could be read as an enforceable literal term.

symptoms: Learners remember the comparison but also import irrelevant source-domain details into the target concept.

symptoms: Readers disagree about whether a phrase is illustrative, definitional, evidentiary, humorous, poetic, or prescriptive.

symptoms: Downstream summaries convert “like X” into “is X,” erasing the original boundary.

root_tension: Figurative resemblance helps cognition by importing structure from a familiar domain, but unmanaged resemblance can silently mutate into identity, proof, definition, or unrestricted transfer.

anti_signatures: The intended claim is literal identity, classification, definition, or equivalence rather than figurative comparison.

anti_signatures: The problem is validating deep structural analogy across many relations; that belongs closer to analogy mapping validation or structural transfer.

anti_signatures: The intended intervention is to change the overall frame of a problem through metaphor; that belongs closer to frame shift or metaphorical reframing.

anti_signatures: The audience already has a stable shared convention and the comparison cannot plausibly be mistaken for a literal claim.

anti_signatures: The expression is purely ornamental and no practical misunderstanding, transfer, or interpretation risk is at stake.

anti_signatures: The main need is translation to an audience register, not preservation of literal versus figurative force.

structural_intervention: Preserve an explicit comparison boundary around a figurative transfer by marking the comparison mode, naming the transferable feature, limiting non-transferable features, and auditing downstream uses for accidental literalization.

action_logic: Identify the target concept, system, or claim that needs clarification.

action_logic: Choose a source domain whose resemblance supports the intended insight without creating dominant misleading entailments.

action_logic: State the comparison with a visible marker such as like, as, resembles, analogous to, comparable to, or works in one respect like.

action_logic: Name the shared feature or relation that is meant to transfer from source to target.

action_logic: State or imply the non-identity boundary so the audience knows that source and target remain different kinds of things.

action_logic: Name high-risk non-transferable features when the audience might import them anyway.

action_logic: Check whether downstream summaries, diagrams, requirements, translations, or automated transformations preserve the marker and scope.

action_logic: Revise the comparison, add a qualifier, or replace the source if the boundary cannot be maintained.

decision_rules: Use a simile-style marker when the comparison is meant to illuminate without defining.

decision_rules: Make the transferable feature explicit whenever the source domain has salient irrelevant features.

decision_rules: Add a boundary note when the comparison could affect legal obligations, safety behavior, scientific belief, clinical action, or policy interpretation.

decision_rules: Do not rely on a figurative comparison as evidence unless independent evidence is supplied.

decision_rules: If the comparison is intended to license many relational inferences, escalate to analogy mapping validation rather than relying on simple boundary marking.

decision_rules: If the comparison is intended to transform the governing frame rather than preserve non-identity, route it to metaphorical reframing or frame shift intervention.

decision_rules: Reject or replace comparisons whose most memorable feature is the misleading one.

target_invariants: The source and target remain explicitly non-identical.

target_invariants: The intended shared feature or relation remains visible.

target_invariants: Non-transferable source-domain features are not silently imported.

target_invariants: The comparison marker survives quoting, summarization, translation, and operationalization.

target_invariants: Figurative language is not converted into evidence, definition, commitment, or obligation without review.

target_invariants: Audience comprehension improves without creating a more dangerous misconception.

expected_outcomes: Readers can use the comparison for insight while avoiding literal overreach.

expected_outcomes: Learners retain the target concept with fewer source-domain misconceptions.

expected_outcomes: Legal, technical, and policy texts avoid unintended obligations or false equivalence created by figurative wording.

expected_outcomes: Poetic and rhetorical interpretation can preserve figurative force without flattening it into literal paraphrase.

expected_outcomes: Downstream artifacts retain the comparison boundary when the phrase is reused.

expected_outcomes: Source-target transfer becomes safer because the permitted inference path is explicit.

Pedagogical Simile Scaffolding

short_definition: Use marked similes in teaching while naming what carries over and what does not.

distinctive_feature: The comparison is embedded in a learning sequence and often pairs the simile with a misconception check.

distinct_from_parent: The parent applies to any bounded figurative comparison; this variant focuses on teaching and concept formation.

still_same_parent_because: The core intervention remains explicit comparison marking plus transfer-scope control.

use_when: Learners need a familiar model for a new concept.

use_when: The familiar source has obvious limitations that could become misconceptions.

use_when: The instructor can test understanding of both the resemblance and the boundary.

example_domains:
physics education
biology education
software onboarding

domain: physics education

example: Current is like water flow only for pathway and resistance intuitions, not literal fluid substance.

cause: The source domain is more memorable than the boundary.

mitigation: Add a non-mapping note and a backcheck question.

Legal Literal-Reading Guardrail

short_definition: Qualify or remove figurative comparisons in legal, contractual, or policy text so they do not create unintended literal obligations.

distinctive_feature: The boundary is tied to interpretive authority and enforceability rather than only comprehension.

distinct_from_parent: The parent covers all figurative-boundary preservation; this variant emphasizes legal literalization risk.

still_same_parent_because: The central move is still preserving the literal-versus-figurative boundary, not designing a dispute-resolution process.

use_when: Figurative wording appears in a text that may be interpreted literally or enforced.

use_when: The comparison is useful for orientation but not intended to define rights, duties, deliverables, or standards.

use_when: Downstream readers may lack the drafting context.

example_domains:
contracts
policy manuals
requirements documents

domain: contract drafting

example: Clarifying that a roadmap is illustrative and not a deliverable unless separately incorporated.

cause: A figurative phrase is read as an operative term.

mitigation: Replace the phrase with literal specification or add a defined boundary clause.

Poetic Figurative-Marker Preservation

short_definition: Preserve the interpretive force of marked figurative comparisons in poetry, criticism, translation, or close reading.

distinctive_feature: The boundary protects aesthetic and interpretive ambiguity rather than only operational precision.

distinct_from_parent: The parent is general; this variant is about literary and expressive interpretation.

still_same_parent_because: It still uses marker preservation and non-identity boundaries to guide reading.

source_primes: simile metaphor

use_when: A literary comparison should not be reduced to literal paraphrase.

use_when: The comparison marker changes the poem’s tone, ambiguity, or interpretive openness.

use_when: A translation or analysis risks erasing the simile boundary.

example_domains:
poetry
translation
literary criticism

domain: poetry reading

example: Keeping “like winter light” as a marked comparison rather than paraphrasing it as a literal attribute.

cause: The marker is omitted or the comparison is paraphrased as definition.

mitigation: Preserve the marker and discuss the interpretive space it opens.

Safety-Critical Analogy Boundarying

short_definition: Add explicit non-transfer notes when a figurative comparison could influence health, safety, engineering, clinical, or public-risk behavior.

distinctive_feature: Risk severity drives the amount of boundary language and review required.

distinct_from_parent: The parent may be routine communication; this variant escalates boundarying based on harm potential.

still_same_parent_because: The basic pattern remains explicit figurative comparison plus bounded transfer.

source_primes: simile analogy uncertainty

use_when: Misreading the comparison could change behavior in a safety-sensitive setting.

use_when: The source domain includes intentional, mechanical, or causal features that do not apply.

use_when: The communication may be acted on without expert mediation.

example_domains:
public health
engineering safety
clinical communication

domain: public health

example: Using a security-system simile for immunity while warning that immune cells are not conscious enforcement agents.

cause: The audience treats the comparison as a literal causal model.

mitigation: Add a boundary note, independent evidence, and comprehension testing.

near_names:
Simile Boundary Preservation
Figurative Boundary Marking
Like-As Transfer Guardrail
Non-Identity Comparison Framing