Constraint Formulation

batch: First Iteration/Batch 29

source_primes: constraint optimization boundary

slug: boundary

slug: boundedness

components:
Constraint Set
Hard Constraint
Soft Constraint
Feasible Set
Violation Policy
Constraint Rationale
Constraint Scope Boundary
Constraint Priority Rule
Constraint Owner
Exception Authority
Feasibility Test Case
Update Trigger

mechanisms:
Requirements Constraint Specification
Design Constraint Document
Policy Rule Set
Optimization Constraint Model
Budget / Time Limit
Safety Constraint
Eligibility Rule
Legal Compliance Constraint
Acceptance Criteria
Constraint Review Checklist

essence_one_line: Turn implicit limits, requirements, and prohibitions into explicit constraints that shape the feasible solution space.

compression_statement: When problem-solving is unconstrained or ambiguously constrained, formulate explicit constraints so search, design, and decisions stay feasible and accountable.

core_intuition: A problem is not fully defined until its limits are defined. Without explicit constraints, teams explore impossible options, smuggle in hidden vetoes, or discover disqualifying requirements only after investing in a solution. Constraint Formulation makes the boundary of feasibility visible before search, design, optimization, or governance decisions proceed.

canonical_formula: problem_context + candidate_variables + explicit_limit_set + hard_soft_classification + violation_policy → feasible_set for search, design, or decision

structural_problem: Actors generate or choose options without clearly knowing which limits, requirements, or prohibitions define feasibility.

condition: Options are being generated before feasibility conditions are explicit.

why_it_matters: The team may spend effort exploring designs, policies, schedules, or plans that will later be disqualified.

condition: Stakeholders disagree about what is mandatory versus merely preferred.

why_it_matters: Unlabeled hard and soft constraints create conflict, hidden vetoes, and unreviewable tradeoffs.

condition: Legal, safety, compatibility, or resource limits are mentioned informally.

why_it_matters: Informal constraints are easy to overlook, reinterpret, or enforce unevenly.

condition: The search space is too broad or unbounded for practical decision-making.

why_it_matters: Explicit constraints prune impossible, unsafe, noncompliant, or irrelevant options before deeper analysis.

condition: Exceptions or violations are likely.

why_it_matters: Constraints without violation handling collapse under pressure or become arbitrary enforcement tools.

condition: A solver, workflow, policy, or review process needs a formal feasible set.

why_it_matters: Downstream mechanisms cannot compensate for an ambiguous definition of admissible action.

symptom: Promising options are rejected late for reasons that were known but unstated.

diagnostic_meaning: Important constraints existed but were not formalized early enough to guide search.

symptom: Stakeholders repeatedly argue over whether a requirement is mandatory.

diagnostic_meaning: The hard/soft classification is missing or not trusted.

symptom: A requirements list contains aspirations, prohibitions, goals, and preferences in one undifferentiated pile.

diagnostic_meaning: The constraint set has not been structured by role, priority, or violation consequence.

symptom: The feasible option set is empty or unknown.

diagnostic_meaning: The constraints may conflict, be overstrict, or be too vague to evaluate.

symptom: Teams work around constraints through informal exceptions.

diagnostic_meaning: Violation policy and exception authority are missing.

symptom: Compliance or safety review arrives only after solution commitment.

diagnostic_meaning: Constraint formulation is occurring too late in the decision process.

symptom: Optimization or prioritization outputs look precise but rest on underspecified limits.

diagnostic_meaning: The mechanism is being trusted before the feasible set has been responsibly defined.

root_tension: Creative search benefits from openness, but real decisions operate inside limits. If limits remain implicit, the process looks flexible while actually being governed by hidden constraints, late vetoes, and inconsistent exception handling.

case: The relevant limits are already explicit, accepted, and governed; the main issue is changing their size or tolerance.

why_not: Use constraint_envelope_adjustment rather than initial constraint formulation.

case: The main issue is deciding what objective to maximize or value to optimize, not what is admissible.

why_not: Use objective_function_alignment or a later optimization/allocation archetype.

case: The task is only to document a preference list that will not shape feasibility, ranking, or violation response.

why_not: Documentation alone does not instantiate the archetype unless it changes the solution space or decision logic.

case: A single moral, legal, or safety prohibition simply must be preserved without tradeoff or design-space reasoning.

why_not: Invariant_guarding or a rights/safety governance archetype may be more precise.

case: The primary problem is finding information rather than defining admissible options.

why_not: Use index_based_retrieval or search-space archetypes instead.

structural_intervention: Identify hard and soft constraints, define the feasible set, rank constraint priority, and specify violation handling.

action: Name the decision, design, search, or policy space being constrained.

purpose: Prevents constraints from floating without a clear object of application.

action: Elicit candidate limits, requirements, prohibitions, permissions, and preferences from stakeholders, evidence, standards, and operating realities.

purpose: Makes hidden constraints available for review before options are generated or selected.

action: Classify constraints as hard, soft, conditional, uncertain, or scope-limited.

purpose: Distinguishes exclusion rules from ranking pressures and from constraints that need interpretation.

action: Define the feasible set or admissibility test produced by the constraint set.

purpose: Connects constraints to concrete inclusion, exclusion, ranking, or redesign consequences.

action: Resolve conflicts and prioritize constraints when simultaneous satisfaction is impossible.

purpose: Prevents hidden tradeoffs and arbitrary enforcement.

action: Specify violation, exception, escalation, and update policies.

purpose: Keeps constraints accountable under real-world pressure, edge cases, and changing conditions.

action: Test constraints against representative options and edge cases.

purpose: Reveals empty feasible sets, loopholes, ambiguous language, and overbroad restrictions.

rule: A hard constraint must state the consequence of violation.

reason: Without a violation consequence, “hard” is only rhetoric.

rule: A soft constraint must state priority, penalty, weight, or negotiation process.

reason: A soft constraint without tradeoff guidance becomes an unhelpful aspiration.

rule: Every constraint should have a scope boundary and rationale.

reason: Scope prevents overreach; rationale supports review, revision, and legitimacy.

rule: If the feasible set is empty, identify conflicting constraints before relaxing or ignoring any one constraint.

reason: Empty feasibility can signal true impossibility, bad scoping, inconsistent requirements, or hidden priorities.

rule: Do not use a solver, checklist, or policy artifact to hide unresolved constraint legitimacy.

reason: Mechanisms can enforce constraints, but they cannot by themselves decide which constraints should govern.

rule: Review constraints when law, risk, resources, technology, stakeholder commitments, or operating scale changes.

reason: Constraints that were valid in one context can become stale or harmful in another.

invariant: Feasibility-defining limits remain explicit.

why_preserve: The archetype fails if hidden vetoes or informal prohibitions govern the decision.

invariant: Hard and soft constraints remain distinguishable.

why_preserve: Admissibility and preference weighting require different actions and failure handling.

invariant: Constraint scope and rationale remain visible.

why_preserve: Limits should be auditable, legitimate, and revisable rather than arbitrary.

invariant: Violation handling is specified before pressure arrives.

why_preserve: Ad hoc exceptions undermine fairness, safety, and trust.

invariant: The feasible set remains testable.

why_preserve: Decision makers need to know whether an option satisfies, violates, or requires reinterpretation of the constraint set.

invariant: Mechanisms remain subordinate to the archetype.

why_preserve: A checklist, contract, model, or requirements matrix is only useful if it implements explicit constraint logic.

outcome: Reduced wasted effort on infeasible options.

indicator: Rejected options fail earlier, with clear traceability to constraint violations.

outcome: More accountable design and decision boundaries.

indicator: Stakeholders can inspect why options are included, excluded, or ranked lower.

outcome: Earlier discovery of conflicts and impossibility.

indicator: Empty or contradictory feasible sets are detected before commitment.

outcome: Better governance of exceptions and waivers.

indicator: Constraint violations trigger documented escalation, repair, or authorized exception paths.

outcome: Improved handoff to downstream mechanisms.

indicator: Optimization models, reviews, checklists, and search procedures receive clear admissibility criteria.

prose_essence:
Constraint Formulation is the intervention of making limits explicit enough to shape the feasible solution space. It turns informal statements like “we can’t do that,” “this must be safe,” “keep it within budget,” or “only eligible cases count” into inspectable constraints with scope, hardness, rationale, and violation handling.

The archetype matters because unconstrained work is often only apparently open. In practice, hidden limits still govern the outcome; they simply appear late, inconsistently, or through informal vetoes. Good constraint formulation makes those limits visible early enough to guide search, design, optimization, and governance.

prose_when_to_use:
Use this archetype when options are being generated, filtered, designed, scheduled, allocated, or governed under limits that are not yet explicit. It is especially useful when stakeholders disagree about what is mandatory, when legal or safety restrictions matter, when a model or review process needs a defined feasible set, or when late infeasibility would be expensive.

Do not use it merely to make a list of wishes. The list becomes part of this archetype only when it changes admissibility, ranking, violation response, or search boundaries.

