Tool-Repertoire Bias Counterbalancing

batch: Batch 14

aliases:
tool bias counterbalancing
instrument bias correction
problem-first tool selection
tool-agnostic problem framing
hammer-nail bias countermeasure
tool-induced frame correction

slug: bias

slug: representation

slug: agency

slug: framing

slug: schema

slug: category

slug: classification

slug: affordance

slug: viewpoint

slug: performativity

slug: metacognition

slug: sensemaking

slug: abstraction

slug: ontology

slug: decision

components:
Problem-First Restated Need
Tool Repertoire Map
Tool Affordance Boundary
Non-Grippable Residual Register
Alternative Instrument Set
Tool-Fit Gate
Referral or Borrowed-Tool Path
Repertoire Refresh Loop
Outcome Validity Check

mechanisms:
Problem-First Intake Template
Tool Repertoire Inventory
Affordance Blind-Spot Walkthrough
Alternative-Tool Red Team
Favored-Tool Pause Rule
Representation Fit Scorecard
Residual Case Log
Borrow-or-Refer Protocol
Tool-Mismatch Postmortem

essence_one_line: Counter tool-induced problem bias by describing the need before choosing the tool, mapping what the tool can and cannot grip, testing alternative instruments, and creating a path for residual cases.

compression_statement: Tool-Repertoire Bias Counterbalancing applies when an actor’s available methods, interfaces, professional habits, or institutional toolchain are not merely resources but filters: they make some problems visible, classify ambiguous cases into familiar categories, and generate interventions that the tool can perform while making non-grippable aspects disappear. The archetype inserts a problem-first framing layer, a tool-repertoire map, an affordance/blindspot analysis, an alternative-tool probe, a fit gate, and a residual escalation or repertoire-refresh loop.

core_intuition: A tool does not only solve problems; it also teaches the user what a problem looks like. The remedy is not tool rejection. It is to keep the problem larger than the local tool, then justify tool choice against the independently stated need.

canonical_formula: good_tool_use = problem_first_frame + repertoire_map + affordance_boundary + alternative_probe + fit_gate + residual_path + repertoire_update

structural_problem: An actor or organization is using an available tool, method, representation, interface, or specialty repertoire as an implicit ontology for the situation, causing misrecognition, overclassification into familiar categories, and interventions that fit the tool better than the underlying need.

trigger_conditions: A team proposes the familiar method before the problem has been independently described.

trigger_conditions: A professional specialty, software system, dashboard, or standard operating procedure controls intake and classification.

trigger_conditions: Awkward cases are redescribed until they fit an available category or workflow.

trigger_conditions: Stakeholders report needs that fall outside the official tool categories or action menu.

trigger_conditions: The organization owns a costly tool or capability and feels pressure to use it even when fit is uncertain.

trigger_conditions: The interface exposes some interventions as easy buttons while hiding alternatives, referrals, or nontechnical responses.

trigger_conditions: Repeated failures show that the output was well-formed for the tool but weakly connected to the original problem.

symptoms: Every problem becomes a training problem, a policy problem, a software problem, a data problem, a disciplinary problem, or a compliance problem depending on who receives it.

symptoms: Problem descriptions contain solution language too early.

symptoms: Intake forms, dashboards, ticket systems, or diagnostic categories exclude important aspects of the situation.

symptoms: People ask “which tool should we use?” before asking “what would count as solving this?”

symptoms: Residual cases accumulate as workarounds, shadow spreadsheets, exceptions, escalations, or unowned complaints.

symptoms: Tool success metrics improve while user, patient, customer, citizen, or system outcomes do not.

symptoms: Alternative disciplines or methods are treated as overkill because they are not part of the local repertoire.

symptoms: After failure, the explanation focuses on poor execution rather than possible tool/problem mismatch.

root_tension: Tools make action possible by simplifying the world into grips, categories, and operations. The same simplification can become an epistemic trap: what the tool cannot grip becomes cognitively or institutionally unreal.

anti_signatures: The issue is only that stakeholders need a different interpretive frame, with no tool or repertoire constraint; use Frame Shift Intervention.

anti_signatures: The task is already defined and the only question is which representation preserves task-relevant features; use Representation Fit Selection.

anti_signatures: The problem is a known cognitive bias in a decision review, not tool-induced classification or intervention narrowing; use Bias-Specific Decision Audit.

anti_signatures: The main need is mapping states, actions, goals, and constraints without a default tool imposing the map; use Problem Space Mapping.

anti_signatures: The tool is known to fit and the problem is poor training, maintenance, or execution rather than misframing.

anti_signatures: Urgent emergency conditions require immediate use of the only viable tool; defer the counterbalancing review to stabilization or postmortem.

anti_signatures: The case requires standardization for safety and deviations are more dangerous than tool mismatch; use a constrained exception process rather than broad tool diversification.

structural_intervention: Insert an explicit separation between problem recognition and tool selection: restate the need without tool language, map the available repertoire and its blind spots, test alternative instruments or representations, require a tool-fit decision gate, route non-grippable residuals, and update the repertoire when mismatch recurs.

action_logic: Freeze the first proposed tool or method long enough to restate the problem in problem-first language.

action_logic: Identify the actor’s available repertoire: tools, templates, data systems, skills, authority, professional categories, and default workflows.

action_logic: For each candidate tool, map what it can perceive, classify, modify, measure, and ignore.

action_logic: Name the residuals: problem features, stakeholders, contexts, constraints, or outcomes that do not fit the current tool affordances.

action_logic: Generate at least one alternative instrument, representation, discipline, referral path, or no-tool intervention.

action_logic: Apply a fit gate: choose a tool only when it preserves enough of the problem structure and has a plan for residuals.

action_logic: Where local tools do not fit, borrow capability, refer, escalate, change representation, or defer action until fit is improved.

action_logic: Compare outcomes against the original problem-first statement, not only against tool-native success metrics.

action_logic: Feed recurrent mismatch back into training, procurement, interface design, partnerships, or repertoire expansion.

decision_rules: If the problem statement already names a tool, ask for a tool-free restatement before approving action.

decision_rules: If a problem feature cannot be represented in the available tool, record it as a residual rather than dropping it.

decision_rules: If more than one plausible tool sees the case differently, compare the differences before choosing one.

decision_rules: If the favored tool solves its own proxy but not the original outcome, reject the fit claim.

decision_rules: If residuals recur across cases, treat them as evidence of repertoire deficiency rather than isolated exceptions.

decision_rules: If tool mismatch carries high harm, require external review or referral before proceeding.

target_invariants: The problem-first statement remains visible throughout selection and execution.

target_invariants: Tool choice is justified by fit to the problem, not by availability, sunk cost, familiarity, or professional identity.

target_invariants: Non-grippable residuals are preserved, routed, or escalated instead of erased.

target_invariants: At least one alternative representation or tool path is considered when stakes justify it.

target_invariants: Outcome evaluation returns to the original need, not merely to tool-native outputs.

target_invariants: Repertoire limits are treated as system design facts, not personal failures.

expected_outcomes: Fewer cases are misclassified into familiar but wrong solution categories.

expected_outcomes: Tool use becomes more deliberate and better matched to actual need.

expected_outcomes: Invisible or awkward problem features remain visible in decisions.

expected_outcomes: Referral, escalation, borrowing, or redesign paths improve when local tools are insufficient.

expected_outcomes: Organizations discover recurring capability gaps earlier.

expected_outcomes: Users and stakeholders experience fewer interventions that are elegant for the tool but irrelevant to their problem.

Hammer–Nail Bias Countermeasure

short_definition: A cognitive-debiasing variant that interrupts the tendency to define every problem as the kind of problem one familiar tool can solve.

distinctive_feature: Names the classic “if all you have is a hammer” cognitive form of the target prime.

distinct_from_parent: The parent also covers institutional, technical, platform, and repertoire-design forms; this variant centers individual or group cognitive debiasing.

still_same_parent_because: It uses the same problem-first restatement, repertoire map, alternative-tool probe, and fit gate.

use_when: An expert, team, or organization repeatedly reaches for the same favored method before the problem has been independently characterized.

use_when: Nonconforming cases are being redescribed until they fit the familiar tool rather than being treated as evidence of tool mismatch.

use_when: A lightweight countermeasure is needed inside decision review, intake, diagnosis, or planning.

Professional Repertoire Lock-In Review

short_definition: A professional-practice variant where a specialty’s available methods shape diagnosis, referral, and intervention choice.

distinctive_feature: Centers role, credential, revenue, and jurisdictional incentives that make tool bias persistent.

distinct_from_parent: The parent is cross-domain; this variant focuses on professional service systems and jurisdictional gatekeeping.

still_same_parent_because: The same bias arises from available repertoire shaping problem recognition and solution generation.

use_when: A professional group controls intake or diagnosis and is incentivized to see cases through its own service repertoire.

use_when: Cases that require a different specialty, community resource, or nontechnical response are under-referred.

use_when: Governance can require referral thresholds, cross-disciplinary review, or second opinions.

Software Tool Tunnel-Vision Release

short_definition: A product or workflow variant where the available software interface determines which problems users perceive and which interventions they attempt.

distinctive_feature: Centers interface affordances and workflow capture rather than only human cognition.

distinct_from_parent: The parent can be applied without software; this variant specifically audits digital-tool categories and action paths.

still_same_parent_because: It repairs the same tool-imposed restriction on recognition, classification, and action generation.

use_when: The interface exposes only certain categories, workflows, or reports, causing users to mistake software affordances for the whole operating reality.

