One-sentence answer: Constraints work by removing impossible, unavailable, unsafe or unauthorised states from the space of possible actions, revealing which limits are currently binding, and forcing a system to find solutions that respect physics, resources, time, interfaces, rights, requirements and other non-negotiable boundaries.
Constraints are often described as obstacles. That is only half the story. A bridge load limit constrains use because matter has physical limits. A budget constrains spending because resources are finite. A deadline constrains timing. A safety rule constrains action to prevent unacceptable harm. An accessibility requirement constrains design so a system remains usable by intended receivers.
Remove every constraint and you do not get freedom. You often get an undefined problem.
Constraints shape the possible world. The key question is not “How do we remove limits?” but “Which limits are real, which are chosen, which are binding, and what happens to the receiver if we change them?”
Quick Read: the causal chain
GOAL → SYSTEM BOUNDARY → POSSIBLE STATES → CONSTRAINTS → FEASIBLE SET → BINDING LIMITS → TRADE-OFFS → CANDIDATE SOLUTION → VERIFICATION → RECEIVER EFFECT → CONSTRAINT RELAXATION / TIGHTENING → NEW BOTTLENECK → WORLD RETURN
1. Constraints define what counts as feasible
Imagine designing a school timetable. A mathematically imaginable timetable becomes infeasible if one teacher is assigned to two classrooms at the same time. The teacher’s simultaneous availability is a constraint.
In optimisation language, constraints define the feasible set: the candidate solutions allowed by the model.
A solution can therefore be:
- desirable but infeasible;
- feasible but poor;
- feasible and good under the chosen objective;
- apparently feasible only because a constraint was omitted.
This is why How Optimisation Works needs Constraints upstream: optimisation searches among solutions that remain admissible after limits are applied.
2. Constraints come from different kinds of reality
| Constraint family | Example |
|---|---|
| Physical | Mass, size, temperature, strength, geography |
| Resource | Money, staff, machines, energy, materials |
| Capacity | Maximum throughput, seats, storage, bandwidth |
| Temporal | Deadlines, opening windows, sequencing, expiry |
| Logical | One condition must precede or exclude another |
| Interface | Required format, dimensions, protocol or compatibility |
| Human | Physical capability, workload, attention, skill, reaction time |
| Safety | States that must not be entered |
| Legal / regulatory | Actions prohibited or required by legitimate authority |
| Ethical / rights-based | Protected values that may limit otherwise feasible actions |
| Environmental | Operating conditions or ecological limits |
| Information | Missing, uncertain or unavailable state needed for action |
NASA systems-engineering guidance explicitly treats cost, schedule, physical product conditions, use environment and human capabilities among design constraints. The key point is that different constraints have different owners and different degrees of changeability.
3. Real constraint ≠ preference ≠ assumption ≠ objective
| Constraint | A condition a feasible solution must respect, unless explicitly treated as relaxable. |
|---|---|
| Preference | A desirable property that may be traded off. |
| Assumption | A condition taken as true for the model or analysis. |
| Objective | The quantity or outcome being improved, minimised or maximised. |
| Requirement | A stated need or characteristic that a product/system must satisfy; some requirements function as constraints. |
Calling a preference a constraint can prematurely close the search space. Calling a real constraint a preference can produce unsafe or impossible solutions.
4. Hard and soft constraints make different promises
A hard constraint must be satisfied for the solution to be accepted under the model. A soft constraint may be violated at some penalty, cost or loss of quality.
For a timetable:
- “A teacher cannot teach two classes simultaneously” may be hard.
- “Avoid first-period lessons for this teacher where possible” may be soft.
But language depends on domain. In project scheduling, software “hard date constraints” can sometimes be artificial fixed dates that override logical dependencies. GAO warns that excessive imposed date constraints can make schedules unrealistic. So the label “hard” does not itself prove that a constraint is legitimate.
5. Binding and non-binding constraints are different
A system can have many constraints, but only some govern the current outcome.
A binding constraint is active at the current operating point: changing it can change the feasible solution or system outcome. A non-binding constraint exists but still has slack.
Imagine a hall limited by:
- 200 physical seats;
- 150 people allowed by a temporary safety rule;
- 120 tickets currently available.
If ticket inventory is 120, adding more physical seats does nothing to attendance. Seating capacity exists as a constraint, but it is not yet the binding one.
6. Bottleneck is a system effect of a binding constraint
A bottleneck is a limiting point that restricts flow or throughput. Bottlenecks often arise from constraints, but the terms are not identical.
A legal prohibition may constrain action without being a throughput bottleneck. A narrow machine station may be both a capacity constraint and the production bottleneck.
How Capacity Works owns the throughput side. Constraints owns the more general grammar of admissible versus inadmissible states.
7. Relaxing one constraint can move the bottleneck
Suppose a factory increases capacity at its slowest machine. Throughput rises—until packaging becomes the next bottleneck. Add packaging capacity and quality inspection may become limiting. Increase inspection speed and supplier availability may become limiting.
This creates a recurring system law:
IDENTIFY BINDING LIMIT → RELAX OR REDESIGN → OBSERVE SYSTEM RESPONSE → FIND NEW BINDING LIMIT → REPEAT
Improving a system is therefore rarely “remove the constraint once.” Constraint structure moves as the operating point changes.
8. Constraints can interact
Two individually harmless constraints can make a system infeasible together.
For example:
- a delivery must arrive by 5 pm;
- a road closes from 3–4 pm;
- the loading bay opens only after 4:30 pm;
- the route takes at least 45 minutes.
Each constraint is understandable alone. Together they may eliminate every feasible route.
When no feasible solution exists, the right response is not to force an answer. It is to identify the conflicting constraints, challenge assumptions or renegotiate the legitimate relaxable conditions.
9. Constraint infeasibility is valuable information
“No solution” can be a high-quality result. It tells us that the requested world cannot exist under the current declared conditions.
Useful systems should report:
- which constraints conflict;
- which are immutable;
- which are policy choices;
- which can be relaxed and by whom;
- what consequence follows from relaxation;
- which additional resource would restore feasibility.
A fabricated feasible answer is worse than a transparent infeasibility receipt.
10. Constraints can protect value
Not all constraints are performance losses. Some prevent the optimisation process from sacrificing something that should not be traded away.
- safety constraints prevent hazardous states;
- privacy constraints limit unnecessary data collection;
- accessibility constraints preserve use by intended receivers;
- fairness constraints can limit exclusionary allocations;
- budget constraints preserve financial sustainability;
- load constraints prevent structural failure.
A system that improves its headline objective by violating one of these may be “optimal” only because the objective was too narrow.
11. Constraints can also preserve bad systems
Some constraints are institutional choices rather than laws of nature. Legacy rules, outdated interfaces, procurement requirements, permissions, organisational boundaries or inherited technical decisions can remain long after their original justification disappears.
A strong constraint review therefore asks:
- Who created this constraint?
- Why?
- Is that reason still current?
- Who has authority to change it?
- Who benefits from it?
- Who bears its cost?
- What evidence would justify relaxation?
Constraint analysis is partly engineering and partly governance.
12. Changeability must be explicit
| Constraint state | Example response |
|---|---|
| Immutable for the task | Design around it. |
| Technically changeable | Evaluate cost, risk and side effects. |
| Policy-controlled | Route to legitimate authority. |
| Temporarily imposed | Track expiry and review trigger. |
| Assumed but unverified | Test whether the constraint actually exists. |
| Receiver-specific | Preserve it for that receiver even if others do not need it. |
This prevents an AI or optimiser from silently “solving” a problem by removing a constraint it had no authority to change.
13. Constraint relaxation has a value—and a cost
In mathematical optimisation, sensitivity analysis can estimate how the objective changes when a binding constraint is relaxed slightly. This is sometimes expressed through a dual or shadow value.
The concept is useful beyond the mathematics: if one extra hour, worker, unit of capacity or kilogram of allowable mass creates a large improvement, that constraint may be valuable to address.
But not every constraint can be priced. Legal rights, human safety and protected values may not be legitimate variables to trade for marginal performance.
14. Constraints have operating ranges and time
A constraint may bind only under certain conditions.
- a road capacity constraint binds during peak traffic;
- a cooling limit binds during high ambient temperature;
- a classroom capacity binds only for larger cohorts;
- a deadline becomes binding as remaining time shrinks;
- a human attention constraint becomes binding under excessive workload.
Constraint state is therefore dynamic. Systems should not permanently label yesterday’s bottleneck as today’s cause.
15. Hidden constraints are often discovered through failed transfer
A solution can work in one context and fail in another because the second environment contains an undeclared constraint.
A study method that works at home may fail during a timed examination because time and working conditions changed. A route that works for one traveller may fail for another because steps, gradients or transfer times impose receiver-specific constraints. A software tool may work in testing but fail in production because network, permissions or concurrency limits were absent from the test environment.
Transfer failure is evidence to search for the missing constraint.
16. Worked example: accessible route planning
A navigation system finds the shortest route between a station and a building. The route includes stairs.
For a wheelchair user, step-free access is not a minor preference. It is a feasibility constraint. The route must also consider:
- lift availability;
- door widths;
- surface and gradient;
- opening hours;
- construction closures;
- transfer time;
- current accessibility status.
The shortest path algorithm can be perfectly correct and still answer the wrong problem because a receiver constraint was omitted.
17. Worked example: study planning
A student has four hours available and six revision tasks. “Do all six tonight” is infeasible if the tasks require seven hours of focused work.
Possible responses include:
- reduce scope;
- move a non-urgent task;
- shorten tasks where quality permits;
- increase available time;
- prioritise the earliest weak link;
- change the target from completion to diagnostic sampling.
Pretending the time constraint does not exist produces a plan that fails before it begins.
18. Worked example: project schedules and artificial constraints
A project manager enters “Must Finish On 30 September” into scheduling software. The software now displays the milestone on that date even when predecessor tasks slip.
The date did not become physically feasible because it was typed into a constraint field. GAO’s Schedule Assessment Guide warns that excessive hard or soft scheduling constraints can override network logic and create an artificial view of the plan.
This is an important distinction: declaring a constraint can describe reality—or conceal it.
19. Constraints across domains
| Domain | Possible constraints | Boundary |
|---|---|---|
| Engineering | Mass, power, geometry, environment, safety | Constraints belong to defined operating conditions. |
| Scheduling | Time, dependencies, resources, windows | Artificial date constraints can hide infeasibility. |
| Computing | Memory, compute, latency, permissions, interfaces | Scaling can move the binding constraint. |
| Education | Time, prerequisites, attention, assessment conditions | Generic constraints must not become fixed learner labels. |
| Finance | Capital, liquidity, rules, limits | Institutional and jurisdictional ownership matters. |
| Medicine | Contraindications, resources, timing, physiology | Clinical constraints require clinical ownership. |
| Public policy | Law, budget, rights, institutions, capacity | A policy constraint can be changeable but only by legitimate authority. |
20. Common constraint failures
| Failure | What goes wrong | Repair |
|---|---|---|
| Preference-as-constraint | Search space is narrowed unnecessarily. | Separate must-have from nice-to-have. |
| Constraint-as-preference | Unsafe or impossible solution is admitted. | Mark non-negotiable limits explicitly. |
| Non-binding optimisation | Effort improves a limit that is not governing output. | Identify current binding constraint. |
| Single-bottleneck thinking | After improvement, new limit is ignored. | Re-measure the system after intervention. |
| Hidden receiver constraint | Solution works for model but not person. | Include receiver capability in feasibility. |
| Stale constraint | Old policy or operating condition persists after reality changes. | Attach owner, review date and update trigger. |
| Authority collapse | System removes a constraint it cannot legitimately change. | Record change authority and escalation. |
| Artificial fixed-date constraint | Schedule looks feasible while logic says otherwise. | Preserve dependency logic and show true variance. |
| Constraint overload | No feasible solution remains but system fabricates one. | Return infeasibility and conflicting set. |
21. Hostile test: vary the candidate limit
To test whether a suspected constraint is actually binding, vary it while holding the receiver goal and observation window stable.
- What outcome is currently limited?
- What candidate constraint is suspected?
- Who or what imposes it?
- Is it physically immutable, policy-controlled or merely assumed?
- Does relaxing it change throughput, quality or receiver outcome?
- If not, which constraint now appears binding?
- What new risk appears after relaxation?
- Does the solution remain safe, lawful and accessible?
- Who has authority to change the constraint?
- When should constraint status be reviewed again?
22. Where Constraints fits in the wider How Things Work map
Constraints is a root mechanism connecting Capacity, Optimisation, Scheduling, Algorithms, Scarcity, Safety, Human Oversight and Problem Solving.
Its distinct public job is: How do limits define the feasible world, and how do we determine which limit actually governs the current outcome?
23. What this article does not claim
- Every inconvenience is not a true constraint.
- Every constraint is not a bottleneck.
- A binding constraint can move after intervention.
- Removing a constraint is not automatically beneficial.
- A declared constraint can be artificial or outdated.
- Mathematical feasibility does not imply safety, legality, fairness or receiver usefulness unless those are represented.
- A system may not relax a legal, clinical, safety or rights-based constraint merely because doing so improves an objective.
24. Observable mastery test
You understand constraints when you can take an unfamiliar problem, list its physical, resource, temporal, interface, human and governance limits, separate constraints from preferences and assumptions, identify which limit is binding, test what happens when it changes, predict the next bottleneck and state who has legitimate authority to relax it.
Authoritative source corridor
- NASA Systems Engineering Handbook — Appendix — requirements, constraints, system boundaries and traceability.
- NASA Systems Engineering Processes and Requirements — design constraints including cost, schedule, physical, environmental and human constraints.
- NASA Systems Engineering Handbook — constraints as inputs to technical requirements and design boundaries.
- U.S. GAO Schedule Assessment Guide — why artificial scheduling constraints can override network logic and hide true feasibility.
- Boyd & Vandenberghe: Convex Optimization — formal treatment of constrained optimisation, feasibility, duality and sensitivity.
Governing idea: Constraints are the walls of the possible world. Good reasoning distinguishes the walls that protect reality from the walls we merely forgot we built.