Acceptable Substitution Mapping

batch: First Iteration/Batch 10/second wave

related_primes: resource_management opportunity_cost constraint boundedness boundary threshold

Indifference Curves

role: Motivates the central idea that different bundles can be treated as equal enough under a stated preference or outcome criterion.

Trade-Offs

role: Frames substitution as an explicit exchange among attributes, resources, risks, or constraints rather than as free equivalence.

Substitution vs Sequential Variation

role: Distinguishes replacing one element with another from merely changing order or sequence.

Equivalence Relation

role: Supplies the logic for deciding when alternatives can be treated as equivalent for a particular purpose.

Resource Management

role: Substitutions often arise because resources, vendors, staff, time, or capacities are scarce and must be reconfigured.

Opportunity Cost

role: Every substitute displaces another bundle, so the map must make the value of forgone attributes visible.

Constraint

slug: constraint

role: Non-substitutable requirements turn some dimensions into hard limits rather than tradable attributes.

Boundedness

slug: boundedness

role: Acceptability normally lives inside a bounded region rather than across the entire option space.

Boundary

role: The map draws a practical boundary between acceptable substitutes, review-needed substitutes, and unacceptable substitutions.

Threshold

slug: threshold

role: Many substitution rules rely on minimum performance, evidence, or quality thresholds.

components: Preference Surface or Equivalence Region

mechanisms:
Substitution Matrix
Equivalency Table
Approved Alternative Catalog
Indifference Map
Preference Elicitation Workshop
Conjoint or Tradeoff Survey
Procurement Equivalence Review
Design Tradeoff Curve
Service Tier Mapping
Exception Review Workflow

essence_one_line: Map which combinations of resources, attributes, or alternatives can substitute for one another while preserving acceptable outcome value.

compression_statement: When multiple bundles could satisfy a goal but acceptable substitutions are implicit, contested, or inconsistently applied, define the equivalence region, substitution rules, non-substitutable constraints, and review boundaries that make swapping one bundle for another legitimate.

core_intuition: Substitution is safe only when the system knows what must be preserved, what can vary, how much one attribute can compensate for another, and where the tradeoff stops being acceptable.

canonical_formula: preserved outcome + variable attributes + equivalence rule + non-substitutable constraints + validation/update logic => acceptable substitutes

structural_problem: A system has multiple possible bundles, resources, service forms, designs, or pathways that might satisfy a goal, but the boundary between acceptable substitution and harmful false equivalence is unclear.

trigger_conditions: Several options differ across multiple attributes, but decision-makers need to choose or authorize substitutes.

trigger_conditions: A preferred resource, supplier, pathway, role, or design is unavailable, too costly, too slow, or not suitable for all users.

trigger_conditions: Stakeholders disagree about whether one bundle is really equivalent to another.

trigger_conditions: A shortage, budget constraint, customization need, or redesign pressure forces substitution rather than simple selection of the ideal option.

trigger_conditions: Prior substitutions have caused quality loss, access problems, user dissatisfaction, safety incidents, compatibility failures, or fairness concerns.

symptoms: People call alternatives equivalent without naming the outcome being preserved.

symptoms: Substitutions are approved ad hoc by whoever has local authority or urgency.

symptoms: Cheaper or more available options quietly replace important quality, safety, accessibility, or trust attributes.

symptoms: Decision meetings repeatedly revisit the same substitution disputes because no reusable rule exists.

symptoms: Approved alternatives exist as a list but do not explain evidence, constraints, or review triggers.

symptoms: A one-dimensional score hides differences among attributes that are not actually interchangeable.

root_tension: The system wants flexibility in how a goal is satisfied, but flexibility becomes dangerous when it erases distinctions among alternatives that are not equivalent for the preserved outcome.

anti_signatures: There is only one feasible option, so no substitution decision is present.

anti_signatures: The relevant requirement is absolute and no attribute can compensate for violating it.

anti_signatures: The issue is dominated-option elimination rather than equivalence among acceptable bundles; Pareto Frontier Navigation is a closer fit.

anti_signatures: The task is only to show a tradeoff surface without authorizing swaps; Tradeoff Surface Mapping or a decision-analysis mechanism is a closer fit.

anti_signatures: The problem is simply that a choice has an opportunity cost; Opportunity Cost Surfacing is a closer fit.

anti_signatures: The map is an artifact with no decision consequences, validation rule, or review boundary.

structural_intervention: Define what outcome must be preserved, identify the variable attributes or resources, map acceptable equivalence regions, state substitution rules and rates, mark non-substitutable constraints, validate substitutes, and maintain the map as conditions change.

action_logic: Name the preserved outcome, capability, obligation, or value that substitutes must satisfy.

action_logic: List the dimensions along which candidate bundles differ and decide which dimensions are potentially tradable.

action_logic: Identify feasible bundles and remove options that violate non-negotiable constraints before comparing substitutable attributes.

action_logic: Construct an equivalence region or acceptability band that distinguishes acceptable, marginal, review-needed, and unacceptable substitutes.

action_logic: Define substitution rules: what can replace what, under which conditions, at what exchange rate or tier, and with what evidence.

action_logic: Attach validation criteria so a proposed substitute can be tested or reviewed rather than merely asserted.

action_logic: Assign review and update responsibility so the map changes when preferences, evidence, constraints, costs, or risks change.

decision_rules: A substitute is acceptable only if it preserves the named outcome requirement and remains inside every non-substitutable constraint.

decision_rules: A higher level of one attribute compensates for a lower level of another only when the substitution rule explicitly authorizes that exchange.

decision_rules: A bundle outside the equivalence region must either be redesigned, escalated for review, or rejected rather than quietly accepted.

decision_rules: Stakeholder preference evidence is required when acceptability depends on lived value, burden, access, trust, or fairness.

decision_rules: Substitution rates or equivalence classes must be revisited when evidence, context, constraints, or stakeholder preferences change.

target_invariants: The preserved outcome or capability remains satisfied.

target_invariants: Non-substitutable constraints are not traded away.

target_invariants: Substitution claims are evidence-based or explicitly reviewed.

target_invariants: Stakeholders can see why one bundle is treated as acceptable relative to another.

target_invariants: The map remains current enough to guide real decisions rather than fossilizing old assumptions.

expected_outcomes: Faster and more legitimate substitution decisions under shortage, redesign, procurement, customization, or capacity pressure.

expected_outcomes: Reduced false equivalence because important non-tradable dimensions are explicitly protected.

expected_outcomes: More flexible resource use without losing the outcome that made the original option valuable.

expected_outcomes: Less repetitive dispute because recurring substitution questions are handled by a reusable map and review rule.

expected_outcomes: Better stakeholder trust because acceptability is explained rather than imposed by hidden assumptions.

prose_essence:
Acceptable Substitution Mapping is the intervention of making substitutes legitimate rather than merely convenient. It asks what must be preserved, what can vary, which combinations are close enough to count as acceptable, and where substitution stops being allowed.

The archetype is useful when there are multiple ways to satisfy a goal: different vendors, service channels, benefit packages, staffing mixes, care pathways, technical designs, or resource bundles. Without a map, actors often approve substitutes ad hoc. The result can be false equivalence: a cheaper, faster, or more available option is treated as the same as the original while quietly losing quality, access, compatibility, dignity, safety, or trust.

The core move is to turn implicit preference-equivalence into a usable rule: these attributes may substitute for one another under these conditions; these attributes require evidence; these attributes cannot be traded away; these edge cases need review.

prose_when_to_use:
Use this archetype when a goal can be satisfied by several bundles but the organization does not yet know which substitutions are acceptable. It is especially useful under scarcity, procurement delays, customization pressure, staffing shortages, service redesign, or multi-attribute design choices.

It fits when people are already arguing about whether one option is "equivalent," "good enough," "acceptable," or "close enough." It also fits when an approved-alternative list exists but lacks the reasoning needed to decide new cases.

Do not use it when every requirement is absolute, when there is only one feasible option, or when the real problem is simply choosing among non-dominated options. In those cases, a guardrail, a capacity decision, or Pareto frontier navigation may be closer.

prose_structural_problem:
The structural problem is unclear substitutability. A system wants flexibility, but the boundaries of acceptable replacement are undefined. One actor may see two alternatives as equivalent because both meet a visible criterion; another actor may see them as very different because one preserves trust, accessibility, compatibility, or safety and the other does not.