use_when: Workarounds, shadow spreadsheets, tickets, or off-system notes reveal a residual problem space the tool cannot grip.

use_when: Changing configuration, workflow, integration, or tool choice is within scope.

Metric/Dashboard Vision-Lock Release

short_definition: A measurement-system variant where dashboards and metrics make some states actionable while making unmeasured states cognitively invisible.

distinctive_feature: The tool is a measurement and representation system, not a general method or professional repertoire.

distinct_from_parent: The parent includes all tool-induced problem-shaping; this variant specializes the visibility and observability channel.

still_same_parent_because: It still requires separating the problem from the available instrument and checking what the instrument cannot grip.

source_primes: measurement metric representation bias

use_when: Decision-makers over-identify the system with what the dashboard can display.

use_when: Unmeasured stakeholders, costs, risks, or quality dimensions are repeatedly absent from intervention design.

use_when: Measurement expansion, qualitative review, or complementary observation can be added.

near_names:
Tool Bias Correction
Instrument Bias Countermeasure
Hammer–Nail Debiasing
Tool-Agnostic Problem Framing
Problem-First Tool Selection


Top-Down / Bottom-Up Synthesis

type: archetype

source: generated

batch: First Iteration/Batch 32

alias: Top-Down / Bottom-Up Integration

notes: Common phrasing for the same central-local synthesis intervention.

alias: Central-Local Synthesis

notes: Plain-language formulation that makes the cross-level structure explicit.

alias: Strategic-Local Alignment

notes: Names the desired alignment outcome rather than the synthesis intervention.

alias: Frontline-Informed Strategy

notes: A narrower variant where local evidence comes primarily from frontline implementation.

alias: Participatory Strategy

notes: Can implement this archetype, but participation alone is not the archetype.

Top-Down Perspective

role: Supplies system-wide direction, strategy, standards, priorities, or constraints that local action must consider.

Bottom-Up Perspective

role: Supplies local evidence, weak signals, lived constraints, and implementation knowledge that central planning cannot infer reliably.

Sociotechnical Systems

role: Motivates integration across human, organizational, and technical realities when cross-level plans meet actual work.

Stakeholder Analysis

role: Helps identify whose local knowledge, incentives, and constraints matter for synthesis.

Feedback

slug: feedback

role: Turns implementation outcomes and local signals into updates for strategy and future action.

Goal Congruence

role: Defines the alignment target between central intent and distributed local behavior.

Local Autonomy / Tiered Escalation

role: Frames how much local discretion is allowed before conflict must escalate.

Downward Causation

role: Explains how higher-level constraints, standards, or goals shape lower-level behavior.

Collective Systemic Learning

role: Supports recurring learning across units rather than one-time consultation.

Formal vs Informal Structures

role: Reminds the draft to compare official plans with how work actually happens locally.

Accountability

slug: accountability

role: Requires visible ownership for how local evidence is used, ignored, adapted, or escalated.

components:
Central Intent
Local Signal
Local Signal Source
Synthesis Forum
Conflict Resolution Rule
Local Action Envelope
Feedback Loop
Adaptation Boundary
Evidence Trace
Representative Local Sample
Escalation Path
Implementation Learning Cadence

mechanisms:
Participatory Strategy Process
Executive-Guided Co-Design
Frontline Feedback System
Federated Governance Cadence
Local-National Policy Synthesis
Agile Portfolio Governance
Community-Informed Implementation
Pilot-and-Scale Feedback Review

essence_one_line: Combine centralized direction with local knowledge so strategy is coherent and implementation is grounded.

compression_statement: When top-down plans are blind and bottom-up signals are fragmented, synthesize both perspectives to create coherent but reality-grounded action.

core_intuition: Central views can see system-wide aims but miss local reality; local views can see practical truth but miss cross-system tradeoffs. The archetype works by making each side correct the other before action is locked in.

canonical_formula: central_intent + local_signal + synthesis_forum + conflict_resolution_rule -> local_action_envelope + upward_feedback_loop

structural_problem: Central direction lacks local validity, while local input lacks system-wide coordination, prioritization, or authority to change the larger plan.

condition: A strategy, policy, standard, or program is being designed centrally but must work across varied local contexts.

condition: Local teams, sites, communities, users, or frontline workers are producing signals that the central plan does not explain.

condition: Local units are adapting informally, creating drift, workarounds, inconsistent quality, or hidden noncompliance.

condition: Central leaders need coherence, comparability, risk control, or strategic prioritization, but purely local optimization would fragment the system.

condition: Implementation learning arrives too late, after the central commitment has become politically, financially, or technically hard to revise.

condition: Multiple levels describe the problem differently, and each description contains partial truth.

symptom: Plans look coherent in central documents but repeatedly fail during rollout.

symptom: Frontline actors maintain shadow practices because the official process does not fit actual work.

symptom: Local feedback is collected but not traceably connected to decision changes.

symptom: Local teams ask for exceptions, while central leaders interpret exceptions as resistance instead of evidence.

symptom: Each local unit solves problems differently, but the organization lacks a way to distinguish useful adaptation from harmful drift.

symptom: Central priorities and local constraints are discussed in separate forums, producing parallel narratives rather than synthesis.

root_tension: System-wide coherence requires top-down intent and constraints; practical validity requires bottom-up evidence and local adaptation. Either side alone is structurally incomplete.

case: The issue is only that local knowledge is missing, and no central direction needs reconciliation; use Bottom-Up Signal Integration or local research mechanisms instead.

case: The issue is only setting a central standard or constraint for distributed execution; use Top-Down Alignment Design or Downward Constraint Design instead.

case: The core intervention is delegating decision rights to local actors within a clear authority envelope; use Control Delegation or Local Autonomy / Tiered Escalation patterns instead.

case: The problem is identifying stakeholders and interests, not reconciling central direction with local evidence; use Stakeholder Analysis rather than this archetype.

case: The primary design object is co-changing social workflows and technical systems together; use Sociotechnical Integration when that joint design is the core intervention.

case: A one-way communication campaign would solve the problem because the central plan is already locally valid and only needs explanation.

structural_intervention: Gather local signals, define central intent, compare the two explicitly, reconcile conflicts through a named rule or forum, translate the result into bounded local action, and feed implementation results back upward.

step: Name the central intent

logic: Clarify the purpose, priority, standard, safety constraint, resource constraint, or strategic commitment that should guide all local action.

step: Map local signal sources

logic: Identify the people, sites, users, communities, cases, systems, or frontline roles that can reveal conditions invisible from the center.

step: Collect local evidence in comparable form

logic: Capture constraints, risks, workarounds, weak signals, outcomes, and context without flattening away the differences that matter.

step: Surface central-local conflicts

logic: Make visible where central assumptions fail locally, where local preferences conflict with shared aims, and where both views are incomplete.

step: Reconcile through a synthesis forum

logic: Use a forum or process with authority to decide what changes: the central plan, local implementation, standards, exceptions, sequencing, or evidence requirements.

step: Define local action envelopes

logic: Translate the synthesis into what local actors may adapt, what they must preserve, what requires escalation, and what outcomes will be monitored.

step: Feed implementation learning upward

logic: Review what happened locally, compare patterns across contexts, and revise central direction or local envelopes when evidence warrants.

rule: Use this archetype only when both central coherence and local validity materially affect success.

rule: Treat central constraints as non-negotiable only when they protect safety, legality, equity, interoperability, strategic intent, or system-wide risk.

rule: Treat local adaptation as legitimate when it responds to evidence and preserves the named central intent.

rule: Escalate unresolved conflict when local evidence implies changing shared standards, resources, or strategic commitments.

rule: Revise the central model when recurring local exceptions reveal a false assumption rather than isolated edge cases.

rule: Do not average incompatible views into a vague compromise; decide which differences require common standards, local variation, or further evidence.

invariant: Central intent remains explicit and traceable through local decisions.

invariant: Local evidence remains connected to source, context, and decision impact.

invariant: Local autonomy is bounded by named non-negotiables rather than informal permission or hidden exception.

invariant: Conflicts between levels remain visible until resolved, escalated, or deliberately monitored.

invariant: Implementation feedback changes future decisions rather than disappearing into reporting channels.

invariant: The synthesis preserves enough common structure to compare outcomes across local variations.

outcome: Strategies, policies, or programs become more implementable because local constraints shape them before rollout.

outcome: Local adaptation becomes legitimate, bounded, and learnable rather than hidden workarounds.

outcome: Central leaders gain earlier warning about plan-reality mismatch.

outcome: Distributed actors understand the shared intent behind constraints and the conditions under which they can adapt.

outcome: The system learns across local contexts rather than repeating the same implementation failure site by site.

outcome: Trust improves when local evidence can visibly affect central decisions.

prose_essence:
Top-Down / Bottom-Up Synthesis is the intervention pattern for situations where neither the central view nor the local view is sufficient. The central view usually carries the system-wide intent: strategy, policy, risk constraint, standard, budget, public obligation, or platform coherence. The local view carries the lived implementation reality: workarounds, weak signals, user needs, operational constraints, informal practices, and context-specific risk.

The archetype does not simply “listen to the front line” and it does not simply “align local units to strategy.” Its distinctive move is to put both perspectives into a structured reconciliation process, decide what must remain common, decide what may vary locally, and then use implementation feedback to update the next cycle of central and local action.

prose_when_to_use:
Use this archetype when a decision must be coherent across a system and grounded in local conditions. It is especially useful during strategy rollout, policy implementation, organizational change, platform governance, service redesign, and community-facing programs where central plans often fail because they do not match how work or life actually happens.

