In the previous lesson, we introduced optimisation.

An optimiser tries to find:

the best action available to us

But there is an important word hidden inside that sentence:

available

Not every imaginable solution is actually possible.

Some satisfy the constraints of the system.

Others do not.

This gives us one of the most fundamental distinctions in optimisation:

Feasible solutions satisfy the constraints. Infeasible solutions do not.

What does feasible mean?

Suppose we are solving an optimisation problem:

[ \min_x C(x) ]

subject to:

[ g_1(x) \leq 0 ]

[ g_2(x) \leq 0 ]

[ \vdots ]

[ g_n(x) \leq 0 ]

A candidate solution (x) is feasible if it satisfies every required constraint.

If even one hard constraint is violated, the solution is infeasible.

So we can think of feasibility as a test:

[ \boxed{ \text{Does this solution obey all the rules of the problem?} } ]

If yes:

[ x \in \mathcal{F} ]

where (\mathcal{F}) is the feasible set.

If no:

[ x \notin \mathcal{F} ]

A simple example

Suppose you have:

[ £20 ]

to spend on lunch.

A meal costs:

[ £14 ]

That solution is feasible:

[ 14 \leq 20 ]

Another meal costs:

[ £27 ]

That solution is infeasible:

[ 27 > 20 ]

It may be a better lunch.

It may be more nutritious.

It may taste better.

But given the current constraint, it is not available to you.

This is an important idea:

An infeasible solution can be highly desirable and still not be a valid solution to the current problem.

Best does not mean feasible

Suppose a hospital has ten beds.

There are fifty patients who would benefit from admission.

A hypothetical solution might be:

Admit all fifty patients.

According to an objective such as:

[ \max \text{number of patients treated} ]

this may be excellent.

But the constraint is:

[ \sum_i x_i \leq 10 ]

where:

[ x_i = \begin{cases} 1 & \text{if patient } i \text{ receives a bed} \ 0 & \text{otherwise} \end{cases} ]

Allocating fifty beds gives:

[ \sum_i x_i = 50 ]

so:

[ 50 > 10 ]

The solution is infeasible.

The optimiser must therefore search for the best solution among allocations using at most ten beds.

The feasible set

The collection of all feasible solutions is called the feasible set.

We can write:

[ \mathcal{F}

{x : g_i(x) \leq 0 \text{ for all } i} ]

The optimisation problem then becomes:

[ x^*

\arg\min_{x \in \mathcal{F}} C(x) ]

This tells us something important.

The optimiser is not choosing between:

every solution we can imagine.

It is choosing between:

every solution the model considers possible and permissible.

The feasible set defines the world the optimiser is allowed to operate inside.

A two-variable example

Suppose a small factory produces two products:

[ x ]

and:

[ y ]

Each unit of (x) requires one hour of machine time.

Each unit of (y) requires two hours.

The factory has:

[ 10 ]

machine-hours available.

So:

[ x + 2y \leq 10 ]

We also cannot produce negative quantities:

[ x \geq 0 ]

[ y \geq 0 ]

Now consider several candidate solutions.

Solution A

[ x=4,\quad y=2 ]

Machine time required:

[ 4 + 2(2)=8 ]

Since:

[ 8 \leq 10 ]

Solution A is feasible.

Solution B

[ x=8,\quad y=2 ]

Machine time required:

[ 8 + 2(2)=12 ]

Since:

[ 12 > 10 ]

Solution B is infeasible.

Solution C

[ x=-1,\quad y=3 ]

Machine time might appear acceptable:

[ -1 + 2(3)=5 ]

But:

[ x=-1 ]

violates:

[ x \geq 0 ]

So Solution C is also infeasible.

A solution must satisfy all constraints.

Passing one constraint does not compensate for failing another.

Feasibility before optimality

This gives us a useful ordering.

Before asking:

Is this solution optimal?

we should ask:

Is this solution feasible?

There is no point comparing the objective value of a solution that cannot actually be implemented.

In many optimisation algorithms, feasibility acts like a gate:

[ \text{candidate solution} \rightarrow \text{constraints satisfied?} \rightarrow \begin{cases} \text{yes} & \rightarrow \text{evaluate objective} \ \text{no} & \rightarrow \text{reject or repair} \end{cases} ]

A solution can therefore be:

feasible but poor
feasible and good
feasible and optimal
infeasible

These are different concepts.

Feasible does not mean good

Suppose an electricity system has enough generation to meet demand.

Consider two feasible dispatches.

Dispatch A

Cost:

[ £1,000 ]

Dispatch B

Cost:

[ £10,000 ]

Both satisfy:

demand balance
generator limits
network limits

So both are feasible.

But if our objective is to minimise cost, Dispatch A is much better.

Feasibility tells us:

Can we do this?

Optimality tells us:

Of the things we can do, which is best?

Do not confuse them.

Infeasible does not mean undesirable

The reverse is also important.

Suppose an electricity network wants to deliver cheap renewable electricity from the north of a country to consumers in the south.

The generation exists.

Demand exists.

The proposed allocation would be cheap and low-carbon.

But the transmission network cannot carry the required flow.

The solution is infeasible.

That does not mean it is undesirable.

It means:

the current system cannot support it.

This distinction can reveal where investment is needed.

Perhaps the long-term response is:

build more transmission
add storage
develop local generation
change demand patterns

An infeasible solution can sometimes show us what the existing system is preventing.

Electricity example

Imagine two areas:

North

Available wind generation:

[ 1000 \text{ MW} ]

Local demand:

[ 200 \text{ MW} ]

South

Local generation:

[ 100 \text{ MW} ]

Demand:

[ 800 \text{ MW} ]

The North therefore has:

[ 800 \text{ MW} ]

available for export.

The South needs:

[ 700 \text{ MW} ]

from elsewhere.

At first glance:

[ 800 \geq 700 ]

so the system appears to have enough electricity.

But suppose the line between North and South can carry only:

[ 500 \text{ MW} ]

Then the proposed transfer:

[ 700 \text{ MW} ]

violates:

[ F \leq 500 ]

The solution is infeasible.

Nationally, there is enough electricity.

Locally, the network cannot deliver it.

This is one reason electricity cannot be treated simply as one homogeneous pool of energy.

Feasibility depends on the network.

Feasibility can depend on location

The same action may be feasible in one location and infeasible in another.

A 7 kW electric vehicle charger may be perfectly acceptable on one part of a distribution network.

On another heavily loaded feeder, switching on several chargers simultaneously might violate:

transformer capacity
voltage limits
cable thermal limits

The device itself has not changed.

The surrounding system has.

So feasibility can depend on:

[ \text{action} + \text{location} + \text{system state} ]

This matters enormously in cyber-physical systems.

Feasibility can depend on time

A solution may also be feasible now and infeasible later.

Suppose a battery contains:

[ 10 \text{ kWh} ]

At 18:00, discharging:

[ 5 \text{ kWh} ]

is feasible.

After doing so, only:

[ 5 \text{ kWh} ]

remains.

Trying to discharge another:

[ 8 \text{ kWh} ]

at 18:30 is now infeasible.

The earlier decision changed the later feasible set.

This is why dynamic systems require us to keep track of state.

The feasible set moves

We can represent this as:

[ \mathcal{F}_t ]

the feasible set at time (t).

At the next moment:

[ \mathcal{F}_{t+1} ]

may be different.

Why?

Because:

batteries charge and discharge
hospital beds become occupied or free
workers start and finish shifts
roads become congested
generators fail
weather changes
budgets are spent
inventory is consumed

Real-world optimisation often means operating inside a feasible region that is constantly changing.

Feasibility under uncertainty

There is another complication.

We may not know exactly where the constraint boundary is.

Suppose a renewable forecast says wind generation tomorrow will be:

[ 1000 \text{ MW} ]

But actual generation could be:

[ 800 \text{ MW} ]

A plan requiring all:

[ 1000 \text{ MW} ]