This problem often appears as repeated substitution disputes, informal exceptions, confusing procurement approvals, service downgrades disguised as equivalence, one-dimensional scoring, or stakeholder dissatisfaction after a supposedly equivalent change.

The root tension is that flexibility is valuable only if the preserved outcome remains intact. A substitution map prevents the system from confusing "different but acceptable" with "different in a way that breaks the purpose."

prose_intervention_logic:
The intervention begins by naming the outcome requirement. The system must specify what all acceptable bundles need to preserve: a capability, a service outcome, a safety condition, a quality level, a user experience, a legal obligation, or a value promise.

Next, the system identifies the dimensions along which bundles vary. Some dimensions are tradable: one bundle can have more of one attribute and less of another while remaining acceptable. Other dimensions are non-substitutable: no amount of convenience, price reduction, or speed compensates for violating them.

The archetype then defines an equivalence region or acceptability band. This can be quantitative, qualitative, tiered, or procedural. What matters is that it tells decision-makers which substitutions are automatically acceptable, which require evidence or review, and which are out of bounds.

Finally, the map is maintained. Substitutions that were acceptable under one supply condition, technology, stakeholder group, or risk level may become unacceptable later. The map therefore needs update triggers, accountable ownership, and a path for exceptions.

prose_key_components:
### Outcome Requirement

The outcome requirement is the value that must survive substitution. It might be patient safety, service access, product reliability, learning outcome, technical compatibility, or strategic capability. Without this component, the system has no basis for saying that two alternatives are equivalent for the purpose at hand.

### Attribute or Resource Dimensions

These are the dimensions that differ across bundles: cost, time, quality, risk, coverage, staffing, convenience, durability, maintainability, accessibility, or expertise. The map needs dimensions because substitution usually trades among attributes rather than replacing one object with an identical copy.

### Acceptable Bundle Set

The acceptable bundle set names the feasible combinations being considered. It prevents the map from drifting into hypothetical options that cannot actually be used. A bundle may be a product, service tier, staffing mix, compensation package, care pathway, or design configuration.

### Preference Surface or Equivalence Region

This component captures the "equal enough" area. It may be an indifference curve, a tiered band, an equivalence class, a policy rule, or a qualitative acceptability zone. It explains why several different bundles can count as acceptable for the same purpose.

### Substitution Rule

The substitution rule converts the map into action. It states what may substitute for what, under what conditions, and with what evidence. This is the component that keeps the archetype from being only an analysis artifact.

### Substitution Rate or Exchange Ratio

Some domains require an explicit rate: how much of one attribute compensates for a reduction in another. Other domains use levels, thresholds, or equivalency classes. The purpose is to prevent vague claims that one benefit offsets another cost without a stated rule.

### Non-Substitutable Constraint

Not everything can be traded. Safety, legality, dignity, rights, minimum access, compatibility, identity-defining features, or clinical requirements may be non-substitutable. This component protects the map from becoming a license for unacceptable sacrifice.

### Evidence or Validation Criterion

A substitute needs evidence. Depending on the domain, that evidence may be testing, certification, stakeholder acceptance, trial results, audit data, clinical judgment, or compatibility verification. Validation turns substitution from assertion into accountable decision-making.

### Stakeholder Preference Source

Acceptability often depends on whose values are being preserved. A substitution that is acceptable to a budget owner may be unacceptable to a user, patient, worker, or community. This component identifies whose preferences and burdens matter.

### Decision Boundary and Review Rule

The review rule divides the map into ordinary cases, review-needed cases, and rejected cases. It reduces repetitive negotiation while preserving judgment for edge cases and contested substitutions.

### Update Trigger

Substitution maps decay. Costs change, technology changes, regulations change, stakeholders change, and evidence changes. The update trigger keeps yesterday's equivalence from becoming today's hidden failure.

Optional components such as tiered acceptability bands, fallback catalogs, appeal paths, uncertainty margins, and explicit ownership strengthen the map when decisions are frequent, high-risk, or contested.

prose_common_mechanisms:
### Substitution Matrix

A substitution matrix compares alternatives against attributes and records which swaps are acceptable. It is helpful for recurring decisions, but it is only a mechanism. The archetype is present only when the matrix is tied to preserved outcomes, constraints, validation, and review rules.

### Equivalency Table

An equivalency table lists options that count as equivalent for a requirement. Procurement, credentialing, compliance, and technical design often use this mechanism. The risk is that the table becomes a frozen list without explaining when equivalence actually holds.

### Approved Alternative Catalog

An approved catalog stores substitutes that have already passed review. It speeds decisions under shortage or urgency. It also needs maintenance because a substitute can become obsolete, unsupported, unsafe, or unacceptable as context changes.

### Indifference Map

An indifference map visualizes bundles that stakeholders treat as equal enough. It can be quantitative or qualitative. It becomes part of this archetype only when it supports an actionable substitution rule.

### Preference Elicitation Workshop

A workshop gathers stakeholder judgments about which attributes can compensate for others. This mechanism is important when acceptability is social, experiential, or value-laden rather than purely technical.

### Conjoint or Tradeoff Survey

A survey can estimate how people value attribute combinations. It can reveal substitution rates, but the survey does not replace non-substitutable constraints or ethical review.

### Procurement Equivalence Review

This workflow tests whether alternate products, vendors, or materials satisfy the same requirement. It prevents substitution from becoming a hidden downgrade in quality, compatibility, lifecycle support, or compliance.

### Design Tradeoff Curve

A design curve shows how one technical attribute may vary against another. It supports substitution mapping when the team uses it to decide which design bundles preserve the required function.

### Service Tier Mapping

Service tier mapping defines bundles of service attributes. It can support acceptable substitution when different tiers preserve the relevant outcome for the users they serve.

### Exception Review Workflow

An exception workflow handles substitutes that fall outside the map or near its boundary. It keeps the map flexible without turning every case into arbitrary local discretion.

prose_failure_modes:
False equivalence is the central failure mode. It occurs when two alternatives are treated as interchangeable because they share a visible property while differing on the attribute that actually matters.

A hidden non-substitutable constraint appears when a hard requirement is accidentally treated as tradable. For example, a cheaper option may be acceptable on cost and delivery time but unacceptable on accessibility or safety.

Preference capture happens when the map reflects the preferences of powerful actors rather than affected stakeholders. A manager's acceptable substitute may be an end user's unacceptable burden.

A stale map preserves old equivalences after the context changes. A vendor, technology, channel, or staffing mix that was acceptable last year may no longer preserve the same outcome.

Metric laundering happens when a number makes incomparable attributes look commensurable. A weighted score can be useful, but it cannot prove equivalence unless the substitution logic is valid.

Exception creep occurs when repeated marginal exceptions expand the map until it no longer protects the original outcome.

prose_neighbor_distinctions:
Acceptable Substitution Mapping is close to Tradeoff Surface Mapping, but not identical. A tradeoff map shows what is gained and lost. A substitution map decides which swaps are acceptable enough to act on.

It is close to Pareto Frontier Navigation, but the question is different. Pareto navigation asks which options are non-dominated. Acceptable substitution asks which bundles can stand in for one another while preserving a requirement.

It is close to Opportunity Cost Surfacing because both make alternatives visible. Opportunity cost asks what is forgone. Acceptable substitution asks whether an alternative can replace another without losing what matters.

It is close to Tradeoff Guardrail because substitution maps often contain non-substitutable constraints. The guardrail says what cannot be sacrificed; the substitution map defines allowable variation inside those boundaries.

It is close to Equivalence Class Consolidation, but more action-oriented. Equivalence classes group things treated as the same. Acceptable Substitution Mapping governs when one thing may replace another in a live decision.

prose_cross_domain_examples:
In procurement, a substitute material is acceptable only if it satisfies performance, safety, compliance, compatibility, and lifecycle support requirements. Price and availability alone do not establish equivalence.

In service delivery, a self-service channel can substitute for live support only for tasks where users can still complete the job with acceptable error recovery, access, and trust.

In compensation design, more flexibility may compensate for lower salary for some people, but not if the package violates pay equity, legal requirements, or basic livelihood constraints.

