Scoped Experimentation

batch: First Iteration/Batch 04/Wave 2

aliases:
Limited Trial
Bounded Experiment
Pilot Trial
Field Trial
Controlled Rollout
Small-Scale Experiment
Limited User Experiment

related_primes: feedback measurement constraint representation

Boundary

slug: boundary

role: Scoped Experimentation depends on drawing a temporary boundary around where a risky learning action may operate.

Virtualization

slug: virtualization

role: Some scoped experiments use simulated, staged, or virtual environments, although the archetype also applies to live bounded trials.

Controlled Reentry

role: The experiment must define how evidence leads to safe expansion, rollback, continuation, or transition into wider use.

Feedback

slug: feedback

role: Monitoring and evaluation turn bounded exposure into learning rather than mere containment.

Measurement

slug: measurement

role: Success, safety, and guardrail metrics determine whether the experiment should stop, continue, expand, or be redesigned.

Constraint

role: Exposure limits, eligibility rules, duration caps, resource caps, and stop conditions constrain the experiment’s blast radius.

Representation

slug: representation

role: Scope statements, protocols, metrics, dashboards, and evidence records represent the experiment well enough to govern and review it.

components:
Experiment Learning Question
Experiment Scope Boundary
Exposure Limit
Participant or Unit Selection Rule
Success and Safety Metrics
Monitoring Plan
Rollback or Stop Condition
Escalation or Reentry Decision Rule
Evidence Capture Record
Boundary Communication Protocol
Comparison or Control Design
Consent and Ethics Review
Sandbox or Staging Environment
Ramp Schedule
Debrief and Adoption Plan

mechanisms:
Pilot Program
A/B Test
Test Market
Clinical Pilot Study
Staged Policy Trial
Regulatory Sandbox Trial
Beta Program
Canary Release
Feature Flag Rollout
Limited License or Waiver

essence_one_line: Limit an experiment to a defined scope so learning can occur while risk to the wider system remains bounded.

compression_statement: When experimentation is valuable but risky, confine the learning action to a defined scope of participants, places, resources, time, exposure, metrics, monitoring, rollback, and reentry criteria so decision-relevant evidence can be gathered without uncontrolled system-wide consequences.

core_intuition: You cannot learn everything from analysis, but you also do not have to expose the whole system at once. A well-scoped experiment creates a small, governable envelope where reality can answer a question while the rest of the system remains protected.

canonical_formula: uncertainty + rollout risk + bounded exposure + monitoring + stop/expand rule -> safe learning before wider commitment

structural_problem: An experiment, change, policy, feature, treatment, market move, or operating practice may generate valuable learning, but system-wide application would create unacceptable uncertainty, harm, cost, reputational risk, operational disruption, ethical exposure, or irreversible consequences.

trigger_conditions: A decision cannot be settled by analysis, simulation, or precedent alone because behavior in context matters.

trigger_conditions: Full rollout would expose too many people, assets, users, patients, customers, services, or dependent systems before evidence exists.

trigger_conditions: The change can be bounded by population, unit, geography, traffic share, time, resource budget, legal permission, or operational surface.

trigger_conditions: Monitoring and rollback are possible while the experiment remains small.

trigger_conditions: Decision makers need evidence strong enough to decide whether to stop, revise, expand, or institutionalize the change.

symptoms: Teams debate an uncertain change but avoid testing because rollout feels too risky.

symptoms: Pilot projects run informally without criteria for success, safety, stopping, or scaling.

symptoms: A change is released broadly and only then discovers harms that could have been found under bounded exposure.

symptoms: Experiments collect data but do not connect to a decision rule or adoption pathway.

symptoms: A small trial drifts into permanent practice without review or consent from affected parties.

root_tension: The system needs contact with reality to learn, but the same contact can harm people, degrade service, contaminate evidence, trigger irreversible effects, or create political and operational commitments before the learning is justified.

anti_signatures: The activity can be safely evaluated entirely in a sandbox or simulation and no live or operational exposure is needed.

anti_signatures: The decision is already reversible and low-risk at full scale, making formal scoping unnecessary.

anti_signatures: The goal is only to design a statistically valid study, with no boundary, exposure, rollback, or operational-risk problem.

anti_signatures: The main issue is moving a proven change from test to production; that is closer to Controlled Reentry or staged release.

anti_signatures: The so-called experiment has no learning question, no decision rule, and no intention to use the evidence.

structural_intervention: Define a temporary experiment envelope that limits who, what, where, when, how much, and how far the experimental action may affect the system; pair that envelope with monitoring, success and safety metrics, rollback or stop conditions, and a decision rule for expansion, revision, continuation, or termination.

logic: Convert vague uncertainty into a decision-relevant question that requires bounded real-world or operational evidence.

logic: Specify the included participants, units, sites, resources, data, time window, permissions, and interfaces, while also naming what remains outside the experiment.

logic: Set limits that prevent the experiment from becoming a full rollout by accident or from harming more of the system than intended.

logic: Measure success, safety, fairness, reliability, cost, and unexpected effects while the experiment is still small enough to change course.

logic: Define what evidence triggers rollback, redesign, continuation, expansion, controlled reentry, or abandonment.

logic: Operate the experiment only within the authorized envelope and preserve context needed to interpret the findings.

logic: Use the evidence record and decision rules to stop, revise, expand, institutionalize, or hand off to a controlled-reentry pathway.

rule: Use Scoped Experimentation when learning from bounded exposure is necessary and safer than full deployment.

notes: The experiment should answer a decision that cannot be resolved with desk analysis alone.

rule: Do not expand the scope unless success metrics, safety metrics, and interpretation limits have been reviewed.

notes: Expansion should be a decision, not a side effect of momentum.

rule: Stop or roll back when predefined guardrails are breached, even if the primary performance metric improves.

notes: Safety and integrity constraints are not optional success metrics.

rule: Treat evidence as local unless the experiment scope represents the wider system well enough to support generalization.

notes: A scoped experiment can reduce uncertainty without proving full-system behavior.

rule: Escalate to ethics, legal, governance, or affected-party review when the experiment changes rights, obligations, access, care, public services, or material risk exposure.

notes: Bounded scope does not erase responsibility for exposed parties.

description: The experiment must remain within the authorized participants, sites, traffic, resources, duration, and harm surface.

description: The experiment must produce evidence that can change a decision, not only activity or optics.

description: The system must retain enough reversibility, compensation, or containment to act when stop conditions are met.

description: Measurement, selection, and interpretation must remain credible enough that the experiment does not create false confidence.

description: People or systems inside the experimental boundary must not be treated as disposable merely because the experiment is limited.

description: Effects must not propagate beyond the scope boundary without monitoring, consent, mitigation, or review.

description: The system obtains real evidence while limiting the number of people, assets, processes, or contexts exposed to uncertainty.

description: Problems are found while they are still reversible or limited in scale.

description: The experiment produces enough evidence to decide whether to stop, revise, scale, or hand off to controlled reentry.

description: Feedback from the bounded context reveals adaptations needed before wider use.

description: Explicit boundaries, communication, metrics, and review make experimentation more accountable than ad hoc rollout.

prose_essence:
Scoped Experimentation is the pattern of learning from reality without exposing the whole system to uncertainty at once. It draws a temporary boundary around an experiment: who or what is included, where it can operate, how long it can run, how much exposure is allowed, what will be measured, and what happens if the evidence is good, bad, ambiguous, or unsafe.