prose_structural_problem:
The structural problem is ambiguous feasibility. Actors are working in a decision space without a shared definition of what counts as allowed, possible, acceptable, or negotiable. The result is wasted exploration, late rejection, inconsistent enforcement, and hidden tradeoffs.

This is not just a communication issue. A constraint changes the structure of the problem: it partitions options into feasible, infeasible, conditionally feasible, or feasible-but-penalized categories. Until that partition is visible, downstream mechanisms such as optimization, checklists, policy review, and acceptance testing can produce misleading confidence.

prose_intervention_logic:
The intervention begins by naming the space being constrained: a product design, policy choice, schedule, allocation problem, technical system, or governance process. It then elicits possible limits, classifies them, defines their scope, and connects them to a feasible set or admissibility test. Hard constraints exclude or require formal exception; soft constraints rank, penalize, or guide tradeoff. Conflict and violation policies keep the system from collapsing when real cases are messy.

A strong formulation answers five questions: what is constrained, which constraints are hard or soft, where each constraint applies, what happens if it is violated, and who may revise or interpret it.

prose_key_components:
```yaml
component:
  slug: constraint_set
  name: Constraint Set
  role: >-
    Collects the explicit limits, requirements, prohibitions, and permissions that
    define what counts as a feasible option.
  notes: >-
    The set should include enough context to inspect completeness, conflict, ownership,
    and update needs. A single isolated rule rarely captures the real feasible space.
```
Constraint Set is a structural part of the archetype, not merely a documentation field. The set should include enough context to inspect completeness, conflict, ownership, and update needs. A single isolated rule rarely captures the real feasible space.

```yaml
component:
  slug: hard_constraint
  name: Hard Constraint
  role: >-
    Marks a condition that an option must satisfy to remain admissible, such as a
    legal prohibition, safety limit, compatibility requirement, or absolute budget
    ceiling.
  notes: >-
    Calling a constraint hard should imply rejection, redesign, or formal exception
    handling when violated. If violation is merely costly, it is probably a soft constraint.
```
Hard Constraint is a structural part of the archetype, not merely a documentation field. Calling a constraint hard should imply rejection, redesign, or formal exception handling when violated. If violation is merely costly, it is probably a soft constraint.

```yaml
component:
  slug: soft_constraint
  name: Soft Constraint
  role: >-
    Represents a preference, target, penalty, or negotiable requirement that shapes
    ranking without automatically excluding every violating option.
  notes: >-
    Soft constraints need priority, penalty, or tradeoff guidance; otherwise they
    become vague wishes that cannot guide search or negotiation.
```
Soft Constraint is a structural part of the archetype, not merely a documentation field. Soft constraints need priority, penalty, or tradeoff guidance; otherwise they become vague wishes that cannot guide search or negotiation.

```yaml
component:
  slug: feasible_set
  name: Feasible Set
  role: >-
    Identifies the options, designs, actions, schedules, or policies that satisfy
    the active constraint set.
  notes: >-
    The feasible set can be a literal set, a modeled region, a filtered candidate
    list, or a governed definition of admissibility. It should be checkable, not merely
    asserted.
```
Feasible Set is a structural part of the archetype, not merely a documentation field. The feasible set can be a literal set, a modeled region, a filtered candidate list, or a governed definition of admissibility. It should be checkable, not merely asserted.

```yaml
component:
  slug: violation_policy
  name: Violation Policy
  role: >-
    Specifies what happens when a constraint is breached, uncertain, waived, contested,
    or found to conflict with another constraint.
  notes: >-
    Without a violation policy, constraints tend to be enforced inconsistently or
    ignored when inconvenient. The policy should state escalation, exception authority,
    repair, and documentation requirements.
```
Violation Policy is a structural part of the archetype, not merely a documentation field. Without a violation policy, constraints tend to be enforced inconsistently or ignored when inconvenient. The policy should state escalation, exception authority, repair, and documentation requirements.

```yaml
component:
  slug: constraint_rationale
  name: Constraint Rationale
  role: >-
    Explains why each constraint exists, what harm or failure it prevents, and what
    value or obligation it protects.
  notes: >-
    Rationale prevents constraints from becoming arbitrary inherited rules. It also
    helps decide whether a constraint should be hardened, softened, revised, or retired.
```
Constraint Rationale is a structural part of the archetype, not merely a documentation field. Rationale prevents constraints from becoming arbitrary inherited rules. It also helps decide whether a constraint should be hardened, softened, revised, or retired.

```yaml
component:
  slug: constraint_scope_boundary
  name: Constraint Scope Boundary
  role: >-
    Defines where the constraint applies, which entities or cases are covered, and
    where the constraint no longer governs the decision.
  notes: >-
    Scope boundaries prevent overreach and undercoverage. The same limit may be appropriate
    for one product line, population, jurisdiction, scale, or time horizon and inappropriate
    for another.
```
Constraint Scope Boundary is a structural part of the archetype, not merely a documentation field. Scope boundaries prevent overreach and undercoverage. The same limit may be appropriate for one product line, population, jurisdiction, scale, or time horizon and inappropriate for another.

```yaml
component:
  slug: constraint_priority_rule
  name: Constraint Priority Rule
  role: >-
    Orders constraints or defines conflict handling when not all limits can be satisfied
    simultaneously.
  notes: >-
    Priority rules are especially important when safety, law, equity, cost, time,
    and performance constraints collide. They make tradeoffs auditable rather than
    hidden.
```
Constraint Priority Rule is a structural part of the archetype, not merely a documentation field. Priority rules are especially important when safety, law, equity, cost, time, and performance constraints collide. They make tradeoffs auditable rather than hidden.

prose_common_mechanisms:
The mechanisms below are concrete ways to implement the archetype. They should not be confused with the archetype itself. A requirements document, policy rule set, legal contract, or optimization model only instantiates Constraint Formulation when it actually defines feasibility, priority, scope, and violation handling.

```yaml
mechanism:
  slug: requirements_constraint_specification
  name: Requirements Constraint Specification
  mechanism_type: document
  role: >-
    Turns stakeholder needs, product requirements, or project rules into explicit
    must-satisfy and prefer-to-satisfy conditions.
```
Requirements Constraint Specification implements Constraint Formulation when it makes constraints actionable and reviewable. Useful when constraints are scattered across conversations, tickets, procurement terms, or design notes. It should not be mistaken for the archetype itself.

```yaml
mechanism:
  slug: design_constraint_document
  name: Design Constraint Document
  mechanism_type: document
  role: >-
    Records physical, usability, interoperability, environmental, manufacturing, or
    maintenance limits that shape design choices.
```
Design Constraint Document implements Constraint Formulation when it makes constraints actionable and reviewable. The document implements the archetype only when it changes feasible design search and decision criteria. It should not be mistaken for the archetype itself.

```yaml
mechanism:
  slug: policy_rule_set
  name: Policy Rule Set
  mechanism_type: document
  role: >-
    Expresses policy limits, permissions, conditions, and prohibitions so actors can
    determine admissible action.
```
Policy Rule Set implements Constraint Formulation when it makes constraints actionable and reviewable. Policy rules need interpretation, exception handling, and update ownership to avoid becoming brittle or symbolic. It should not be mistaken for the archetype itself.

```yaml
mechanism:
  slug: optimization_constraint_model
  name: Optimization Constraint Model
  mechanism_type: method
  role: >-
    Represents variables and constraints in a mathematical or computational model
    so solvers or analysts can search the feasible region.
```
Optimization Constraint Model implements Constraint Formulation when it makes constraints actionable and reviewable. This is a mechanism, not the parent archetype. The archetype is the decision to formalize limits and feasible options; the model is one implementation. It should not be mistaken for the archetype itself.

```yaml
mechanism:
  slug: budget_time_limit
  name: Budget / Time Limit
  mechanism_type: other
  role: >-
    Sets resource or schedule boundaries that exclude or penalize options exceeding
    available money, time, labor, or capacity.
```
Budget / Time Limit implements Constraint Formulation when it makes constraints actionable and reviewable. Budget and time limits often look simple, but they still need scope, tolerance, exception policy, and review cadence. It should not be mistaken for the archetype itself.

```yaml
mechanism:
  slug: safety_constraint
  name: Safety Constraint
  mechanism_type: protocol
  role: >-
    Defines conditions that must be met to prevent injury, catastrophic loss, operational
    hazard, or unacceptable exposure.
```
Safety Constraint implements Constraint Formulation when it makes constraints actionable and reviewable. Safety constraints are often hard constraints, but the draft should still document rationale, threshold, evidence, and escalation. It should not be mistaken for the archetype itself.

```yaml
mechanism:
  slug: eligibility_rule
  name: Eligibility Rule
  mechanism_type: test_or_assessment
  role: >-
    Specifies which people, cases, projects, records, or options are admitted into
    a program, process, queue, or decision space.
```
Eligibility Rule implements Constraint Formulation when it makes constraints actionable and reviewable. Eligibility rules can instantiate constraint formulation when they define admissibility and include appeal or exception handling. It should not be mistaken for the archetype itself.