In healthcare access, telehealth can substitute for an in-person visit only for cases where diagnostic quality, privacy, follow-up, and patient-specific risk remain acceptable.

In software architecture, a managed service can substitute for custom infrastructure only if it preserves security, latency, observability, data-handling, and operational-control requirements.

In staffing, automation plus a smaller expert team can substitute for a larger generalist team only if coverage, escalation, and accountability remain intact.

prose_non_examples:
A cheaper vendor list is not acceptable substitution mapping if nobody has defined the outcome requirements and validation evidence.

A preference survey is not the archetype if it does not create a decision rule.

A hard safety threshold is not this archetype by itself; it is more likely a Tradeoff Guardrail.

A Pareto chart is not this archetype by itself; it supports frontier reasoning, not equivalence governance.

A list of options ranked from best to worst is not a substitution map unless it defines which options can stand in for one another and under what conditions.

prose_tradeoffs:
The main tradeoff is flexibility versus precision. A wider acceptability region gives more options but raises the risk that important differences are ignored.

Another tradeoff is speed versus legitimacy. Pre-approved substitutes move quickly, but fast approval can ignore stakeholders or new evidence.

There is also a simplification tradeoff. A map must simplify to be usable, but it can oversimplify if it compresses dignity, safety, access, trust, or identity into a single score.

Finally, there is a governance tradeoff. The more review the map requires, the safer and more legitimate it may be; the more burdensome it may become for ordinary low-risk decisions.

prose_invariants_to_preserve:
The preserved outcome must remain intact. A substitute that breaks the reason the original option mattered is not acceptable.

Non-substitutable constraints must remain visible and enforceable. They should not be converted into ordinary preference weights unless human review explicitly authorizes that change.

The basis for equivalence must be explainable. Stakeholders should be able to see why a bundle counts as acceptable, what evidence supports it, and where the boundary lies.

The map must remain revisable. A substitution rule that cannot change becomes dangerous when evidence or context changes.

prose_target_outcomes:
A successful map improves flexibility without sacrificing the protected outcome. It lets decision-makers use alternative resources, pathways, designs, or bundles when the ideal option is unavailable, costly, slow, or mismatched.

It reduces repeated dispute because recurring substitution questions are answered by a shared rule. It also improves accountability because false equivalence becomes easier to detect.

The strongest outcome is legitimate adaptation: the system can vary how a goal is achieved while preserving the reason the goal mattered.

prose_parameter_dimensions:
The main tuning dimension is strictness. A strict map allows few substitutions and protects quality, safety, or legitimacy, but may reduce flexibility. A loose map allows more adaptation but increases false-equivalence risk.

A second dimension is granularity. A coarse map may use broad tiers such as acceptable, review-needed, and unacceptable. A fine map may specify detailed exchange ratios, eligibility rules, and validation evidence.

A third dimension is evidence burden. Low-risk substitutions can use lightweight review. High-risk substitutions need stronger evidence, testing, audit, or stakeholder validation.

A fourth dimension is stakeholder specificity. Some maps apply broadly; others must distinguish groups because what is acceptable for one group may not be acceptable for another.

A fifth dimension is update cadence. Stable domains can review maps periodically. Fast-changing domains need event-triggered updates when supply, technology, regulation, cost, or preference changes.

prose_variants_and_near_names:
Procurement Equivalency Mapping is the procurement-focused variant. It deals with products, vendors, materials, specifications, certifications, compatibility, and lifecycle support.

Service Bundle Substitution maps alternative service packages that preserve acceptable value. It is useful for service tiers, channel design, public services, and customer support.

Compensation Bundle Equivalence asks which mixes of pay, flexibility, benefits, stability, autonomy, and development are acceptable to different participants. It is a candidate variant because it overlaps with incentive design and fairness questions.

Capability Mix Substitution maps which combinations of roles, skills, automation, tools, or staffing levels preserve a required capability.

Care Pathway Substitution is a safety-sensitive candidate variant. It maps alternative interventions or support pathways, but only with careful attention to outcome evidence, consent, dignity, and individual variation.

Near names include acceptable alternative mapping, preference equivalence mapping, substitution mapping, equivalency mapping, indifference map, substitution matrix, and approved alternative list. The last three are often mechanisms, not the archetype itself.

Procurement Equivalency Mapping

short_definition: Defines which products, vendors, materials, or specifications may substitute for one another while preserving required performance, compatibility, and risk constraints.

distinctive_feature: The substitution unit is a procured item, vendor, material, or specification, and validation often depends on certifications, compatibility tests, lifecycle support, and compliance evidence.

distinct_from_parent: The parent covers substitution across domains; this variant narrows the pattern to purchasing and specification equivalency.

still_same_parent_because: It still preserves an outcome requirement by naming acceptable substitutes, non-substitutable constraints, validation criteria, and review boundaries.

use_when: A procurement decision has several possible suppliers, materials, versions, or configurations.

use_when: Substitution could preserve the outcome but might silently reduce quality, compatibility, maintainability, or compliance.

use_when: Decision-makers need a reusable equivalency rule rather than a one-off exception.

Outcome Requirement

role: Defines the result, capability, obligation, or value that all substituted bundles must preserve.

notes: The archetype cannot work until the preserved outcome is named. Otherwise any swap can be defended as equivalent by convenience rather than by outcome value.

Substitution Rule

role: States what may replace what, under which conditions, and with which evidence.

notes: A substitution rule turns a preference map into an operational decision rule. Without it, the draft would collapse into a diagram or analysis method.

Non-Substitutable Constraint

role: Marks dimensions that cannot be traded away even when other attributes can substitute.

notes: This keeps substitution from becoming false equivalence. Safety, legal compliance, rights, minimum quality, and identity-defining requirements often sit here.

Evidence or Validation Criterion

role: Defines how an asserted substitute is tested, justified, or rejected.

notes: Evidence can be measurement, certification, stakeholder acceptance, trial performance, clinical outcome, audit result, or expert review.

Fallback Alternative Catalog

role: Stores pre-approved substitutes for common shortage, procurement, design, or staffing conditions.

notes: A catalog speeds action, but it must remain tied to the substitution rule and validation criteria.

Equivalency Table

mechanism_type: artifact

role: Lists alternatives that count as equivalent or acceptable substitutes for a requirement.

notes: Common in procurement, compliance, credentialing, and technical design; it is a mechanism, not the whole archetype.

Approved Alternative Catalog

role: Maintains a reusable list of substitutes that have already passed validation.

notes: Useful when speed matters, but risky if the catalog is not periodically reviewed.

Procurement Equivalence Review

role: Reviews whether alternate products, vendors, or materials satisfy the same requirement.

notes: Prevents supply substitution from quietly reducing quality, compatibility, safety, or lifecycle support.

domain: construction

example: A substitute material is acceptable only if it meets load, fire, lifecycle, and compatibility requirements, not merely because it is cheaper.

domain: IT procurement

example: A replacement vendor is approved only if integration, support, data-handling, and service-level conditions remain satisfied.

failure_modes: False equivalence between cheaper and fit-for-purpose alternatives.

failure_modes: Approved-substitute lists becoming stale after supply, regulation, or lifecycle support changes.

Service Bundle Substitution

short_definition: Maps alternative bundles of service features, speed, coverage, channel, support, and price that preserve acceptable user value.

distinctive_feature: The substitute is a bundle of service attributes rather than a single product, resource, or design parameter.

distinct_from_parent: The parent is general; this variant emphasizes bundle design, service tiers, and customer/user acceptability.

still_same_parent_because: It still relies on outcome preservation, equivalence regions, substitution rules, and non-substitutable constraints.

use_when: A service can be delivered through multiple bundles rather than one fixed package.

use_when: Users or customers differ in which attributes they value most.

use_when: The provider must avoid treating lower-cost or lower-touch service as equivalent when the protected outcome is not actually preserved.

Acceptable Bundle Set

role: Identifies the combinations that are candidates for being treated as acceptable ways to satisfy the requirement.

notes: The set should include only feasible bundles, not every imagined alternative. Infeasible bundles belong outside the map.

name: Preference Surface or Equivalence Region

role: Captures where different bundles are treated as equal enough, close enough, or acceptable enough for the decision at hand.

notes: This component generalizes indifference curves into a practical decision region. It need not be mathematical, but it must explain why alternatives are comparable.