The archetype is useful when analysis, simulation, expert judgment, or precedent cannot answer the question, but full rollout would be reckless. Its core promise is not that the experiment is risk-free. Its promise is that the risk is bounded, watched, reversible where possible, and connected to a decision.

prose_when_to_use:
Use Scoped Experimentation when a proposed change needs real-world learning but should not yet touch the whole system. Common triggers include uncertain product changes, policy pilots, clinical or operational workflow changes, staged releases, test markets, school pilots, and regulated innovation trials.

The pattern is especially appropriate when the experiment can be bounded by population, geography, service site, traffic share, market, department, resource budget, time window, legal permission, or operational process. It is weak when effects are irreversible even at small scale, when monitoring cannot catch harm early enough, or when the small scope is so unrepresentative that it cannot answer the decision question.

prose_structural_problem:
The structural problem is a conflict between learning and exposure. The system needs contact with reality to learn how a change behaves, but that contact can produce harm, disruption, lock-in, unfairness, privacy loss, operational failure, or political commitment before the change is justified.

Without this archetype, organizations often fall into one of two failures. They either avoid action because uncertainty feels too dangerous, or they roll out broadly and discover failure after the blast radius is already large. A third failure is the vague pilot: a small trial with no clear learning question, no stop condition, no safety guardrails, and no decision rule for what happens next.

prose_intervention_logic:
Scoped Experimentation intervenes by creating an experiment envelope. The envelope limits exposure while allowing enough contact with the real system to produce useful evidence.

The usual logic is:

1. Name the uncertainty that must be resolved before wider action.
2. Draw the experiment scope boundary around participants, places, units, traffic, resources, duration, permissions, and interfaces.
3. Cap exposure so the experiment cannot accidentally become full rollout.
4. Define success metrics and safety guardrails together.
5. Monitor while the scope is still small enough for intervention.
6. Predefine rollback, stop, revision, expansion, and controlled-reentry rules.
7. Preserve an evidence record that distinguishes what was learned from what remains unknown.

A good scoped experiment is not just smaller than a full rollout. It is smaller in a deliberate way that preserves learning value while limiting harm.

prose_key_components:
### Experiment Learning Question

The learning question defines what uncertainty must be resolved. It keeps the experiment from becoming activity for its own sake. A good learning question is tied to a decision: stop, revise, expand, or adopt.

### Experiment Scope Boundary

The scope boundary states what is inside and outside the experiment. It may define participants, users, sites, geography, departments, data, traffic share, duration, legal permissions, budget, or operational surfaces. This is the boundary-specific core of the archetype.

### Exposure Limit

The exposure limit caps the experiment’s blast radius. It answers: how many people, how much traffic, how much money, how much time, how much risk, or how many system dependencies may be affected before review is required?

### Participant or Unit Selection Rule

The selection rule determines who or what enters the experiment. It must balance safety, representativeness, fairness, consent, and usefulness. A convenience-only selection rule can make the experiment safer but less informative, or unfairly concentrate risk.

### Success and Safety Metrics

Success metrics say whether the change appears to work. Safety metrics say whether it is harming reliability, equity, privacy, access, workload, cost, trust, or downstream systems. Both are needed. A change that wins on the primary metric but violates guardrails should not scale automatically.

### Monitoring Plan

The monitoring plan defines what will be watched during the experiment, how often, by whom, and through which escalation path. Monitoring converts limited exposure into controlled learning rather than mere hopeful exposure.

### Rollback or Stop Condition

The stop condition defines when the experiment must pause, reverse, terminate, quarantine outputs, or compensate affected parties. Without a real stop condition, a scoped experiment is just a rollout with a softer name.

### Escalation or Reentry Decision Rule

This rule defines how evidence leads to expansion, redesign, abandonment, continuation, or controlled reentry into the wider system. It prevents both premature scaling and endless pilots.

### Evidence Capture Record

The evidence record preserves results, incidents, anomalies, context, boundary changes, and interpretation limits. It matters because the experiment’s findings are local: they must not be generalized beyond what the scope can support.

### Boundary Communication Protocol

The communication protocol tells affected people and system owners what is experimental, who is included, what protections apply, what will be measured, and how concerns can be escalated. This component is essential when people are affected by services, policies, clinical care, education, pricing, or platform behavior.

Optional components include comparison groups, consent and ethics review, a sandbox or staging environment, a ramp schedule, and a debrief or adoption plan.

prose_common_mechanisms:
### Pilot Program

A pilot program implements the archetype by trying a change in a bounded site, group, service line, or time period. It is a mechanism, not the archetype itself. Many pilots fail because they lack explicit scope, metrics, rollback, or adoption criteria.

### A/B Test

An A/B test compares alternatives across bounded groups or traffic slices. It implements Scoped Experimentation when operational exposure, safety guardrails, privacy, fairness, and rollback are governed rather than treated as purely statistical details.

### Test Market

A test market exposes a product, price, campaign, or service model to a limited market before broader adoption. It helps reveal real behavior while limiting financial, reputational, and operational exposure.

### Clinical Pilot Study

A clinical pilot study tests a workflow, treatment process, or care model with bounded participants and strong safety requirements. It requires careful attention to consent, review, adverse events, and transfer limits.

### Staged Policy Trial

A staged policy trial tests a policy or institutional rule in a limited jurisdiction, department, population, or time window. It is useful when full implementation would be politically, administratively, or ethically risky.

### Regulatory Sandbox Trial

A regulatory sandbox trial allows a regulated activity to operate under temporary eligibility limits, monitoring duties, safeguards, and exit criteria. It is a scoped experiment when the central logic is bounded learning under oversight, not merely regulatory exemption.

### Beta Program

A beta program exposes a product, service, or workflow to a selected user group. It works as Scoped Experimentation when participant selection, feedback, risk limits, and next decisions are explicit.

### Canary Release

A canary release routes a small slice of production through a change before broader release. It is often a Controlled Reentry mechanism, but it can implement Scoped Experimentation when the canary is explicitly designed to learn under limited exposure.

### Feature Flag Rollout

A feature flag rollout gives operators control over who sees a change and how quickly exposure grows. The flag is not the archetype; it is an exposure-control mechanism.

### Limited License or Waiver

A limited license or waiver creates a temporary permission boundary. It is common in regulated domains where experimentation requires legal scope, reporting, and exit rules.

prose_failure_modes:
Common failure modes include underpowered scope, scope creep, irreversible harm inside the boundary, guardrail blindness, contaminated learning, rollback in name only, pilot theater, and false generalization.

Underpowered scope occurs when the experiment is too small or atypical to answer the question. Scope creep occurs when exposure expands before review. Guardrail blindness occurs when a primary metric improves while unmeasured harms grow. Pilot theater occurs when the trial is run to create the appearance of caution but lacks a genuine decision rule. False generalization occurs when evidence from one scope is treated as proof for all contexts.

prose_neighbor_distinctions:
Scoped Experimentation is closest to Sandboxing, but the distinction is important. Sandboxing creates an isolated or simulated environment. Scoped Experimentation limits exposure for learning, often in a real or partially live setting. A scoped experiment may use a sandbox, but it does not have to.

It is also close to Controlled Reentry. Controlled Reentry manages movement from a contained or tested state into wider circulation. Scoped Experimentation creates the bounded trial that may generate the evidence for that movement.

It differs from Experimental Design because experimental design focuses on inference quality, while this archetype focuses on operational boundary, exposure, rollback, monitoring, and decision governance. It differs from Boundary Permeability Control because it is not primarily about ongoing crossing rules; it is about a temporary learning envelope.