It is also useful when local actors have already begun creating informal adaptations. Those adaptations may be valuable evidence, but they can also create drift, inequity, or hidden risk. Synthesis turns that informal variation into a reviewable design question: what should be standardized, what should be adapted, what should be escalated, and what should be learned from repeated exceptions?

Do not use this archetype merely to justify consensus meetings. It is appropriate only when local evidence can change the plan or when central intent can legitimately bound local variation.

prose_structural_problem:
The structural problem is cross-level incompleteness. A top-down perspective sees scale, coherence, priorities, standards, and shared risk, but it abstracts away local detail. A bottom-up perspective sees lived constraints, tacit knowledge, specific failures, and practical opportunity, but it can be fragmented, parochial, and hard to prioritize across the whole system.

Failure appears when one level dominates. Pure top-down action produces brittle plans that look good on paper and fail in practice. Pure bottom-up action produces many local optimizations that may not add up to a coherent system. The problem is not that one side is “wrong.” The problem is that each side is structurally partial.

prose_intervention_logic:
The intervention begins by naming the central intent. A synthesis cannot work if the center provides only vague aspirations or shifting preferences. The center must say what goal, constraint, standard, risk, or commitment local actors are expected to preserve.

Next, local signals are gathered from sources that genuinely see implementation context. These may include frontline workers, users, local managers, community groups, delivery teams, sites, cases, or operational data. The local signals must be structured enough to compare, but not flattened so much that their contextual meaning is lost.

The synthesis forum then compares central assumptions against local evidence. Some conflicts reveal a local misunderstanding of the central goal. Some reveal a central misunderstanding of reality. Some reveal a true tradeoff. The conflict resolution rule decides whether to revise the central plan, permit local variation, escalate the issue, gather more evidence, or preserve the conflict as a monitored risk.

The output is a local action envelope: what local actors may adapt, what must remain common, what requires escalation, and what outcomes will be monitored. Implementation results then feed back upward so central direction can learn from recurring local patterns.

prose_key_components:
### Central Intent

States the system-wide purpose, priority, constraint, or direction that distributed local action must respect. The intent should be specific enough to orient action but not so detailed that it pre-decides every local implementation choice.
### Local Signal

Captures ground-level evidence, constraint, workaround, need, weak signal, or experience that the central view cannot reliably see alone. Local signals should be traceable to context and evidence; otherwise they become anecdotes or political claims rather than useful bottom-up input.
### Local Signal Source

Identifies the frontline actors, users, communities, local units, sites, cases, or sensors from which local evidence is drawn. The source map prevents the synthesis from treating a narrow or vocal sample as if it represented all local conditions.
### Synthesis Forum

Creates a structured place where central direction and local evidence can be compared, challenged, and reconciled. The forum may be a recurring meeting, governance body, design review, policy process, or planning cadence; it must have enough authority to change plans rather than merely collect comments.
### Conflict Resolution Rule

Defines how tensions between central intent and local evidence are resolved, escalated, adapted, or preserved as explicit tradeoffs. Without a rule, synthesis collapses into hierarchy, lobbying, averaging, or endless consultation.
### Local Action Envelope

Specifies what local actors may adapt, decide, sequence, or customize while still preserving shared intent and non-negotiable constraints. The envelope is the practical output of synthesis: central coherence plus local degrees of freedom.
### Feedback Loop

Returns implementation results, exceptions, unintended effects, and new local learning back into central planning and future local action. The loop prevents the synthesis from becoming a one-time consultation before a fixed plan; it makes the relationship adaptive.
### Adaptation Boundary

Separates local flexibility from the constraints, standards, safety rules, or commitments that may not be changed locally. Useful when local adaptation is desirable but unbounded variation would fragment the system.
### Evidence Trace

Records where local claims came from, what they mean, and how they influenced central decisions. Evidence traces protect against tokenistic listening and make later review possible.
### Representative Local Sample

Checks whether the local signals reflect relevant variation across sites, users, roles, geographies, risk levels, or contexts. Use when local input could be captured by a few accessible, powerful, or unusually vocal sources.
### Escalation Path

Moves unresolved central-local conflicts to a decision owner or higher synthesis forum without hiding the disagreement. Escalation prevents local workarounds and central overrides from becoming invisible governance.
### Implementation Learning Cadence

Sets the rhythm for reviewing what happened after local action and updating the central-local synthesis. Cadence may be fast during rollout, slower after stabilization, and event-triggered after failures or surprising signals.

prose_common_mechanisms:
### Participatory Strategy Process

This is a procedure that implements the archetype by structures strategy formation so leadership intent is tested against knowledge from people who must implement, use, or live with the strategy. This is a mechanism for synthesis only when participation can change priorities, constraints, or implementation envelopes. It should not be mistaken for the archetype itself: without explicit central intent, local signal, reconciliation, bounded action, and feedback, it is only an implementation method.
### Executive-Guided Co-Design

This is a workflow that implements the archetype by combines executive direction with collaborative design sessions that adapt the plan to practical and local constraints. The executive frame supplies direction; co-design supplies ground truth and feasible local pathways. It should not be mistaken for the archetype itself: without explicit central intent, local signal, reconciliation, bounded action, and feedback, it is only an implementation method.
### Frontline Feedback System

This is a software_or_tool that implements the archetype by collects structured observations, exceptions, workarounds, bottlenecks, and early warnings from people closest to implementation. The tool is not the archetype; it becomes useful only when signals are synthesized into decisions. It should not be mistaken for the archetype itself: without explicit central intent, local signal, reconciliation, bounded action, and feedback, it is only an implementation method.
### Federated Governance Cadence

This is a institution that implements the archetype by creates recurring cross-level decision forums where central owners and local representatives revise standards, exceptions, and shared priorities. Federation works when authority is distributed but still coordinated through shared rules and review cycles. It should not be mistaken for the archetype itself: without explicit central intent, local signal, reconciliation, bounded action, and feedback, it is only an implementation method.
### Local-National Policy Synthesis

This is a method that implements the archetype by reconciles broad policy goals with regional, municipal, community, or site-level implementation evidence. The same pattern can apply to national-local government, headquarters-branch organizations, or platform-ecosystem governance. It should not be mistaken for the archetype itself: without explicit central intent, local signal, reconciliation, bounded action, and feedback, it is only an implementation method.
### Agile Portfolio Governance

This is a procedure that implements the archetype by uses periodic portfolio review to align central priorities with delivery-team evidence, capacity, dependencies, and learning. It is a synthesis mechanism when teams can revise sequencing, scope, and assumptions based on implementation feedback. It should not be mistaken for the archetype itself: without explicit central intent, local signal, reconciliation, bounded action, and feedback, it is only an implementation method.
### Community-Informed Implementation

This is a workflow that implements the archetype by uses community knowledge to adapt central programs, services, or interventions to lived context while preserving program goals. This mechanism is especially important when legitimacy and practical fit depend on local trust. It should not be mistaken for the archetype itself: without explicit central intent, local signal, reconciliation, bounded action, and feedback, it is only an implementation method.
### Pilot-and-Scale Feedback Review

This is a procedure that implements the archetype by runs limited local implementations, examines what they reveal, and revises the central plan before wider rollout. Pilots instantiate the archetype only when central assumptions are actually revisable from pilot evidence. It should not be mistaken for the archetype itself: without explicit central intent, local signal, reconciliation, bounded action, and feedback, it is only an implementation method.

Mechanisms such as stakeholder surveys, frontline feedback forms, OKR trees, and strategy cascades are useful only as supporting machinery. A survey collects a signal; a cascade transmits intent; a forum creates a meeting. None of these is the archetype unless it participates in the full synthesis loop.

prose_failure_modes:
Tokenistic consultation occurs when local input is collected but cannot change the plan. The mitigation is an evidence trace that records what changed, what did not, and why.

Fragmentation disguised as adaptation occurs when every local unit customizes freely without preserving central intent. The mitigation is an adaptation boundary and local action envelope.

Central override occurs when leaders treat local evidence as resistance rather than information. The mitigation is a conflict resolution rule that requires recurring exceptions to be reviewed as potential central-model failures.

Local capture occurs when the loudest or easiest-to-reach local voices dominate. The mitigation is a signal source map and representativeness check.

Endless synthesis occurs when the forum has no authority, deadline, or escalation path. The mitigation is to assign decision owners and thresholds for when discussion becomes decision.

Sociotechnical blind spot occurs when the synthesis changes strategy but ignores tools, workflows, incentives, training, or culture. The mitigation is to escalate to Sociotechnical Integration when the social and technical system must be redesigned together.

prose_neighbor_distinctions:
**Bottom-Up Signal Integration** focuses on collecting and integrating local knowledge. Top-Down / Bottom-Up Synthesis uses local signal integration but adds explicit central intent, conflict reconciliation, and bounded action.

**Top-Down Alignment Design** focuses on translating central strategy, standards, or constraints downward. This archetype differs when bottom-up evidence can alter central plans, implementation envelopes, or standards.

**Downward Constraint Design** specifies higher-level constraints that shape lower-level behavior. This archetype includes constraints, but it also requires upward evidence and feedback.

**Participatory Control Design** changes who participates in governance or control. This archetype may use participatory mechanisms, but it does not require shared control authority; it requires cross-level synthesis.

**Stakeholder Analysis** identifies actors, interests, power, and needs. It supports signal-source mapping, but it does not by itself reconcile central direction with local evidence.