```yaml
mechanism:
  slug: legal_compliance_constraint
  name: Legal Compliance Constraint
  mechanism_type: procedure
  role: >-
    Translates laws, regulations, contracts, or standards into actionable constraints
    on design, operation, or decision-making.
```
Legal Compliance Constraint implements Constraint Formulation when it makes constraints actionable and reviewable. Legal constraints should not be reduced to vague “be compliant” statements; they need scope, authority, and evidence requirements. It should not be mistaken for the archetype itself.

```yaml
mechanism:
  slug: acceptance_criteria
  name: Acceptance Criteria
  mechanism_type: test_or_assessment
  role: >-
    Defines pass/fail or accept/reject conditions for a deliverable, case, design,
    or decision.
```
Acceptance Criteria implements Constraint Formulation when it makes constraints actionable and reviewable. Acceptance criteria are a lightweight mechanism when they filter options before release, deployment, approval, or handoff. It should not be mistaken for the archetype itself.

```yaml
mechanism:
  slug: constraint_review_checklist
  name: Constraint Review Checklist
  mechanism_type: procedure
  role: >-
    Prompts reviewers to check hard/soft classification, conflicts, scope, enforcement,
    exceptions, and stale assumptions.
```
Constraint Review Checklist implements Constraint Formulation when it makes constraints actionable and reviewable. The checklist supports governance of the archetype, especially when many constraints must be maintained over time. It should not be mistaken for the archetype itself.

prose_failure_modes:
Common failure modes include overconstraint, underconstraint, pseudo-hard constraints, hidden stakeholder vetoes, conflicting constraints, constraint theater, stale constraint lock-in, and scope leakage. Overconstraint happens when preferences are treated as mandatory. Underconstraint happens when important limits stay implicit. Constraint theater happens when constraints are documented but not connected to decisions, tests, owners, or violation consequences.

The most dangerous failure mode is legitimacy laundering: a questionable preference or power interest is presented as a technical or legal impossibility. The mitigation is to require rationale, source, scope, owner, and review path for important constraints.

prose_neighbor_distinctions:
Constraint Formulation is distinct from Constraint Envelope Adjustment because it defines or clarifies the constraint set, while envelope adjustment changes an already-existing boundary. It is distinct from Objective Function Alignment because objectives define what should be optimized, whereas constraints define what is admissible or penalized. It is distinct from Search Space Pruning because pruning is a search operation, while formulation defines the feasibility rules that may justify pruning.

It also differs from Constrained Resource Allocation. Allocation uses constraints to distribute scarce resources; this archetype defines the constraints and feasible set that allocation may later use. Objective–constraint formulation remains merge-sensitive because it may combine objective definition, feasible-set definition, and allocation logic.

prose_cross_domain_examples:
In product development, a team might formalize maximum weight, minimum battery life, regulatory requirements, manufacturing constraints, and cost targets before selecting concepts. In public administration, eligibility law can be converted into admissibility criteria, documentation requirements, appeal routes, and exception policies. In hospital scheduling, certification and rest-period rules can be treated as hard constraints, while shift preferences become soft constraints.

In infrastructure planning, route options are shaped by floodplain restrictions, clearance requirements, environmental protections, budget ceilings, and maintenance access. In data governance, privacy commitments become access, retention, purpose, audit, and deletion constraints. In optimization modeling, constraint formulation happens before the solver: variables, feasibility conditions, and prohibited combinations must be specified first.

prose_non_examples:
A brainstorming session that deliberately delays constraints is not this archetype yet. A hidden managerial veto is a symptom of missing constraint formulation, not a good instance of it. A risk matrix is not this archetype because it weights likelihood and consequence rather than defining feasibility. An optimization solver that operates on already-formulated constraints is a mechanism, not the parent pattern.

A single absolute prohibition may be better handled as invariant guarding if the work does not require broader feasible-set definition, hard/soft classification, or exception handling.

prose_tradeoffs:
The central tradeoff is clarity versus exploration. Constraints focus search, but premature constraints can suppress discovery. Hardness protects safety and legality, but too many hard constraints create brittle or empty feasible sets. Completeness reduces late surprises, but exhaustive constraint elicitation can slow action.

Constraint formulation also trades formal enforceability against human judgment. Precise rules improve auditability, but some cases need legitimate discretion. The remedy is not to abandon constraints; it is to define exception authority and review standards explicitly.

prose_invariants_to_preserve:
The main invariant is that feasibility-defining limits remain visible. Hidden constraints defeat the purpose of the archetype. A second invariant is the hard/soft distinction: exclusion rules and preferences must not be blurred. A third invariant is scope: constraints must not silently expand beyond their intended cases or fail to cover critical edge cases.

The violation policy is also invariant. Constraints are most tested when they are inconvenient, so exception authority, escalation, repair, and documentation should be defined before pressure arrives. Finally, mechanisms must remain subordinate to the archetype; a checklist or model is only useful if it preserves the logic of explicit constraint formulation.

prose_target_outcomes:
The target outcomes are earlier detection of infeasible options, clearer accountability for design and policy boundaries, fewer late surprises, better handling of exceptions, and more reliable handoff to downstream tools. In practice, success looks like options being excluded, redesigned, or ranked for stated reasons rather than by informal veto or after-the-fact justification.

A well-formulated constraint set also improves collaboration. Stakeholders can challenge the rationale, scope, or hardness of a constraint instead of arguing vaguely about whether an option “works.”

prose_parameter_dimensions:
Constraint Formulation can be tuned along several dimensions. The first is hardness: a constraint can be absolute, negotiable, weighted, conditional, or advisory. The second is scope: constraints may apply to all cases or only to a jurisdiction, product class, population, time window, risk level, or operating mode. The third is granularity: constraints can be broad principles or precise tests. The fourth is permissiveness: a formulation may define a narrow feasible set or a broad one with later pruning.

Other tuning dimensions include enforcement strength, exception tolerance, evidence threshold, update cadence, stakeholder legitimacy, and whether soft constraints are handled through qualitative priority, numeric penalties, or deliberative review. These parameters should be explicit because changing them changes the solution space.

prose_variants_and_near_names:
### Hard-Constraint Formulation

A subtype that defines absolute admissibility conditions whose violation excludes an option or requires formal exception review. It remains under the parent because it uses the same core components—constraint set, feasible set, scope, rationale, and violation policy—but with a stricter violation consequence.
### Soft-Constraint Prioritization

A subtype that turns preferences, targets, penalties, and negotiable requirements into explicit ranking pressure rather than pass/fail exclusion. It remains under the parent because it still formalizes limits and preferences so the solution space is shaped explicitly rather than informally.
### Feasibility Envelope Definition

A subtype that defines the overall envelope within which options remain feasible across scope, capacity, performance, or operating conditions. It remains under the parent because the envelope exists because constraints have been formalized; it is not a separate intervention unless mapping trajectories or optimizing within it becomes central.
### Compliance Constraint Formulation

A domain variant that translates legal, regulatory, contractual, ethical, or policy obligations into actionable constraints. It remains under the parent because the same intervention applies: translate limits into explicit constraints that shape feasible action and violation handling.
### Near names and collapsed candidates

Constraint specification, constraint modeling, feasibility definition, limits formalization, and guardrail definition should generally route to this archetype. Domain names such as design constraints, policy constraints, legal constraints, safety constraints, eligibility constraints, and budget/time limits are mechanisms or variants unless they develop distinct cross-domain structure. Objective–constraint formulation remains a merge-review warning because it may belong with constrained resource allocation or objective-function alignment rather than this parent.

Hard-Constraint Formulation

distinctive_feature: The decisive feature is exclusion: violating the constraint removes the option from the feasible set unless an explicit exception process is invoked.

distinct_from_parent: The parent covers all constraint formalization; this variant focuses on constraints that define admissibility rather than preference or penalty.

still_same_parent_because: It uses the same core components—constraint set, feasible set, scope, rationale, and violation policy—but with a stricter violation consequence.

source_primes: constraint boundary closure

condition: Violation would breach law, safety, physical possibility, compatibility, mission integrity, or a non-negotiable commitment.

condition: The decision needs a clear pass/fail boundary before options are ranked or optimized.

Feasible Set

role: Identifies the options, designs, actions, schedules, or policies that satisfy the active constraint set.

Acceptance Criteria

role: Defines pass/fail or accept/reject conditions for a deliverable, case, design, or decision.

domain: Safety engineering

example: Rejecting machine configurations that exceed a maximum safe load.

domain: Procurement

example: Excluding vendors that cannot meet mandatory security certification requirements.

failure_mode: False hardness

cause: A negotiable preference is mislabeled as non-negotiable, unnecessarily shrinking the feasible set.

failure_mode: Backdoor exception

cause: Hard constraints are waived informally without a visible exception authority.

Soft-Constraint Prioritization

distinctive_feature: The constraint does not simply exclude; it adds a penalty, priority, weight, or negotiated preference to the decision.

distinct_from_parent: The parent includes hard and soft constraints; this variant emphasizes the ranking and penalty logic for negotiable constraints.

still_same_parent_because: It still formalizes limits and preferences so the solution space is shaped explicitly rather than informally.

source_primes: constraint optimization trade_offs