prose_cross_domain_examples:
In software operations, a team may use feature flags to expose a new model to a small traffic slice while monitoring performance and harm metrics. In public policy, a city may test a new service schedule in two districts before broader deployment. In healthcare, a clinic may pilot a discharge workflow with one team before hospital-wide use. In education, a district may test a tutoring schedule in selected classrooms. In regulation, a sandbox trial may permit a capped participant group to test an innovation under reporting and exit conditions.

Across these examples, the domains differ, but the structure is the same: real-world learning is allowed only inside a bounded, monitored, reviewable envelope.

prose_non_examples: A full rollout with monitoring is not Scoped Experimentation because exposure is not bounded. A purely offline simulation is usually Sandboxing or modeling, not this archetype. A research design with no operational scope boundary or rollback problem is Experimental Design. A permanent exception with no metrics or review is a carve-out, not an experiment. A trivial low-risk change may not need the archetype at all.

prose_tradeoffs:
Scoped Experimentation trades representativeness against risk reduction. Smaller scopes are safer but may not generalize. Larger scopes produce stronger evidence but increase exposure. It also trades speed against safeguards: rapid tests can be valuable, but human-subjects, public-service, safety, privacy, and fairness contexts require more care.

Another tradeoff is control versus ecological validity. A sandbox or tightly managed site can produce cleaner conditions, while field exposure reveals messy interactions. Finally, pilots create momentum. Once a trial has staff, users, contracts, and champions, stopping it may become politically hard even when the evidence says stop.

prose_invariants_to_preserve:
The central invariant is bounded exposure: the experiment must remain inside the approved scope. Other invariants are decision-relevant learning, rollback readiness, evidence integrity, affected-party protection, and no unmanaged spillover beyond the experimental boundary.

These invariants matter because the archetype can otherwise be abused. A limited experiment can become stealth rollout, an underpowered pilot can create false confidence, and a scoped trial can concentrate risk on people with limited power to object.

prose_target_outcomes:
The target outcomes are safer learning, reduced rollout risk, earlier detection of failure, better design fit, clearer adoption decisions, and improved legitimacy. If the archetype works, the system learns enough to stop, revise, expand, or transition deliberately rather than by inertia.

A successful scoped experiment does not always produce a successful change. Sometimes the best outcome is evidence that the change should not scale.

prose_parameter_dimensions:
Important tuning dimensions include scope breadth, duration, exposure cap, participant selection, representativeness, live versus simulated context, monitoring frequency, rollback speed, success thresholds, safety guardrails, consent requirements, and expansion criteria.

A narrow scope reduces risk but may produce weak evidence. A broad scope improves realism but increases blast radius. Long duration reveals delayed effects but may normalize the experiment before review. Strict guardrails protect the system but may prevent the experiment from encountering real operating conditions. The art is to make the scope large enough to learn and small enough to remain governable.

prose_variants_and_near_names:
Recognized variants include bounded pilot trials, limited user experiments, scoped policy trials, regulatory sandbox trials, and canary learning releases. Near names include limited trial, pilot program, pilot study, field trial, controlled rollout, A/B test, and test market.

These names should not all become separate archetypes. Most are mechanisms or variants. They belong under Scoped Experimentation when they share the same core structure: bounded exposure, monitored learning, explicit stop criteria, and a decision rule for what happens next.

raw_bundle_path: solution_archetypes/_Batches/First Iteration/Batch 04/Wave 2/scoped_experimentation_solution_archetype_output_bundle.zip

Bounded Pilot Trial

short_definition: A small-scale operational trial that limits who, where, for how long, and how far effects may propagate while collecting decision-relevant learning.

distinctive_feature: The pilot is bounded by an explicit experiment envelope, not merely run informally on a small scale.

distinct_from_parent: This is the common small-scale field form of Scoped Experimentation.

still_same_parent_because: The causal logic remains scope-limited learning with rollback and escalation criteria.

use_when: A proposed change should be tried in practice before wider adoption.

use_when: The trial can be limited to a coherent site, team, population, route, market, classroom, clinic, or subsystem.

use_when: Learning is more useful than pure simulation, but uncontrolled rollout is too risky.

example_domains:
public services
healthcare operations
education
product operations

case: A transit agency tests a modified bus route in one corridor before citywide route redesign.

why_variant_fits: The intervention is exposed only to a defined geography and time window while ridership, complaints, and safety are monitored.

Limited User Experiment

short_definition: A digital or service experiment exposed only to a bounded user segment, traffic slice, account class, or usage context.

distinctive_feature: The scope boundary is often a traffic percentage, cohort rule, feature flag, or account segment.

distinct_from_parent: This variant specializes the parent for user-facing digital, platform, or service contexts.

still_same_parent_because: It still depends on bounded exposure, monitoring, evaluation, and rollback or expansion criteria.

source_primes: boundary feedback

use_when: A product, policy, model, or interface change can be assigned to a limited user group.

use_when: Comparative feedback or causal evidence is needed before wider adoption.

use_when: User harm, fairness, privacy, or operational risk must remain bounded.

example_domains:
software products
platform governance
digital services

case: A platform exposes a new ranking rule to five percent of accounts with harm metrics and rollback triggers.

why_variant_fits: The test is not just a statistical design; it is an operationally bounded exposure envelope.

Scoped Policy Trial

short_definition: A governance or institutional rule tested within a bounded jurisdiction, department, population, or time window before wider adoption.

distinctive_feature: The scope boundary is institutional or jurisdictional rather than only technical.

distinct_from_parent: This variant names policy and governance cases where legitimacy, communication, and affected-party review matter strongly.

still_same_parent_because: The core pattern remains bounded learning plus stop, revise, expand, or institutionalize decisions.

source_primes: boundary representation

use_when: A policy change may have distributional, administrative, legal, or legitimacy consequences.

use_when: A limited jurisdiction, site, group, or period can be chosen without unfairly hiding risk.

use_when: Decision makers need evidence before system-wide policy change.

example_domains:
public policy
organizational governance
regulation
social programs

case: A city tests a new parking rule in one district for three months before wider adoption.

why_variant_fits: The experiment is limited by jurisdiction and duration, and expansion depends on evidence and review.

Canary Learning Release

short_definition: A staged production exposure used primarily to learn whether a change remains safe under limited real conditions before wider release.

distinctive_feature: It sits at the boundary between scoped experimentation and controlled reentry.

distinct_from_parent: This variant is narrower and release-oriented; it may be better treated as a mechanism when release management is dominant.

still_same_parent_because: When the canary is designed as a learning experiment with explicit scope, metrics, and stop criteria, it implements Scoped Experimentation.

use_when: A change has already passed offline or sandbox checks but live-system behavior remains uncertain.

use_when: A small production slice can reveal failure signals before larger exposure.

use_when: Rollback can occur quickly enough to preserve the bounded-risk invariant.

example_domains:
software operations
infrastructure operations
model deployment

case: A service routes one percent of traffic to a new version and stops if error rate, latency, or safety metrics cross thresholds.

why_variant_fits: The release is a bounded exposure used to learn under live conditions.

Regulatory Sandbox Trial

short_definition: A regulated innovation trial conducted under temporary scope limits, monitoring duties, eligibility rules, and exit criteria.

distinctive_feature: The scope boundary includes legal permission, monitoring, and regulatory oversight.

distinct_from_parent: It combines Scoped Experimentation with a governance sandbox; the sandbox name should not obscure the bounded-experiment logic.

