Good Regulator Theorem
More choices do not help if the system cannot see which choice fits the situation.
A controller needs enough of the right information to tell when two situations need different responses.
Three providers and one score that hides the difference
A payment platform can send transactions through three providers.
The routing rule appears sensible. Rank the providers by recent success rate and send the next transaction to the leader:
- Provider A: 98.7 percent
- Provider B: 98.2 percent
- Provider C: 97.9 percent
Most traffic goes to A.
The overall score hides the details that should change the choice: where the money is going, how large the payment is, how much money each provider has available and whether one is already having problems. A works well for small transfers to one country but becomes unreliable for large payouts elsewhere when the money it set aside runs low. B is strongest for salary payments, though its balance update arrives fifteen minutes late. C is slower on an ordinary day, but it uses different infrastructure and stays available when the others fail.
The router has choices but cannot see when it should make a different one. Large payouts keep failing and retrying through the same provider, the queue grows, and a customer waiting for rent money receives another generic delay while support loses trust in a system described as intelligent.
What the controller needs to represent
The Good Regulator Theorem comes from Roger Conant and W. Ross Ashby's 1970 paper, “Every good regulator of a system must be a model of that system”.
A controller sees something happening, acts, then uses the result to decide what to do next. To make good choices consistently, it needs information that separates the situations where each action works from the ones where it does not.
The model does not need to copy everything. A thermostat does not need the history of a building, the wall colour or every air current. It only needs to tell when the building needs heating and when it does not.
For the payment router, a useful internal state might include:
- Corridor and currency
- Transaction type and amount band
- Current provider balance and capacity
- Live incident and latency state
- Error class from the previous attempt
- Freshness and confidence of each observation
That information lets the router treat a large payout, a low balance or an active incident differently. When the information is stale or missing, it can use a safe fallback instead of pretending it knows enough.
The control loop is:
System state → internal model → chosen action → observed result → model update
The decision can fail because the router omitted a condition, observed it too late, chose the wrong action or failed to learn from the result.
When a system keeps making the wrong choice, look at what it can see as well as what it is able to do.
How this works in other fields
Cybernetics and control engineering. A regulator counters disturbances by choosing actions that keep important outcomes within bounds. An aircraft controller needs enough representation of position, velocity, orientation and dynamics to know which correction will stabilise the craft. A larger action set is useless if the controller can't distinguish the state in which each action is appropriate. The model may be implicit in the controller's structure rather than stored as a readable diagram.
Biology and cognition. Living systems regulate temperature, energy, movement and threat by mapping signals onto responses. Effective regulation often depends on prediction: an organism prepares for demand before a variable has moved far outside its safe range. The immune system likewise distinguishes classes of threat and recruits different responses. An evolved organism responds to signals that call for different actions without having one explicit, stable objective or a neat central model.
Software, organisations and public institutions. Software can only act on conditions its data can describe. If a payment system records only “provider up” or “provider down”, it cannot respond differently when the provider is slow or only some payments are failing. Organisations have similar blind spots because reports, budgets and lines of authority determine what leaders can see and act on. A market regulator that looks at firms one by one may miss risks they share, such as the same source of funding or incentives that spread trouble across the market.
In each case, the controller needs to observe the differences that should change its response.
How to design the controller
Use this model when an automated system has many rules but still chooses badly because the data leaves out important context.
Ask:
- What outcome or invariant is the controller protecting?
- Which system states require meaningfully different actions?
- Which of those states can the controller currently observe?
- How fresh and reliable are those observations?
- What actions can the controller take?
- What maps each represented state to an action?
- How does the result update the model?
- What happens when the state is unknown, novel or contested?
- Which distinctions were deliberately omitted, and when would that simplification fail?
For the router, identify the smallest set of information that changes a routing decision, test that mapping and define a safe fallback for conditions the model doesn't recognise.
When more modelling makes things worse
More detailed models create costs: slower decisions, extra data collection, brittle categories and false precision. A controller can overfit yesterday's failure modes while missing a new one. Strategic participants may also change their behaviour once they understand what the model rewards.
Some relevant states remain partly unobservable. In those cases, confidence estimates, reserves, human appeals, reversible actions and margins of safety matter more than another decimal place.
The theorem also says nothing about whether the goal itself is right. A precise model can regulate a system efficiently towards a harmful goal. People affected by the controller may have values and rights that are absent from its optimisation target.
Keep the differences that change the action visible, and leave people a way to correct what the model leaves out.
Related models
Requisite Variety says the regulator needs enough response variety to match the variety of disturbances it must absorb. The Good Regulator Theorem concerns the representation that connects a perceived state to the suitable response. Many buttons don't create control when the controller can't tell which one fits.
Map Is Not the Territory warns that every representation omits reality. The Good Regulator Theorem says an adequate representation is nevertheless necessary for effective control. Together they recommend a model that's deliberately partial: small enough to use, rich enough to preserve every distinction that changes the decision, and open to revision when reality produces a state it can't explain.
A good controller sees enough of the current situation to choose the right available action, then updates as conditions change.