**Sociotechnical Integration** co-designs social and technical elements. Top-Down / Bottom-Up Synthesis should not absorb it. When the main failure is that tools, workflows, incentives, roles, and culture do not fit together, Sociotechnical Integration is the better archetype.

prose_cross_domain_examples:
In organizational strategy, a leadership team may define a retention goal while local teams show that customer churn differs by market. The synthesis preserves a common target but changes playbooks, resources, and sequencing.

In public health, a central agency may preserve a vaccination objective while community partners change outreach channels, clinic locations, and messaging based on trust and access barriers.

In software platform governance, a central platform team may set migration standards while product teams surface local dependency risks that alter rollout order and exception rules.

In education, a district may set a literacy goal while schools adapt schedules, tutoring models, and family engagement based on local learner and community conditions.

In infrastructure planning, a regional resilience plan may combine central risk thresholds with local maintenance knowledge and evacuation constraints.

prose_non_examples:
A strategy cascade that transmits goals downward is not this archetype unless local evidence can revise the plan or action envelope.

A stakeholder survey is not this archetype if it only collects opinions and no synthesis forum changes decisions.

Decentralization without shared central intent is not this archetype. It may be local autonomy, delegation, or fragmentation depending on design.

A one-time workshop is not this archetype if it produces no conflict rule, no local action envelope, and no feedback loop.

A sociotechnical rollout is not this archetype if the main intervention is redesigning workflows, tools, training, and incentives together rather than synthesizing central and local perspectives.

prose_tradeoffs:
The archetype trades speed for groundedness. It may slow initial decision-making, but it often prevents expensive rework after rollout.

It trades uniformity for contextual fit. Too much standardization produces brittle plans; too much local variation produces fragmentation. The local action envelope is the design object that manages this tension.

It trades political comfort for conflict visibility. Real synthesis exposes contradictions between central assumptions and local experience. That can be uncomfortable, but it is usually safer than letting contradictions appear later as failure.

It trades participation breadth against participation burden. The people with the best local knowledge are often busy doing the work. Signal collection must respect their time and protect them from retaliation for inconvenient evidence.

prose_invariants_to_preserve:
Preserve central intent. Local adaptation should not become a quiet abandonment of the shared goal.

Preserve local evidence integrity. A signal should remain connected to its source, context, and interpretation so that decision-makers know what it does and does not prove.

Preserve the visibility of conflict. When central and local views disagree, the disagreement should not be hidden inside vague compromise, local workaround, or executive override.

Preserve two-way accountability. The center must be accountable for how local evidence is used or rejected; local actors must be accountable for preserving shared constraints when adapting.

Preserve learnability across variation. If local adaptation becomes too idiosyncratic to compare, the system cannot learn which variation is useful.

prose_target_outcomes:
The target outcome is coherent action that fits reality. A successful synthesis produces plans that local actors can actually implement without abandoning system-wide purpose.

A second outcome is earlier mismatch detection. Local weak signals should surface before the system has committed too much money, political capital, code, infrastructure, or trust to a flawed plan.

A third outcome is legitimate adaptation. Local units should know when they are allowed to vary, when they must preserve common constraints, and when they need to escalate conflict.

A fourth outcome is shared learning. The system should be able to compare local implementations, identify recurring patterns, and update central direction accordingly.

prose_parameter_dimensions:
The first tuning dimension is **central constraint strength**. Some situations require strong common standards because safety, legality, interoperability, equity, or public obligation is at stake. Other situations allow broader local freedom because outcomes depend heavily on context.

The second dimension is **local signal breadth**. A narrow signal may be fast, but it risks capture by a few visible voices. A broad signal may be more legitimate and representative, but it can burden participants and slow decisions.

The third dimension is **adaptation granularity**. Local action can vary by region, site, team, user segment, workflow stage, risk level, or case type. Coarse envelopes are easier to manage; fine-grained envelopes fit reality better but are harder to compare and govern.

The fourth dimension is **synthesis cadence**. During rollout or crisis, the loop may need to be short. In stable operations, it may be periodic. When risks are high, the cadence should include event-triggered review after failures, exceptions, or surprising local signals.

The fifth dimension is **evidence weighting**. Central models, quantitative metrics, local testimony, community knowledge, operational data, and expert judgment may all matter. The archetype works best when the decision rule makes clear how these evidence types are compared.

prose_variants_and_near_names:
**Frontline-Informed Strategy** is a variant where the key local signals come from the people closest to implementation: workers, support teams, operators, users, or service providers. Its risk is tokenistic listening.

**Federated Direction Setting** is a variant where central and local units participate in recurring shared governance. Its risk is slow negotiation without a decision rule.

**Policy Implementation Synthesis** is a domain variant where central policies are adapted through local implementation evidence. Its risk is either hidden noncompliance or rigid central denial of local conditions.

**Central-Local Portfolio Synthesis** is a candidate variant for portfolio governance, where central priorities meet delivery-team capacity and dependency evidence.

Near names include top-down/bottom-up integration, central-local synthesis, strategic-local alignment, participatory strategy, and frontline-informed planning. Strategy cascades, stakeholder surveys, frontline feedback forms, and OKR trees are mechanisms or artifacts, not standalone archetypes.

Frontline-Informed Strategy

short_definition: A variant in which strategic direction is revised using evidence from frontline workers, service providers, local operators, or users.

distinctive_feature: The decisive bottom-up input comes from people closest to implementation and operational reality.

distinct_from_parent: The parent can synthesize any central and local levels; this variant focuses specifically on frontline-to-strategy learning.

still_same_parent_because: It still combines central intent, local signal, reconciliation, action translation, and upward feedback.

use_when: Senior strategy is plausible but misses constraints visible to people doing the work.

use_when: Implementation failures, workarounds, exceptions, or weak signals are appearing at the edge of the organization.

use_when: Frontline knowledge must influence priorities or design, not merely be acknowledged.

Central Intent

role: Keeps frontline-informed adaptation oriented to the shared strategic purpose.

notes: Prevents local reports from becoming disconnected complaints or unrelated optimization.

Local Signal Source

role: Identifies frontline workers, users, or local sites that produce the relevant evidence.

notes: Source diversity matters because one frontline group may not represent all local contexts.

Feedback Loop

role: Carries implementation learning back into strategic priorities and local practice.

notes: Without a loop, listening becomes episodic and tokenistic.

Frontline Feedback System

role: Collects structured frontline signals for synthesis.

Pilot-and-Scale Feedback Review

mechanism_type: procedure

role: Uses local pilots to update strategy before broad rollout.

example_domains:
healthcare operations
retail operations
public service delivery
software delivery

domain: healthcare operations

example: A hospital updates a throughput initiative after nurses identify where the central plan conflicts with medication timing and bed availability.

domain: software delivery

example: Product leadership revises a roadmap when support teams show that a proposed feature would amplify the most common user workaround.

failure_modes: Frontline input is collected but filtered until it confirms the original central plan.

failure_modes: A few visible frontline voices are mistaken for the full range of local conditions.

Federated Direction Setting

short_definition: A variant in which central and local units share direction-setting through a federated forum, standard, or cadence.

distinctive_feature: Authority is deliberately distributed across a federation rather than concentrated in a single center.

distinct_from_parent: The parent can occur under hierarchical authority; this variant makes the cross-level governance structure explicit and recurring.

still_same_parent_because: The intervention remains the same synthesis of central intent, local evidence, conflict rules, action envelopes, and feedback.

use_when: Local units need autonomy because their contexts differ materially.

use_when: The organization still needs shared standards, pooled learning, or coordinated priorities.

use_when: Neither centralized command nor fully independent local optimization is acceptable.

Synthesis Forum

role: Hosts recurring cross-level direction-setting.

notes: A federated forum must be able to update standards and exceptions.

Adaptation Boundary

role: Distinguishes shared requirements from local discretion.

notes: This boundary is the federation’s practical constitution.

Escalation Path

role: Handles disputes that cannot be solved at one level.

notes: Escalation keeps conflict visible rather than leaving each unit to improvise.

Federated Governance Cadence

mechanism_type: institution

role: Convenes central and local representatives to update shared direction.

Agile Portfolio Governance

role: Coordinates portfolio priorities with delivery evidence across units.

example_domains:
multisite organizations
platform governance
public administration
research consortia

domain: public administration

example: A national program sets standards while regional offices adjust delivery models and report outcomes back into policy review.

domain: platform governance

example: A central platform team sets interface constraints while product teams surface local needs that change extension priorities.

failure_modes: Federation becomes a slow negotiation ritual with no decision rule.

failure_modes: Local autonomy is claimed for convenience while shared commitments erode.

Policy Implementation Synthesis

short_definition: A policy-focused variant that adapts central rules to local implementation evidence while feeding local outcomes back into policy design.

distinctive_feature: The central-local tension appears as policy design versus policy-as-implemented.

distinct_from_parent: The parent is domain-general; this variant emphasizes rules, compliance, waivers, implementation evidence, and policy revision.

still_same_parent_because: Policy revision still uses central intent, local signals, reconciliation, bounded adaptation, and feedback.

use_when: A broad policy or standard must work across many jurisdictions, institutions, groups, or service contexts.

use_when: Local implementers face constraints, informal practices, or community conditions not captured in the central rule.

use_when: Repeated local exceptions suggest the central policy should change rather than merely issue waivers.

Central Intent

role: Clarifies the policy objective that local adaptation must preserve.

notes: Policy intent matters because literal rule compliance may miss the goal.

Local Action Envelope

role: Defines permissible local implementation choices.

notes: The envelope distinguishes legitimate adaptation from arbitrary noncompliance.

Evidence Trace