still_same_parent_because: The intervention remains limited exposure for learning and review, not merely an isolated test environment.

source_primes: boundary virtualization

use_when: Regulated activity needs real-world learning without full-market exposure.

use_when: Authorities can define eligibility, caps, disclosures, safeguards, and evaluation windows.

use_when: The trial must avoid treating regulatory relief as an uncontrolled exemption.

example_domains:
financial technology
health technology
energy regulation
transport regulation

case: A regulator allows a payment product to serve a capped participant group under reporting, complaint, and exit rules.

why_variant_fits: The regulatory permission is temporary, bounded, monitored, and tied to learning.

near_names:
Limited Trial
Pilot Program
Pilot Study
Controlled Rollout
A/B Test
Test Market
Field Trial


Search Space Pruning

type: archetype

source: generated

batch: First Iteration/Batch 15/Wave 2

slug: optimization

slug: constraint

slug: complexity

slug: uncertainty

slug: screening

slug: threshold

slug: observability

slug: accountability

slug: transparency

slug: robustness

components:
Search Space Definition
Candidate or Region Representation
Objective or Success Criterion
Constraint Filter
Feasibility Test
Dominance Check
Pruning Rule
Diversity Preservation Rule
False-Negative Review
Reentry or Exception Path
Pruning Audit Trail
Cost of Evaluation Estimate
Confidence Threshold
Representative Sample Holdout
Pruning Owner
Criteria Update Trigger

mechanisms:
Branch and Bound
Constraint Filtering
Eligibility Screening
Shortlisting
Triage Filter
Dominated-Option Removal
Decision Tree Pruning
Beam Search
Safety or Compliance Exclusion
Negative Keyword Filter
Red-Flag Screen
Sample Audit of Exclusions

essence_one_line: Reduce an overwhelming search space by eliminating candidates or regions that cannot plausibly satisfy constraints or improve the outcome.

compression_statement: When exhaustive exploration is too costly, slow, unsafe, or impossible, Search Space Pruning defines explicit elimination criteria that remove infeasible, dominated, redundant, unsafe, or low-value parts of the space while preserving enough diversity, auditability, and reentry paths to prevent premature exclusion of good options.

core_intuition: A search becomes manageable when you stop treating every possible path as equally worth exploring. The intervention works by converting implicit hunches about what can be ignored into explicit pruning rules that can be checked, challenged, and revised.

canonical_formula: large candidate space + explicit exclusion criteria + false-negative safeguards → tractable search without unexamined premature closure

structural_problem: The possible solution, decision, diagnosis, or action space is too large to explore exhaustively, and many options are infeasible, dominated, unsafe, redundant, irrelevant, or too low value to justify equal attention.

condition: Combinatorial growth

description: Each additional variable, option, dependency, or branch multiplies the number of candidates.

condition: High evaluation cost

description: Testing every option would consume too much time, money, attention, compute, legal process, or human review capacity.

condition: Known hard constraints

description: Some candidates can be ruled out because they violate eligibility, safety, budget, law, physics, capacity, timing, or compatibility constraints.

condition: Dominated options

description: Some candidates are worse than another available candidate on all relevant criteria or cannot outperform the current best under any plausible scoring.

condition: Risky exploration

description: Some regions are dangerous, unethical, destabilizing, or costly enough that they require exclusion unless new evidence justifies review.

condition: Decision overload

description: The human or institutional decision maker cannot reason productively while the option set remains unbounded or cluttered.

symptom: Search paralysis

diagnostic_meaning: The team keeps collecting options but cannot compare or converge.

symptom: Wasteful evaluation

diagnostic_meaning: Resources are spent assessing candidates that were predictably infeasible or uncompetitive.

symptom: Late discovery of constraint violations

diagnostic_meaning: Options survive too long because exclusion criteria were not applied early.

symptom: Unexplained shortlists

diagnostic_meaning: Pruning is happening implicitly, creating fairness, auditability, or bias problems.

symptom: Premature narrowing

diagnostic_meaning: The search becomes tractable by losing valuable diversity or excluding unconventional viable candidates.

root_tension: The search needs to become smaller to be usable, but making it smaller can destroy the very option, diagnosis, or solution that would have been best.

case: The problem is not too large or costly to search

why_not: If all candidates can be evaluated cheaply and safely, pruning may add unnecessary governance overhead.

case: The objective and constraints are unknown

why_not: Objective Function Alignment or problem framing should come first; pruning without criteria only disguises arbitrary exclusion.

case: The main need is to create options

why_not: Option generation, divergent exploration, or problem-space mapping may be needed before pruning.

case: The issue is final decision commitment

why_not: Decision closure, satisficing, or convergence criteria may be the central archetype rather than pruning.

case: All options must receive equal procedural review

why_not: Legal, ethical, or institutional rules may forbid early elimination except through a formal admissibility or eligibility process.

structural_intervention: Define the searchable space, represent its candidates or regions, apply explicit pruning criteria, remove low-promise regions, and maintain safeguards that allow excluded areas to be audited or reopened when evidence changes.

Represent the search space

logic: State what counts as a candidate, branch, region, hypothesis, or option so pruning has a target.

name: Separate hard constraints from preferences

logic: Distinguish exclusions that must be enforced from soft criteria that only lower priority.

Choose pruning criteria

logic: Specify feasibility, dominance, safety, value, relevance, redundancy, budget, or evidence thresholds.

Apply pruning at the right granularity

logic: Eliminate a candidate, class, branch, region, document set, hypothesis group, or scenario only when the criterion justifies that scope.

Preserve search diversity

logic: Retain representative or uncertain regions when over-pruning would collapse the space too early.

Track exclusions

logic: Record what was pruned, why, under which assumptions, and who may revisit the decision.

Review false-negative risk

logic: Test whether pruned regions hide unusual, high-value, edge-case, or equity-relevant candidates.

Reopen when evidence changes

logic: Provide a reentry path when constraints, objectives, data, risk tolerance, or domain knowledge change.

rule: Only prune by explicit criteria

description: Every exclusion should cite a constraint, dominance relation, risk rule, evidence threshold, or agreed heuristic.

rule: Prefer hard exclusion for hard impossibility

description: Use decisive pruning when a candidate cannot satisfy mandatory constraints.

rule: Prefer ranking or deferral for uncertainty

description: When evidence is weak, lower priority or flag for later review rather than deleting the region.

rule: Audit high-impact exclusions

description: Pruning that affects rights, safety, opportunity, or strategic optionality requires stronger explanation and review.

rule: Use diversity preservation when the objective is uncertain

description: Maintain varied candidates when the scoring model may be incomplete or biased.

rule: Make criteria updateable

description: If the objective, constraints, or evidence changes, previously pruned regions should be eligible for reconsideration.

invariant: Feasible candidates remain reachable

description: Pruning should not eliminate every path to a satisfactory solution.

invariant: Exclusions are explainable

description: A reviewer can reconstruct why an option or region was removed.

invariant: Mandatory constraints are respected

description: Pruning must reliably remove candidates that cannot satisfy hard requirements.

invariant: False-negative risk is bounded

description: The system has a defined way to detect or mitigate over-pruning.

invariant: Diversity is preserved when needed

description: The remaining space is not narrowed to one brittle family of solutions before uncertainty has been resolved.

invariant: Criteria remain aligned with the objective

description: Pruning rules do not become proxy filters that optimize convenience rather than the intended outcome.

outcome: Tractable search

description: The remaining space is small enough to evaluate, compare, or explore effectively.

outcome: Lower evaluation cost