condition: Many desirable conditions cannot all be fully satisfied, but violations differ by severity, cost, or stakeholder importance.

condition: The decision needs a transparent way to rank feasible-but-imperfect options.

Constraint Priority Rule

role: Orders constraints or defines conflict handling when not all limits can be satisfied simultaneously.

Constraint Review Checklist

domain: Scheduling

example: Treating preferred shift patterns as penalties rather than absolute exclusions.

domain: Product design

example: Prioritizing lower weight and lower cost without rejecting every design that misses a target slightly.

failure_mode: Preference laundering

cause: Stakeholder preferences are hidden inside technical weights without legitimacy review.

failure_mode: Penalty opacity

cause: The cost of violating a soft constraint is not visible, so ranking cannot be audited.

Feasibility Envelope Definition

distinctive_feature: The output is an interpretable envelope or admissible region rather than a simple list of requirements.

distinct_from_parent: The parent can formulate constraints as individual rules; this variant emphasizes the combined boundary produced by many constraints together.

still_same_parent_because: The envelope exists because constraints have been formalized; it is not a separate intervention unless mapping trajectories or optimizing within it becomes central.

source_primes: constraint boundedness boundary

condition: The task is not only to list constraints but to draw a usable admissible region or operating envelope.

condition: Actors need to know how far a solution can vary before it leaves safe, legal, possible, or useful bounds.

Design Constraint Document

domain: Engineering

example: Defining the safe operating region for temperature, pressure, and load.

domain: Service operations

example: Defining a staffing envelope within which response-time commitments remain feasible.

failure_mode: Envelope overconfidence

cause: The boundary is treated as precise even though it was built from uncertain or incomplete constraints.

failure_mode: Boundary myopia

cause: Only the visible constraints are mapped, leaving hidden stakeholder or implementation constraints outside the envelope.

Compliance Constraint Formulation

distinctive_feature: Authority and evidence matter: the constraint must trace to a rule source and show how compliance will be demonstrated.

distinct_from_parent: The parent is cross-domain; this variant is used when formal authority, auditability, and rule interpretation are central.

still_same_parent_because: The same intervention applies: translate limits into explicit constraints that shape feasible action and violation handling.

source_primes: constraint boundary

condition: The decision must satisfy externally imposed or institutionally authorized rules.

condition: A vague mandate such as “be compliant” must become concrete admissibility criteria, evidence requirements, and exception rules.

Policy Rule Set

role: Expresses policy limits, permissions, conditions, and prohibitions so actors can determine admissible action.

Eligibility Rule

domain: Healthcare

example: Translating patient privacy obligations into data-access constraints and audit requirements.

domain: Public administration

example: Turning eligibility law into program rules, documentation requirements, and appeal pathways.

failure_mode: Rule-source drift

cause: The constraint persists after the underlying legal or policy source changes.

failure_mode: Overcompliance lock-in

cause: Conservative interpretation becomes a hidden hard constraint that unnecessarily excludes legitimate options.

near_names:
Constraint Specification
Constraint Modeling
Requirements Constraint Formulation
Feasibility Definition
Limits Formalization
Guardrail Definition
Objective–Constraint Formulation


Constraint-Guided Backtracking

type: archetype

source: generated

batch: Batch 13

canonical_family: Search, Constraint & Reversible Commitment

source_primes: backtracking search_and_retrieval constraint algorithm recursion state_and_state_transition sequencing

slug: backtracking

slug: constraint

slug: algorithm

slug: recursion

slug: sequencing

slug: optimization

slug: completeness

slug: complexity

slug: approximation

slug: feedback

slug: threshold

slug: uncertainty

slug: dependency

slug: traceability

slug: decision

slug: closure

slug: discreteness

slug: iteration

slug: satisficing

components:
Partial Solution State
Decision Stack
Extension Operator
Constraint Failure Test
Rollback Rule
Branch Ordering Policy
Visited Branch Record
Preserved Context Boundary
Completion or Exhaustion Condition
Forward-Checking Probe
Constraint Explanation Trace
Alternative Branch Queue
Rollback Depth Limit
Human Review Escape Hatch

essence_one_line: Solve a constrained, path-dependent problem by extending a partial solution, testing it early, and undoing the latest failed commitment while preserving still-valid prior work.

compression_statement: When a solution must be built from interdependent choices and some constraints become visible only after partial construction, represent the current partial solution explicitly, extend it one reversible step at a time, test each extension against constraints or evidence, abandon a branch as soon as it cannot lead to success, roll back to the most recent useful decision point, record the failure reason, and try the next viable branch until completion, exhaustion, or method switch.

core_intuition: Backtracking works because many failures are local to a recent choice, not proof that the entire earlier structure was wrong. By separating valid context from tentative commitments, the system avoids both blind enumeration and destructive restart. It learns from dead ends without treating them as disasters.

canonical_formula: State S_k = extend(S_{k-1}, choice c_k). If constraints(S_k) pass, continue; if fail, record cause, undo c_k or the implicated suffix, preserve valid prefix S_j, and try next c in alternatives(S_j). Stop when complete(S_n), alternatives exhausted, or escalation rule fires.

structural_problem: A problem is being solved through a sequence of interdependent choices, but feasibility cannot be known from any single choice in isolation. Greedy commitment may trap the solver in a dead branch, exhaustive restart wastes valid work, and broad pruning may be unsafe because the exact reason a branch fails is discovered only after partial construction.

trigger_conditions: The candidate solution can be represented as a sequence, tree, partial assignment, path, plan, or hypothesis chain.

trigger_conditions: Constraints, dependencies, evidence, or compatibility rules can invalidate a partial path before a full solution is reached.

trigger_conditions: Earlier choices may remain valid even when the newest extension fails.

trigger_conditions: The search space is too large for blind enumeration but not structured enough for one-shot optimization.

trigger_conditions: Greedy local choice is tempting but cannot guarantee feasibility or adequacy.

trigger_conditions: Rollback is cheaper, safer, or more informative than restarting the entire process.

trigger_conditions: The domain needs an auditable record of which branches were tried and why they failed.

symptoms: Teams repeatedly restart from scratch after every failed path instead of preserving verified work.

symptoms: A process commits early to a path and only discovers a hard constraint after many dependent choices accumulate.

symptoms: The same invalid branch is retried because failure reasons were not recorded.

symptoms: A solver, team, or workflow treats all constraints as final gates rather than testing them during construction.

symptoms: People debate whether to prune options broadly when the real need is to undo the latest incompatible commitment.

symptoms: A design or diagnosis becomes brittle because downstream contradictions cannot be traced to the responsible choice.

symptoms: Search effort oscillates between chaotic trial-and-error and overly rigid irreversible commitment.

root_tension: The archetype manages the tension between exploration and commitment. Effective progress requires making tentative choices, but those choices must remain reversible until enough constraints have been satisfied. Too little commitment prevents construction; too much commitment creates lock-in, rework, or false completion.

anti_signatures: The problem is mainly broad candidate filtering where rejected regions need not be built as partial solutions; use search_space_pruning instead.

anti_signatures: Objective bounds or dominance proofs are the central exclusion logic; use bounded_search_pruning or branch-and-bound mechanisms instead.

anti_signatures: The central problem is saving and restoring a known-good operational state after risky change; use checkpoint_and_rollback instead.

anti_signatures: The process is a linear readiness pipeline with explicit go/no-go gates; use stage_gate_progression instead.

anti_signatures: The task is to formulate constraints or propagate implications before solving, not to manage a reversible search path; use constraint_formulation or constraint_propagation_and_decoupling.

anti_signatures: A greedy algorithm is valid because local choices have the required global optimality property; do not add rollback ceremony unnecessarily.

anti_signatures: Rollback would violate safety, rights, consent, evidence integrity, or irreversible material constraints; use irreversible_commitment_management or human review first.

structural_intervention: Turn the problem into a reversible partial-solution search: define the state and constraints, make each new commitment explicit and undoable, test feasibility after each extension, preserve the valid prefix on failure, record the rejected branch, and choose the next alternative under a branch-ordering policy.

action_logic: Define the representation of a partial solution, including what counts as a commitment and what remains undecided.

action_logic: List hard constraints, soft constraints, evidence tests, dependency checks, and completion criteria before search begins.

action_logic: Choose an extension operator and branch-ordering policy for selecting the next candidate commitment.

action_logic: Apply one extension to the current partial state and immediately test the newly exposed constraints.

action_logic: If the partial state remains feasible, continue extending; if it fails, record the conflict and abandon that branch.

action_logic: Roll back the newest implicated commitment while preserving the valid prefix and the evidence or work that should survive.

action_logic: Try the next branch, optionally using forward checking, constraint propagation, heuristics, or human review to reduce wasted search.

action_logic: Stop when a complete valid solution is found, all branches are exhausted, resource limits are reached, or a stronger method is required.

decision_rules: Roll back only as far as the conflict explanation requires; default to the newest reversible commitment, but backjump deeper when the failure implicates an earlier dependency.