Stakeholder Preference Source

role: Identifies whose preferences, constraints, or outcome judgments determine acceptability.

notes: Substitution maps are dangerous when they replace affected parties with designer assumptions. This component anchors the map in legitimate preference evidence.

Tiered Acceptability Band

role: Separates ideal, acceptable, marginal, and unacceptable substitutes.

notes: Useful when exact equivalence is too strict but total substitutability is unsafe.

Indifference Map

role: Visualizes bundles that are treated as preference-equivalent or acceptable under current assumptions.

notes: It can support reasoning, but the archetype is the decision discipline that makes those equivalences actionable.

Preference Elicitation Workshop

mechanism_type: ritual

role: Elicits stakeholder judgments about which attributes can compensate for others.

notes: Useful when acceptability depends on lived experience, values, or contested priorities rather than purely technical equivalence.

Service Tier Mapping

role: Defines alternative service bundles that provide acceptable value for different needs, budgets, or constraints.

notes: Useful when different customers or users can receive different bundles without undermining the protected outcome.

domain: customer support

example: A self-service option can substitute for live support only for tasks where resolution quality and accessibility remain acceptable.

example: A hybrid learning bundle is acceptable only when learning outcomes, feedback, and access constraints are preserved.

failure_modes: Offering cheaper service bundles that preserve provider cost goals but not user outcomes.

failure_modes: Ignoring accessibility or trust as non-substitutable dimensions.

Compensation Bundle Equivalence

short_definition: Maps combinations of pay, benefits, flexibility, autonomy, status, stability, and development that may be acceptable to different participants.

distinctive_feature: The acceptability of substitution depends heavily on participant preference heterogeneity and fairness perceptions.

distinct_from_parent: The parent handles any acceptable substitution. This variant focuses on incentive and employment bundles.

still_same_parent_because: It uses the same architecture of preference evidence, equivalence region, non-substitutable constraints, and review boundary.

use_when: A compensation or incentive decision contains multiple valued attributes rather than one scalar reward.

use_when: Different people treat bundles differently, so the organization cannot assume a universal exchange rate.

use_when: The decision needs to preserve perceived fairness, retention, motivation, or contractual value.

Substitution Rate or Exchange Ratio

role: Specifies the amount of one attribute, resource, or condition that compensates for a change in another.

notes: Some domains need an explicit exchange rate; others use ordinal tiers, equivalency classes, or qualitative acceptability bands.

Decision Boundary and Review Rule

role: Specifies when a mapped substitute is automatically acceptable, when it needs review, and when it is out of bounds.

notes: This component prevents endless negotiation while preserving human review for edge cases, uncertainty, or contested substitutions.

Conjoint or Tradeoff Survey

role: Estimates how stakeholders value different attribute combinations.

notes: Can reveal substitution rates, but survey results must be interpreted through constraints and validity checks.

domain: workforce planning

example: More remote-work flexibility may compensate for lower salary for some roles, but not when pay falls below a non-substitutable living-wage or equity constraint.

failure_modes: Assuming one group's preference curve applies to everyone.

failure_modes: Using perks to mask non-substitutable compensation or dignity requirements.

Capability Mix Substitution

short_definition: Maps how different mixes of roles, skills, tools, staffing, or automation can preserve a required capability.

distinctive_feature: The substitute is a capability-producing mix, not a product or service bundle.

distinct_from_parent: This variant emphasizes staffing, skill-mix, tool-mix, and capability preservation.

still_same_parent_because: It still asks which bundle preserves the required outcome, under which rules and constraints.

use_when: A capability can be produced by several combinations of people, tools, expertise, or process design.

use_when: Capacity shortages or design choices require substitution among skills, roles, automation, or support structures.

use_when: The system needs to know where substitution is safe and where it breaks accountability, judgment, or coverage.

Attribute or Resource Dimensions

role: Names the dimensions along which alternatives differ and can potentially substitute for one another.

notes: Typical dimensions include cost, time, quality, risk, accessibility, durability, coverage, expertise, convenience, and capacity.

Substitution Matrix

role: Compares alternatives against attributes and records which swaps are acceptable under stated conditions.

notes: The matrix implements the archetype only when it is tied to a preserved outcome, validation criteria, and non-substitutable constraints.

Exception Review Workflow

role: Routes uncertain or out-of-map substitutions to accountable review.

notes: This mechanism keeps the map flexible without turning every substitution into ad hoc negotiation.

example: A smaller expert team plus automation may substitute for a larger generalist team only if coverage, escalation, and exception-handling remain intact.

failure_modes: Substituting headcount for expertise when judgment is non-substitutable.

failure_modes: Ignoring hidden coordination or supervision costs.

Care Pathway Substitution

short_definition: Maps alternative care, support, or intervention pathways that can preserve acceptable outcomes without violating safety or dignity constraints.

distinctive_feature: Substitution carries heightened safety, consent, and individual-fit risks.

distinct_from_parent: The parent is domain-general; this variant is sensitive to health, care, and support contexts where equivalence evidence is uncertain and person-specific.

still_same_parent_because: It still maps acceptable substitutes against preserved outcomes, constraints, evidence, and review rules.

use_when: Multiple interventions could plausibly satisfy a care or support goal.

use_when: Safety, dignity, consent, and individual variation make false equivalence especially harmful.

use_when: The decision requires explicit non-substitutable constraints and evidence standards.

Exception and Appeal Path

role: Provides a governed route for contested or novel substitutions.

notes: Especially important when substitutions affect safety, access, fairness, identity, or trust.

Uncertainty Margin

role: Adds caution when equivalence evidence is incomplete or variable.

notes: Prevents brittle claims of equivalence in noisy domains.

domain: healthcare access

example: Telehealth may substitute for in-person care only for cases where diagnostic quality, privacy, follow-up, and patient access remain acceptable.

failure_modes: Treating administratively convenient substitutions as clinically or personally equivalent.

failure_modes: Failing to adapt the substitution map to individual risk and preference.

near_names:
Acceptable Alternative Mapping
Preference Equivalence Mapping
Substitution Mapping
Equivalency Mapping
Substitution Matrix
Equivalency Table
Approved Alternative List
Indifference Map
Equivalent Bundle Selection


Access-Conditioned Bundle Decoupling

type: archetype

source: generated

batch: Batch 09

aliases:
conditional access bundle governance
coercive tying decoupling
forced bundle separation
access leverage audit
take-it-or-leave-it condition review
access-conditioned consent separation
unwanted add-on unbundling
conditional access fairness guardrail

source_primes: conditional_access coercion compellence consent optionality relationship_specific_investment

slug: coercion

slug: compellence

slug: consent

slug: optionality

slug: gatekeeping

slug: contract

slug: monopoly

slug: dependency

slug: substitutability

slug: asymmetry

slug: authority

slug: accountability

slug: externality

slug: exchange

slug: scarcity

components: Essential-Access Heightened Scrutiny Trigger

mechanisms: Appeal, Waiver, or Manual Access Channel

compression_statement: Access-conditioned bundle decoupling applies when a controller controls a desired access path and attaches an undesired condition, add-on, waiver, data demand, obligation, product, policy, or relationship commitment to that access. The central task is not merely to allow or deny entry. It is to ask whether the condition is necessary to the access being granted, proportionate to the purpose, separately consentable, fairly priced or scoped, reviewable, and escapable through a realistic alternative. Conditions that are integral to safety, performance, compatibility, or legal duty may remain bundled; conditions that use dependency or scarcity to extract unrelated acceptance are separated, limited, made optional, compensated, or prohibited.

core_intuition: Choice is distorted when the item someone needs is used as the handle for extracting something else. A person may appear to accept the whole package, but the observed choice may reveal dependency rather than preference. The remedy is to open the bundle: identify which parts are truly required for the desired access, which parts are opportunistic add-ons, and what alternative path would make refusal meaningful.

canonical_formula: Let D be desired access, U an undesired condition, C the controller, and A the affected party. Conditional-access risk exists when C controls D and offers D only if A accepts U. Decoupling requires classify(U) as necessary/integral or separable/extractive; if separable, provide D without U, create a realistic alternative path, or justify U through explicit necessity, proportionality, consent, remedy, and review rules.