role: Shows how local implementation evidence changed policy or exception rules.

notes: This makes policy learning accountable.

Local-National Policy Synthesis

mechanism_type: method

role: Compares broad policy goals with local implementation evidence.

Community-Informed Implementation

mechanism_type: workflow

role: Uses community knowledge to adapt delivery without abandoning policy goals.

example_domains:
public health
education policy
environmental policy
municipal services

domain: public health

example: A vaccination campaign keeps national eligibility rules but changes outreach after community partners identify trust and access barriers.

domain: education policy

example: A district updates an attendance policy after schools show how local transport constraints affect implementation.

failure_modes: Local adaptation becomes informal noncompliance hidden from central review.

failure_modes: Central policy treats all local feedback as resistance instead of implementation evidence.

Central-Local Portfolio Synthesis

short_definition: A portfolio-planning variant that reconciles central priorities with delivery-team capacity, dependencies, risk, and learning.

distinctive_feature: The synthesis object is a portfolio of initiatives, resources, sequencing choices, and delivery commitments.

distinct_from_parent: The parent can apply to any central-local decision; this variant applies it to portfolio governance and delivery planning.

still_same_parent_because: It still reconciles central direction with bottom-up evidence and feeds implementation results upward.

use_when: A portfolio owner sets strategic priorities but local teams know delivery constraints and emergent risks.

use_when: Central sequencing decisions depend on team-level dependencies, bottlenecks, or user feedback.

use_when: Regular planning cadences can revise portfolio decisions from implementation evidence.

Central Intent

role: Defines portfolio priority and strategic direction.

notes: Portfolio decisions need strategic intent to avoid becoming a queue of local requests.

Local Signal

role: Supplies capacity, dependency, risk, and user-learning evidence.

notes: Delivery evidence should challenge unrealistic scope or sequencing.

Implementation Learning Cadence

role: Updates the portfolio on a recurring schedule.

notes: Cadence keeps synthesis active across release or planning cycles.

Agile Portfolio Governance

role: Reviews strategic portfolio choices alongside team-level delivery evidence.

Pilot-and-Scale Feedback Review

role: Uses early implementation outcomes to shape broader rollout.

example_domains:
software portfolios
capital planning
research portfolios
service redesign

domain: software portfolio

example: A product portfolio shifts sequence when engineering teams surface dependency risks invisible in the executive roadmap.

domain: service redesign

example: A central modernization portfolio adjusts rollout speed after local sites report staffing and training constraints.

failure_modes: Portfolio governance becomes a top-down priority broadcast with local data used only for estimates.

failure_modes: Local teams negotiate for resources without tying claims back to central intent.

near_names:
Top-Down / Bottom-Up Integration
Central-Local Synthesis
Strategic-Local Alignment
Frontline-Informed Planning
Participatory Strategy
Federated Governance


Topic-Brokered Event Distribution

batch: Batch 07

aliases:
Publish-Subscribe Coordination
Pub/Sub Event Distribution
Pub Sub Routing
Brokered Topic Routing
Topic Subscription Fan-Out
Anonymous Topic Distribution
Event Bus Subscription Routing
Topic-Based Message Distribution
Subscriber-Decoupled Event Delivery
Brokered Event Fanout

source_primes: publish_subscribe message_passing indirection channel coordination coupling queueing

slug: indirection

slug: channel

slug: coordination

slug: coupling

slug: queueing

slug: embedding

slug: observability

slug: backpressure

slug: boundary

slug: interface

components:
Event Domain Boundary
Topic Namespace
Publisher Authority Profile
Event Message Contract
Broker Routing Boundary
Subscription Registry
Filter and Selector Rule
Fan-Out Delivery Semantics
Subscriber Handler Contract
Backpressure and Isolation Profile
Replay and Retention Policy
Authorization and Visibility Policy
Delivery Trace Record
Subscription Lifecycle Rule
Broker Compromise Safeguard
Schema Compatibility Matrix
Consumer Group Partition Plan
Topic Governance Board
Subscriber Relevance Feedback Loop

mechanisms:
Topic Exchange or Event Bus
Message Broker
Publish API or Producer SDK
Subscription API
Topic Catalog
Schema Registry
Content-Based Subscription Filter
Durable Subscription Queue
Consumer Group
Fan-Out Exchange
Delivery Acknowledgement
Dead-Letter Queue
Replay Log or Event Stream
Transactional Outbox
Webhook Subscription
Access-Controlled Topic
Slow Consumer Isolation
Subscription Health Dashboard

essence_one_line: Route producer emissions through named topics and broker-managed subscriptions so consumers receive relevant events without producers needing to know who listens.

compression_statement: Topic-Brokered Event Distribution is the pattern of replacing direct sender-recipient coupling with a topic namespace, a broker or routing layer, and subscriber-owned consumption contracts. Producers publish event messages to topics; consumers declare subscriptions, filters, delivery preferences, and handler obligations; the broker validates, routes, fans out, buffers, replays, throttles, expires, and observes the resulting deliveries while preserving boundaries between producer state, broker responsibility, and subscriber state.

core_intuition: A producer should not have to maintain a list of every interested receiver, and a consumer should not have to negotiate separately with every possible producer. A topic and broker create a shared rendezvous surface: the producer says what happened, the subscriber says what kind of happenings it wants, and the broker enforces the distribution contract between them.

canonical_formula: publishers + topic_namespace + broker_subscription_registry + fanout_delivery_semantics + subscriber_handlers -> decoupled_event_distribution

structural_problem: Many producers and consumers need to exchange event-like information, notifications, updates, telemetry, claims, or state-change signals, but direct producer-to-consumer wiring creates brittle coupling, recipient enumeration, duplicate integrations, inconsistent filtering, hidden fan-out, and unclear delivery obligations. Without a governed publish-subscribe structure, subscribers miss relevant changes, producers over-know their audience, brokers become opaque trusted intermediaries, and overload, replay, authorization, ordering, and subscription lifecycle failures become invisible until downstream behavior diverges.

condition: One producer may have zero, one, or many legitimate consumers.

notes: Direct addressing becomes brittle when the consumer set changes independently.

condition: Consumers want categories of events rather than commands addressed specifically to them.

notes: The topic becomes the indirection surface between producer and subscriber.

condition: Producer and consumer lifecycles evolve independently.

notes: Subscribers can join, leave, pause, replay, or change filters without requiring producer rewrites.

condition: Fan-out, filtering, buffering, retry, replay, or ordering semantics matter to correctness.

notes: The broker is not just a transport; it is a semantic boundary.

condition: The same event stream must serve multiple audiences with different needs.

notes: Different subscriptions may require different filters, transforms, authorization scopes, freshness rules, or retention windows.

condition: Visibility into who received what and why is needed after the fact.

notes: Auditability matters when events trigger downstream action across boundaries.

symptoms: Producers keep bespoke recipient lists or hard-coded callbacks for many consumers.

symptoms: New subscribers require changes in producer code or producer governance.

symptoms: Consumers poll multiple sources for updates that should have been pushed as events.

symptoms: Duplicate notification, missing notification, or out-of-order fan-out creates downstream inconsistency.

symptoms: A broker, event bus, mailing list, or feed exists but its topics, subscription rules, and delivery guarantees are informal.

symptoms: Consumers treat every message on a broad channel as relevant because filtering is under-specified.

symptoms: Subscribers cannot reconstruct whether an event was not published, not routed, not delivered, filtered out, expired, or mishandled.

symptoms: Sensitive payloads or metadata leak because topics are too broad or subscriber authorization is too coarse.

symptoms: Unsubscribe, replay, and backfill behavior is inconsistent across consumers.

root_tension: Producer-consumer decoupling creates scalability and autonomy, but the indirection layer also creates ambiguity about topic meaning, delivery responsibility, visibility, authorization, and failure. Publish-subscribe works only when the brokered topic surface is governed as a semantic distribution contract rather than treated as a convenient pipe.

anti_signatures: If a sender knows the exact recipient and expects a reply or state transition from that recipient, use message_mediated_state_coordination rather than this more specific topic/fan-out archetype.

anti_signatures: If the main problem is centralizing many bilateral relationships through a known hub, use hub_and_spoke_coordination.

anti_signatures: If the main problem is crossing an access boundary with validation, use gateway_mediation or boundary_permeability_control.

anti_signatures: If the concern is queue service order after work has already been admitted, use queue_discipline_design or queue_draining.

anti_signatures: If the term subscription refers to payment, membership, or patronage rather than topic-based event delivery, this archetype probably does not apply.

anti_signatures: If all parties are intentionally sharing one mutable dataset or feed without event semantics, use data synchronization or shared-state governance patterns instead.

anti_signatures: If a broker is merely a social actor slot, use network_broker_role as a component inside a broader mediation archetype.

structural_intervention: Create a governed publish-subscribe channel by defining a topic namespace, publisher authority, event message contracts, broker responsibilities, subscription registry, filter and authorization rules, delivery and replay semantics, subscriber handler obligations, lifecycle controls, observability, and broker compromise safeguards.

logic: Define what kinds of happenings, updates, notifications, measurements, or claims are eligible to be published.

logic: Create topic names, hierarchy, routing keys, partition keys, versioning, and ownership rules that express stable meaning without exposing producer internals.

logic: Specify who may publish which event types, with what payload, metadata, timing, authority, provenance, and schema obligations.

logic: State which layer owns validation, routing, buffering, fan-out, filtering, persistence, replay, authorization enforcement, and delivery observation.

logic: Record subscribers, topic interests, filters, delivery endpoints, consumer groups, backfill windows, retention needs, and lifecycle state.

