What Should Happen When the Model Cannot Help?

A missing reading or unavailable model still requires a response. Build a route that makes the failure visible and sends the case somewhere useful.

13 sections · 4 questions · 1 coding challenge

1 / 13

The arrow keys move between sections too.

A Busy Service Needs a Defined Reduced Behaviour

BOTIE

Google’s discussion of overload describes controlling work when a service cannot fulfil every request normally. Admission decisions and degraded responses can prevent excess work from overwhelming the remaining capacity. The useful behaviour depends on which work the service can safely defer or simplify.

For our inspection example, an unusable sensor record routes to review. That is an illustrative policy chosen for this lesson. A real inspection process would need to establish who reviews the case, how soon, and what happens if that route is also unavailable.

Sources for this history

Google SRE Book: Handling Overload

Botie Lost the Reading. The Pump Did Not Stop Existing.

The inspection service expects a recent sensor record. Today the network delivers an old one, and one pump has no valid record at all. The system still has to decide what to do with those pumps.

We should decide that behaviour before a failure occurs. We will build a routing rule that uses model output only when its input checks pass and otherwise requests a separate review. Then we will examine what that fallback itself requires.

Review is a separate operational route. It is not an automatic guarantee that a fault will be found.

Step 1 of 2

Check the evidence before using the decision

The maximum age is five minutes. Model decisions use 0 for defer and 1 for inspect.

A plausible model output cannot repair an invalid or stale input.
Pump	Valid record?	Age	Model decision	Chosen action
A	1	2 min	1	Inspect
B	1	9 min	0	Review
C	0	1 min	1	Review

A
Valid record?
1
Age
2 min
Model decision
1
Chosen action
Inspect
B
Valid record?
1
Age
9 min
Model decision
0
Chosen action
Review
C
Valid record?
0
Age
1 min
Model decision
1
Chosen action
Review

A plausible model output cannot repair an invalid or stale input.

Step 2 of 2

Keep the fallback in the same decision path

Both branches must produce an action the next component understands.

1
Check
Valid record and acceptable age
2
If both pass
Use the model’s proposed action
3
Otherwise
Route to review and record the reason

Do not count routed-away cases as successful model predictions.

A failed precondition needs a visible response

The mask enforces preconditions before choosing the action. The review code remains distinguishable from an ordinary prediction.

Which pumps need the fallback route?

Change record validity and age. A valid record at or below the maximum age uses the model decision; otherwise it receives the review code.

BOTIE

Botie should use a model decision only when its record is valid and recent enough. Every other case needs the specified fallback action.

Choose an example

Record validity flags

Record ages in minutes

Maximum age in minutes

Model action codes

Review action codes

Actions: −1 = review, 0 = defer, 1 = inspect

Follow the operations

1. Record validity flags
1. 01
2. 11
3. 20
2. Maximum age in minutes
```
5
```
3. Record ages in minutes
1. 02
2. 19
3. 21
4. Threshold gate
1. 01
2. 10
3. 21
5. Multiply
1. 01
2. 10
3. 20
6. Model action codes
1. 01
2. 10
3. 21
7. Review action codes
1. 0-1
2. 1-1
3. 2-1
8. Choose by a mask
1. 01
2. 1-1
3. 2-1
9. Result
1. 01
2. 1-1
3. 2-1

The review team needs its own capacity and response policy. This routing calculation does not prove that manual review is effective or timely.

1. List the conditions the model depends on

Start with the assumptions we already identified: the record belongs to the right pump, its units match, and its timestamp is usable. Add runtime availability and any other condition required for a prediction.

For this workshop, a supplied validity flag summarises the schema checks. Record age is checked separately. That division lets us see what the routing rule does without hiding every input check inside one component.

A validity flag is an observed precondition result. It is not the model’s confidence in its own prediction.

2. Choose a meaning for every outcome

Our model proposes either defer or inspect. An unusable input gets a third code, review, so downstream code can distinguish it from an ordinary defer decision. The number −1 is just an identifier for that route.

A review task needs enough context to be useful, including the pump identity and why the automated path declined. Do not display a normal-looking answer while silently using a different procedure.

Fallback behaviour should be visible in logs and evaluation as well as in the user-facing process.

3. Build the use-model mask

First compare the maximum age with every record age. Then require both that freshness check and the supplied validity flag. These binary values combine with multiplication in the workshop.

Choose by a mask then takes the model’s value at each 1 and the fallback value at each 0. It preserves pump order and does not average the two routes.

Valid = [1, 1, 0]
Ages = [2, 9, 1] minutes
Maximum age = 5 minutes
Fresh = [1, 0, 1]
Use model = valid × fresh = [1, 0, 0]
Model actions = [1, 0, 1]
Review actions = [−1, −1, −1]
Chosen actions = [1, −1, −1]

The third pump’s fresh-looking timestamp does not override its invalid record.

Select a route without changing the order

np.where chooses between aligned values using a boolean mask. It does not validate the mask’s meaning for us.

Python

import numpy as np
use_model = np.array([True, False])
model_action = np.array([0, 1])
chosen = np.where(use_model, model_action, -1)
print(chosen.tolist())

Output

[0, -1]

The first pump keeps its defer decision. The second is routed to review, regardless of its proposed model action.

4. Do not mistake confidence for a health check

A model can produce a high score from malformed or unfamiliar inputs. A confidence threshold may be useful for a carefully evaluated abstention policy, but it does not replace schema or freshness checks.

If confidence determines whether to answer, evaluate both error on answered cases and the fraction of cases answered. Otherwise, a system can appear accurate by declining nearly everything.

Our route uses explicit preconditions. Adding a confidence-based route would require another contract and evaluation.

5. Budget the fallback too

Manual review has capacity and delay, just like inference. A sensor outage affecting every pump can overwhelm a review queue that usually receives only a few cases. Test that scenario.

If the normal path and fallback depend on the same unavailable server, the apparent backup may fail at the same time. Draw those dependencies and choose a response that still exists under the failure being handled.

A fallback is part of the design, with its own limits. It is not a word that makes a failure disappear.

6. Decide how the system recovers

When readings return, check that they are fresh and valid before restoring the normal route. Keep the compatible model and preprocessing versions together. A retry should have a limit and should not amplify an outage with endless immediate work.

Preserve records of which route each case took. Later outcomes can then reveal whether the fallback met its purpose and whether a recurring input failure needs a repair upstream.

Botie’s workshop tests routing. A real recovery test also exercises ownership, capacity, timing, and the transition back to normal service.