structural_problem: A party that controls a scarce, required, or highly valued access path uses that control to attach additional terms the affected party would not freely choose if the desired item were available separately. The coupled package makes acceptance ambiguous: observed agreement may reflect preference for the desired item, dependency on the access path, lack of substitutes, switching costs, fear of exclusion, or inability to negotiate rather than genuine acceptance of the added condition.

trigger_conditions: One actor or institution controls a desired access path, scarce resource, platform, credential, contract, service, channel, benefit, or gateway.

trigger_conditions: The access is paired with an additional condition, add-on, waiver, product, permission, data use, duty, restriction, relationship commitment, or collateral obligation.

trigger_conditions: The added condition is not obviously necessary for safety, compatibility, performance, legal compliance, or core delivery of the desired access.

trigger_conditions: The affected party has limited substitutes, high switching costs, deadline pressure, relationship-specific investment, or dependency on continued access.

trigger_conditions: Acceptance is recorded as consent, purchase, agreement, revealed preference, or participation even though refusal would mean losing the desired access.

trigger_conditions: The controller benefits from the attached condition in a way that is not transparently priced, compensated, or separately negotiable.

trigger_conditions: Affected parties cannot easily identify which terms are mandatory, which are optional, and which are bundled by convenience or leverage.

trigger_conditions: Separate pricing, separate consent, opt-out, fallback access, appeal, or review would be technically possible but is absent, hidden, or punitive.

trigger_conditions: The bundle is justified by broad claims of efficiency, security, quality, or standardization without a specific necessity test.

trigger_conditions: Downstream harm appears as coerced data sharing, unwanted purchases, bundled waivers, lock-in, exclusion, distorted market signals, or suppressed alternatives.

symptoms: Users, buyers, employees, patients, students, suppliers, or citizens say they had no real choice even though records show formal agreement.

symptoms: The same access path repeatedly carries unrelated conditions that would struggle to stand on their own.

symptoms: Opt-out exists nominally but leads to service loss, degraded access, punitive pricing, excessive delay, or social/professional penalty.

symptoms: Teams cannot explain why a condition must be attached to access except that it improves uptake, compliance, revenue, data capture, or administrative convenience.

symptoms: Bundles mix safety-critical requirements with negotiable commercial, informational, or behavioral conditions, making refusal confusing.

symptoms: Revealed preference claims overstate desire because the choice set omitted the desired item without the unwanted add-on.

symptoms: The bundle is defended as standard practice even after context changes remove the original reason for coupling.

symptoms: Affected parties are told that the bundle is mandatory but cannot find the rule, owner, evidence, exception criteria, or appeal route.

symptoms: Contracts, onboarding flows, procurement terms, account creation, or access renewals accumulate unrelated acceptance requirements over time.

symptoms: Complaints cluster around unfairness, lock-in, forced acceptance, dark patterns, tying, consent fatigue, or lack of separable alternatives.

root_tension: Access sometimes legitimately requires conditions: authentication, safety rules, interoperability standards, payment, eligibility, or minimum obligations may be necessary. But the same structure can be used to smuggle in unrelated extraction. The design problem is to preserve legitimate preconditions while preventing access asymmetry from converting dependency into coerced acceptance.

anti_signatures: The condition is strictly necessary for safe or compatible access, is minimally scoped, and cannot be separated without defeating the purpose; use least_privilege_access_design, gateway_mediation, or guarded_state_transition instead.

anti_signatures: The main issue is ordinary product bundling that creates synergistic value and is offered beside a viable unbundled alternative; use synergistic_combination_design or versioning_and_quality_discrimination.

anti_signatures: The task is simply to change rewards, prices, or penalties in a strategic interaction; use payoff_restructuring unless access-conditioned acceptance is the central lever.

anti_signatures: The main concern is that consent is unclear, uninformed, or poorly recorded even without asymmetric access leverage; use informed_consent_governance.

anti_signatures: The boundary controls who may enter based on role, identity, or task need, but no unrelated condition is forced; use least_privilege_access_design or boundary_permeability_control.

anti_signatures: The offer is all-or-nothing because operations are technically atomic and rollback is required for consistency; use transactional_atomicity.

anti_signatures: The bundle exists only because components are complementary and no party is using dependency to impose an unwanted term.

anti_signatures: The affected party can easily obtain the desired item elsewhere with low cost and no material penalty, so the coercive access-asymmetry structure is weak.

anti_signatures: The added condition is optional, transparently priced, separately refuseable, and not bundled into access records or renewal flows.

structural_intervention: Map the desired access, controller, affected party, and attached conditions; classify each condition by necessity and proportionality; separate unrelated or disproportionate elements; create realistic refusal, opt-out, alternative access, severability, or remedy paths; and monitor for rebundling, punitive alternatives, or false consent claims.

action_logic: Name the desired access path and why it matters to the affected party.

action_logic: Identify the controller, their control basis, and the affected party’s dependency, substitutes, switching costs, deadlines, and bargaining position.

action_logic: Inventory every condition attached to access: product, term, waiver, data use, permission, duty, behavioral requirement, relationship commitment, pricing restriction, or collateral obligation.

action_logic: Classify each condition as integral, safety-critical, compatibility-critical, legally required, commercially negotiable, optional, unrelated, extractive, or uncertain.

action_logic: Require a necessity and proportionality justification for conditions that remain bundled with desired access.

action_logic: Separate conditions that can be separately chosen, priced, consented to, timed, scoped, or declined without undermining the desired access.

action_logic: Create a meaningful refusal path: alternative access, equivalent base service, manual process, appeal, waiver, competitive procurement, or severable contract clause.

action_logic: Make consent records distinguish acceptance of desired access from acceptance of add-on conditions.

action_logic: Set review triggers for changes in technology, law, market substitutes, security context, dependency, complaints, or evidence of harm.

action_logic: Monitor whether the alternative is real by tracking opt-out rates, denial reasons, friction, price penalties, service degradation, complaints, and hidden rebundling.

decision_rules: If the condition is necessary for safety, identity verification, interoperability, legal eligibility, or core service delivery, keep it bundled only at the minimum effective scope and document the reason.

decision_rules: If the condition primarily benefits the controller and is not necessary for the desired access, separate it by default.

decision_rules: If refusal causes loss of essential access, employment, care, education, market participation, or public service, require heightened scrutiny and a realistic alternative path.

decision_rules: If an opt-out path exists but imposes punitive friction, delay, degraded quality, stigma, or opaque pricing, treat it as insufficient decoupling.

decision_rules: If the controller claims efficiency, standardization, fraud prevention, or security, require evidence that less restrictive separation would materially fail.

decision_rules: If observed acceptance is used as evidence of preference, qualify it by the choice set and dependency context.

decision_rules: If relationship-specific investment or lock-in increases over time, lower the threshold for review and strengthen exit, portability, or renewal protections.

decision_rules: If the bundle is beneficial but potentially coercive, offer a bundle discount without eliminating the standalone option.

decision_rules: If the condition cannot yet be classified, use temporary limited coupling with expiry, disclosure, monitoring, and review rather than permanent acceptance.

decision_rules: If exceptions are allowed, make criteria explicit enough that access controllers cannot selectively reward allies or punish challengers.

target_invariants: Access conditions remain tied to a stated purpose rather than accumulated opportunistically.

target_invariants: Necessary conditions are minimally scoped, reviewable, and separated from unrelated add-ons.

target_invariants: Refusal of a separable condition does not silently destroy access to the desired item.

target_invariants: Alternatives are practical, timely, comprehensible, and not punitive in disguise.

target_invariants: Consent records preserve granularity between desired access and each attached condition.

target_invariants: Observed acceptance is not interpreted as free preference without choice-set context.

target_invariants: Security, safety, and compliance justifications are specific rather than blanket rationalizations.

target_invariants: Dependency, lock-in, and relationship-specific investment are treated as increasing coercion risk.

target_invariants: Exception, appeal, severability, and remedy paths exist for contested conditions.

target_invariants: The controller cannot rebundle separated terms through defaults, renewal friction, dark patterns, or discriminatory pricing.

expected_outcomes: Fewer cases where dependency is misread as voluntary acceptance.

expected_outcomes: Clearer distinction between legitimate access preconditions and unrelated extraction.

expected_outcomes: Improved trust in consent, contract, onboarding, service access, procurement, and platform governance.