description: Time, money, attention, compute, or institutional review effort is focused on plausible candidates.

outcome: Earlier constraint enforcement

description: Infeasible or unsafe candidates are removed before they consume downstream effort.

outcome: More transparent selection

description: The path from broad space to candidate set is auditable rather than hidden in informal judgment.

outcome: Reduced decision overload

description: Decision makers can compare a meaningful candidate set instead of drowning in possibilities.

outcome: Better controlled exploration risk

description: Dangerous or unethical regions are explicitly excluded while preserving review paths for exceptional cases.

prose_essence:
Search Space Pruning is the discipline of making a large or branching search tractable by removing options that do not deserve continued exploration. It is not simply “having a filter.” The archetype requires an explicit search space, explicit exclusion criteria, and safeguards against deleting the option that would have mattered.

The core move is to replace hidden narrowing with governed narrowing. A team, algorithm, institution, or investigator states which candidates or regions can be removed, why they can be removed, what assumptions justify that removal, and how the exclusion can be audited or reopened.

prose_when_to_use:
Use this archetype when the candidate space is too large, costly, risky, or time-sensitive to evaluate exhaustively. It fits especially well when some possibilities can be ruled out because they violate hard constraints, cannot feasibly work, are dominated by better options, create unacceptable risk, or are too unlikely to justify equal attention.

It is also useful when pruning is already happening informally. In hiring, discovery, diagnosis, product selection, algorithmic search, and strategic planning, people often remove options silently. This archetype makes that removal visible and accountable.

Do not start here when the real problem is that the goal is unclear. In that case, use Objective Function Alignment first. Do not start here when the real need is to generate more possibilities; pruning should normally follow at least enough exploration to know what kind of space is being narrowed.

prose_structural_problem:
The structural problem is a mismatch between the size of the possible search space and the capacity available to explore it. The space may be combinatorial, legally complex, clinically uncertain, strategically broad, or simply too large for human attention.

The pressure to narrow is legitimate: without pruning, the search may stall, waste resources, or bury the best candidates among many impossible ones. The danger is equally real: a bad pruning rule can remove the rare, unconventional, high-value, or safety-critical option before anyone notices.

prose_intervention_logic:
The intervention begins by defining the search space and the unit of pruning. A unit may be an option, a branch, a hypothesis family, a document class, a vendor category, a model configuration, or a design direction. Once the unit is defined, the intervention separates hard constraints from preferences, chooses pruning criteria, applies them at the right granularity, records exclusions, and preserves review paths for uncertain or high-impact cases.

A strong pruning system does not merely delete. It distinguishes exclusion from deprioritization, preserves representative diversity when uncertainty remains, audits false negatives, and updates criteria when objectives or evidence change.

prose_key_components:
The key components are structural parts of the archetype, not implementation artifacts.

- **Search Space Definition** (`search_space_definition`): Defines the universe of candidates, branches, regions, hypotheses, actions, or solutions that might be explored. Without an explicit space, pruning becomes informal omission rather than a governed intervention.
- **Candidate or Region Representation** (`candidate_or_region_representation`): Specifies the unit that can be kept, removed, grouped, subdivided, or reopened. The representation may be a branch in a tree, a set of vendors, a diagnosis family, a design direction, a document class, or an optimization region.
- **Objective or Success Criterion** (`objective_or_success_criterion`): States what the search is trying to improve or satisfy so pruning does not remove options for irrelevant reasons. This component imports boundary discipline from Objective Function Alignment without becoming that archetype itself.
- **Constraint Filter** (`constraint_filter`): Applies hard requirements that candidates must satisfy to remain in the search. Examples include budget, safety, law, eligibility, physical feasibility, compatibility, timing, capacity, and ethical restrictions.
- **Feasibility Test** (`feasibility_test`): Checks whether a candidate or region can plausibly satisfy the constraints before deeper evaluation. The test can be exact, approximate, qualitative, probabilistic, or expert-informed, but its reliability should be stated.
- **Dominance Check** (`dominance_check`): Identifies candidates or regions that cannot outperform available alternatives under the relevant criteria. Dominance can be formal, as in optimization, or practical, as in removing options that cost more and deliver less than another option.
- **Pruning Rule** (`pruning_rule`): Defines the condition under which a candidate or region is eliminated rather than deferred or ranked lower. The pruning rule is the central governance component; it must distinguish hard exclusion from soft deprioritization.
- **Diversity Preservation Rule** (`diversity_preservation_rule`): Prevents the remaining set from collapsing too quickly into a narrow, biased, or fragile family of candidates. This is especially important when the objective is uncertain, the model is incomplete, or rare cases matter.
- **False-Negative Review** (`false_negative_review`): Audits whether valuable, feasible, or safety-critical candidates were incorrectly excluded. A pruning system without false-negative review may look efficient while silently losing the best option.
- **Reentry or Exception Path** (`reentry_or_exception_path`): Specifies how a pruned candidate or region can return to consideration when evidence, constraints, or objectives change. Reentry prevents pruning from becoming irreversible premature closure.
- **Pruning Audit Trail** (`pruning_audit_trail`): Records what was pruned, by which rule, under what assumptions, and with what reviewer or evidence source. Audit trails are especially important in high-stakes domains such as hiring, medicine, law, safety, and public policy.

Optional components often appear when pruning is high-stakes or resource-sensitive:

- **Cost of Evaluation Estimate** (`cost_of_evaluation_estimate`): Estimates how expensive deeper evaluation would be for each candidate or region. Useful when pruning is justified by scarce review capacity or opportunity cost.
- **Confidence Threshold** (`confidence_threshold`): Sets the certainty needed before exclusion is allowed. Lower thresholds prune faster but increase false-negative risk.
- **Representative Sample Holdout** (`representative_sample_holdout`): Keeps samples from pruned regions for monitoring, learning, or fairness review. A holdout can reveal whether a filter is too aggressive or biased.
- **Pruning Owner** (`pruning_owner`): Assigns accountability for criteria selection, updates, exception handling, and audit response. Ownership prevents pruning rules from becoming orphaned process artifacts.
- **Criteria Update Trigger** (`criteria_update_trigger`): Defines events that require pruning rules to be revisited. Triggers may include new evidence, changed constraints, model drift, stakeholder appeal, or unexpected failure patterns.

Together, these components create a narrowing system that is both efficient and reviewable. The pruning rule does the central exclusion work, but the diversity, false-negative, audit, and reentry components prevent pruning from becoming premature closure.

prose_common_mechanisms:
Mechanisms implement the archetype in particular domains. They should not be confused with the archetype itself.