might appear feasible according to the forecast.

In reality, it may fail.

So there is a difference between:

feasible according to our model

and:

feasible in the real world

That gap matters.

Models can be wrong

Every optimisation problem is built on a model.

The model might say:

[ x \in \mathcal{F} ]

But if:

data is wrong
forecasts are wrong
network parameters are wrong
equipment behaves unexpectedly
people respond differently

then the real system may disagree.

This is one reason safety-critical systems often include margins.

Instead of operating exactly at:

[ F = F^{\max} ]

we might aim for:

[ F \leq 0.9F^{\max} ]

The unused margin provides protection against uncertainty.

Feasible on paper, impossible in practice

Some solutions satisfy the mathematical model but are not realistically implementable.

Imagine an optimiser produces a hospital schedule requiring a doctor to:

finish surgery at 10:00
start another procedure at 10:00
in another building

If travel time was omitted from the model, the solution may look feasible mathematically.

Operationally, it is impossible.

This tells us something important:

Feasibility is only as good as the constraints we model.

If an important constraint is missing, the optimiser may exploit the omission.

Optimisers exploit loopholes

An optimiser takes the model seriously.

If the model says something is allowed, the optimiser may use it.

Suppose a delivery-routing model includes:

road distances
fuel costs
vehicle capacity

but forgets to include:

driver working hours

The cheapest solution may ask someone to drive for:

[ 23 \text{ hours} ]

The optimiser has not behaved badly.

It has found a loophole in the model.

This is a recurring lesson in AI and optimisation:

If you forget to encode an important constraint, do not expect the optimiser to respect it.

Artificial intelligence can amplify this problem

Humans often use common sense to reject obviously absurd actions.

An automated optimiser may not.

If its feasible region accidentally contains dangerous or undesirable actions, a capable optimiser may discover them faster than a human would.

This is why deploying increasingly powerful AI systems increases the importance of carefully defining:

objectives
constraints
permissions
safety boundaries

Capability makes specification more important.

Infeasible optimisation problems

Sometimes the problem itself has no feasible solution.

Suppose a hospital has:

[ 10 \text{ beds} ]

but imposes the constraints:

[ \text{every one of 20 patients must receive a bed} ]

and:

[ \text{beds used} \leq 10 ]

There is no solution satisfying both.

The feasible set is empty:

[ \mathcal{F} = \varnothing ]

This is an infeasible optimisation problem.

Infeasibility is information

An optimiser reporting:

No feasible solution

is not necessarily a failure.

It may be telling us something extremely important about the real system.

For example:

There is no way to meet all electricity demand without exceeding network capacity.

Or:

There is no staffing schedule satisfying all required coverage and working-time rules.

Or:

There is no budget allocation funding every promised programme within the available budget.

The optimiser has exposed a contradiction between:

[ \text{what we demand} ]

and:

[ \text{what the system can provide} ]

That can be one of the most valuable outputs optimisation gives us.

Do not hide infeasibility

A badly designed system may try to conceal this.

Suppose politicians promise:

every service will improve
taxes will fall
spending will not rise
debt will fall
nobody will lose anything

Perhaps there is no feasible combination satisfying all of those conditions.

No amount of optimisation creates resources that do not exist.

At some point, the system must acknowledge the trade-off.

A mathematical model can sometimes make these contradictions explicit.

What do we do when a problem is infeasible?

Several options exist.

1. Increase resources

If the problem is:

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

we may add capacity.

Examples:

build hospital beds
hire staff
build transmission
purchase ambulances
increase budget

This changes the feasible set.

2. Relax a constraint

Perhaps a requirement is unnecessarily strict.

For example:

Every delivery must arrive within exactly two hours.

Maybe allowing:

[ 3 \text{ hours} ]

makes the problem feasible.

The important question becomes:

Which constraint can reasonably be relaxed?

3. Change the objective

Perhaps we cannot maximise everything simultaneously.

We may need to decide which outcome matters most.

4. Introduce priorities

