In the previous lesson, we introduced objectives.

An objective tells a decision system what it is trying to achieve.

For example:

[ \min \text{cost} ]

or:

[ \max \text{patient benefit} ]

or:

[ \min \text{journey time} ]

But there is an immediate problem.

We cannot simply choose whatever action produces the best objective.

The real world places limits on what we can actually do.

These limits are called constraints.

The real world is constrained

Imagine a hospital trying to maximise the number of patients successfully treated.

If there were unlimited:

doctors
nurses
beds
operating theatres
medicines
money
time

then the allocation problem would be much easier.

Treat everyone.

But resources are not unlimited.

Suppose there are:

50 patients
10 beds

The hospital cannot choose:

Give all 50 patients a bed.

It does not matter how desirable that outcome would be.

It is physically impossible.

We therefore have a constraint:

[ \text{beds allocated} \leq 10 ]

The decision problem becomes:

[ \max \text{patient benefit} ]

subject to:

[ \text{beds allocated} \leq 10 ]

This simple phrase:

subject to

is enormously important.

It separates the world we would like from the world that is actually possible.

Objectives and constraints are different

It is worth being very clear about the distinction.

An objective tells us what we would like to improve.

A constraint tells us what we are allowed or able to do.

For example, a delivery company might have the objective:

[ \min \text{total delivery time} ]

But its vehicles have limited capacity:

[ \text{packages in van} \leq \text{van capacity} ]

Drivers can only work certain hours:

[ \text{driving time} \leq \text{legal limit} ]

And a vehicle cannot be in two places simultaneously.

These constraints define which possible solutions are actually feasible.

The feasible region

Suppose we have thousands of possible actions.

Some satisfy all our constraints.

Others do not.

The set of actions that satisfy the constraints is called the feasible region.

We can think of the decision problem as:

[ \boxed{ \text{Find the best solution among all feasible solutions} } ]

This is the heart of many optimisation problems.

Mathematically, we might write:

[ a^* = \arg\min_a C(a) ]

subject to:

[ g_1(a) \leq 0 ]

[ g_2(a) \leq 0 ]

[ \vdots ]

[ g_n(a) \leq 0 ]

The objective tells us which direction is better.

The constraints draw the boundaries around where we are allowed to go.

A simple example

Imagine you have £20 and want to buy lunch for a group.

There are several possible meals.

Your objective might be:

[ \max \text{total satisfaction} ]

But you have a budget constraint:

[ \text{total cost} \leq £20 ]

A meal combination costing £35 might produce much greater satisfaction.

But it is not feasible.

The optimisation problem does not ask:

What is the best imaginable lunch?

It asks:

What is the best lunch we can actually buy with £20?

That distinction appears everywhere.

Prediction does not remove constraints

Now we can connect this back to AI.

Suppose an AI model perfectly predicts electricity demand tomorrow.

It tells us:

[ D_{18:00} = 42.3 \text{ GW} ]

with extraordinary accuracy.

Useful.

But the electricity system still has physical constraints.

Generators have maximum outputs:

[ 0 \leq P_g \leq P_g^{\max} ]

Power lines have thermal limits:

[ |F_l| \leq F_l^{\max} ]

Batteries have limited energy:

[ 0 \leq E_b \leq E_b^{\max} ]

Generators may have limits on how quickly they can change output:

[ -\Delta P_g^{\max} \leq P_{g,t}-P_{g,t-1} \leq \Delta P_g^{\max} ]

And electricity supply and demand must remain balanced:

[ \sum_g P_g

\sum_i D_i ]

approximately in real time.

The forecast may be perfect.

That does not mean the system can physically deliver whatever outcome we want.

Physical reality matters

This distinction becomes particularly important when AI interacts with the physical world.

A language model can generate a proposed action almost instantly.

But physical systems cannot necessarily execute that action.

A robot cannot:

move infinitely quickly
carry unlimited weight
pass through a wall
operate forever without energy

A battery cannot:

store unlimited electricity
charge instantaneously
discharge more energy than it contains

A power network cannot:

transmit unlimited electricity
ignore voltage limits
ignore thermal limits
move electricity independently of network physics

A hospital cannot:

create doctors instantly
treat unlimited patients simultaneously
manufacture beds by prediction

Intelligence does not abolish physics.

The electricity grid is a network

Electricity provides a particularly useful example because constraints are not merely about how much energy exists.

They are also about where it is.

Imagine two locations:

North