- **Branch and Bound** (`branch_and_bound`): A algorithmic pruning method that implements the archetype by uses bounds to eliminate branches that cannot beat the current best feasible solution.
- **Constraint Filtering** (`constraint_filtering`): A screening method that implements the archetype by removes candidates that violate hard requirements before deeper evaluation.
- **Eligibility Screening** (`eligibility_screening`): A institutional review method that implements the archetype by filters applicants, cases, proposals, vendors, or records against formal criteria.
- **Shortlisting** (`shortlisting`): A decision process artifact that implements the archetype by reduces a broad set of options to a manageable candidate set for detailed comparison.
- **Triage Filter** (`triage_filter`): A prioritization procedure that implements the archetype by separates cases that need immediate attention, deferred review, routine handling, or exclusion.
- **Dominated-Option Removal** (`dominated_option_removal`): A comparative evaluation method that implements the archetype by eliminates options that are strictly or practically worse than another available option.
- **Decision Tree Pruning** (`decision_tree_pruning`): A model simplification method that implements the archetype by removes branches that add little predictive or explanatory value or that overfit training data.
- **Beam Search** (`beam_search`): A heuristic search method that implements the archetype by keeps only the most promising candidates at each step under a fixed-width search budget.
- **Safety or Compliance Exclusion** (`safety_or_compliance_exclusion`): A risk control rule that implements the archetype by removes candidates that violate safety, legal, ethical, or compliance requirements.
- **Negative Keyword Filter** (`negative_keyword_filter`): A retrieval filter that implements the archetype by excludes irrelevant document or search-result regions using explicit terms or metadata.
- **Red-Flag Screen** (`red_flag_screen`): A early warning checklist that implements the archetype by identifies disqualifying warning signs before deeper review.
- **Sample Audit of Exclusions** (`sample_audit_of_exclusions`): A quality control review that implements the archetype by reviews a subset of pruned items to detect false negatives, bias, or drift.

These mechanisms differ in strength. Branch and bound can justify formal exclusion in mathematical search. Eligibility screening can justify procedural exclusion in institutions. A red-flag screen may be useful as an early warning mechanism, but it needs audit and exception handling when consequences are high.

prose_failure_modes:
The most common failure mode is over-pruning: the system removes too much too early. This often happens when the objective is unclear, constraints are mistaken for preferences, or the team wants closure more than insight.

Another failure mode is proxy pruning. A convenient filter, such as pedigree, keyword presence, cost, or familiarity, becomes a substitute for the true objective. In high-stakes domains, this can amplify bias or deny opportunity.

A third failure mode is opaque deletion. Candidates disappear without reasons, making it impossible to audit mistakes. A fourth is stale criteria: pruning rules remain active after the environment, objective, or evidence changes.

prose_neighbor_distinctions:
Search Space Pruning is downstream of **Objective Function Alignment**. Objective Function Alignment asks what the search is trying to optimize or protect. Search Space Pruning asks which regions no longer deserve exploration under that objective and its constraints.

It differs from **Iterative Refinement Loop** because refinement improves an artifact through repeated feedback, while pruning removes options from consideration. It differs from **Branching and Merging** because branching governs safe divergence and recombination, while pruning governs which branches remain worth exploring.

It differs from **Progressive Narrowing** when the central pattern is staged convergence from broad to narrow. It differs from **Solution Space Bounding** when the central pattern is making an unbounded space finite before search. It differs from **Bounded Search Pruning** when formal bounds and proof of non-dominance are the central mechanism rather than one implementation family.

prose_cross_domain_examples:
In route optimization, branches whose lower-bound cost exceeds the best feasible route can be removed. In product planning, concepts that violate mandatory privacy or capacity constraints can be removed before detailed scoring. In medical diagnosis, inconsistent diagnostic families can be ruled out while rare high-risk cases remain on watch. In legal discovery, document classes outside scope can be excluded with sample audits. In hiring, formal eligibility screens can reduce volume while fairness audits check whether the filter is misclassifying candidates.

These examples differ in domain, but the structure is the same: define the space, apply explicit exclusion criteria, keep the remaining search tractable, and guard against false negatives.

prose_non_examples: A brainstorming session that postpones judgment is not Search Space Pruning; it is divergent option generation. A team defining a scoring metric is not pruning; it is objective or evaluation design. A committee hiding rejected options to avoid controversy is not pruning in the archetypal sense because it violates explainability and auditability. A training process that stops when validation loss stabilizes is a convergence or stopping-rule issue, not candidate-space pruning.

prose_tradeoffs:
Search Space Pruning trades completeness for tractability. That trade can be valuable, but it must be managed consciously.

The main tradeoff is efficiency versus discovery. More aggressive pruning makes the search cheaper but can remove unexpected solutions. Formal rules improve consistency but can mishandle context. Transparent criteria support accountability but may be gamed. Diversity-preserving pruning reduces bias and local traps but keeps more candidates alive.

prose_invariants_to_preserve:
The first invariant is reachability: at least one feasible path to a satisfactory solution must remain. If pruning removes all viable paths, the search becomes efficient but useless.

The second invariant is explainability. A reviewer should be able to see what was removed, by which criterion, under what assumptions, and with what opportunity for review.

The third invariant is alignment. Pruning rules must remain tied to the intended objective and constraints rather than drifting into convenience filters.

The fourth invariant is bounded false-negative risk. Pruning should not silently exclude valuable, rare, or safety-critical candidates without review mechanisms.

prose_target_outcomes:
The target outcome is not necessarily the best final option. The immediate outcome is a smaller, more meaningful search space that can be evaluated with available resources.

Successful pruning reduces evaluation cost, enforces constraints earlier, improves transparency, decreases decision overload, and makes subsequent comparison or optimization more reliable. In high-stakes settings, it also creates an auditable record of exclusion decisions.

prose_parameter_dimensions:
Important tuning dimensions include pruning aggressiveness, confidence threshold, granularity of pruning, review frequency, diversity preservation, and reentry difficulty.

A low confidence threshold prunes quickly but increases false-negative risk. Coarse-grained pruning removes whole regions and saves effort, but it can remove hidden viable subregions. Fine-grained pruning is safer but more expensive. Strict reentry rules preserve tractability, while permissive reentry rules protect exceptions but can recreate the original overload.

Another important parameter is whether the pruning rule is exact, approximate, heuristic, or judgment-based. Exact rules can be decisive when constraints are known. Heuristics are often necessary in real-world search, but they require stronger monitoring.

prose_variants_and_near_names:
Common variants include constraint-based pruning, dominance-based pruning, branch-and-bound pruning, safety pruning, and diversity-preserving pruning. These variants are useful for retrieval and explanation, but they remain under the same parent when the core intervention is explicit elimination of low-promise or unacceptable search regions.

Near names include candidate pruning, option pruning, solution-space pruning, search narrowing, screening filters, and shortlisting. “Shortlisting” is usually an output artifact or mechanism rather than a top-level archetype. “Branch and bound” is a formal mechanism and variant, not the whole archetype.

raw_bundle_path: solution_archetypes/_Batches/First Iteration/Batch 15/Wave 2/search_space_pruning_solution_archetype_output_bundle.zip

Constraint-Based Pruning

short_definition: Candidates or regions are removed because they violate explicit hard constraints.

distinctive_feature: Hard requirements, rather than comparative preference, justify exclusion.

distinct_from_parent: The parent covers many pruning criteria; this variant focuses on mandatory constraint violation.

still_same_parent_because: The core logic remains explicit exclusion of search-space regions to make search tractable.

use_when: constraint violations can be checked early

use_when: deeper evaluation would waste scarce review capacity

Constraint Filter

role: Applies hard requirements.

Feasibility Test

role: Checks whether the candidate can satisfy constraints.

Eligibility Screening

role: Filters candidates against formal criteria.

Safety or Compliance Exclusion

role: Removes prohibited candidates.

example_domains:
procurement
compliance
medical triage
software configuration

domain: Procurement

example: Vendors without required certifications are removed before scoring.

domain: Software

example: Configurations outside supported version constraints are excluded.

failure_modes: hard constraints are mistaken for preferences

Dominance-Based Pruning

short_definition: Candidates are removed because another candidate or class is at least as good on every relevant dimension and better on some.

distinctive_feature: Exclusion is justified by comparative inferiority, not absolute infeasibility.

distinct_from_parent: The parent also includes feasibility, risk, heuristic, and institutional pruning.