If not everyone can be served, we may need an allocation rule.

For example:

clinical urgency
waiting time
essential need
random allocation
proportional allocation

Now the problem moves from feasibility into fairness.

5. Redesign the system

Sometimes repeated infeasibility indicates that the architecture itself is wrong.

If the system continually cannot satisfy its own requirements, perhaps it needs more than better optimisation.

It may need redesign.

Feasibility and rationing

Suppose electricity demand is:

[ 1000 \text{ MW} ]

but the maximum feasible supply is:

[ 900 \text{ MW} ]

There is no feasible solution in which:

[ \text{served demand} = 1000 ]

while respecting the available resources.

Some demand cannot be served.

The problem becomes:

How should the 900 MW be allocated?

One approach might maximise total served demand:

[ \max \sum_i s_i ]

subject to:

[ \sum_i s_i \leq 900 ]

and:

[ 0 \leq s_i \leq d_i ]

But many allocations might serve the same total amount.

For example, we could:

cut one consumer completely
reduce everyone slightly
protect essential demand
rotate interruptions
prioritise vulnerable users

Feasibility tells us that scarcity exists.

It does not tell us how scarcity should be shared.

That requires an allocation rule.

Feasibility and fairness are different

This is important.

An allocation can be feasible and unfair.

Suppose there are ten hospital beds.

Giving all ten to the ten richest patients is feasible.

Giving them to the ten youngest patients may also be feasible.

A lottery may be feasible.

A clinical-priority system may be feasible.

The constraint tells us:

[ \text{no more than 10 beds} ]

It does not tell us:

who deserves them.

Feasibility defines the possible.

Fairness helps us choose among the possible.

Constraint boundaries matter

Sometimes the most interesting part of a system occurs near the edge of feasibility.

Suppose a power line limit is:

[ 500 \text{ MW} ]

At:

[ 300 \text{ MW} ]

the constraint barely matters.

At:

[ 499 \text{ MW} ]

it becomes extremely important.

A small increase in demand may suddenly require:

redispatch
storage
demand reduction
curtailment

Constraints often have little visible effect until they bind.

What is a binding constraint?

A constraint is binding when the solution sits exactly at its limit.

Suppose:

[ x + 2y \leq 10 ]

and the optimal solution has:

[ x + 2y = 10 ]

The constraint is binding.

Every available unit of that resource is being used.

If instead:

[ x + 2y = 6 ]

then the constraint has slack:

[ 10 - 6 = 4 ]

The resource is not fully utilised.

Slack

For a constraint:

[ x \leq b ]

we can think of slack as:

[ s = b-x ]

If:

[ s>0 ]

there is spare capacity.

If:

[ s=0 ]

the constraint is binding.

Slack can represent:

spare hospital beds
unused network capacity
remaining budget
available storage
unused staff time

Slack is often valuable.

It gives the system room to respond.

A system with no slack can be fragile

Imagine every resource is operated exactly at its limit.

Power lines:

[ F=F^{\max} ]

Hospital beds:

[ B=B^{\max} ]

Staff:

[ H=H^{\max} ]

Budget:

[ C=C^{\max} ]

This may look highly efficient.

There is no "waste."

But now one unexpected event occurs.

Demand rises.

Equipment fails.

Someone becomes ill.

Costs increase.

There is nowhere to go.

The system moves immediately from:

[ \text{feasible} ]

to:

[ \text{infeasible} ]

Efficiency without slack can produce fragility.

Feasibility margins

Robust systems often deliberately remain away from absolute limits.

Instead of:

[ F \leq 500 ]

an operator may choose to operate normally at:

[ F \leq 450 ]

The remaining:

[ 50 ]

provides a margin.

This sacrifices some apparent utilisation.

But it creates:

resilience
safety
optionality

Again:

unused capacity is not automatically wasted capacity.

Changing the feasible region

A powerful way to think about system transformation is:

Can we expand the set of good things the system is capable of doing?

Suppose today's feasible set is:

[ \mathcal{F}_0 ]

New technology might create:

[ \mathcal{F}_1 ]

where:

[ \mathcal{F}_0 \subset \mathcal{F}_1 ]

Meaning:

everything we could do before is still possible, but additional possibilities now exist.

Examples:

batteries make new electricity-system actions possible
digital communications enable remote coordination
cloud computing enables scalable services
AI enables new forms of prediction and control

Technology can expand the feasible region.

But institutions may continue behaving as though:

[ \mathcal{F}=\mathcal{F}_0 ]

even after technology has made:

[ \mathcal{F}_1 ]

possible.

That is one reason old systems can become unfit for purpose.

Legacy constraints

A constraint may once have been necessary.

Then technology changes.

The constraint remains.

Suppose a process was designed when every document had to be:

printed
transported physically
signed by hand
stored in filing cabinets

Those limitations may have shaped the entire institution.

Digital technology later removes many of them.

Yet the process may remain almost unchanged.

The organisation has inherited a legacy constraint.

The constraint is no longer imposed by technology.

It is imposed by the system's memory of older technology.

Do not confuse "not allowed" with "not possible"

This distinction is especially useful.

Consider three statements:

Physically impossible

This battery cannot discharge 100 kWh because it contains only 10 kWh.

Legally prohibited

The organisation is not allowed to perform this action.

Procedurally prohibited

Our internal process does not permit this.

All three may appear as constraints.

But they have very different meanings.

The first may require new physical capability.

The second may require legal change.

The third may require someone to redesign a process.

Understanding the source of infeasibility matters.

AI systems inherit the feasible region we give them

Suppose we ask an AI:

Optimise this government process.

If the model assumes all existing procedures are fixed constraints, it may find a better way to operate the current bureaucracy.

But perhaps the highest-value solution is:

remove three unnecessary stages entirely.

An optimiser cannot choose that if we declared those stages immutable.

The feasible region is partly a design choice.

This is why defining the problem correctly matters as much as solving it.

Sometimes the best solution is outside the current feasible set

This sounds contradictory.

By definition, we cannot implement an infeasible solution today.

But an infeasible solution can reveal a valuable future direction.

Suppose the best electricity-system configuration requires:

[ 700 \text{ MW} ]

of transmission capacity.

Today we have:

[ 500 \text{ MW} ]

So the configuration is infeasible.

But now we have learned:

increasing network capacity by 200 MW could unlock a much better system.

The infeasible solution becomes an investment signal.

It tells us which constraint is preventing a better outcome.

Shadow value of a constraint

In optimisation, constraints can have values associated with relaxing them.

Conceptually, we can ask:

How much better could the objective become if this constraint were slightly relaxed?

Suppose adding:

[ 1 \text{ MW} ]

of transmission capacity reduces total system cost by:

[ £500 ]

per hour.

Then that extra capacity has real system value.

This idea becomes important in:

network planning
electricity pricing
capacity investment
resource allocation

Constraints do not merely prevent actions.

They can tell us where additional capability is most valuable.

Feasible is model-dependent

We should therefore be careful whenever someone says:

That solution isn't feasible.

Ask:

Why?

Is it infeasible because of:

physics?
resources?
law?
current technology?
current infrastructure?
an organisational process?
a modelling assumption?
an arbitrary rule?

Those are very different answers.

"Not feasible" should not automatically mean:

impossible forever.

Sometimes it means:

impossible under the system we currently have.

physical
financial
legal
safety
institutional
informational
technological

[ \boxed{x \in \mathcal{F} \Rightarrow \text{feasible}} ]

[ \boxed{x \notin \mathcal{F} \Rightarrow \text{infeasible}} ]

But feasibility does not mean:

good.

And infeasibility does not necessarily mean:

bad.

A feasible solution may be expensive, unfair or inefficient.

An infeasible solution may reveal an opportunity for investment or system redesign.

The deeper question is therefore not only:

What can the system do today?

It is also:

Why are these the boundaries of what the system can do?

And:

Should those boundaries change?

That is where optimisation begins to become system transformation.