and:

South

The North has:

[ 1000 \text{ MW} ]

of available generation.

The South needs:

[ 800 \text{ MW} ]

At first glance, there seems to be plenty of electricity.

But suppose the transmission line connecting them can carry only:

[ 500 \text{ MW} ]

Then:

[ 800 > 500 ]

The North may have enough generation.

The network cannot deliver enough of it to the South.

The constraint is not:

We do not have enough electricity.

The constraint is:

We cannot move enough electricity through this part of the network.

This is called congestion.

And it illustrates something fundamental:

Resources are often constrained not only by quantity, but by location, time and connectivity.

Constraints create scarcity

Suppose there are 50 patients and 50 hospital beds.

There is no bed scarcity.

But suppose only 10 of those beds have the specialist equipment required for a particular treatment.

Suddenly:

[ 50 \text{ patients} \rightarrow 10 \text{ suitable beds} ]

A constraint has created scarcity.

The same thing happens in electricity.

There may be abundant generation nationally.

But if the network cannot transport it to a particular location, electricity can become locally scarce.

There may be plenty of food in a country but insufficient transport capacity to deliver it somewhere.

There may be enough teachers nationally but too few in a particular region.

There may be enough money allocated to a programme but insufficient staff to deliver it.

Scarcity is therefore often produced by the interaction between:

[ \text{resources} ]

and:

[ \text{constraints} ]

Constraints can take many forms

Not all constraints are physical.

Real decision systems operate under many different kinds of limits.

Physical constraints

These arise from the physical world.

Examples include:

hospital beds
road capacity
power-line limits
battery capacity
water availability
warehouse space
machine operating limits

These cannot simply be wished away.

Financial constraints

Most organisations have limited resources.

For example:

[ \text{spending} \leq \text{budget} ]

A government may want to build:

hospitals
schools
railways
renewable generation
housing

but cannot necessarily fund every project simultaneously.

Money itself becomes a constraint on the decision space.

Time constraints

Some decisions have deadlines.

An ambulance must respond quickly.

An electricity system must balance supply and demand continuously.

A fraud-detection system may have milliseconds to approve or reject a transaction.

A perfect decision produced three hours later may be useless.

We might therefore have:

[ \text{decision time} \leq 100\text{ ms} ]

Computation itself can become constrained.

Legal constraints

A decision may be technically possible but legally prohibited.

For example, a company might find that discriminating against a particular group increases profit.

That does not mean it should be included as a legitimate option.

The law can remove actions from the feasible region.

Safety constraints

Some actions should simply never occur.

A power line must remain within safe operating limits.

An aircraft must maintain safe separation.

A medical device must not administer a dangerous dose.

These requirements may be represented as hard constraints:

[ x \leq x_{\text{safe}} ]

The optimiser is free to search for good solutions.

But only inside the safe region.

Resource constraints

Resources themselves may be limited.

There may be:

10 hospital beds
20 ambulances
5 engineers
100 MW of battery capacity
£1 million of funding
24 hours in a day

These limits create allocation problems.

Information constraints

Decision-makers rarely know everything.

A system may not know:

future demand
future prices
whether equipment will fail
what another participant intends to do
whether a prediction is correct

The decision therefore happens under uncertainty.

Even an extremely good AI model does not eliminate uncertainty completely.

Hard constraints

Some constraints should never be violated.

These are often called hard constraints.

For example:

[ \text{passengers} \leq \text{aircraft capacity} ]

or:

[ |F_l| \leq F_l^{\max} ]

for a power line.

A solution violating these conditions is simply infeasible.

Suppose an AI proposes:

Put 300 passengers on an aircraft certified for 180.

The fact that this might maximise ticket revenue is irrelevant.

The solution is outside the feasible region.

Soft constraints

Other constraints may be preferences rather than absolute limits.

Suppose a delivery company would prefer every package to arrive within 24 hours.

We might write:

[ \text{delivery time} \leq 24 \text{ hours} ]

But perhaps during extreme disruption, some deliveries can arrive later.

Instead of making this an absolute constraint, we could introduce a penalty:

[ C = \text{operating cost} + \lambda \times \text{late deliveries} ]

Now late deliveries are undesirable rather than impossible.

This is a soft constraint.

The parameter:

[ \lambda ]

determines how seriously we treat the violation.

Hard or soft?

Choosing whether something is a hard or soft constraint can be a major design decision.

Consider:

Electricity should be affordable.

