Constraint Formulation¶
Turn implicit limits, requirements, and prohibitions into explicit constraints that shape the feasible solution space.
The Diagnostic Story¶
Symptom: Teams generate options, invest effort, and build toward a solution — then a requirement surfaces late that makes the chosen direction infeasible. The requirements list mixes mandatory limits with preferences, aspirations, and soft guidance, so no one knows which rules are actually binding. Exceptions are handled informally, creating inconsistency. The feasible option set is unknown, and optimization outputs look precise while resting on underspecified limits.
Pivot: Separate hard constraints from soft preferences before options are generated. Define the feasible set explicitly, rank constraint priority, and specify in advance how violations will be handled — so every downstream step operates inside a known and accountable boundary.
Resolution: Effort concentrates on genuinely feasible options, and late vetoes become rare because constraints were visible from the start. Conflicts and impossibilities surface early when they are still cheap to resolve. Exceptions require explicit approval against a named rule, replacing informal workarounds with governed discretion.
Reach for this when you hear…¶
[product management] “We spent two sprints on a feature and then legal told us it violated a data-residency rule they'd mentioned in a kick-off slide nobody flagged as binding.”
[infrastructure procurement] “The RFP listed sixty requirements and we had no idea which ones were dealbreakers until vendors started asking — we should have tiered them before we published.”
[conservation planning] “We optimized the reserve design for biodiversity and then found out three of our best candidate sites are legally off-limits — the feasibility layer has to come first.”
When This Archetype Applies¶
No catalog groundingNone of the structural conditions is currently represented by an accepted prime or domain-specific abstraction.
Diagnostic problem
Actors generate or choose options without clearly knowing which limits, requirements, or prohibitions define feasibility.
What this problem means
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.
Show the applicability expression
Applicability expression5 distinct conditions
groundedpartly groundedopen
5 conditions, all required.
5Required in every casenumbered 1–5
These hold no matter which pattern applies.
Premature option generation · open
Options are generated before feasibility conditions are explicit.
The source archetype describes the situation as follows: Options are being generated before feasibility conditions are explicit. The normalized requirement above isolates the load-bearing portion used in this condition set.
Mandatory-preference disagreement · open
Stakeholders disagree which requirements are mandatory and which are preferences.
The source archetype describes the situation as follows: Stakeholders disagree about what is mandatory versus merely preferred. The normalized requirement above isolates the load-bearing portion used in this condition set.
Informal hard limits · open
Legal, safety, compatibility, or resource limits are mentioned only informally.
The source archetype describes the situation as follows: Legal, safety, compatibility, or resource limits are mentioned informally. The normalized requirement above isolates the load-bearing portion used in this condition set.
Unbounded choice space · open
The unconstrained search space is too broad or unbounded for practical choice.
The source archetype describes the situation as follows: The search space is too broad or unbounded for practical decision-making. The normalized requirement above isolates the load-bearing portion used in this condition set.
Likely feasibility violations · open
Exceptions or violations of the eventual feasibility rules are likely.
The source archetype describes the situation as follows: Exceptions or violations are likely. The normalized requirement above isolates the load-bearing portion used in this condition set.
Other requirements and context (1)
Why these sit outside the expression
Goal — a goal states an intended outcome or evaluation criterion, not a pre-existing situation that independently summons the archetype.
GoalA solver, workflow, policy, or review process needs a formal feasible set.
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. In this archetype, the relevant goal is: A solver, workflow, policy, or review process needs a formal feasible set. It supplies a criterion for evaluating what the intervention should accomplish or preserve.
Coverage
0 of 5 conditions grounded · 5 open.
Mechanisms / Implementations¶
- Requirements Constraint Specification: Turns stakeholder needs, product requirements, or project rules into explicit must-satisfy and prefer-to-satisfy conditions.
- Design Constraint Document: Records physical, usability, interoperability, environmental, manufacturing, or maintenance limits that shape design choices.
- Policy Rule Set: Expresses policy limits, permissions, conditions, and prohibitions so actors can determine admissible action.
- Optimization Constraint Model: Represents variables and constraints in a mathematical or computational model so solvers or analysts can search the feasible region.
- Budget / Time Limit: Sets resource or schedule boundaries that exclude or penalize options exceeding available money, time, labor, or capacity.
- Safety Constraint: Defines conditions that must be met to prevent injury, catastrophic loss, operational hazard, or unacceptable exposure.
- Eligibility Rule: Specifies which people, cases, projects, records, or options are admitted into a program, process, queue, or decision space.
- Legal Compliance Constraint: Translates laws, regulations, contracts, or standards into actionable constraints on design, operation, or decision-making.
- Acceptance Criteria: Defines pass/fail or accept/reject conditions for a deliverable, case, design, or decision.
- Constraint Review Checklist: Prompts reviewers to check hard/soft classification, conflicts, scope, enforcement, exceptions, and stale assumptions.
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (3)
- Boundary: Defines system limits.
- Constraint: Limits possibilities to guide outcomes.
- Optimization: Finds best solution under constraints.
Also references 4 related abstractions
- Boundedness: Values remain within limits.
- Closure: Ensures operations remain within a set.
- Search and Retrieval: Locate and extract information.
- Trade-offs: Balancing competing priorities.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Hard-Constraint Formulation · subtype · recognized
A subtype that defines absolute admissibility conditions whose violation excludes an option or requires formal exception review.
Soft-Constraint Prioritization · subtype · recognized
A subtype that turns preferences, targets, penalties, and negotiable requirements into explicit ranking pressure rather than pass/fail exclusion.
Feasibility Envelope Definition · scale variant · candidate
A subtype that defines the overall envelope within which options remain feasible across scope, capacity, performance, or operating conditions.
Compliance Constraint Formulation · domain variant · recognized
A domain variant that translates legal, regulatory, contractual, ethical, or policy obligations into actionable constraints.
Editorial Notes¶
Problem Classification¶
Classification: Correctness, Conformance & Formal Validity Failure → Feasibility & Requirement Consistency
Problem kernel: option generation proceeds before feasibility constraints are known
Rationale: Actors cannot tell which choices satisfy limits, requirements, and prohibitions, so the declared decision space includes invalid states.
Independent corroboration: The earliest necessary condition in the frozen evidence is: Actors generate or choose options without clearly knowing which limits, requirements, or prohibitions define feasibility. That is a feasibility requirement and invariant consistency problem because Required constraints, guarantees, relations, or necessary conditions are absent, mutually incompatible, intrinsically impossible, or unenforceable together within the stated scope.
Review outcome: Independent reviewer agreement; high confidence.