decision_rules: Treat a branch as closed only when a stated constraint, evidence contradiction, or compatibility rule proves it cannot complete under current assumptions.

decision_rules: Do not discard a valid prefix merely because a suffix failed; preserve verified state, evidence, and choices whose constraints still hold.

decision_rules: Prefer branch ordering that exposes high-risk or highly constraining choices early when the cost of late failure is high.

decision_rules: Escalate to bounded_search_pruning when objective bounds, incumbent quality, or dominance proofs drive exclusion more than constraint failure.

decision_rules: Reopen or revalidate a closed branch if constraints, evidence, requirements, or assumptions materially change.

decision_rules: Use human review when rollback affects rights, consent, safety, accountability, or expensive irreversible commitments.

target_invariants: Soundness: accepted completions satisfy the declared constraints.

target_invariants: Prefix preservation: valid earlier work is retained unless explicitly implicated by the failure.

target_invariants: Reversibility: tentative commitments remain undoable until they pass the relevant commitment boundary.

target_invariants: Traceability: rejected branches have recorded reasons so failures inform future search.

target_invariants: Completeness awareness: the search distinguishes exhausted alternatives from merely untried alternatives.

target_invariants: State consistency: rollback returns the partial state to a coherent and inspectable condition.

target_invariants: Safety and fairness constraints are not treated as optional search heuristics.

expected_outcomes: Less wasted work than restart-after-failure approaches.

expected_outcomes: Fewer invalid completions because infeasibility is detected earlier.

expected_outcomes: Better exploration than greedy commitment when local choices can fail globally.

expected_outcomes: A clearer audit trail of attempted paths, constraints, and rejection reasons.

expected_outcomes: More reliable handling of combinatorial, diagnostic, and design problems with interdependent commitments.

expected_outcomes: Reduced lock-in because tentative choices remain reversible until justified.

short_definition: Applies recursive backtracking to assign values in a constraint-satisfaction problem while undoing infeasible assignments.

distinctive_feature: The partial solution is usually a variable assignment and feasibility is governed by an explicit constraint set.

distinct_from_parent: Narrower than the parent because it uses formal constraint-satisfaction machinery and often a recursive implementation.

still_same_parent_because: It uses the same partial-state, extension, constraint-check, rollback, and alternative-branch logic.

source_primes: backtracking constraint recursion

use_when: A problem can be represented as variables, candidate values, and constraints.

use_when: Constraint violations can be detected before a full solution is complete.

use_when: A depth-first or recursive search structure is acceptable for the evaluation budget.

example: Assigning values in a Sudoku solver and undoing a placement when a row, column, or box constraint fails.

domain: operations

example: Constructing a shift roster one assignment at a time and reversing the last assignment when a labor rule is violated.

failure_modes: The constraint set is incomplete, so the search spends time on branches that only fail late.

Diagnostic Hypothesis Backtracking

short_definition: Explores an explanatory path or hypothesis tree, then retracts the latest assumption when evidence contradicts it.

distinctive_feature: The rollback target is an assumption, hypothesis, or investigative branch rather than a formal variable assignment.

distinct_from_parent: Narrower than the parent because its constraints are evidentiary and explanatory rather than purely formal.

still_same_parent_because: It retains the same reversible commitment stack and contradiction-triggered rollback structure.

use_when: A diagnosis depends on a sequence of assumptions, tests, or investigative moves.

use_when: New evidence can falsify the most recent explanatory branch while preserving earlier observations.

use_when: The team needs a trace of tried paths to avoid cycling or confirmation bias.

domain: software debugging

example: Testing an input-parsing hypothesis, rejecting it after a counterexample, and returning to the last verified fault branch.

domain: incident response

example: Retracting a suspected root-cause path when timeline evidence proves it impossible.

failure_modes: The team rolls back only surface assumptions while retaining an invalid early framing.

Design Commitment Backtracking

short_definition: Builds a design or plan through reversible commitments, undoing the latest incompatible choice while preserving earlier compatible structure.

distinctive_feature: The search object is a practical design or plan whose commitments create dependency and rework risk.

distinct_from_parent: Narrower than the parent because it emphasizes human and organizational commitment management.

still_same_parent_because: It still uses reversible partial construction, constraint detection, and last-commitment rollback.

use_when: A design, plan, or architecture accumulates interdependent commitments.

use_when: Some commitments are reversible and can be undone before wider lock-in.

use_when: Compatibility constraints are discovered during construction rather than known entirely in advance.

domain: software architecture

example: Trying an integration approach, finding an incompatible dependency, and reversing that choice without discarding the validated module boundary.

domain: policy design

example: Backing out the most recent eligibility rule when it violates a statutory constraint while retaining earlier scope choices.

failure_modes: A nominally reversible commitment becomes socially or technically locked in before the incompatibility is tested.

Interactive Workflow Backtracking

short_definition: Allows a person or team to step back through a structured workflow when a downstream constraint reveals an earlier local choice was invalid.

distinctive_feature: The rollback surface is an interface, form, checklist, or collaborative workflow rather than a hidden algorithm.

distinct_from_parent: Narrower than the parent because human usability, state visibility, and undo semantics are central.

still_same_parent_because: It preserves the same stepwise partial-state and constraint-triggered reversal logic.

source_primes: backtracking sequencing feedback

use_when: A workflow has ordered steps with dependencies among choices.

use_when: Downstream evidence reveals that a recent step must be revised.

use_when: Users need to preserve valid earlier context rather than restart the entire process.

domain: case management

example: Returning to the most recent intake choice when an eligibility screen fails, while keeping verified identity and document information.

failure_modes: Back navigation corrupts hidden state or conceals which downstream constraints changed.

near_names:
Backtracking Search
Recursive Backtracking
Depth-First Backtracking
Trial-and-Error with Rollback
Constraint-Guided Rollback Search
Chronological Backtracking


Constraint-Guided Improvisation

batch: Batch 06

slug: improvisation

slug: constraint

slug: sensemaking

slug: composition

slug: compositionality

slug: coordination

slug: polyphony

slug: performativity

slug: kairos

slug: discretion

slug: observability

slug: controllability

essence_one_line: Generate competent next moves in real time by recombining an internalized repertoire inside stable constraints and continually updating from the developing situation.

compression_statement: Declare intent and non-negotiable constraints; grant calibrated discretion only where competence, authority, reversibility, and observability support it; cultivate a repertoire and combination grammar; maintain a live situation model; choose the smallest coherent move that can yield useful feedback; make consequential moves legible to collaborators; update the next move from observed effects; and pause, reset, hand off, or escalate when constraints, coherence, or authority fail. Treat successful improvisations as provisional evidence until a learning gate determines whether they should be rehearsed, standardized, or discarded.

core_intuition: A script cannot enumerate every developing state, but freedom without preparation or bounds is merely uncontrolled variation. Reliable improvisation is prepared freedom: stable purpose and limits make local novelty safer, a practiced vocabulary makes it competent, and fast feedback plus recoverability lets the response remain fitted to what is actually happening.

canonical_formula:
Given intent I, guardrails G, authority-and-competence envelope A, repertoire R,
combination grammar Γ, live situation x_t, and commitment history H_t:

M_t = generate(R, Γ, x_t, H_t)
Choose a_t ∈ M_t such that:
  a_t ∈ G ∩ A
  coherent(a_t, H_t, I)
  observable(a_t)
  recoverable(a_t) or explicitly authorized(a_t)
  fit(a_t, x_t) is sufficient for the current risk tier.

Act; observe y_t; update x_(t+1) and H_(t+1).
If G, A, coherence, or observability fails, pause, stabilize, reset, hand off, or escalate.
Promote a provisional move to standard practice only after review of context, outcomes, and transfer limits.

structural_problem: A changing situation requires action before a complete plan can be written or centrally approved. Existing scripts cover only part of the state space, information is distributed or delayed, and competent local adaptation is necessary. Yet unconstrained deviation can create safety violations, coordination collisions, incoherence, inequity, authority creep, and unreviewed precedent.

trigger_conditions: The environment changes faster than a detailed script can be updated.

trigger_conditions: The relevant state cannot be fully predicted or observed in advance.

trigger_conditions: Actors possess practiced tacit or explicit repertoire that can be recombined.

trigger_conditions: Delay, repeated escalation, or rigid script adherence has meaningful cost.

trigger_conditions: A stable purpose, constraint backbone, and stop or handoff path can be stated.

trigger_conditions: Feedback from local moves arrives soon enough to inform subsequent action.

symptoms: Teams either freeze when the playbook ends or make opaque exceptions with no common bounds.

symptoms: Experienced actors adapt successfully, but only through personal heroics that cannot be explained, taught, or audited.

symptoms: Central approval becomes a bottleneck while local actors hold the most current information.

symptoms: Parallel responders make individually sensible moves that conflict at system level.

symptoms: Temporary workarounds become permanent standards because success is confused with general validity.

symptoms: Plans accumulate exceptions until nobody knows which constraints remain non-negotiable.

root_tension: Responsiveness requires local novelty and discretion; reliability requires limits, coordination, accountability, and continuity. Too little latitude produces brittleness and delay, while too much latitude produces drift, collision, and unbounded risk.