Should affordability be:

an objective?
a soft constraint?
a hard consumer protection rule?

Consider:

Everyone should have access to essential healthcare.

Should this be:

something the system tries to maximise?
or a minimum entitlement that cannot be traded away?

Consider:

A system should be fair.

Should fairness be:

[ \max \text{fairness} ]

or should certain unfair outcomes simply be prohibited?

There is no universal answer.

But the distinction matters.

Constraints can conflict

Sometimes constraints make it impossible to satisfy everything simultaneously.

Imagine a hospital with:

20 emergency patients
10 beds

Suppose the rules say:

every emergency patient must receive a bed
no more than 10 beds can be used

These constraints cannot both be satisfied.

The problem is infeasible.

No amount of AI sophistication changes that.

The system has to decide what happens when its requirements cannot all be met.

Perhaps:

additional capacity is activated
patients are transferred
priorities are introduced
some constraints are relaxed
emergency rules take effect

This is where system design becomes especially important.

Sometimes there is no perfect answer

This is worth emphasising.

AI is often discussed as though enough intelligence will eventually produce:

the correct answer.

But sometimes the world simply does not contain an answer satisfying everything we want.

Suppose there are:

[ 10 ]

lifesaving treatments and:

[ 50 ]

people who need them.

No algorithm can produce:

[ 50 ]

treatments from:

[ 10 ]

treatments.

The difficult question is not prediction.

It is:

How should unavoidable scarcity be handled?

That is an allocation problem.

Constraints can reveal the real problem

Sometimes an apparent optimisation problem is actually a capacity problem.

Suppose a hospital repeatedly struggles to allocate beds.

We might build a sophisticated AI system to optimise bed allocation.

Perhaps it improves utilisation.

But suppose the real problem is simply:

[ \text{demand} \gg \text{capacity} ]

Then better allocation can help manage the shortage.

It cannot eliminate the shortage.

The long-term solution might be:

build more capacity.

This distinction matters because optimisation can sometimes make a badly designed system operate more efficiently without addressing why the system is under strain.

Efficiency versus resilience

Constraints also help us understand the difference between efficiency and resilience.

Suppose a hospital normally needs 90 beds.

It owns 100.

Average utilisation is:

[ 90% ]

Someone might argue:

We should increase efficiency by reducing capacity to 90 beds.

Now utilisation becomes:

[ 100% ]

Excellent.

Until something unexpected happens.

A flu outbreak creates demand for:

[ 110 ]

beds.

The spare capacity that looked inefficient was actually providing resilience.

The same logic appears in:

electricity generation
supply chains
banking
transport
telecommunications
emergency services

A system designed to operate exactly at its constraints under normal conditions may be extremely fragile when conditions change.

Slack is not always waste

This creates an important systems insight.

Unused capacity can look wasteful.

But some unused capacity may provide:

resilience
redundancy
optionality
emergency response
adaptability

Suppose an electricity system requires:

[ 40 \text{ GW} ]

on an ordinary day.

Building exactly:

[ 40 \text{ GW} ]

of generation capacity might look efficient.

But what happens when:

demand rises unexpectedly?
a generator fails?
wind output falls?
a transmission line disconnects?

A robust system needs room to respond.

So the constraint should not necessarily be:

[ \text{available capacity} = \text{expected demand} ]

We may deliberately require:

[ \text{available capacity} > \text{expected demand} ]

The difference provides resilience.

Constraints change over time

Constraints are not always fixed.

A battery's available energy changes as it charges and discharges.

A hospital's available beds change as patients arrive and leave.

Traffic capacity changes after an accident.

Renewable generation changes with the weather.

Staff availability changes throughout the day.

The feasible region therefore moves.

At time (t), we might have:

[ g(a_t, x_t) \leq 0 ]

where (x_t) represents the current state of the system.

At the next moment:

[ x_{t+1} \neq x_t ]

and the available decisions change.

This is one reason real-world decision-making is often dynamic rather than a one-off optimisation problem.

Decisions affect future constraints

There is another complication.

Our decisions today can change what is possible tomorrow.

Consider a battery.

Suppose it contains:

[ 10 \text{ kWh} ]

If we discharge all 10 kWh now, that may be optimal for the current moment.

But then:

[ E_{t+1} = 0 ]

The battery cannot respond to a later event.

Today's decision changed tomorrow's feasible region.

The same happens when:

governments spend budgets
hospitals use supplies
companies consume inventory
reservoirs release water
people accumulate debt
natural resources are depleted