expected_outcomes: More accurate revealed-preference and market-signal interpretation because choice sets are less distorted.

expected_outcomes: Reduced lock-in exploitation and relationship-specific hold-up.

expected_outcomes: Better auditability of why conditions are mandatory, optional, or prohibited.

expected_outcomes: Safer use of security or eligibility conditions because they are purpose-limited and reviewable.

expected_outcomes: More durable compliance and legitimacy because affected parties can understand and contest access conditions.

prose_essence:
Prevent access leverage from forcing unwanted bundled acceptance by testing necessity, unbundling separable conditions, and preserving meaningful refusal, alternatives, or remedies.

This archetype treats conditional access as a structural coupling problem. Someone controls a desired access path, and acceptance of another condition is made the price of entry. Sometimes that coupling is legitimate: security checks, eligibility requirements, compatibility constraints, or minimum obligations may be required for the access to work safely. The danger appears when the controller uses that same access handle to force unrelated acceptance.

The intervention is therefore not simple permissiveness. It is disciplined decoupling: keep necessary access conditions, separate or narrow separable conditions, and make refusal practical enough that acceptance can mean something.

Essential-Access Condition Safeguard

short_definition: Heightened scrutiny for conditions attached to essential services, livelihood, care, education, public benefits, or critical infrastructure access.

distinctive_feature: Raises the review threshold because dependency makes formal acceptance especially unreliable.

distinct_from_parent: The parent applies to any access-conditioned bundle; this variant applies when the access is essential or rights-adjacent.

still_same_parent_because: It uses the same necessity, separability, alternative-path, and rebundling checks.

use_when: Desired access is essential or practically unavoidable.

use_when: Refusal would create serious harm, exclusion, or loss of rights.

use_when: A standalone or assisted alternative may be required.

Contractual Tying Decoupling

short_definition: Review and sever contract terms where access to a desired agreement or service is tied to unrelated waivers, purchases, duties, or restrictions.

distinctive_feature: Works through term inventory, severability, renewal, and negotiation mechanics.

distinct_from_parent: Narrower than the parent because it focuses on legal/contractual instruments rather than interfaces, platform settings, or institutional gates.

still_same_parent_because: It still tests access leverage, necessity, proportionality, separability, and refusal paths.

source_primes: conditional_access contract coercion

use_when: The bundle appears primarily in contracts or terms of service.

use_when: A severability or standalone term path is possible.

use_when: Nonnegotiable terms are defended as acceptance.

Bundled Consent Separation

short_definition: Separate consent for optional data uses, communications, waivers, or permissions from consent needed for core access.

distinctive_feature: Emphasizes consent granularity and record design.

distinct_from_parent: Narrower than the parent because it operates at consent capture and documentation layers.

still_same_parent_because: It counters the same access-conditioned forced acceptance structure.

use_when: A single click, signature, or consent form covers multiple distinct permissions.

use_when: Some permissions are optional or unrelated to core access.

use_when: Consent records are later interpreted as broad voluntary acceptance.

Platform Gate Unbundling

short_definition: Separate core platform access from optional telemetry, promotion, identity-linking, upgrade, or ecosystem commitments.

distinctive_feature: Centers gatekeeping, network dependency, account renewal, and interface-level rebundling.

distinct_from_parent: Narrower than the parent because it concerns platform gates and digital interfaces.

still_same_parent_because: The same necessity and alternative-path logic applies to each attached condition.

use_when: A platform controls a gateway to users, creators, developers, workers, data, or markets.

use_when: Access renewal carries extra permissions or obligations.

use_when: Alternatives are weak because of network effects or lock-in.

Relationship-Specific Hold-Up Safeguard

short_definition: Protect parties who have invested in a relationship from later access renewals that add new conditions they cannot realistically refuse.

distinctive_feature: Emphasizes temporal drift and lock-in after investment has already occurred.

distinct_from_parent: Narrower than the parent because it focuses on post-investment hold-up rather than initial access offers.

still_same_parent_because: The harmful move is still access-conditioned acceptance of separable conditions.

use_when: Relationship-specific investment or accumulated data/workflow dependence is high.

use_when: Renewal or continued access carries new unrelated conditions.

Legitimate Security Conditioning

short_definition: Keep security, safety, or eligibility conditions attached to access only when the condition is necessary, minimal, purpose-bound, and reviewable.

distinctive_feature: Separates legitimate preconditions from access-leverage abuse without treating all conditions as suspect.

distinct_from_parent: It is a defensive variant for preserving legitimate coupling, not only removing coercive coupling.

still_same_parent_because: It uses the same purpose, necessity, proportionality, and review record.

use_when: A condition is likely legitimate but could be used as cover for unrelated extraction.

use_when: Security or safety rationales are broad and need narrowing.

near_names:
Conditional Access Governance
Coercive Tying Decoupling
Forced Bundle Separation
Access Leverage Audit
Take-It-or-Leave-It Access Review
Access-Conditioned Consent Separation


batch: Batch 05

aliases:
controlled denormalization
governed denormalization
access-path denormalization
performance-oriented denormalization
synchronized redundant representation

related_primes: canonical_form consistency_model data_integrity versioning redundancy caching search_and_retrieval observability synchronization latency optimization traceability transaction eventual_consistency schema

slug: denormalization

slug: representation

slug: versioning

slug: redundancy

slug: caching

slug: observability

slug: synchronization

slug: latency

slug: optimization

slug: traceability

slug: transaction

slug: schema

components:
Source-of-Truth Reference
Access Workload Profile
Access-Path Performance Target
Redundant Representation Specification
Derivation and Duplication Mapping
Redundancy Scope Boundary
Read-Path Contract
Write-Authority Rule
Synchronization Rule
Freshness and Staleness Bound
Freshness Rule
Transformation Lineage Record
Divergence Signal
Recovery and Reconciliation Path
Performance Benefit and Cost Model
Schema-Change Propagation Plan
Privacy and Deletion Propagation Rule
Projection Lifecycle Rule
Version Token
Invalidation Rule
Service-Level Objective
Degraded Read Mode
Writable-Projection Exception Rule
Projection Change Record

mechanisms:
Materialized View
Search Index
Synchronization Job
Reconciliation Workflow
Data Lineage Capture
Versioned Schema Change
Embedded Aggregate Document
Prejoined Read Table
Dimensional Star Schema
Summary or Rollup Table
CQRS Read-Model Projection
Event-Sourced Projection
Change-Data-Capture Propagation
Transactional Outbox Projection
Database-Trigger Synchronization
Scheduled Incremental Refresh
Freshness Watermark
Checksum and Sample Reconciliation
Backfill and Rebuild Job
Denormalized Field Generation
Read-Model Version Gate

essence_one_line: Create a governed redundant representation around a proven access path, keep one authority and an explicit derivation, bound divergence, verify the benefit, and make refresh, repair, schema change, privacy, and retirement part of the design.

compression_statement: Identify an expensive recurring access pattern; retain a canonical authority; specify a narrowly scoped alternate representation and field-level derivation; define write ownership, synchronization, freshness, and consistency budgets; route eligible reads to the projection; preserve lineage; detect and repair divergence; propagate corrections, deletions, and schema changes; measure access gains against write amplification, storage, operational burden, and risk; and retire the redundant form when the trade-off no longer holds.

core_intuition: A normalized or canonical representation minimizes duplicate truth, but it does not make every important access path cheap. Controlled redundancy moves work and structure from read time to write, refresh, or rebuild time. The move is valuable only when the copied form remains subordinate to explicit authority, its divergence is bounded and visible, and the saved access cost is greater than the complexity and risk introduced by another representation.

canonical_formula: Choose redundant representation R = f(C) for workload W only when ΔAccess(W,R) > Cost_storage(R) + Cost_sync(R) + Cost_change(R) + Risk_divergence(R), subject to Authority(R)=C, Traceable(R,C), and D(R,C,t) ≤ ε for the declared consistency budget.

structural_problem: The canonical representation preserves update simplicity, semantic unity, or normalization, but the dominant access paths repeatedly pay excessive joins, traversal, aggregation, network fan-out, transformation, or reconstruction cost. Teams either accept poor tail latency and fragile cross-boundary reads or create ad hoc copies that lack authority, lineage, freshness semantics, deletion propagation, repair, schema migration, and retirement controls. The resulting system has neither efficient access nor trustworthy correspondence.