anti_signatures: The task is stable, repetitive, and fully specifiable, so a tested standard procedure is safer and cheaper.

anti_signatures: The actor lacks the minimum competence or information needed to detect consequences.

anti_signatures: Feedback is too delayed, noisy, or irreversible to support incremental adjustment.

anti_signatures: The situation involves a non-delegable decision or a hard legal, ethical, consent, or safety prohibition.

anti_signatures: The organization is using improvisation language to excuse chronic understaffing, absent planning, or missing safeguards.

anti_signatures: A purely exploratory ideation session is occurring without consequential real-time execution.

structural_intervention: Replace the impossible demand for a complete script with a governed generative system: stable intent and constraints, prepared repertoire and grammar, calibrated discretion, live sensing, small coherent moves, explicit cueing, rapid feedback, and reliable reset, handoff, escalation, and learning paths.

action_logic: State the central intent and the outcomes or values that must remain legible through changing tactics.

action_logic: Separate fixed constraints from variable dimensions; identify rights, safety, consent, legal, data-integrity, timing, resource, and interface limits.

action_logic: Define entry conditions, competence thresholds, decision rights, risk tiers, and escalation boundaries.

action_logic: Build and rehearse a diverse response repertoire together with the grammar for combining, sequencing, and stopping moves.

action_logic: Establish a live situation model and specify which signals, uncertainties, and recent commitments must be visible.

action_logic: Generate multiple plausible next moves rather than treating the first available action as necessary.

action_logic: Prefer the smallest informative, coherent, and recoverable move compatible with urgency and consequence.

action_logic: Announce consequential moves, intent, dependencies, and requested support; require acknowledgment where coordination matters.

action_logic: Observe direct, delayed, distributional, and weak feedback; update the situation model and next-move set.

action_logic: Maintain a coherence thread across the developing sequence, and explicitly reset when local moves no longer form a viable whole.

action_logic: Pause, stabilize, hand off, or escalate when authority, competence, guardrails, feedback, or recovery capacity is exceeded.

action_logic: After action, separate luck from learning; retain context and evidence, then rehearse, standardize, constrain, or reject provisional moves through a review gate.

decision_rules: Use improvisation only when the situation is materially under-specified and the cost of waiting for a complete plan exceeds the controlled adaptation risk.

decision_rules: Latitude increases with demonstrated competence, signal quality, reversibility, observability, and recoverability, and decreases with consequence, uncertainty, irreversibility, and rights impact.

decision_rules: No local success overrides a hard constraint or creates authority by precedent.

decision_rules: Choose smaller moves when feedback is weak; larger or irreversible moves require stronger evidence and explicit authorization.

decision_rules: A move that is locally effective but breaks sequence coherence, shared intent, or another actor’s safe operating envelope is not competent improvisation.

decision_rules: Silence is not acknowledgment for consequential ensemble moves.

decision_rules: Repeated recurrence of the same improvisation is evidence that planning, staffing, interfaces, or standard work may need redesign.

decision_rules: A provisional move is not generalized until review identifies the conditions under which it worked and the conditions under which it would fail.

target_invariants: Central purpose remains recognizable while tactics vary.

target_invariants: Non-negotiable rights, safety, legal, consent, and data-integrity constraints remain intact.

target_invariants: Actors remain inside demonstrated competence and delegated authority.

target_invariants: Consequential action remains observable, attributable, and contestable.

target_invariants: The developing sequence remains coherent enough for collaborators and successors to continue.

target_invariants: Affected people retain voice, appeal, and stop paths appropriate to consequence.

target_invariants: Temporary success does not silently become permanent policy.

target_invariants: A safe pause, stabilization, handoff, or escalation path remains available.

expected_outcomes: Faster competent response to unanticipated conditions.

expected_outcomes: Lower dependence on brittle scripts and central approval bottlenecks.

expected_outcomes: Greater local initiative without loss of coordination or accountability.

expected_outcomes: Earlier detection of mismatch through small feedback-seeking moves.

expected_outcomes: More resilient teams with teachable repertoires rather than hero-only expertise.

expected_outcomes: Clearer separation between bounded adaptation and unauthorized deviation.

expected_outcomes: Improved organizational learning from provisional moves without normalizing unsafe workarounds.

Solo Expert Improvisation

short_definition: A competent individual generates and tests situated moves inside a clear authority and safety envelope.

distinctive_feature: The main control problem is calibrated discretion rather than multi-actor synchronization.

distinct_from_parent: It narrows the parent to one principal improviser and places greater weight on competence verification, observability, and escalation.

still_same_parent_because: It retains prepared repertoire, constraint-guided generation, live feedback, coherent sequencing, and a stop or handoff path.

use_when: One actor has concentrated situational access and relevant tacit skill.

use_when: Coordination overhead would exceed the value of continuous group consultation.

example: A technician uses approved parts and diagnostic principles to create a reversible workaround, then hands off when the fault crosses the authorization envelope.

failure_modes: Hero dependency hides missing staffing or preparation.

failure_modes: Tacit judgment becomes unchallengeable because observers cannot reconstruct the choice.

Ensemble Improvisation

short_definition: Multiple actors co-generate a coherent response through cueing, listening, reciprocal adjustment, and distributed initiative.

distinctive_feature: Coherence emerges through mutual cue uptake and role-sensitive contribution rather than a single controller.

distinct_from_parent: It makes interaction timing, legibility, contribution balance, and collision management central.

still_same_parent_because: The ensemble still generates competent real-time moves from repertoire within a shared constraint backbone.

source_primes: improvisation coordination polyphony turn_taking

use_when: No single actor has enough information or capability to script the response.

use_when: The work benefits from simultaneous differentiated contributions.

example: Specialists make bounded parallel interventions, announce consequential moves, and reset together when the shared situation model diverges.

failure_modes: Unacknowledged moves collide or duplicate effort.

failure_modes: High-status contributors crowd out weak signals and local knowledge.

Bounded Operational Improvisation

short_definition: Real-time adaptation in safety-, rights-, or mission-critical work where discretion is tiered by consequence and reversibility.

distinctive_feature: Risk-tiered authority, explicit stop conditions, and rapid stabilization dominate the design.

distinct_from_parent: It strengthens the parent guardrails and evidence burden for consequential or irreversible moves.

still_same_parent_because: The response remains repertoire-based, generative, feedback-driven, and situated rather than a fixed contingency script.

source_primes: improvisation constraint discretion uncertainty

use_when: The situation cannot be fully scripted but action delay has material cost.

use_when: Some moves are locally reversible while others require formal authorization.

domain: cybersecurity

example: Responders may isolate a limited segment and increase observation locally, but destructive remediation or broad shutdown requires escalation.

failure_modes: Emergency language silently expands authority.

failure_modes: A successful workaround is normalized without evidence or control review.

near_names:
Improvisation
Disciplined Improvisation
Bounded Improvisation
Repertoire-Guided Improvisation
Structured Improvisation
Adaptive Execution


Constraint Propagation and Decoupling

batch: Second Iteration/Pilot

aliases:
constraint-based decomposition
constraint propagation
decoupled problem solving
propagation-driven problem partitioning
solution-space reduction by constraints
gauge constraint reduction

source_primes: decomposition gauge_invariance_gauge_symmetry constraint propagation

Decomposition

slug: decomposition

role: Provides the target act of splitting a coupled problem into subproblems after the constraint structure has been made explicit.

Gauge Invariance / Gauge Symmetry

role: Highlights redundant representational degrees of freedom and invariant relations that can be exploited to reduce the problem without changing observables.

Constraint

role: Names the restrictions, bounds, exclusions, equations, dependency conditions, or feasibility requirements whose implications are propagated.

Propagation

slug: propagation

role: Names the movement of implications from one part of the network to other affected variables, tasks, resources, or subsystems.

Coupling

slug: coupling

Modularity

slug: modularity

name: Modularity and Compositional Independence

name: Modularity and Hierarchical Decomposability

Boundary

slug: boundary

Invariance

slug: invariance

Symmetry

slug: symmetry

Optimization

slug: optimization

Relation

slug: relation

Network

slug: network

Flow

slug: flow

Feedback

slug: feedback

Causality

slug: causality

Boundedness

slug: boundedness

Approximation

slug: approximation

Algorithm

slug: algorithm

Decision

slug: decision

Complexity

slug: complexity

Synchronization

slug: synchronization

components:
Constraint Network Model
Invariant and Gauge Basis
Propagation Rule Set
Derived Implication Register
Coupling Boundary Map
Decoupled Subproblem Partition
Consistency and Recomposition Check
Propagation Stop Condition
Slack or Tolerance Budget
Conflict Explanation Record

mechanisms:
Constraint Dependency Matrix
Domain Reduction Pass
Gauge-Fixing Choice
Cut-Set or Separator Analysis
Constraint-Satisfaction Solver Pass
Backward Deadline Pass
Recomposition Consistency Test

essence_one_line: When constraints bind a problem into an unwieldy whole, propagate their implications first, then solve only the reduced and justified subproblems that remain.