logic: Define whether subscribers receive events by topic match, content selector, attribute rule, role scope, priority, geography, time window, or policy condition.

logic: Choose durable or ephemeral delivery, ordering guarantees, at-most/at-least/effectively-once delivery, acknowledgement, retry, expiry, dead-letter, replay, and deduplication rules.

logic: Make each subscriber own validation, idempotency, state transition, side-effect, rejection, pause, and compensation behavior for delivered events.

logic: Bound fan-out load, isolate slow subscribers, rate-limit publishers, prioritize critical topics, and protect unrelated subscribers from noisy streams.

logic: Attach event IDs, topic versions, publisher identity, subscription IDs, filter decisions, delivery attempts, acknowledgements, handler outcomes, and replay records.

logic: Audit whether the broker, topics, metadata, timing, subscriber lists, or error behavior leak information or centralize unacceptable control.

decision_rules: Use a topic when consumers subscribe to a class of events; use direct messages when a sender intends a particular receiver.

decision_rules: A topic name is a contract: producers and subscribers must share its meaning, version, ownership, and deprecation rule.

decision_rules: A subscription must be explicit about scope, filter, delivery endpoint, lifecycle state, and handler responsibility.

decision_rules: Delivery semantics must be stated before subscribers rely on events for correctness.

decision_rules: Fan-out should not let one slow subscriber block unrelated subscribers unless that coupling is explicitly required.

decision_rules: Sensitive event payloads should be minimized or partitioned before publication to broad topics.

decision_rules: Subscriber authorization must be checked at subscription time and, where needed, at delivery time.

decision_rules: Replay and backfill should preserve event identity and ordering assumptions rather than creating a second unofficial truth stream.

decision_rules: Broker observability must distinguish publish failure, route failure, filter exclusion, delivery failure, acknowledgement failure, and handler failure.

decision_rules: Topics that accumulate many unrelated meanings should be split, versioned, or retired.

target_invariants: Producers do not need to enumerate or directly coordinate with all consumers.

target_invariants: Consumers can subscribe to a meaningful event class rather than poll or negotiate individually with producers.

target_invariants: Topic, event, subscription, and delivery semantics are explicit and versioned.

target_invariants: The broker or routing layer has declared responsibilities and accountability limits.

target_invariants: Filtering, authorization, replay, and unsubscribe behavior are governed rather than accidental.

target_invariants: Failures can be traced to publication, routing, filtering, delivery, acknowledgement, or handler stages.

target_invariants: Brokered fan-out does not become an uncontrolled side channel or single point of invisible capture.

expected_outcomes: Lower producer-consumer coupling and easier subscriber onboarding.

expected_outcomes: Cleaner fan-out of state changes, events, notifications, telemetry, and public updates.

expected_outcomes: More consistent filtering and routing across subscriber classes.

expected_outcomes: Better resilience under subscriber churn, slow consumers, retries, and replay needs.

expected_outcomes: Improved auditability of who was eligible to receive which event and what happened to it.

expected_outcomes: Reduced polling, duplicate integrations, and bespoke callback wiring.

expected_outcomes: Clearer boundary between generic message passing, brokered topic distribution, and social/intermediary brokerage.

Notification Pub/Sub

short_definition: Producers publish notifications to topics that subscribers receive for awareness or action.

distinctive_feature: The payload is primarily an awareness signal rather than an authoritative event stream.

distinct_from_parent: It is a lower-durability, notification-centered subtype of the broader topic-brokered distribution pattern.

still_same_parent_because: It still uses topics, subscriptions, broker fan-out, and subscriber lifecycle controls.

use_when: Events are lightweight alerts or notices.

use_when: Missed delivery is tolerable or separately recoverable.

use_when: Subscribers need independence from producer recipient lists.

domain: operations

example: Systems subscribe to deployment_finished or incident_opened notifications.

failure_modes: Important subscribers assume durable delivery when the channel is only best-effort.

Durable Event Stream Subscription

short_definition: Published events are retained so subscribers can replay, backfill, or resume from an offset.

distinctive_feature: Retention and replay make the event channel a durable record rather than only a live notification surface.

distinct_from_parent: It strengthens persistence, ordering, replay, and compatibility requirements.

still_same_parent_because: It still distributes producer events through topic subscriptions.

use_when: Events are part of system state reconstruction.

use_when: New subscribers need historical backfill.

example: Analytics consumers replay a customer_event topic from last week after deploying a new model.

failure_modes: Replay creates duplicate side effects if handlers are not idempotent.

Content-Based Pub/Sub Routing

short_definition: Subscribers receive events based on attributes or predicates inside the event, not just the topic name.

distinctive_feature: The selector rule becomes a first-class distribution contract.

distinct_from_parent: It emphasizes predicate routing over simple topic membership.

still_same_parent_because: It remains brokered topic/event distribution to independent subscribers.

use_when: Event attributes can be trusted and indexed.

example: Maintenance subscribers receive only vibration events above a threshold for assigned regions.

failure_modes: Selectors become hidden business rules that subscribers cannot audit.

Webhook Pub/Sub

short_definition: Subscribers register endpoints that receive topic events as outbound callbacks.

distinctive_feature: The subscription endpoint is a network callback controlled by the subscriber.

distinct_from_parent: It is a concrete external-integration delivery form with endpoint security and retry concerns.

still_same_parent_because: It still rests on brokered topic subscription and event fan-out.

use_when: External consumers need event delivery without polling.

use_when: Subscriber endpoints can be authenticated and monitored.

use_when: Retry and signature verification are required.

domain: payments

example: Merchants subscribe to payment_succeeded and dispute_opened webhooks.

failure_modes: Endpoint downtime causes retry storms or dropped events.

near_names:
Pub/Sub
PubSub
Publish Subscribe
Brokered Topic Router
Event Bus


Topology-Preserving Transformation

alias: Relationship-Preserving Transformation

notes: Plain-language name emphasizing that the preserved structure is relational rather than visual.

alias: Topological Preservation

notes: Useful shorthand, but less intervention-oriented than the canonical title.

alias: Topology-Safe Redesign

notes: Common design-facing phrasing for transformations that must not break critical links.

alias: Adjacency-Preserving Redesign

notes: Covers cases where adjacency is the critical invariant but not all topology-preserving cases.

source_primes: topology invariance network

related_primes: relation representation graph_network continuity robustness interoperability modularity

Topology

slug: topology

role: Primary source prime: directs attention to connectivity, adjacency, continuity, and relation structure rather than surface form.

Invariance

slug: invariance

role: Defines the preservation requirement: selected relationships must remain unchanged or functionally equivalent through transformation.

Network

slug: network

role: Supplies the recurring cross-domain form in which the preserved topology appears as nodes, links, paths, dependencies, or reachability.

Relation

slug: relation

role: The archetype protects relations among entities, not merely entity attributes.

Representation

slug: representation

role: Many transformations change how a system is represented while preserving the relationships that representation must carry.

Graph / Network

role: A common formal or practical way to express connectivity, reachability, adjacency, and dependency invariants.

Continuity

slug: continuity

role: Relevant when paths, handoffs, sequences, or service relationships must remain unbroken through change.

Robustness

slug: robustness

role: Relation preservation is often a robustness requirement during redesign, migration, or simplification.

Interoperability

slug: interoperability

role: Interface-preserving cases require transformed parts to keep working with dependent actors or systems.

Modularity

slug: modularity

role: Refactors and reorganizations often change internal modules while preserving boundary relations.

components:
Relation Scope Boundary
Current Topology Map
Connectivity Invariant
Transformation Rule
Preservation Check
Repair Path
Adjacency Map
Lineage Mapping
External Relation Contract
Allowed Deviation Record
Stabilization Monitor

mechanisms:
Graph Difference Review
Reachability Test
Relational Data Migration Check
Interface Contract Test
Handoff Continuity Walkthrough
Organizational Path Preservation Review
Compatibility Bridge or Shim
Topology Regression Suite

essence_one_line: Change a system's shape, scale, organization, or representation while preserving the connectivity relationships that matter.

compression_statement: When a redesign, migration, simplification, or refactor must change surface form without breaking critical relationships, define the relation invariants, transform around them, verify preservation, and repair broken links.

core_intuition: A system can look very different while still doing the same relational work, or it can look superficially similar while its working relationships have been destroyed. Topology-preserving transformation separates surface shape from functional connectivity so change can proceed without severing the paths, adjacencies, dependencies, or interfaces that carry value.

canonical_formula: relation_invariant + allowed_form_change -> transformed_system + preserved_connectivity + repair_for_broken_links

structural_problem: A transformation is underway or needed, but planners are focusing on visible form, ownership, categories, components, or efficiency while risking the loss of the connectivity relationships that make the system function.

condition: A system must be migrated, reorganized, refactored, simplified, scaled, compressed, or represented differently.

condition: The things being moved or changed are meaningful because of their relations: dependencies, adjacency, lineage, permissions, communication paths, service routes, or handoff sequences.

condition: A proposed change optimizes local boxes, labels, or components but does not state which relationships must survive.

condition: Stakeholders worry that a redesign will orphan users, records, teams, services, interfaces, or responsibilities.

condition: The old form is costly or obsolete, but some of its relation structure remains valuable and must be carried forward.

symptom: A migration succeeds in copying objects but loses references, ownership, dependencies, or history.

symptom: A reorganization creates cleaner boxes but breaks informal communication paths or escalation routes.

symptom: A simplified workflow removes steps that looked redundant but were preserving continuity, authorization, or context.