still_same_parent_because: Dominance is one pruning criterion used to reduce search space.

source_primes: optimization trade_offs constraint

use_when: candidates can be compared across relevant dimensions

use_when: evaluation resources should focus on nondominated options

Dominance Check

role: Detects inferior options.

Objective or Success Criterion

role: Defines the comparison basis.

Dominated-Option Removal

role: Removes worse options.

example_domains:
portfolio selection
product tradeoff analysis
route planning

domain: Product strategy

example: A feature option that costs more, takes longer, and solves less is removed.

failure_modes:
comparison dimensions are incomplete
qualitative value is ignored
false dominance hides optionality

Branch-and-Bound Pruning

short_definition: Branches are removed when a bound proves they cannot outperform the best available feasible candidate.

distinctive_feature: Bound logic supplies a formal exclusion proof.

distinct_from_parent: The parent also includes heuristic and institutional pruning without formal bound proofs.

still_same_parent_because: It implements the same exclusion logic within a formal search tree.

use_when: the search space can be represented as a branching structure

use_when: valid upper or lower bounds can be computed

Candidate or Region Representation

role: Defines branches.

Pruning Rule

role: States bound-based exclusion.

Branch and Bound

role: Prunes provably noncompetitive branches.

example_domains:
integer programming
route optimization
scheduling

domain: Logistics

example: A delivery-route branch is dropped when its lower-bound cost exceeds the current best route.

failure_modes: problem representation hides better branches

Safety Pruning

short_definition: Unsafe, unethical, destabilizing, or noncompliant regions are removed from the search before ordinary optimization.

distinctive_feature: The pruning criterion is protection from harm rather than efficiency alone.

distinct_from_parent: The parent includes value and feasibility pruning; this variant foregrounds safety and compliance exclusion.

still_same_parent_because: The core intervention remains explicit exclusion of regions from the search space.

use_when: some candidates are unacceptable even if they score well

use_when: safety constraints must override optimization pressure

Constraint Filter

role: Encodes safety or compliance constraints.

False-Negative Review

role: Checks whether exclusions and inclusions are safe.

example_domains:
clinical care
engineering safety
AI deployment
public policy

domain: Engineering

example: Design variants that violate load-bearing safety requirements are removed before cost optimization.

failure_modes: safety review becomes a symbolic checklist

Diversity-Preserving Pruning

short_definition: The space is pruned while deliberately retaining diverse representatives to avoid premature closure, bias, or local optima.

distinctive_feature: The pruning policy includes a preservation rule rather than maximizing immediate elimination.

distinct_from_parent: The parent covers pruning generally; this variant emphasizes retained diversity as a safeguard.

still_same_parent_because: It still removes regions under explicit criteria while controlling false-negative risk.

source_primes: optimization uncertainty robustness

use_when: the objective is uncertain or multi-dimensional

use_when: over-pruning would create strategic brittleness or bias

Diversity Preservation Rule

role: Keeps varied candidates or samples.

Representative Sample Holdout

role: Monitors pruned regions.

Sample Audit of Exclusions

role: Checks whether excluded samples reveal bias or missed value.

example_domains:
hiring
portfolio design
medical diagnosis
research search

domain: Research

example: A literature review keeps a sample of off-keyword papers to test whether search filters are missing relevant evidence.

failure_modes:
diversity holdouts become tokenistic
too much space is retained
preservation criteria are unclear

near_names:
Candidate Pruning
Option Pruning
Solution Space Pruning
Shortlisting
Screening Filter
Constraint Filtering


Second-System Complexity Restraint

batch: Batch 14

aliases:
second-system syndrome restraint
successor overengineering prevention
post-success scope discipline
v2 bloat control
successor scope discipline
rewrite bloat prevention
constraint-release ambition control

slug: supersession

slug: boundedness

slug: overfitting

slug: scalability

slug: modularity

slug: coupling

slug: risk

slug: minimalism

slug: iteration

slug: interoperability

slug: continuity

slug: governance

components:
Predecessor Constraint Memory
Deferred Ambition Backlog
Successor Core Contract
Preserved Constraint Function Map
Ambition Triage Gate
Complexity and Scope Budget
Staged Successor Release Ladder
Launchability Review Cadence
Deferred Ambition Parking Lot
Rollback or Escape Path
Stakeholder Expectation Contract
Architecture Flexibility Boundary
Technical Debt Retirement Lane
Negative Example Casebook

mechanisms: Architecture Decision Record with Future-Option Cost

essence_one_line: Keep the successor system launchable by remembering which first-system constraints made focus possible, triaging deferred ambitions, preserving the proven core, and admitting new complexity only through staged value-and-cost gates.

compression_statement: Second-System Complexity Restraint applies when a first system, pilot, or version succeeded under tight constraints and a successor now inherits both real capability and a stockpile of postponed ambitions. Because the original constraints feel like obsolete limitations, stakeholders try to fold parity, redesign, architecture generalization, deferred features, cleanup, and new strategy into one successor. The intervention makes constraint release explicit, separates core successor obligations from ambition backlog, budgets complexity, stages additions, and preserves a launchable migration path.

core_intuition: The constraints that made the first system frustrating may also be the constraints that made it shippable. A successor should not simply remove those constraints; it should identify what work they were doing, replace useful constraint functions with deliberate governance, and let ambition enter only at a pace the system can absorb.

canonical_formula: successor_viability = predecessor_constraint_memory + core_successor_contract + ambition_triage + complexity_budget + staged_release_ladder + launchability_gate + deferred_ambition_path

structural_problem: A successor system is being designed after a constrained first success, but the removal of the old constraints releases accumulated wants faster than the design, delivery, maintenance, and adoption capacity can evaluate or absorb them.

trigger_conditions: A first version, prototype, pilot, or legacy system succeeded while leaving many visible gaps, hacks, manual supports, or deferred requests.

trigger_conditions: A rewrite, second release, scaled version, replatforming, reorganization, or policy revision is authorized with more budget, confidence, tools, or political cover than the first effort had.

trigger_conditions: Stakeholders treat the successor as the once-in-a-generation chance to add everything the first system lacked.

trigger_conditions: The old constraints are described only as obstacles, even though they also limited scope, forced prioritization, and protected launchability.

trigger_conditions: Builders conflate parity with improvement, technical cleanup, architecture expansion, new features, and strategic repositioning.

trigger_conditions: Early design conversations emphasize generality, flexibility, future-proofing, and completeness before the successor has re-earned the first system’s core value.

trigger_conditions: The first system’s users, operators, or support staff are depending on continuity while the successor becomes increasingly ambitious.

symptoms: The phrase “while we are rebuilding it anyway” justifies unrelated additions.

symptoms: The successor backlog contains parity work, defect fixes, future options, stakeholder wishes, architecture abstractions, and nice-to-have enhancements with no shared triage logic.

symptoms: A release that was supposed to replace a working core becomes a multi-year universal redesign.

symptoms: Architecture diagrams become more elegant while the path to a usable launch becomes less concrete.

symptoms: The system accumulates configuration knobs, extension points, governance committees, integration layers, and user modes before core use cases are stable.

symptoms: Deferred ambitions are relabeled as non-negotiable requirements to avoid being challenged.

symptoms: The first system is criticized for constraints, but no one records which constraints protected delivery, comprehension, support, or quality.

symptoms: Original users experience delayed migration, lost familiar functions, degraded reliability, or a successor that solves future imagined problems better than present real ones.