compression_statement: Constraint Propagation and Decoupling turns a tangled system into a tractable one by representing constraints as a network, deriving their downstream and upstream implications, eliminating infeasible or redundant degrees of freedom, locating residual coupling boundaries, solving separated subproblems, and verifying that local solutions recombine without violating the original global constraints.

core_intuition: A hard problem is often hard because everything appears connected to everything else. Some connections are genuine. Others are artifacts of incomplete reasoning, redundant parameterization, or unpropagated constraints. Once implications are pushed through the network, parts of the problem become fixed, impossible, equivalent, bounded, or independent. The safe move is not to split first and hope. It is to let the constraints reveal where splitting is legitimate.

canonical_formula: constraint network + implication propagation + redundancy/infeasibility pruning + decoupling boundary + recomposition check -> tractable subproblems with preserved invariants

structural_problem: A system, model, schedule, design space, supply network, or rule set is treated as one coupled problem because constraints have not been propagated. Teams or solvers either attempt the whole problem at once, split it prematurely, or repeatedly rediscover conflicts. The result is excess complexity, hidden infeasibility, duplicated work, and local solutions that fail when recombined.

trigger_conditions: Multiple constraints bind variables, resources, actors, tasks, decisions, states, or subsystems together.

trigger_conditions: A final condition, invariant, deadline, conservation rule, compatibility rule, or capacity limit has implications for many upstream or downstream choices.

trigger_conditions: The apparent degrees of freedom include redundant representational choices, equivalent parameterizations, or choices that do not affect invariant outcomes.

trigger_conditions: Different teams or solvers need to work locally, but no one can justify which boundaries are safely independent.

trigger_conditions: Constraint violations appear late, after local subproblem solutions have already been produced.

trigger_conditions: The system contains cycles, shared resources, compatibility exclusions, or boundary conditions that make naive decomposition unsafe.

symptoms: Large solution spaces with many options that are actually infeasible once constraints are applied.

symptoms: Repeated late-stage conflicts between locally reasonable plans, configurations, schedules, or subsystem designs.

symptoms: Redundant variables, parameters, or representation choices consume effort without changing observable outcomes.

symptoms: Teams disagree about whether a problem can be split because dependencies and residual couplings are implicit.

symptoms: A solver or planning process gets slow because it searches regions that simple implication propagation would eliminate.

symptoms: Subproblem outputs cannot be recombined without violating original constraints, deadlines, budgets, conservation laws, or interface commitments.

root_tension: Global constraints must be respected, but global solving may be too complex. Local solving is efficient, but local independence is only safe after constraint implications and residual couplings are made explicit.

anti_signatures: The problem only needs initial constraint formulation; implications do not need to be propagated across a network.

anti_signatures: The system can already be decomposed by stable responsibilities, interfaces, or modules without constraint-derived reduction.

anti_signatures: The main issue is choosing between a heuristic and an algorithm, not reducing a constraint-coupled problem.

anti_signatures: The relation constraints only need enforcement or validation, not solution-space pruning and recomposition.

anti_signatures: All relevant constraints are soft preferences and no feasibility, invariance, compatibility, or boundary condition is at stake.

anti_signatures: The intended split is political or organizational convenience rather than a justified decoupling boundary.

structural_intervention: Represent the problem as a constraint network; propagate implications until fixed points, contradictions, or sufficient bounds appear; remove infeasible or redundant possibilities; identify residual coupling boundaries; solve the resulting subproblems under explicit interface conditions; and check recomposition against the original constraints and invariants.

action_logic: Define the variables, states, tasks, resources, actors, options, or subsystems that constitute the problem space.

action_logic: Inventory hard constraints, soft constraints, invariants, boundary conditions, compatibility rules, deadlines, capacities, and gauge or symmetry freedoms.

action_logic: Build a constraint network showing which constraints affect which nodes, links, flows, or states.

action_logic: Propagate implications forward, backward, and laterally to derive fixed values, narrowed ranges, required resources, excluded options, latest-start windows, or infeasible combinations.

action_logic: Record contradictions and decide whether they indicate a true impossibility, an incorrect constraint, a relaxable soft constraint, or a missing boundary condition.

action_logic: Eliminate redundant degrees of freedom by choosing a gauge, normal form, equivalence-class representative, baseline, or reference frame when invariant outcomes permit it.

action_logic: Locate cut sets, separators, weak interfaces, and residual couplings that define where independent or weakly coupled subproblems can be solved.

action_logic: Assign each subproblem local inputs, boundary conditions, outputs, and interface commitments.

action_logic: Solve or review subproblems locally while preserving the propagated constraints and residual interface terms.

action_logic: Recompose local outputs and verify that global constraints, invariants, deadlines, compatibility rules, and resource limits still hold.

decision_rules: Do not split the problem until the decoupling boundary is justified by propagated constraints or visible residual coupling limits.

decision_rules: Treat hard constraints and invariants as non-negotiable unless a governance process explicitly reclassifies them.

decision_rules: Use gauge fixing or normalization only when it changes representation, not the invariant outcome being protected.

decision_rules: Allow approximate decoupling only when the residual coupling is bounded, monitored, and included in recomposition checks.

decision_rules: If propagation produces contradiction, explain the minimal conflicting constraint set before relaxing or deleting constraints.

decision_rules: Re-run propagation after major assumption, capacity, deadline, or boundary changes.

decision_rules: Escalate when different subproblems require incompatible boundary conditions or shared resources.

target_invariants: Original hard constraints remain satisfied unless explicitly revised.

target_invariants: Gauge-invariant or representation-independent observables are preserved.

target_invariants: No hidden cross-boundary dependency is ignored after partitioning.

target_invariants: Local solutions remain compatible at interfaces and shared resources.

target_invariants: Constraint relaxations, approximations, and gauge choices are visible and reversible where possible.

target_invariants: The reduced problem remains equivalent to the original problem for the intended decision or observable.

expected_outcomes: Smaller feasible solution space and faster search or review.

expected_outcomes: Earlier discovery of infeasible combinations, overconstraint, or resource conflicts.

expected_outcomes: Better justified decomposition into local subproblems.

expected_outcomes: Less duplicate work on equivalent or redundant possibilities.

expected_outcomes: Clearer boundary conditions and interface commitments among teams or solvers.

expected_outcomes: Higher confidence that local solutions will recombine into a globally feasible result.

prose_essence:
Constraint Propagation and Decoupling makes a tangled problem tractable by letting constraints reveal structure. Instead of splitting the problem first and hoping the pieces fit later, the archetype begins with a constraint network, derives the consequences of each constraint, removes impossible or redundant possibilities, and then identifies which remaining subproblems can be solved independently or with explicit boundary conditions.

The central intuition is that apparent coupling is often a mixture of real dependency, unpropagated implication, representational redundancy, and hidden boundary conditions. Once the implications are made visible, some choices become fixed, some become impossible, some become equivalent, and some can be separated.

prose_when_to_use:
Use this archetype when a problem is too coupled or combinatorial to solve as a whole, but naive decomposition would be unsafe. It is especially useful when deadlines, capacities, compatibility rules, physical equations, legal constraints, conservation rules, invariants, or gauge freedoms shape many local choices.

It is a poor fit when the only task is to list constraints, when stable modular boundaries already exist, or when constraints are too ambiguous to propagate responsibly.

prose_structural_problem:
A coupled system is being solved at the wrong level of entanglement. Constraints exist, but their implications have not been pushed through the system. As a result, people or solvers search infeasible regions, work on redundant options, split problems at unjustified boundaries, or discover global contradictions only after local solutions have been produced.

The recurring tension is that global constraints matter, but global solving may be intractable. Local solving is efficient, but only safe when independence has been earned by propagation and recomposition checks.

prose_intervention_logic:
First, represent the system as a constraint network: variables, tasks, resources, states, actors, options, or subsystems connected by constraints. Then classify constraints as hard, soft, invariant, relaxable, temporal, resource-based, compatibility-based, or representational.

Next, propagate implications. A deadline may imply latest-start windows. A capacity limit may imply inventory buffers. A compatibility rule may eliminate configurations. A conservation law may narrow feasible flows. A gauge freedom may allow redundant representational choices to be fixed without changing observables.

After propagation, mark what is fixed, impossible, bounded, equivalent, or still coupled. Only then create decoupled subproblems. Each subproblem receives explicit boundary conditions, inputs, outputs, and residual interface commitments. Finally, recombine local solutions and test them against the original constraints and invariants.

prose_key_components:
**Constraint Network Model** represents the variables, tasks, resources, states, or subsystems and the constraints linking them.

**Invariant and Gauge Basis** identifies what must remain unchanged under reduction, normalization, or gauge fixing.

**Propagation Rule Set** defines how constraints generate derived implications, such as bounds, exclusions, requirements, or time windows.

**Derived Implication Register** records every derived bound, exclusion, fixed value, contradiction, or assumption so that pruning is auditable.

**Coupling Boundary Map** distinguishes genuine coupling from redundant or bounded coupling and marks where a problem can be split.