This means decisions cannot always be considered independently.

The system has state and memory.

Constraints and fairness

Constraints also create some of the hardest fairness questions.

If there is enough of something for everyone, allocation may barely matter.

If there are:

[ 50 \text{ beds} ]

and:

[ 20 \text{ patients} ]

everyone can receive one.

But if there are:

[ 10 \text{ beds} ]

and:

[ 50 \text{ patients} ]

we need a rule.

Perhaps:

highest expected benefit
greatest urgency
longest waiting time
first come, first served
random allocation
equal opportunity
willingness to pay
some combination

The constraint has transformed a technical problem into a social one.

This happens repeatedly in real systems.

Scarcity forces us to decide:

Who gets what?

AI cannot make scarcity disappear

AI can help us use scarce resources better.

It can:

predict demand
identify bottlenecks
optimise schedules
reduce waste
improve coordination
discover better feasible solutions

These are enormously valuable capabilities.

But AI cannot repeal constraints imposed by reality.

If there are ten beds, an AI cannot allocate fifty beds.

If a transmission line carries 500 MW, a model cannot safely send 800 MW through it simply because that produces a cheaper mathematical solution.

If there are twenty ambulances, prediction cannot make the twenty-first appear.

AI can improve our decisions within the feasible region.

And it can help us identify where changing the constraints themselves would be valuable.

Sometimes we should change the constraint

Constraints are not all laws of nature.

Some are consequences of choices.

A transmission constraint might be changed by building another power line.

Hospital capacity might be increased by building another ward.

A software bottleneck might disappear after redesigning the architecture.

A legal constraint can be changed through legislation.

A budget constraint can change through investment.

So there are really two different questions:

Given today's constraints, what should we do?

and:

Are today's constraints themselves sensible?

This is a powerful distinction.

Operational decision-making works within the current system.

System design can ask whether the boundaries of that system should change.

Artificial constraints

Some constraints are particularly interesting because humans created them.

Imagine a government service that requires:

Every application must be printed and manually signed.

That creates:

processing delays
staffing requirements
physical storage requirements
administrative costs

Those constraints may once have served a purpose.

But technology may have changed.

If digital signatures are now secure and legally recognised, the constraint may no longer be necessary.

A sophisticated AI system layered on top of the old process might improve document processing.

But the better question could be:

Why does this process still exist?

This is why good system design does not simply optimise everything it encounters.

Sometimes it removes obsolete constraints.

Do not automate nonsense

This gives us an important principle.

Suppose a process contains:

unnecessary steps
outdated rules
duplicated approvals
artificial bottlenecks

We could apply AI to make each step faster.

But then we have created:

a highly efficient version of a bad process.

Before optimising a constrained system, ask:

Which constraints come from physics?

Which constraints protect something important?

Which constraints exist because resources are genuinely scarce?

Which constraints are historical accidents?

Which constraints no longer serve their original purpose?

AI can help us operate within constraints.

System design asks whether the constraints deserve to exist.

A useful hierarchy

We can now extend the framework from the previous lessons.

Prediction

What is likely to happen?

Objective

What are we trying to achieve?

Constraints

What are we actually able or allowed to do?

Decision

Given the objective and constraints, what action should we take?

This can be written as:

[ \boxed{ a^*

\arg\max_{a \in \mathcal{F}} U(a) } ]

where:

(U(a)) is the objective
(\mathcal{F}) is the set of feasible actions
(a^*) is the chosen action

The objective tells us what is desirable.

The constraints determine what is possible.

The decision chooses between the possibilities.

Sometimes it is removing the rule entirely.

The key takeaway

Real decision-making happens inside boundaries.

[ \boxed{\text{Objectives describe what we want.}} ]

[ \boxed{\text{Constraints describe what is possible.}} ]

[ \boxed{\text{Decision-making chooses the best feasible action.}} ]

AI can make extraordinary predictions and search enormous spaces of possible decisions.

But it cannot make physical scarcity disappear.

And it should not blindly accept every institutional constraint it inherits.

Some constraints are fundamental.

Some protect safety, fairness and rights.

Some represent genuine scarcity.

And some are simply remnants of systems designed for another time.

Understanding the difference is fundamental to building intelligent systems that do more than optimise the world as it currently exists.

Sometimes the right question is:

What is the best decision within these constraints?

And sometimes the more important question is:

Why is this a constraint at all?