trigger_conditions: A stable, high-value read or retrieval pattern repeatedly composes the same canonical data.

trigger_conditions: The canonical model is structurally correct for writes or ownership but materially mismatched to read shape.

trigger_conditions: Cross-service fan-out, remote joins, repeated aggregation, or graph traversal dominates latency or reliability.

trigger_conditions: The access path must work under network, edge, offline, or regional constraints.

trigger_conditions: The read-to-write ratio and reuse frequency make moving work to propagation or refresh economically plausible.

trigger_conditions: Consumers need a historical snapshot, query projection, search document, or analytical shape that differs from current canonical state.

trigger_conditions: A team is already copying fields or building projections but cannot state their source, lag, update rule, or retirement condition.

trigger_conditions: A schema or ownership boundary prevents direct access to canonical internals, yet a stable contract can expose a derived representation.

trigger_conditions: The consequence of staleness can be bounded, marked, refused, or corrected rather than ignored.

symptoms: Join storms, N+1 reads, service fan-out, or repeated transformations dominate p95 and p99 latency.

symptoms: Dashboards and reports rescan detailed events to recreate the same totals on every request.

symptoms: Clients assemble the same composite view independently and disagree about defaulting or business logic.

symptoms: Copied fields exist in several tables or documents, but no one knows which is authoritative.

symptoms: Dual writes partially succeed and create silent inconsistencies between canonical and read models.

symptoms: Search results, list pages, exports, and detail pages display contradictory values.

symptoms: A correction or deletion reaches the source but remains in an index, snapshot, edge store, or analytical table.

symptoms: Projection lag is measured as infrastructure delay but not connected to an application staleness limit.

symptoms: Schema changes require emergency backfills because dependencies and derivations were undocumented.

symptoms: A projection continues consuming storage and operational attention after its original consumer disappeared.

symptoms: Teams call every copy a cache even when it has a stable schema, separate consumers, and long-lived semantics.

symptoms: Operational incidents are repaired by hand because the redundant form cannot be deterministically rebuilt.

root_tension: One canonical form reduces duplicate truth and update surfaces, while access efficiency often demands locality, precomposition, alternate grain, or copied context; every access-side win transfers cost and risk into synchronization, storage, write amplification, change propagation, privacy, and divergence management.

anti_signatures: No measured or consequential access bottleneck exists; keep the canonical representation simple.

anti_signatures: The copy exists primarily so service continues after a component fails; use Redundant Backup Provisioning or Diverse Functional Redundancy.

anti_signatures: The stored result is temporary, evictable, and governed mainly by locality, hit rate, and capacity; use Strategic Caching.

anti_signatures: The primary move is doing likely future work before demand, without establishing a stable alternate representation; use Precomputation / Prefetching.

anti_signatures: The structure stores keys or pointers so records can be found without scanning, but does not duplicate meaningful content; use Index-Based Retrieval.

anti_signatures: The task is to collapse equivalent forms, aliases, or duplicate entities toward one canonical representative; use Equivalence Normalization.

anti_signatures: The primary decision is which system or record is authoritative; use Source-of-Truth Assignment.

anti_signatures: The primary decision is which client-visible histories and staleness semantics are legal; use Shared-State Consistency Contract Design.

anti_signatures: Representations have already drifted and the central work is comparison and repair; use Reconciliation After Drift.

anti_signatures: The alternate record is an independently authoritative branch intended for human review and merge; use Branching and Merging.

anti_signatures: A one-off export or report has no recurring access contract, synchronization obligation, or operational lifecycle.

structural_intervention: Replace ad hoc copies or chronically expensive read-time composition with a narrowly scoped, explicitly derived redundant representation whose authority, access contract, synchronization, divergence budget, lineage, evidence, repair, change, privacy, and lifecycle obligations are designed together.

action_logic: Identify the canonical authority, its invariants, ownership boundary, version semantics, and update paths.

action_logic: Measure the recurring access workload and isolate the actual bottleneck: joins, fan-out, traversal, aggregation, transformation, remote latency, or offline dependence.

action_logic: State a quantitative access target and compare nonredundant alternatives such as query tuning, indexing, batching, API redesign, or boundary change.

action_logic: Specify the smallest alternate representation that satisfies the target, including copied, computed, omitted, historical, and restricted fields.

action_logic: Create a field- and aggregate-level derivation mapping from canonical inputs to the redundant form and preserve lineage.

action_logic: Declare write authority and default to one-way propagation; review any writable projection as a separate transaction and conflict problem.

action_logic: Select a synchronization and rebuild strategy whose ordering, retry, idempotence, and failure behavior satisfy the domain invariant.

action_logic: Define freshness and consistency budgets per use case, plus explicit fallback, stale-marking, refusal, or degraded-mode behavior.

action_logic: Route only eligible reads to the projection and expose enough version or freshness context for consumers to interpret results correctly.

action_logic: Instrument access benefit, propagation lag, missed changes, divergence, rebuild health, storage growth, write amplification, and consumer use.

action_logic: Exercise correction, deletion, revocation, late data, out-of-order events, schema change, partial failure, replay, and full rebuild paths.

action_logic: Treat projection schema and derivation changes as versioned migrations with compatibility windows, backfills, validation, and rollback.

action_logic: Periodically recompute the trade-off and retire, consolidate, or redesign projections whose benefit no longer exceeds their burden.

decision_rules: Do not introduce redundancy until the access bottleneck and expected benefit are measured against a simpler alternative.

decision_rules: Maintain one declared authority for each duplicated fact unless a separate multi-authority consistency design is explicitly justified.

decision_rules: Prefer deterministic, one-way, idempotent derivation that can be replayed or rebuilt from canonical history.

decision_rules: Duplicate only the fields and time horizon required by the named access path; do not clone whole models by default.

decision_rules: Choose synchronous propagation only when the invariant requires same-transaction correspondence; otherwise use bounded asynchronous propagation with visible lag.

decision_rules: If a stale answer can cause irreversible harm, refuse, redirect, or revalidate rather than silently serving outside the budget.

decision_rules: If a projection cannot be reconstructed and must accept independent truth, reclassify it as an authority or branch rather than hiding the change under denormalization.

decision_rules: Do not use uncoordinated dual writes as the default; pair authoritative mutation with a durable change record or use transactional propagation where necessary.

decision_rules: Corrections, deletions, consent changes, and access revocations receive the same propagation rigor as ordinary updates.

decision_rules: Schema changes must update the derivation, lineage, validation, and rebuild plan before consumers rely on the new shape.

decision_rules: A projection with no active consumer, no measured benefit, or persistent unexplained divergence should be retired or rebuilt, not normalized as permanent debt.

target_invariants: Every redundant value has a declared canonical authority or historical-snapshot rule.

target_invariants: Every field and aggregate has a reproducible derivation or copy mapping and traceable source versions.

target_invariants: The redundant representation is writable only according to an explicit authority and conflict rule.

target_invariants: Divergence remains within the declared temporal, version, aggregate, and semantic budget for each eligible use.

target_invariants: Consumers can determine whether a projection is current, stale, partial, rebuilding, degraded, or unavailable when that distinction matters.

target_invariants: Corrections, deletions, revocations, and security changes propagate or cause the projection to be quarantined within a declared bound.

target_invariants: The projection can be validated and, where feasible, fully rebuilt without inventing truth outside the canonical source.

target_invariants: Schema and transformation versions remain compatible or are migrated through an observable, reversible process.

target_invariants: The redundant form does not expand data access, retention, residency, or inference beyond approved policy.

target_invariants: Measured access benefit continues to exceed storage, synchronization, write, change, operational, and risk cost.

expected_outcomes: Lower and more predictable read latency for the targeted access path.

expected_outcomes: Reduced joins, graph traversal, network fan-out, and repeated aggregation at request time.

expected_outcomes: Better availability for bounded edge, offline, regional, and cross-service reads.

expected_outcomes: Explicit authority, freshness, lineage, and correction semantics for copies that previously existed informally.

expected_outcomes: Faster diagnosis and deterministic repair or rebuild when a projection diverges.

expected_outcomes: Safer schema evolution because dependencies, derivations, consumers, and backfill paths are known.