symptom: A refactor passes isolated tests but breaks downstream consumers because relation contracts changed.

symptom: Maps, diagrams, or org charts look plausible, but nobody has checked reachability, adjacency, or dependency preservation.

root_tension: Change requires altering form, but function depends on relationships that may be invisible, informal, or distributed across the old form. The intervention must distinguish what can change from what must remain connected.

case: The goal is to deliberately change network topology to alter flow, influence, resilience, or cost; use a network topology redesign or relation reconfiguration archetype instead.

case: The main issue is checking whether conclusions survive equivalent representations; hold for Representation Invariance Check rather than using this archetype.

case: The task is only to draw a network map or topology diagram without executing or governing a transformation.

case: The invariant to preserve is a generic rule, policy, or value rather than a relation structure; consider Invariant Guarding or invariant-preservation neighbors.

case: The transformation should intentionally sever harmful connections, isolate blast radius, or create segmentation; preservation may be the wrong goal.

structural_intervention: Identify the relationship invariants that must survive, map the current topology at the necessary level of detail, define allowed transformations around those invariants, execute the change, verify that connectivity has been preserved, and repair or deliberately document any broken links.

action: Name the transformation

rationale: Clarify whether the change is a migration, reorganization, refactor, simplification, scaling move, representation change, or redesign.

action: Define the relation scope

rationale: Select which relationships matter: adjacency, reachability, dependency, lineage, ownership, permissions, handoffs, interfaces, or continuity.

action: Map the current topology

rationale: Make the relevant relation structure explicit enough to guide the change and expose hidden or informal links.

action: State the connectivity invariant

rationale: Specify what must remain equivalent after the transformation and which losses require review.

action: Constrain the transformation rule

rationale: Allow surface form to change while blocking changes that break required relations without authorization.

action: Run preservation checks

rationale: Compare before and after topology, including edge cases, degraded modes, informal paths, and user-visible dependency paths.

action: Repair or explicitly approve deviations

rationale: Close broken links, add compatibility bridges, restore lineage, or document intentional topology changes with owners and risk controls.

action: Monitor relation health after stabilization

rationale: Some topology loss appears only after usage, volume, exception cases, or social adaptation reveal broken paths.

rule: Use this archetype when preserving relation structure is a success condition of a broader transformation.

rule: Preserve relationships at the level where function or risk lives; do not require exact surface equivalence when functional equivalence is enough.

rule: Map only the relations that matter for the decision, but make the preservation rule explicit enough to test.

rule: Treat informal and social links as topology when they carry work, authority, knowledge, trust, or escalation.

rule: Do not preserve harmful, obsolete, or unsafe links just because they existed in the old topology.

rule: When a relationship is intentionally changed, record it as a topology change rather than letting it masquerade as preserved transformation.

invariant: Required reachability

description: Actors, records, services, or nodes that must be able to reach one another remain connected by valid paths.

invariant: Critical adjacency

description: Entities that must remain next to each other in sequence, responsibility, context, or interface remain adjacent or receive a valid substitute relation.

invariant: Dependency continuity

description: Prerequisites, upstream/downstream dependencies, lineage, and handoffs remain intelligible and actionable after the transformation.

invariant: Interface contract continuity

description: External consumers experience the same required relationship to the transformed part unless a versioned change is explicit.

invariant: Repairable deviations

description: Any broken relation has an owner, repair path, rollback path, or explicit acceptance rationale.

outcome: Safer transformation

description: The system can change form without losing the relationships needed for operation, governance, learning, or service.

outcome: Reduced migration and reorganization breakage

description: Fewer orphaned records, isolated teams, broken handoffs, lost dependencies, and hidden compatibility failures.

outcome: Clearer design tradeoffs

description: Teams can distinguish allowed shape changes from forbidden relation losses.

outcome: Auditable continuity

description: Before/after relation checks provide evidence that required topology was preserved or intentionally changed.

outcome: Focused repair

description: When topology breaks, repair targets are specific links, paths, or contracts rather than vague system quality.

prose_essence:
Topology-Preserving Transformation is for changes that must alter a system's form without breaking the relationships that make it work. The old shape may be too expensive, too confusing, too slow, or no longer fit for purpose, but some of its connectivity is still essential. The archetype asks: what can change, and what relational structure must remain equivalent?

This is not merely drawing a network diagram. A diagram becomes useful only when it defines preservation constraints for a real transformation and supports before/after checks. The heart of the archetype is the controlled separation of surface form from functional topology.

prose_when_to_use:
Use it when a migration, reorganization, refactor, simplification, redesign, or representation change might break important relationships. Typical warning signs include orphaned records, broken handoffs, isolated teams, lost dependency context, incompatible interfaces, or a plan that reorganizes components without stating which paths must remain connected.

The archetype is strongest when the relevant relationships can be named: adjacency, reachability, dependency, lineage, ownership, permission, handoff, interface, sequence, or continuity. It is weaker when the old topology is itself harmful and should be deliberately severed.

prose_structural_problem:
The structural problem is relation loss under form change. A system can be transformed in a way that looks cleaner, faster, or more modern while silently destroying the paths that carried work, meaning, accountability, service, or risk control.

A migration can copy objects but lose references. A reorganization can produce a simpler chart while breaking collaboration paths. A refactor can preserve function locally while breaking downstream consumers. A workflow simplification can remove a step that looked redundant but actually preserved context or authority.

prose_intervention_logic:
The intervention starts by naming the transformation and scoping the relations that matter. It then maps the current topology at the necessary level of detail, defines a connectivity invariant, constrains the transformation around that invariant, verifies the after-state, and repairs or records deviations.

The practical sequence is: define relation scope, map current topology, state preservation requirements, transform under constraints, run preservation checks, repair broken links, and monitor relation health after real use. The transformation is successful only when the preserved relationships are still usable, not merely when the new form looks organized.

prose_key_components:
### Relation Scope Boundary

The relation scope boundary decides which relationships count. Without it, teams either try to preserve everything or accidentally preserve only what is visible in formal diagrams. The boundary may include handoffs, permissions, dependency chains, ownership links, communication paths, service routes, or interface contracts.

### Current Topology Map

The current topology map represents the existing structure of relationships. It can be a graph, table, workflow, dependency map, org-path review, lineage map, or service blueprint. Its purpose is not aesthetic clarity; its purpose is to make preservation testable.

### Connectivity Invariant

The connectivity invariant says what must remain connected or functionally equivalent after transformation. It may require exact preservation, minimum reachability, preserved adjacency, lineage continuity, or equivalent interface behavior. This is the main guardrail against silent breakage.

### Transformation Rule

The transformation rule defines what kinds of changes are allowed while preserving the invariant. It lets surface form change while preventing uncontrolled relation loss. In practice, it answers: which links can move, which can be substituted, which must remain unchanged, and which changes require explicit approval?

### Preservation Check

The preservation check compares the before and after states. It should test more than the happy path: edge cases, exception routes, dependent users, degraded operations, and informal paths may reveal relation loss that a formal review misses.

### Repair Path

The repair path gives broken relationships an owner and a route to correction. It may include rollback, compatibility bridges, data reconciliation, escalation paths, manual repair queues, or accepted-deviation records. Without a repair path, discovery of breakage does not translate into recovery.

prose_common_mechanisms:
### Graph Difference Review

A graph difference review compares before and after topology. It is useful when relationships can be represented explicitly as nodes and edges. It implements the archetype by locating lost, added, weakened, or rerouted connections.

### Reachability Test

A reachability test checks whether priority actors, services, records, or nodes can still reach each other through valid paths. It is especially useful in networks, platform dependencies, access paths, and service-routing contexts.

### Relational Data Migration Check

A relational data migration check validates links such as ownership, references, permissions, lineage, hierarchy, and dependency records. It implements the archetype in migrations where copying values is not enough.

### Interface Contract Test

An interface contract test verifies that dependent users or systems can still interact with a transformed subsystem as expected. It is a mechanism for interface-preserving refactors, not the archetype itself.

### Handoff Continuity Walkthrough

A handoff continuity walkthrough follows a case, user, task, or decision through the redesigned workflow. It checks whether context, timing, authority, and responsibility remain connected across steps.

### Organizational Path Preservation Review

An organizational path preservation review examines whether communication, escalation, expert consultation, and decision paths survive a reorganization. It treats social and operational pathways as real topology.

### Compatibility Bridge or Shim

A compatibility bridge temporarily preserves an old relationship while a new structure is introduced behind it. It is useful when a clean cutover would break users, services, or dependent systems.

### Topology Regression Suite

A topology regression suite repeatedly checks key paths and dependencies across transformation iterations. It is most useful when transformation is incremental and relation breakage can recur.

prose_failure_modes:
Surface preservation occurs when names, boxes, or diagrams remain but real relationships change. Over-preservation occurs when teams keep every legacy link, including harmful or obsolete ones. Hidden informal topology loss occurs when formal diagrams are preserved but social, operational, or trust-based paths break.

False equivalence is another common failure. A substitute path may appear equivalent on paper but lack authority, timing, capacity, context, or user trust. Finally, a transformation can fail because broken links are discovered without a repair path.

prose_neighbor_distinctions:
Topology-Preserving Transformation is narrower than generic invariant preservation because the invariant is relation structure. It differs from Structural Mapping Transfer because it does not transfer a pattern to another context; it preserves selected relationships while changing a system. It differs from Representation Invariance Check because it is about relationship survival through transformation, not conclusion stability across equivalent representations.