**Decoupled Subproblem Partition** defines the local problems that remain after reduction, including their boundary conditions and interface commitments.

**Consistency and Recomposition Check** verifies that local solutions still satisfy original global constraints when combined.

prose_common_mechanisms:
A **constraint dependency matrix** makes propagation paths visible. A **domain reduction pass** narrows feasible values or choices. A **gauge-fixing choice** removes redundant representational freedom while preserving invariant observables. A **cut-set or separator analysis** identifies candidate boundaries for subproblem partitioning. A **constraint-satisfaction solver pass** can automate propagation and conflict detection. A **backward deadline pass** derives local schedule windows from final milestones. A **recomposition consistency test** verifies that local results still fit together.

These mechanisms are not the archetype by themselves. The archetype is the full structural pattern: propagation, reduction, justified decoupling, local solving, and recomposition validation.

prose_failure_modes: The most common failure is premature decoupling: splitting before constraint implications have been fully traced. Another is hidden global violation, where local results appear valid but fail after recomposition. Other failures include treating soft preferences as hard constraints, opaque solver propagation, faulty gauge choices, approximation drift, and local optimization that undermines global feasibility.

prose_neighbor_distinctions: `constraint_formulation` names the constraints; this archetype propagates them and uses the implications to reduce and partition the problem. `modular_decomposition` creates modules; this archetype justifies decoupling by constraint reasoning. `coupling_calibration` tunes coupling; this archetype derives which couplings remain real after propagation. `bounded_search_pruning` removes branches from a search tree; this archetype also eliminates redundant degrees of freedom and creates recomposable subproblems. `relation_constraint_enforcement` validates integrity; this archetype uses constraints to transform how the problem is solved.

prose_cross_domain_examples:
In electrical-grid stability, voltage and line-capacity constraints are propagated through a power-flow model before regions are analyzed as weakly coupled subproblems.

In project scheduling, a launch deadline is propagated backward through prerequisite tasks, revealing latest-start windows and independent workstreams.

In supply-chain planning, demand and service-level commitments are propagated upstream into inventory buffers, production lots, and transport capacity.

In software configuration, compatibility and exclusion rules prune invalid combinations and split independent option groups.

In policy eligibility, rule implications are propagated to expose contradictions and separate verification steps.

prose_non_examples: A department-based work breakdown is not this archetype unless boundaries are justified by constraint implications. A list of constraints is not enough. A black-box solver result is not enough unless propagation, partitioning, and recomposition are inspectable. A generic graph pruning exercise is not enough unless original constraints and invariants are preserved.

prose_tradeoffs: The main tradeoff is rigor versus speed. Explicit propagation and recomposition checks take time, but they prevent late-stage infeasibility. Another tradeoff is independence versus fidelity: decoupling enables parallel work, but over-decoupling can hide real coupling. Solver-based mechanisms can scale, but they may reduce transparency unless derived implications and conflict explanations are captured.

prose_invariants_to_preserve: The original hard constraints must remain satisfied unless explicitly revised. Gauge-invariant or representation-independent observables must not change when redundant degrees of freedom are fixed. Local subproblems must not ignore hidden shared resources, boundary conditions, or global invariants. Approximate decoupling must keep residual coupling bounded and visible.

prose_target_outcomes: A successful application produces a smaller feasible solution space, earlier conflict detection, defensible subproblem boundaries, fewer redundant choices, faster local solving, clearer interface commitments, and higher confidence that recomposed outputs remain globally feasible.

prose_parameter_dimensions:
Important tuning dimensions include constraint hardness, propagation direction, depth of propagation, exact versus approximate decoupling, residual coupling tolerance, gauge or normalization choice, solver transparency, recomposition frequency, and escalation thresholds for conflicts.

A strict setting favors safety and correctness but may slow progress. A loose setting enables faster local work but increases the risk of hidden global violations.

prose_variants_and_near_names:
Recognized variants include **Gauge Constraint Reduction**, **Deadline Constraint Back-Propagation**, **Demand Constraint Inventory Propagation**, and **Configuration Constraint Decoupling**. Near names include constraint propagation, constraint-based decomposition, decoupled problem solving, solution-space reduction by constraints, and gauge constraint reduction.

The next queue candidate, Contextual Selective Propagation, should remain distinct: this archetype propagates constraint implications inside a modeled problem network; contextual selective propagation should concern what effects, meanings, signals, or practices should and should not transfer across contexts.

Gauge Constraint Reduction

variant_type: subtype

short_definition: A mathematical or modeling variant that fixes redundant representational freedom so only invariant, physically or operationally meaningful degrees of freedom remain.

distinctive_feature: The main move is selecting a gauge, normalization, reference frame, or equivalence-class representative before solving the reduced problem.

distinct_from_parent: It is the symmetry/gauge-heavy version of the parent, often appearing in physics, control, optimization, simulation, and representation design.

still_same_parent_because: It still propagates constraints, reduces the solution space, and verifies that recomposed outputs preserve invariant observables.

source_primes: gauge_invariance_gauge_symmetry constraint invariance symmetry

use_when: Several parameterizations describe the same underlying state, outcome, or observable.

use_when: A constraint or symmetry relation can eliminate redundant variables without changing invariant predictions.

use_when: Solvers, reviewers, or implementers are wasting effort on representational choices that do not affect the target outcome.

example_domains:
physics modeling
control systems
optimization
data normalization
simulation

domain: physics modeling

example: A model fixes a redundant potential representation so the solver handles only fields that affect observed quantities.

domain: simulation

example: Equivalent coordinate choices are normalized before running separate numerical submodels.

failure_modes: gauge choice hides a meaningful boundary condition

failure_modes: solver mistakes representation-specific quantities for observables

failure_modes: residual coupling remains after reduction

Deadline Constraint Back-Propagation

short_definition: A project, logistics, or operations variant that propagates final deadlines backward through predecessor relationships to derive local latest-start, latest-finish, and slack constraints.

distinctive_feature: The propagation direction is usually backward from an external deadline or milestone through a task network.

distinct_from_parent: It narrows the parent to time and precedence constraints rather than any mathematical, resource, or structural constraint network.

still_same_parent_because: It still derives local implications, detects contradictions, partitions workstreams, and recombines them through milestone checks.

source_primes: constraint propagation decomposition synchronization

use_when: A final delivery, launch, or service deadline constrains many upstream tasks.

use_when: The dependency graph contains workstreams that can be separated after predecessor constraints and slack are made explicit.

use_when: Teams need local schedules that remain globally feasible.

example_domains:
project management
construction
product launch
event operations

domain: project scheduling

example: A launch date is propagated backward through design, procurement, testing, and release tasks to identify independent workstream windows.

failure_modes: hidden task dependency invalidates local slack

failure_modes: optimistic duration assumptions create false decoupling

failure_modes: deadline propagation ignores resource coupling

Demand Constraint Inventory Propagation

short_definition: A supply-chain variant that propagates demand, service-level, capacity, and inventory constraints upstream to derive feasible local inventory and production requirements.

distinctive_feature: The primary propagated implications are quantity, buffer, lead-time, and capacity requirements along a flow network.

distinct_from_parent: It is narrower than the parent because the constraint network is a material or service flow network.

still_same_parent_because: It uses the same reduction sequence: model constraints, propagate implications, find residual coupling, solve locally, and check recomposition.

source_primes: constraint propagation flow resource_management

use_when: Downstream demand or service-level commitments impose constraints on upstream inventory, production, or transport nodes.

use_when: Different product lanes, regions, or suppliers can be decoupled only after shared constraints are exposed.

use_when: The system must avoid local optimization that violates global demand or capacity feasibility.

example_domains:
supply chains
retail logistics
manufacturing planning
service operations

domain: supply chain

example: A customer service-level target is propagated upstream into inventory buffers, reorder windows, and capacity requirements for each supplier lane.

failure_modes: bullwhip amplification from over-propagated demand

failure_modes: failure to account for shared constrained resource

failure_modes: local lane independence assumed too early

Configuration Constraint Decoupling

short_definition: A software, product, or rules-engine variant that propagates compatibility constraints to reduce valid configurations and split independent option groups.

distinctive_feature: It turns local compatibility rules into a smaller set of valid option domains and independent choice clusters.

distinct_from_parent: It is a concrete configuration-space use case rather than the whole cross-domain archetype.

still_same_parent_because: It still applies constraint propagation, conflict detection, partitioning, and recomposition validation.

source_primes: constraint propagation modularity algorithm

use_when: Users, planners, or systems choose from many options with compatibility and exclusion rules.

use_when: Some option groups are independent after compatibility implications are propagated.

use_when: The configuration space is too large to enumerate naively.

example_domains:
software configuration
product configurators
policy eligibility engines
course scheduling

domain: product configuration

example: Selecting one engine option propagates emissions, battery, and package constraints so unrelated trim choices can be solved separately.

failure_modes: invalid independence clusters after rule changes

near_names:
Constraint Propagation
Decoupled Problem Solving
Constraint-Based Decomposition
Gauge Constraint Reduction
Dependency Constraint Propagation
Solution-Space Reduction by Constraints