symptoms: Teams keep postponing launch because each new omission now feels irresponsible compared with the promise of the successor.

root_tension: The first system’s constraints are simultaneously pain points and focusing devices. Removing them increases design freedom, but without replacement discipline the liberated ambition turns into overengineering.

anti_signatures: The successor has strict core scope, explicit release tiers, and a defended path for deferring ambitions without political penalty.

anti_signatures: A complex successor is required because the operating context genuinely changed and complexity has been validated against current constraints.

anti_signatures: The work is only a normal incremental release, not a successor after constraint release.

anti_signatures: The problem is ordinary scope creep without a predecessor system, postponed-ambition stockpile, or capability-retention dynamic.

anti_signatures: The intervention needed is only a generic complexity budget, feasibility review, or scale gate; the second-system temporal structure is not central.

structural_intervention: Turn the successor transition into a governed constraint-release process: preserve the proven core, document the old constraints and their useful functions, triage the ambition backlog, budget added complexity, stage expansion, and make launchability a protected invariant.

action_logic: Recover predecessor constraint memory: identify what the first system could not do, what it postponed, and what constraints made it focused, shippable, understandable, or operable.

action_logic: Separate work classes: distinguish core parity, safety or continuity obligations, defect repair, technical debt retirement, validated improvement, speculative future option, and parked ambition.

action_logic: State the successor core contract: define the smallest successor that preserves the first system’s validated value while improving only the failures chosen for this cycle.

action_logic: Map constraint functions: decide which old constraints should be removed, which should be replaced by deliberate gates, and which should be retained until later evidence justifies release.

action_logic: Create an ambition triage gate: require each addition to name its value, cost, coupling, maintenance load, validation need, and effect on launchability.

action_logic: Set a complexity-and-scope budget: cap the total cognitive, operational, architectural, user, and support load allowed in the successor release.

action_logic: Build a staged release ladder: route deferred ambitions into later tiers with review triggers rather than silently packing them into the second system.

action_logic: Run launchability reviews: test whether the successor can be delivered, migrated, supported, and learned before accepting more ambition.

action_logic: Preserve a rollback or escape path: avoid making the successor so totalizing that failure strands users or operations.

decision_rules: No postponed ambition becomes a successor requirement merely because it was postponed by the first system.

decision_rules: A lifted constraint must have a named replacement discipline if that constraint previously protected scope, quality, delivery, comprehension, support, or safety.

decision_rules: Separate parity from improvement: parity preserves validated value; improvement requires current evidence and a complexity-cost justification.

decision_rules: Treat architecture generality as a cost unless it enables a validated near-term release tier or protects a specified invariant.

decision_rules: Admit additions only while the launchability invariant remains satisfied under current team, user, support, migration, and governance capacity.

decision_rules: Ambitions rejected from the current tier must be parked with a review trigger, not erased, so stakeholders do not smuggle them back as hidden requirements.

decision_rules: If the successor cannot be launched without a large-bang migration, reduce ambition or add an incremental transition seam.

target_invariants: The successor preserves the first system’s validated core outcome before pursuing broad ambition.

target_invariants: Launchability, supportability, maintainability, and learnability remain protected constraints.

target_invariants: Users and operators have a continuity or migration path.

target_invariants: Added complexity has explicit value, cost, owner, and validation logic.

target_invariants: Deferred ambitions remain visible and legitimate without controlling the current release.

target_invariants: Architecture supports staged evolution rather than becoming a speculative monument to future possibilities.

target_invariants: Governance can say “later” without converting “later” into “never” or “now.”

expected_outcomes: The second system ships or transitions without being overloaded by the full deferred wish list.

expected_outcomes: Core value is preserved while selected improvements are delivered in a deliberate sequence.

expected_outcomes: Stakeholders can see why some ambitions are staged, parked, rejected, or converted into later experiments.

expected_outcomes: Architecture and scope remain proportional to current evidence and capacity.

expected_outcomes: Technical debt, feature demand, and strategic ambition are handled through different channels rather than merged into one successor bundle.

expected_outcomes: The organization retains ambition without surrendering the successor to ambition flood.

Successor Rewrite Scope Discipline

short_definition: A software, platform, or process-rewrite variant that prevents a replacement build from absorbing every postponed feature, architecture wish, and cleanup ambition before the core successor has shipped.

distinctive_feature: Centers the rewrite or replacement moment, where capability has been retained but old constraints and launch discipline appear to have disappeared.

distinct_from_parent: The parent applies to any successor system; this variant focuses on software, platform, process, or infrastructure rewrites.

still_same_parent_because: It uses the same predecessor-constraint memory, ambition triage, successor core contract, complexity budget, staged release ladder, and launchability gate.

use_when: A working first system is being rewritten, replatformed, or replaced rather than incrementally improved.

use_when: The rewrite team is tempted to combine parity, architecture improvement, feature expansion, and long-postponed technical cleanup into one release.

use_when: Stakeholders interpret the successor as the one chance to fix everything that the first system could not address.

Post-Pilot Expansion Restraint

short_definition: A scale-up variant that prevents a successful constrained pilot from being expanded into an overloaded second version when pilot constraints are removed.

distinctive_feature: Treats the first system’s constraints as part of the success mechanism rather than as mere limitations to discard.

distinct_from_parent: The parent covers successor overengineering generally; this variant focuses on pilot-to-scale transitions and pilot-boundary amnesia.

still_same_parent_because: The same ambition flood occurs when constraints that previously forced focus are lifted after a visible success.

use_when: A pilot, prototype, or small cohort succeeded partly because it had narrow users, tight support, unusual resources, or direct founder involvement.

use_when: The scaled successor is expected to serve many more users, contexts, exceptions, or stakeholders at once.

use_when: New demands are justified by saying the pilot proved the concept, even though the new demands were outside the pilot boundary.

V2 Feature-Flood Control

short_definition: A product, policy, curriculum, or service-versioning variant that keeps the second release from becoming the dumping ground for every deferred request from the first release.

distinctive_feature: Names the backlog-flood form of second-system risk, especially in versioned products and services.

distinct_from_parent: The parent also covers architecture, organization, and governance successors; this variant centers feature backlog flooding.

still_same_parent_because: The solution still preserves a core successor contract, triages ambitions, budgets complexity, and sequences capability additions.

use_when: The first version shipped with explicit omissions or narrow scope, creating a visible backlog of wanted additions.

use_when: Users, sponsors, or builders assume that the second version should finally include every deferred item.

use_when: The successor lacks a hard distinction between core parity, validated expansion, nice-to-have additions, and parked ambitions.

Architectural Grandiosity Brake

short_definition: A design-governance variant that checks the tendency to replace a simple proven core with an excessively general architecture built for imagined future cases.

distinctive_feature: Focuses on overgeneralized architecture and abstraction expansion rather than only visible feature count.

distinct_from_parent: The parent handles all successor ambition flooding; this variant isolates architectural ambition as the flood channel.

still_same_parent_because: It still constrains the successor by preserving core value, testing additions, budgeting complexity, and staging deferred ambition.

source_primes: second_system_effect complexity modularity coupling

use_when: The successor architecture is being justified by hypothetical future flexibility more than by validated near-term requirements.

use_when: Generalization, configurability, abstraction layers, or plugin points are multiplying before the successor has met its core use case.

use_when: The team treats the first system’s narrowness as a mistake rather than as the constraint that made delivery possible.

near_names:
second-system syndrome restraint
successor overengineering prevention
v2 bloat control
rewrite scope firewall
post-success scope discipline