It also differs from Network Topology Redesign. In network redesign, the topology itself is intentionally changed to alter flow, influence, resilience, or cost. Here, topology is the thing being protected while other features change.

prose_cross_domain_examples:
In software, a service can be rewritten internally while API contracts and downstream dependencies remain stable. In organizational design, teams can be reorganized while escalation and expert-consultation paths remain reachable. In data migration, records can move while ownership, history, permissions, and references remain intact.

In healthcare workflow design, intake can be simplified while preserving continuity from triage to treatment to follow-up. In curriculum design, modules can be reorganized while prerequisite paths and conceptual adjacency remain clear.

prose_non_examples: A network diagram made for communication but not used to constrain change is not this archetype. A redesign that intentionally severs dependencies to reduce blast radius is not topology-preserving transformation, though it may be good design. A chart-style change that checks whether a conclusion looks the same is closer to representation invariance checking. A reorganization with no path, handoff, or dependency review is simply a reorganization.

prose_tradeoffs:
The main tradeoff is continuity versus simplification. Preserving too little causes breakage; preserving too much keeps obsolete complexity alive. Another tradeoff is exact preservation versus functional equivalence. Exact preservation may be safer but rigid, while functional equivalence permits better design but requires judgment.

A third tradeoff is mapping depth versus speed. Detailed topology maps catch hidden dependencies but slow transformation. Lightweight maps are faster but may miss critical informal or edge-case relationships.

prose_invariants_to_preserve:
The central invariant is required connectivity: the actors, records, services, steps, or concepts that must remain connected can still reach one another after the change. Depending on the domain, that may include critical adjacency, dependency continuity, lineage continuity, interface contract continuity, service route continuity, or ownership continuity.

Preservation does not always mean identical form. A relationship may be preserved through a new route, new interface, new owner, or new representation if it remains functionally equivalent for the relevant purpose.

prose_target_outcomes:
A good topology-preserving transformation makes change safer. It reduces orphaned records, isolated teams, broken handoffs, lost dependencies, and hidden compatibility failures. It also improves governance because the team can say exactly which relationships were preserved, which were changed, and which require repair.

The desired outcome is not immobility. The system should be able to change form while keeping the relational substrate needed for function, accountability, service continuity, learning, or resilience.

prose_parameter_dimensions:
The first tuning dimension is preservation strictness: exact copying, functional equivalence, minimum viable reachability, or monitored deviation. Exact copying is easier to verify but may preserve unnecessary complexity; functional equivalence is more flexible but requires clearer criteria.

The second dimension is topology granularity. A map may operate at actor, team, record, module, interface, workflow step, service route, concept, or dependency level. The right granularity is the one at which breakage would matter.

The third dimension is relation scope. Teams must choose whether to include formal links only or also informal knowledge, trust, escalation, and workarounds. Informal topology often carries real function.

The fourth dimension is timing: preservation can be checked pre-change, during phased migration, at cutover, and after stabilization. Some broken relationships only appear under live usage.

The fifth dimension is deviation policy. A topology change may be allowed, but it must be intentional, owned, justified, and monitored rather than accidental.

prose_variants_and_near_names:
Network-Preserving Redesign applies when the preserved structure is reachability, path continuity, or graph-like connectivity. Relationship-Preserving Migration applies when data, cases, responsibilities, or processes move to a new system while preserving links. Interface-Preserving Refactor applies when internal structure changes while external relation contracts remain stable.

Near names include topological preservation, relationship-preserving transformation, adjacency-preserving redesign, continuity-preserving redesign, and topology-safe migration. Topology maps, adjacency matrices, and topological sorts should be treated as components or mechanisms, not standalone archetypes.

Network-Preserving Redesign

short_definition: A redesign that changes visible structure while preserving the critical links, routes, and reachability that make the network work.

distinctive_feature: The preserved invariant is explicitly network structure: connectivity, reachability, adjacency, or path continuity.

distinct_from_parent: The parent applies to any relation-preserving transformation; this variant is specifically about networked systems and graph-like relations.

still_same_parent_because: The intervention still identifies relationship invariants, transforms surface form, verifies preservation, and repairs broken links.

source_primes: network topology invariance

use_when: A communication, service, supply, knowledge, or coordination network must be reorganized without isolating key nodes.

use_when: The surface layout can change, but important paths, redundancies, or adjacency relationships must remain usable.

use_when: Failure would appear as broken handoffs, orphaned actors, disconnected resources, or lost reachability rather than as a simple performance dip.

Connectivity Invariant

role: Specifies which links, paths, or reachability relations must survive the change.

notes: The invariant may be exact, minimum viable, or prioritized by risk.

Adjacency Map

role: Shows which actors, nodes, records, services, or steps must remain adjacent or reachable.

notes: The map is an input to transformation, not the archetype itself.

Preservation Check

role: Verifies after the change that required connectivity still exists.

notes: Checks should include edge cases and degraded modes.

Graph Difference Review

role: Compares before and after relation maps to identify lost or added edges.

Reachability Test

role: Confirms that priority nodes, actors, services, or records can still reach each other through valid paths.

Bridge Path Preservation

role: Protects critical bridging paths that connect otherwise separated clusters.

example_domains:
organizational restructuring
supply networks
service operations
knowledge management
infrastructure planning

domain: organizational restructuring

example: A reorganization changes reporting lines but preserves cross-team escalation and technical consultation paths.

domain: supply networks

example: A distribution redesign consolidates facilities while preserving alternative routes for critical deliveries.

failure_modes: Formal links remain on paper but practical reachability is lost because people, incentives, or access paths changed.

failure_modes: The redesign preserves low-value connections while ignoring the relations that carry real work or risk.

Relationship-Preserving Migration

short_definition: A migration that moves data, processes, accounts, or responsibilities while preserving the relationships that give them meaning.

distinctive_feature: The transformation is a migration across containers or representations, with relation preservation as the core risk.

distinct_from_parent: The parent can apply to many forms of transformation; this variant focuses on moves between systems, repositories, or organizational homes.

still_same_parent_because: The decisive intervention is still to define relation invariants, move the system, check preservation, and repair relation loss.

source_primes: relation representation invariance

use_when: Records, workflows, customers, cases, assets, or responsibilities are being moved into a new system or structure.

use_when: The values being migrated are less important than the links among them: ownership, dependency, lineage, sequence, membership, or entitlement.

use_when: The migration can appear successful superficially while losing context through broken relations.

Relation Scope Boundary

role: Defines which relationship types must be preserved and which are outside scope.

notes: Without scope, migration checks either miss key relations or become impossible to complete.

Lineage Mapping

role: Tracks where each object, case, or responsibility came from and where it lands.

notes: Lineage prevents silent orphaning during migration.

Repair Path

role: Provides a controlled way to restore missing or incorrect relationships after migration.

notes: Repair must be planned before cutover.

Relational Integrity Test

role: Checks whether expected links remain valid after migration.

Crosswalk Table

mechanism_type: artifact

role: Maps old identifiers, relations, and categories to their new locations or representations.

Orphan Record Review

role: Finds records, cases, or tasks that lost required connections.

example_domains:
data migration
case management
enterprise system rollout
archives
service transition

domain: data migration

example: Customer records move to a new CRM while account hierarchies, ownership, permissions, and service history links remain intact.

domain: public services

example: A case-transfer process keeps benefit eligibility, appeal status, and assigned support relationships linked to the person.

failure_modes: Objects arrive in the new system but their dependencies, history, or authority links are missing.

failure_modes: Legacy relationships are copied blindly even when some are obsolete or unsafe to preserve.

Interface-Preserving Refactor

short_definition: A refactor that changes internal structure while preserving externally relied-upon interfaces and dependency relations.

distinctive_feature: The invariant is the boundary relationship between the transformed subsystem and its consumers.

distinct_from_parent: The parent includes non-technical transformations; this variant is common in software, process, and modular-system refactoring.

still_same_parent_because: The refactor works by explicitly preserving relation invariants while transforming nonessential internal form.

source_primes: modularity invariance interoperability

use_when: A system needs internal cleanup, simplification, or modernization without breaking users or dependent systems.

use_when: The internal shape may change, but public contracts, dependency paths, or handoff relationships must remain stable.

use_when: Breakage would cascade through consumers who depend on the old relation structure.

External Relation Contract

role: Names the inputs, outputs, dependencies, responsibilities, and expectations that must remain stable.

notes: This may be an API, service promise, handoff standard, or governance expectation.

Transformation Rule

role: Constrains which internal changes are allowed while preserving external relations.

notes: A refactor without a rule can optimize the inside while breaking the outside.

Topology Regression Check

role: Tests that the transformed subsystem still connects correctly to dependent actors or systems.

notes: Regression checks are relationship checks, not just performance checks.

Contract Test

role: Verifies that an interface or handoff still satisfies the same relation contract.

Strangler-Fig Migration

role: Gradually replaces internal structure while keeping the external surface usable.

Compatibility Shim

mechanism_type: interface

role: Maintains old relation expectations while new internals are introduced.

example_domains:
software refactoring
service redesign
platform migration
process improvement

domain: software

example: A service is rewritten internally while API contracts and downstream dependency expectations remain stable.

example: A team changes its internal workflow while preserving the timing and format of handoffs to partner teams.

failure_modes: The team preserves names but changes semantics, so dependent users experience silent breakage.

failure_modes: Preserving every old interface blocks necessary simplification and carries obsolete dependencies forward.

near_names:
Topological Preservation
Relationship-Preserving Transformation
Adjacency-Preserving Redesign
Continuity-Preserving Redesign
Topology-Safe Migration