expected_outcomes: Reduced privacy and retention surprises through deliberate propagation and lifecycle controls.

expected_outcomes: A reversible portfolio of read-oriented representations rather than unbounded accidental duplication.

prose_tradeoffs:
The intervention is valuable precisely because it changes a trade-off rather than eliminating one. The read path becomes cheaper by spending resources and accepting governance obligations elsewhere.

- Read latency and fan-out improve at the cost of additional storage and more write or refresh work.
- Locality and availability improve while the probability and duration of stale observation increase.
- A simpler consumer interface creates a more complex producer, propagation, lineage, and migration surface.
- Prejoined or embedded shapes reduce request-time composition but constrain independent evolution and may duplicate sensitive context.
- Synchronous propagation protects strong correspondence but increases transaction latency, contention, and failure coupling.
- Asynchronous propagation decouples writes and improves availability but requires explicit staleness, replay, ordering, and repair semantics.
- Fine-grained projections reduce copied data but increase the number of models, pipelines, ownership boundaries, and version combinations.
- Broad projections simplify consumer reuse but increase storage, privacy exposure, update amplification, and accidental dependency.
- Stored historical snapshots preserve past meaning but complicate correction, erasure, and the distinction between current and historical truth.
- Rebuildable projections reduce repair risk but require durable canonical history, deterministic transformations, and capacity for backfill.
- Aggressive aggregation lowers query cost but loses detail and can make corrections or alternative groupings expensive.
- A strict freshness budget protects semantics but may force fallback or refusal precisely when the optimized path is most valuable.

Embedded-Aggregate Denormalization

variant_type: subtype

short_definition: Place related values inside one aggregate-shaped representation so the dominant read and consistency boundary can be served locally.

distinctive_feature: The redundant shape follows an aggregate boundary and often copies child summaries or reference attributes directly into the parent record.

distinct_from_parent: The parent permits any governed redundant representation; this subtype specifically aligns storage with an aggregate and locality boundary.

still_same_parent_because: It still creates a governed, traceable redundant representation for an access-side benefit while retaining canonical authority, a derivation mapping, a synchronization or rebuild contract, bounded divergence, and lifecycle control.

use_when: The same parent-and-child data is read together far more often than it is updated independently.

use_when: A domain aggregate supplies a meaningful ownership and transaction boundary.

use_when: Cross-record joins or network fan-out dominate tail latency.

domain: commerce

example: An order stores the purchased product name, tax category, and price snapshot needed to render and audit that order.

example: A case document embeds the current contact summary used by the dominant review workflow while retaining the contact authority.

failure_modes: Independent child writes silently overwrite embedded values

failure_modes: Copied current attributes are mistaken for historical snapshots

Access-Specific Read Projection

short_definition: Maintain a query-shaped projection separate from the command or canonical model for a stable class of reads.

distinctive_feature: The representation is explicitly consumer- or query-specific and may have its own schema, refresh frontier, and availability behavior.

distinct_from_parent: The parent also covers copied fields and analytical forms; this subtype centers a separately deployed read model.

use_when: The write model is optimized for invariants and change while readers need a materially different shape.

use_when: Read fan-out crosses service or ownership boundaries.

use_when: The projection can be derived one way from committed changes.

domain: logistics

example: A shipment-status API serves a projection assembled from routing, inventory, and carrier events.

example: An agent screen reads one case view built from several authoritative services.

failure_modes: Projection falls behind without visible frontier

failure_modes: Read-model schema changes break consumers

Analytical Dimensional Denormalization

short_definition: Shape detailed operational facts and selectively redundant dimensions for repeatable analytical slicing, grouping, and aggregation.

distinctive_feature: It introduces fact, dimension, grain, and historical-version choices that are specific to analytical access.

distinct_from_parent: It remains the same parent because the key move is still controlled redundant representation against canonical operational sources.

source_primes: denormalization aggregation dimension data_structure

use_when: Analytical workloads repeatedly join stable dimensions to large fact sets.

use_when: Historical interpretation and slowly changing attributes must be explicit.

use_when: Predictable scan and aggregation behavior matters more than normalized update convenience.

domain: finance

example: A fact table stores transaction measures with versioned account and calendar dimensions for recurring reporting.

example: A reporting mart uses declared geographic and demographic dimensions while preserving source lineage and suppression rules.

failure_modes: Slowly changing dimensions rewrite history

failure_modes: Late-arriving data produces inconsistent totals

Precomputed-Summary Denormalization

short_definition: Persist derived totals, counters, windows, or summaries so common aggregate reads avoid scanning and recomputing detailed canonical data.

distinctive_feature: Its redundant object is a computed summary rather than a copied relational shape.

distinct_from_parent: Precomputation is the mechanism family, but the parent remains necessary to govern authority, derivation, staleness, lineage, correction, and lifecycle as a stored representation.

source_primes: denormalization aggregation caching optimization

use_when: The same aggregate is requested frequently.

use_when: The derivation can be incrementally maintained or rebuilt.

use_when: The acceptable lag and correction behavior can be stated.

example_domains: analytics usage_metering inventory monitoring

example: Daily account totals are maintained from immutable usage events with an explicit event frontier and rebilling path.

domain: operations

example: A dashboard serves minute-level rollups while labeling the last complete interval.

failure_modes: Window boundaries differ between producer and consumer

failure_modes: Summary is treated as authoritative detail

Historical Snapshot Embedding

short_definition: Copy selected reference values into a transaction or record so its historical meaning remains stable even after the current reference changes.

distinctive_feature: The duplication intentionally freezes a time-specific interpretation rather than trying to remain current.

distinct_from_parent: It uses the same controlled redundancy pattern but its freshness invariant is historical fidelity, not convergence to the latest authority.

source_primes: denormalization versioning traceability transaction

use_when: The record must be interpreted according to facts known or agreed at a past decision time.

use_when: Reconstructing historical reference state would be costly or unreliable.

use_when: The snapshot fields and correction policy can be distinguished from current values.

example: An invoice stores the legal name, address, tax treatment, description, and price used at issue time.

example: A treatment record retains the protocol version and dosage rule applied when the decision was made.

failure_modes: Current and snapshot fields are confused

failure_modes: Corrections to illegal or harmful data cannot propagate

failure_modes: Sensitive values are retained beyond necessity

Edge-Local Denormalized Representation

short_definition: Maintain a bounded local representation near users or devices so reads and limited decisions remain possible under latency or connectivity constraints.

distinctive_feature: Locality and intermittent connectivity are first-class constraints, so the projection has explicit offline and reconnection states.

distinct_from_parent: It remains a redundant representation with canonical authority and bounded divergence rather than an independently authoritative replica.

use_when: Network latency or disconnection makes the canonical path unreliable.

use_when: The local decision set can be restricted by freshness and authority.

use_when: Catch-up, conflict, and revocation behavior can be made explicit.

example: A technician device carries a task-and-parts projection with an expiry boundary and queues only permitted local updates.

example: An edge node serves recent equipment metadata but refuses safety-critical changes when its authority frontier is too old.

failure_modes: Local state is promoted to authority after reconnection without review

failure_modes: Users are not told that results are stale

Search-Document Denormalization

short_definition: Assemble searchable text, facets, ranking features, and display fields from canonical sources into query-oriented documents.

distinctive_feature: The redundant representation combines retrieval structure with copied display and ranking data, not only pointers to canonical records.

distinct_from_parent: It remains under the parent because the index document is a governed derived representation whose authority, lineage, synchronization, and staleness must be controlled.

source_primes: denormalization search_and_retrieval index representation

use_when: Search must filter or rank across fields owned by several canonical records.

use_when: Result rendering should not fan out to many services.

use_when: Index freshness and omission behavior can be monitored.

domain: ecommerce

example: A search document embeds product title, seller status, category facets, and availability summary from distinct authorities.

example: An index stores searchable text and declared metadata while retaining links to authoritative documents and versions.

failure_modes: Deleted or restricted content remains searchable

failure_modes: Ranking fields update at different frontiers

failure_modes: Search result display contradicts the authoritative detail page

near_names:
Denormalization
Controlled Denormalization
Governed Denormalization
Access-Path Denormalization
Flattened Read Model
Star-Schema Denormalization
Materialized Aggregation
Embedded Reference Snapshot