Real-World Mathematics: Water, Flow, Tanks and Rainfall

Application of Mathematics in Real-World Usage · Worked application 6 · BTT Mathematics Hub

Two storms deliver the same amount of rain onto the same roof. One fills a tank and spills water. The other does not. Nothing in that statement contradicts conservation. The missing information is when the water arrives and what leaves while it is arriving.

Water makes several mathematical ideas unusually tangible. A tank contains a stock. A pipe carries a flow. Rainfall depth becomes volume only after an area is supplied. A tank can have enough total capacity but still be empty when demand occurs. A calculation that ignores overflow can promise water that has already left the system.

This guide follows water through a mathematical boundary, keeping track of inflow, storage, outflow, losses and unserved demand. The rainfall, tank dimensions, readings and operating schedules are fictional teaching examples. They are not local rainfall records, flood predictions, plumbing designs or water-quality assessments. Collected water is not assumed safe to drink. Do not enter drains, climb onto roofs or modify plumbing to carry out these exercises; supplied data and safe classroom models are sufficient.

The first question is whether we are counting water or its rate of movement

“The tank contains 600 litres” describes a quantity at an instant. “The pipe supplies 20 litres per minute” describes a rate. To connect them, specify a duration. A constant 20 L/min flow delivers 200 L over ten minutes, provided it actually continues for those ten minutes.

The distinction is the same as power and energy in Electricity, Energy, Power and Bills. A rate multiplied by time gives an accumulated quantity. Rate alone does not tell us the total; a total alone does not tell us how sharply the demand or supply was concentrated.

Keep litres, litres per minute and minutes visible in the working. If 600 L is divided by 20 L/min, the units reduce to 30 min. If the question asks for time and the final unit is litres squared, the expression has lost its intended meaning even before the numerical answer is inspected.

A water balance is an accounting identity

Choose a boundary around one tank. Over a specified interval, the basic balance is: final storage = initial storage + water entering − water leaving. Water leaving may include useful delivery, deliberate discharge, leakage, overflow or other losses. Name the terms that belong to the model rather than treating every decrease as useful consumption.

For example, begin with 300 L, receive 900 L, deliver 650 L and lose 50 L through a stated modelled loss. Final storage is 300 + 900 − 650 − 50 = 500 L. The result can be checked in reverse: the 1,200 L initially available or received must equal 650 L delivered, 50 L lost and 500 L remaining.

This balance does not tell us why water left or whether the quantities were measured accurately. It gives a condition any proposed explanation must satisfy. If the accounting does not reconcile, inspect missing terms, timing, units and measurement uncertainty before inventing a physical cause.

A useful habit is to sketch the boundary in words: “One tank, from 09:00 to 10:00, including its inlet and outlet, excluding an adjacent tank.” Changing the boundary changes the ledger. Internal movement between two tanks is an outflow for one tank but not necessarily an outflow for a boundary enclosing both.

Net flow answers the filling question

A tank initially contains 300 L. A constant inlet supplies 24 L/min while a constant outlet removes 6 L/min. We want to know when storage reaches 1,200 L, assuming the tank has sufficient capacity and the stated flows persist.

The amount that must accumulate is 1,200 − 300 = 900 L. Net inflow is 24 − 6 = 18 L/min. Time required is 900/18 = 50 minutes. A direct check gives initial storage 300 plus 24 × 50 entering minus 6 × 50 leaving, which equals 1,200 L.

Dividing 1,200 by 24 would ignore both the initial water and the outlet. Dividing 900 by 30 would add rates that act in opposite directions. The error is not caused by difficult division; it comes from representing the physical roles incorrectly.

There are important boundary cases. Equal inlet and outlet rates leave storage unchanged while the assumptions remain valid. If outflow exceeds inflow, storage decreases. A filling-time expression with a negative denominator does not mean the target is reached at a negative future time; it means the stated target is not reached under that operating pattern.

Tank shape connects volume to water level

For a rectangular tank with a constant horizontal base area, stored volume equals base area multiplied by water depth. Suppose the base is 1.5 m by 0.8 m, giving 1.2 m². At a depth of 0.5 m, volume is 0.6 m³, or 600 L.

If net inflow is 36 L/min, convert it to 0.036 m³/min. The water level rises at 0.036/1.2 = 0.03 m/min, or 3 cm/min. This is another rate conversion: a volume rate divided by an area gives a height rate.

That relationship depends on a constant cross-sectional area. In a tank that becomes wider with height, the same additional volume produces a smaller rise near the wider part. A height reading is therefore not automatically a constant fraction of full volume. “Half the height” and “half the capacity” coincide only for appropriate geometry.

This is a valuable modelling checkpoint. Before using proportional reasoning, ask what must remain constant. The school formula V = Ah is powerful precisely because its conditions are clear. Applying it to an arbitrary shape without checking those conditions changes a valid formula into an invalid model.

One millimetre of rainfall over one square metre is one litre

Rainfall is commonly represented as an equivalent depth. To turn depth into volume, multiply by the horizontal area receiving it. The USGS metric rainfall calculator provides an educational route for this depth-and-area conversion.

The metric relationship can be derived directly. One millimetre is 0.001 m. Multiplying 0.001 m by 1 m² gives 0.001 m³. Since 1 m³ is 1,000 L, the result is 1 L. Therefore rainfall volume in litres equals rainfall depth in millimetres multiplied by receiving area in square metres, for the stated uniform-depth model.

Suppose 18 mm of rain falls uniformly over an 80 m² horizontal collection area. The incident volume is 18 × 80 = 1,440 L. This is not automatically the amount entering a tank. Some water may fail to reach the collection system or may be diverted or lost before storage.

Do not substitute the sloping surface area of a roof without deciding how rainfall depth and collection geometry are defined. In the simple vertical-rain model used here, the relevant area is the horizontal projected area. The specification of area belongs with the number, not in an unstated assumption.

Separate incident rainfall from collected inflow

Let a hypothetical collection fraction be 0.80. Then 80% of the incident 1,440 L reaches the tank inlet: 1,440 × 0.80 = 1,152 L. The remaining 288 L lies outside the assumed captured inflow. This fraction is an illustrative parameter, not a measured property of a named roof or an approved design coefficient.

The USGS explanation of surface runoff describes why surface conditions and infiltration affect where rainfall goes. For this mathematical exercise, the chosen collection fraction compresses several effects into one input. Such compression makes a calculation manageable but creates an obligation to state its limits.

It is also important to keep capture losses and tank overflow separate. A collection fraction describes the route to the inlet. Overflow describes what happens after inflow meets a finite tank. Multiplying by a capture fraction and then assuming unlimited storage still overstates usable water when the tank fills.

A careful report can therefore contain four different quantities: incident rainfall, captured inflow, retained storage and water actually delivered to demand. They are connected, but they are not interchangeable labels for the same number.

The same rainfall total can produce different overflow

Consider a 1,500 L tank initially holding 800 L. Keep the captured inflow at 1,152 L and a constant outlet demand of 10 L/min. Compare two idealised storms with uniform captured inflow during their respective durations. The tank never empties in either scenario, so the stated outlet can continue.

Short storm: 20 minutes. Captured inflow rate is 1,152/20 = 57.6 L/min. Net rate before overflow is 47.6 L/min. Without a capacity limit, final storage would be 800 + 1,152 − 200 = 1,752 L. Because the tank can retain only 1,500 L, 252 L overflows.

Long storm: 120 minutes. Captured inflow rate is 9.6 L/min, slightly below the outlet’s 10 L/min. Storage decreases slowly and ends at 800 + 1,152 − 1,200 = 752 L. There is no overflow. The tank has served much more water during the longer storm.

Both storms deliver the same captured volume. Timing changes the overlap between supply and demand. This is why a total alone cannot answer every storage or drainage question. The USGS discussion of impervious surfaces likewise distinguishes changes in runoff amount and the speed at which water reaches waterways. Our tank calculation is a small teaching model, not a flood-design method.

Rainfall depth and rainfall intensity must not be confused

The 18 mm short storm lasts one-third hour, so its average intensity is 18/(1/3) = 54 mm/hour. The same depth over two hours has average intensity 9 mm/hour. Dividing by duration changes a depth into a depth rate.

At a hypothetical intensity of 60 mm/hour over 80 m² with collection fraction 0.80, captured rate is 60 × 80 × 0.80 = 3,840 L/hour, or 64 L/min. The units show why a division by 60 is needed when the rest of the tank model uses minutes.

An average intensity still does not reveal the within-storm pattern. Two storms can share total depth and duration while one contains a much sharper burst. A model with a large time step can hide that burst and underestimate temporary storage needs. Greater arithmetic precision cannot compensate for a time representation that omits the important peak.

Storage cannot be negative, and demand is not the same as delivery

Suppose a tank contains 200 L and the next request is for 600 L, with no inflow. It can deliver at most 200 L. Final storage is zero, while 400 L of demand is unserved. Writing final storage as −400 L may be useful as an unconstrained accounting deficit, but it is not a physical tank state.

Distinguish the requested quantity from the delivered quantity. A model that subtracts all demand even when the tank is empty falsely records water as delivered. The correct representation contains a nonnegative storage variable and a separate shortage variable.

For a model step in which supply arrives first and demand occurs afterward, calculate available water after overflow; actual delivery is the smaller of available water and requested demand. Unserved demand is requested demand minus actual delivery. These simple minimum and maximum operations are applications of piecewise functions.

A chronological ledger that accounts for every litre

Take a 1,000 L tank initially holding 200 L. At each step, the listed inflow arrives first. Any excess over capacity spills immediately. The listed demand is then served as far as possible. This event order is part of the model; it must not be changed silently.

Step	Inflow	Demand	Overflow	Delivered	End storage	Unserved
1	600 L	300 L	0 L	300 L	500 L	0 L
2	700 L	500 L	200 L	500 L	500 L	0 L
3	100 L	400 L	0 L	400 L	200 L	0 L
4	0 L	600 L	0 L	200 L	0 L	400 L

At step 2, the tank begins with 500 L and receives 700 L. That would make 1,200 L, so 200 L spills. Only then is 500 L delivered, leaving 500 L. At step 4, the remaining 200 L is delivered and the other 400 L requested cannot be supplied.

Check the complete balance. Initial storage plus total inflow is 200 + 600 + 700 + 100 = 1,600 L. Total actual delivery is 300 + 500 + 400 + 200 = 1,400 L. Add 200 L overflow and zero final storage to recover 1,600 L. Unserved demand is not an additional water outflow; it is water that was requested but never delivered.

A model that simply sums supply and demand would report a 200 L overall deficit, but the chronological system leaves 400 L unserved because 200 L was lost earlier through overflow. Both total availability and timing matter.

Why a larger tank cannot solve every shortage

Increase the capacity in the ledger from 1,000 to 1,200 L while keeping initial storage and inflows unchanged. Step 2 no longer spills. The extra retained 200 L can reduce the final shortage from 400 to 200 L. It cannot eliminate the remaining shortage because total demand is 1,800 L but initial storage plus inflow is only 1,600 L.

Capacity can preserve water that would otherwise be lost. It cannot manufacture new water. This gives a useful impossibility test before trying many tank sizes: if total available supply is less than demand over the entire horizon, increased capacity alone cannot satisfy all demand.

Now change two assumptions openly: initial storage becomes 400 L and capacity becomes 1,400 L. The successive pre-demand quantities are 1,000, 1,400, 1,000 and 600 L; the four demands can all be served, ending at zero without overflow. This demonstrates a feasible combination. It does not prove that it is the cheapest or best real installation.

The distinction between proving feasibility and proving optimality will recur in Packaging, Cutting and Material Waste. Finding one working arrangement answers “can this work?” A claim that no better arrangement exists requires an additional argument.

Event order is part of the mathematical evidence

Suppose 700 L of inflow and 500 L of demand occur during the same broad reporting interval. If all inflow arrives first, the tank may overflow. If demand occurs first, space may be created before the inflow arrives. If both occur gradually, the continuous time profile matters.

It is therefore not always valid to cap only the final net total. The expression “initial + inflow − demand” can hide an intermediate overflow or an earlier period with no water available. A sequence with a sensible final number can still violate the physical constraints halfway through.

Choose a time step fine enough to represent the event relevant to the decision, or state a justified ordering convention. When the order is unknown, compare plausible orderings as scenarios. Do not turn missing chronology into invented certainty merely because a spreadsheet expects one value per row.

A meter can reveal unexplained flow without identifying its cause

Imagine a meter rising from 12.451 to 12.463 m³ during a 40-minute interval. The difference is 0.012 m³, or 12 L. Average recorded flow is 12/40 = 0.30 L/min. If the same unexplained rate continued for an entire day, it would correspond to 0.30 × 60 × 24 = 432 L.

The conditional phrase “if it continued” matters. A 40-minute observation is not proof of a constant 24-hour pattern. Nor is every unexplained meter change necessarily a pipe leak: legitimate automatic use, an incorrect boundary or reading precision may also need consideration. The EPA WaterSense leak guidance includes meter-based checks; our calculation illustrates how a recorded volume becomes an average rate.

The mathematical task is to distinguish observed quantity, inferred rate and projected daily amount. Those are three different evidential states. An honest report does not label all three as measured facts.

Consumption comparisons need the right population and time base

A fictional household meter rises from 125.42 to 139.87 m³ over 28 days. Recorded use is 14.45 m³, or 14,450 L. If five people are present throughout the interval, use per person per day is 14,450/(5 × 28), approximately 103.21 L.

This is a constructed calculation, not a household benchmark or a recommended target. If two people were absent for part of the interval, the denominator of 140 person-days would need revision. If the meter included a garden or another unit, the interpretation would also change.

A ratio can help compare different-sized groups, but it does not explain every difference. Report both the total and the normalised measure when each is relevant. An apparent reduction per person can coexist with a rise in total use if the population grows.

Represent uncertainty without manufacturing a confidence level

Suppose rainfall depth is assumed to lie from 16 to 20 mm, collection area from 78 to 82 m², and collection fraction from 0.70 to 0.90. All inputs are positive. A conservative corner calculation gives a lower captured amount of 16 × 78 × 0.70 = 873.6 L and an upper amount of 20 × 82 × 0.90 = 1,476 L.

This range is conditional on the stated bounds and the simple multiplicative model. It is not a 95% confidence interval. The endpoints may also be overly conservative if the input extremes cannot occur together. The calculation is still useful because it reveals how much an apparently precise estimate depends on uncertain assumptions.

For a tank-capacity decision, check both supply and timing under the adverse scenario relevant to the objective. A low-capture scenario may matter for shortage. A high-intensity scenario may matter for overflow. There is no single “worst case” independent of the question being asked.

What changes when rates vary continuously?

With constant rates, multiplication by time is enough. With several constant intervals, add the volumes from each interval. Suppose inflow is 10 L/min for four minutes and 25 L/min for two minutes. Total inflow is 40 + 50 = 90 L. The average across the six minutes is 15 L/min, not the unweighted mean of 17.5 L/min.

With smoothly varying rates, integration provides the advanced form of the same accumulation. Before capacity and empty-tank constraints intervene, the rate of change of storage equals inflow rate minus outflow rate. The integral of that net rate over time gives the storage change.

A solver must still respect the boundaries at zero and full capacity. Calculus does not give permission to carry negative water or retain overflow. This is the point where functions, inequalities and physical interpretation have to work together.

Practice: twenty checks on quantities, timing and capacity

All examples below are idealised. Unless stated otherwise, rates are constant during their intervals, tanks have adequate capacity, and no unlisted losses occur.

Convert 2.75 m³ into litres.
A 15 L/min inlet runs for 12 minutes. Find inflow volume.
A tank starts with 240 L and must reach 900 L. Inlet is 30 L/min and outlet is 8 L/min. Find the time.
A tank starts with 600 L. Inlet is 5 L/min and outlet is 17 L/min. When does it first empty?
A rectangular tank has base 2 m by 0.5 m and water depth 0.4 m. Find stored litres.
For question 5, find the height rise caused by an additional 100 L.
Calculate incident volume from 12 mm of uniform rain over 150 m².
With a hypothetical capture fraction 0.75, how much of question 7 reaches the inlet?
Twenty-four millimetres falls in 40 minutes. Find average intensity in mm/hour.
At 30 mm/hour over 100 m² with capture fraction 0.80, find captured flow in L/min.
A 1,000 L tank holds 700 L. An instantaneous 500 L inflow arrives before a 200 L demand. Find overflow and end storage.
Repeat question 11 with the demand occurring before the inflow.
A tank holds 150 L and receives no water before a 220 L request. Find delivered water, final storage and unserved demand.
A meter rises by 0.018 m³ in one hour. Find average L/min and a conditional 24-hour projection.
Use is 12 m³ over 25 days for four continuously present people. Find litres per person per day.
A tank starts with 300 L, receives 1,000 L, delivers 950 L and spills 80 L. Find final storage.
With rainfall bounded by 10–14 mm and fixed area 50 m² and capture fraction 0.8, find the captured-volume interval.
Total demand is 2,000 L and total available water including initial storage is 1,700 L. Can a larger tank alone eliminate all shortage?
Inflow is 6 L/min for five minutes and 18 L/min for ten minutes. Find total inflow and time-weighted average rate.
Why can a model with a nonnegative final storage still be physically impossible during an interval?

Worked answers and the meaning behind them

2,750 L. Multiply cubic metres by 1,000. The physical amount stays the same while the numerical unit changes.
180 L. Multiply 15 L/min by 12 min. This assumes the inlet actually sustains that rate throughout.
30 minutes. Needed accumulation is 660 L and net rate is 22 L/min. Check: 240 + 900 − 240 = 900 L.
50 minutes. Net loss is 12 L/min. The constant-outflow model cannot continue unchanged after the tank empties.
400 L. Base area is 1 m²; volume is 0.4 m³. Convert to litres only after the geometric calculation is consistent.
0.1 m, or 10 cm. The additional 0.1 m³ divided by 1 m² gives the rise. The constant base area is essential.
1,800 L. Multiply 12 mm by 150 m² using the derived metric identity.
1,350 L. Multiply 1,800 by 0.75. This is inlet supply, not necessarily usable delivery after tank overflow.
36 mm/hour. Forty minutes is two-thirds hour. Divide 24 by two-thirds; do not treat 40 minutes as 0.40 hour.
40 L/min. The hourly volume is 30 × 100 × 0.8 = 2,400 L; divide by 60.
200 L overflow; 800 L remaining. Inflow first produces 1,200 L, capped at 1,000 L; delivery then removes 200 L.
No overflow; 1,000 L remaining. Demand first leaves 500 L, then the inflow fills the tank. Identical totals can produce different outcomes.
150 L delivered, zero stored and 70 L unserved. The unmet request is not a negative physical volume in the tank.
0.30 L/min; 432 L/day if unchanged. The observed volume is 18 L. The daily amount is a projection, not a day-long observation.
120 L per person per day. Divide 12,000 L by 100 person-days. Check that the population assumption matches the observation interval.
270 L. Calculate 300 + 1,000 − 950 − 80. Reverse-check: 950 + 80 + 270 = 1,300 L.
400–560 L. Multiply both rainfall bounds by 50 × 0.8. The interval has no stated statistical coverage probability.
No. At least 300 L of demand remains unsupported by supply even with perfect storage and no losses. Capacity does not create water.
210 L and 14 L/min. Add 30 and 180 L, then divide by 15 minutes. Unequal durations require time weighting.
It may have served demand before the required inflow arrived, or retained water that should have overflowed earlier. Check the full chronology, not only its endpoint.

How to teach the difference between a correct sum and a usable model

Start with a simple filling problem and ask the student to identify what is entering, what is leaving and what is already present. Then keep the arithmetic easy while changing one structural feature: add an outlet, introduce a capacity limit, reverse the event order or make demand exceed available water.

The strongest diagnostic task is to give two ledgers with identical total inflow and demand but different timing. Ask the learner to explain why their end storage or shortage differs. A learner who relies only on totals will miss the mechanism. A learner who tracks state after each event will see it.

For advanced learners, connect the discrete ledger to a rate graph and ask which interval first hits a constraint. Require a balance check and a sentence separating measured inputs from assumptions. These habits transfer directly to inventory, batteries, cash-flow timing and scheduling, although the interpretation of a shortage differs in each domain.

Sources and connected learning

Source routes for the real-world concepts are the USGS metric rainfall calculator, Surface Runoff and the Water Cycle, Impervious Surfaces and Flooding, and EPA WaterSense: Fix a Leak Week. The numerical cases and practice data are original teaching examples; these sources are not being represented as the origin of those invented measurements.

Use Electricity, Energy, Power and Bills for another rate-and-accumulation application, Packaging, Cutting and Material Waste for geometric capacity, and Scheduling, Critical Paths and Resources for the mathematics of event order. The data and decisions guide develops the distinction between an observation, an estimate and a supported conclusion. Return to the BTT Mathematics Hub to choose the next learning route.

Household water comparison lab: align units and time before comparing

Teaching dataset: the figures below are synthetic. The purpose is to practise unit conversion, rate normalisation and evidence reporting—not to describe any real household or water-efficiency benchmark.

Household	Recorded use	Residents	Measurement period
A	2.52 m³	4	7 days
B	9,900 L	3	30 days

Align the units. Since 1 m³ = 1,000 L, Household A used 2,520 L in 7 days.
Align the time base. A used 2,520 ÷ 7 = 360 L/day. B used 9,900 ÷ 30 = 330 L/day.
Decide whether household size matters. For per-person comparison, A used 360 ÷ 4 = 90 L/person/day. B used 330 ÷ 3 = 110 L/person/day.
Compare like with like. B uses 30 L/day less at whole-household level, but 20 L/person/day more after normalising for household size.
Quantify the per-person difference if useful. Relative to A, B’s per-person figure is 20 ÷ 90 ≈ 22.2% higher.

Short evidence report

“After converting both records to litres per day, Household A used 360 L/day and Household B used 330 L/day. The whole-household total is therefore lower for B. However, the households have different numbers of residents. On a per-person basis, A used 90 L/person/day while B used 110 L/person/day, so B’s per-person figure is about 22.2% higher. This comparison does not by itself explain why: occupancy patterns, guests, outdoor use, leaks and the measurement window would need investigation before making a causal or behavioural claim.”

Release test: change the units, time periods and household sizes. The learner should choose a common basis before comparing, state the denominator used, and separate the numerical comparison from unsupported explanations.

Correct Arithmetic, Unreliable Model: Sensitivity, Assumptions and Validation

A model can be calculated perfectly and still be untrustworthy.

The arithmetic may be exact. The graph may look smooth. The spreadsheet may contain no formula errors. The answer can still fail because the model assumes the wrong mechanism, ignores a physical limit, uses measurements outside their useful range or extends a short-term pattern far beyond the evidence.

That distinction matters in real-world Mathematics. Solving a model is not the same as validating a model.

A synthetic tank-filling example

The dataset below is original synthetic practice data. It is not a report of a real learner, facility or experiment.

Time after filling starts (min)	Recorded tank volume (L)
0	200
10	320
20	440
30	560
40	680

The pattern is exactly linear across the observed interval. Volume increases by (120) L every (10) minutes, so the net rate is:

[ rac{120}{10}=12 ext{ L/min}. ]

A natural model is:

[ V(t)=200+12t, ]

where (V) is measured in litres and (t) in minutes.

The arithmetic is correct. The model reproduces every training observation. That does not yet show that the model is reliable outside the observed interval.

State the assumptions before using the model

The linear equation quietly assumes several things:

the net flow remains constant at (12) L/min;
the measurement system is stable;
the tank does not overflow;
the inlet does not slow as pressure changes;
the outlet or leakage rate does not change;
there is no interruption to the pump;
the tank geometry does not affect the rate model;
time zero and the initial (200) L reading are accurate enough for the intended use.

These assumptions are not algebraic decorations. They are the bridge between the equation and the physical system.

Validation with unused observations

Now suppose two later synthetic observations are kept out of the original model construction:

Time (min)	Linear-model prediction (L)	Later observed volume (L)
50	800	785
60	920	875

The model predicts:

[ V(50)=200+12(50)=800 ]

and:

[ V(60)=200+12(60)=920. ]

The later measurements are lower. The discrepancy grows with time: (15) L at (50) minutes and (45) L at (60) minutes.

That pattern suggests that the assumption of constant net flow may be weakening. The model fitted the original interval perfectly and still began to fail on new observations.

Out-of-sample checking changes the question

Training fit asks: “How closely does the model reproduce the data used to construct it?”

Validation asks: “How well does the model perform on relevant information it did not use when it was built?”

The second question is often more important.

A model that memorises or perfectly matches observed data can still extrapolate badly. Validation checks whether the mathematical relationship remains useful when the system moves beyond the original fitting sample.

A physical capacity can reject the model before more data arrive

Suppose the tank has a maximum capacity of (900) L.

The linear model predicts:

[ V(60)=920 ext{ L}. ]

That exceeds the tank’s capacity. Even if no (60)-minute measurement were available, the physical constraint would tell us that the model cannot remain valid indefinitely.

This is a powerful model-checking habit: compare predictions with known bounds before trusting extrapolation.

Sensitivity: what happens if the rate estimate moves?

The model uses a net rate of (12) L/min. Suppose the true operating rate could plausibly differ by (1) L/min because of pump variation or uncertain outflow.

At (40) minutes:

with (11) L/min, the model gives (200+11(40)=640) L;
with (12) L/min, it gives (680) L;
with (13) L/min, it gives (720) L.

A rate uncertainty of only (1) L/min changes the (40)-minute prediction by (40) L in either direction.

That is sensitivity. A small change in one assumption produces a larger change in an output after the model has run for time.

Not every parameter has the same influence

Now suppose the initial volume is uncertain by (5) L. At any fixed time, that changes the prediction by only (5) L.

Compare:

initial-volume uncertainty of (pm5) L → prediction uncertainty of (pm5) L;
rate uncertainty of (pm1) L/min over (40) min → prediction uncertainty of (pm40) L.

For longer forecasts, uncertainty in the rate matters far more than the same-sized uncertainty in the starting volume.

This helps decide what should be measured more carefully.

Sensitivity is not the same as error

A sensitive model is not automatically a bad model. It means some inputs strongly influence the output.

The useful questions are:

Which parameters are sensitive?
How accurately can they be measured?
Does the intended decision tolerate the resulting uncertainty?
Can the model be redesigned so the most sensitive assumptions are checked more often?

Change one assumption at a time

Suppose the original constant-rate model is replaced by a simple piecewise model:

[ V(t)=200+12tquad ext{for }0le tle40. ]

After (40) minutes, suppose the effective net rate falls to (9.75) L/min because the system changes operating regime.

Then:

[ V(t)=680+9.75(t-40)quad ext{for }t>40. ]

This gives:

[ V(60)=680+9.75(20)=875, ]

which matches the synthetic validation observation at (60) minutes.

The piecewise model fits better because it acknowledges a changed regime. But fitting the new point does not prove that (9.75) L/min is the true mechanism. It is one candidate explanation that now needs further evidence.

Better fit does not automatically mean better model

A more complicated equation can nearly always fit a small dataset more closely.

The modeller should ask:

Does the extra parameter correspond to something real?
Does the model improve prediction on fresh data?
Does it respect physical constraints?
Is the complexity justified by the intended use?
Can another simpler model perform almost as well?

A complicated curve that chases every measurement fluctuation can be less useful than a simpler model that captures the stable mechanism.

Measurement limits belong in the mathematics

Suppose tank volume is estimated from a level sensor with an uncertainty of roughly (pm5) L. Then differences smaller than that scale should be interpreted cautiously.

If one model predicts (680) L and another predicts (682) L at the same time, the measurement system may not support a strong claim that one is empirically superior.

Precision in the written answer should reflect precision in the evidence.

Units can invalidate a model before calculation

If a flow rate is (12) L/min and time is entered in hours without conversion, the numerical output becomes meaningless even if the formula is typed correctly.

For two hours:

[ 2 ext{ h}=120 ext{ min}. ]

The linear model would use:

[ V=200+12(120), ]

not (200+12(2)).

Unit consistency is a model check, not a formatting detail.

Boundary behaviour can expose implausibility

Ask what the model predicts at extreme values.

For:

[ V(t)=200+12t, ]

large positive (t) produces arbitrarily large volume. A finite tank cannot behave that way. Negative (t) may also produce times before the chosen start of the model that have no operational meaning.

A model can be useful on a limited interval even when it is absurd globally.

The validity interval should therefore be stated.

Correct calculation, wrong variable relationship

Imagine a learner assumes that water depth in a non-rectangular tank increases linearly with volume. If the tank widens with height, equal increases in volume do not create equal increases in depth.

The algebra can be flawless once the linear relationship is assumed. The model is still unreliable because the geometric relationship is wrong.

This is why real-world Mathematics begins before the equation.

Model-building checklist

What question must the model answer?
What variables represent the system?
What units belong to each variable?
What relationship is being assumed?
Which assumptions are structural and which are temporary approximations?
What data were used to build the model?
What data remain available for validation?
What physical or logical bounds must predictions respect?
Which parameters are most sensitive?
Where should the model not be used?

A second synthetic example: rainfall and collection

Suppose a flat collection surface has area (20 ext{ m}^2), and rainfall depth during a short storm is (8) mm.

Convert:

[ 8 ext{ mm}=0.008 ext{ m}. ]

Ideal rainfall volume on the surface is:

[ 20(0.008)=0.16 ext{ m}^3=160 ext{ L}. ]

A naive model might predict that the tank gains (160) L.

But this assumes (100%) collection efficiency. Real systems may lose water through splash, first-flush diversion, gutter overflow or incomplete drainage.

If collection efficiency is assumed to be (80%), the model predicts:

[ 0.80(160)=128 ext{ L}. ]

The arithmetic is simple. The model judgement lies in whether (80%) is defensible for the system and storm conditions.

Sensitivity to collection efficiency

For the same (160)-L ideal rainfall volume:

(70%) efficiency → (112) L collected;
(80%) efficiency → (128) L collected;
(90%) efficiency → (144) L collected.

A (10)-percentage-point change in assumed efficiency moves the prediction by (16) L.

If the decision threshold is whether the tank will overflow by only (5) L, that uncertainty matters. If the tank has (500) L of spare capacity, it may not matter operationally.

Model quality depends partly on the decision the model is being used to support.

Residual thinking without advanced statistics

A residual is observed value minus predicted value.

For the tank example:

at (50) min: (785-800=-15) L;
at (60) min: (875-920=-45) L.

Both residuals are negative and their magnitude grows. That pattern is more informative than two isolated errors. It suggests systematic overprediction rather than random noise around a stable linear model.

Random-looking errors and structured errors are different

If residuals alternate around zero with no visible pattern and remain small relative to measurement uncertainty, the model may still be useful.

If residuals drift in one direction, grow with time or change with operating conditions, the structure may be missing something.

Validation is not the same as confirmation

Do not use validation merely to collect examples that agree with the model. Use it to give the model a chance to fail.

Useful stress tests include:

a longer time horizon;
a different operating rate;
a near-capacity condition;
a lower inflow condition;
a measurement from another day;
a changed outlet rate;
a scenario near a physical boundary.

Fresh transfer problem

A tank starts at (150) L. During the first (30) minutes, volume rises by (10) L/min. A learner proposes:

[ V(t)=150+10t ]

for all future (t).

The tank capacity is (600) L.

Answer:

At what time does the linear model reach (600) L?
What assumption is being made about net flow?
Why is the formula not credible beyond the point where it predicts more than (600) L?
If the net rate after (30) minutes falls to (6) L/min, build a piecewise model.
What fresh observation would be useful for checking the changed-rate assumption?

The first calculation is:

[ 600=150+10t, ]

so:

[ t=45 ext{ min}. ]

The rest of the problem is not arithmetic. It is model judgement.

The durable model loop

Define → choose variables → state units → state assumptions → calculate → compare with data → test sensitivity → check bounds → validate on fresh information → revise or restrict the model.

A correct calculation earns confidence only inside a model whose assumptions and evidence survive those checks.

Continue through BTT Mathematics

Use IB Mathematics AI | Modelling and Functions for the curriculum-specific modelling route. Use How to Check Maths Answers for the wider verification system. Return to the World Mathematics Atlas for modelling, functions, statistics and applied Mathematics connections.

Water Modelling Casebook: Sensitivity, Assumptions and Validation

The examples below are original synthetic Mathematics exercises. They are not measurements from a real household, reservoir, building or learner project. Their purpose is to show how a model can be arithmetically correct while remaining operationally unreliable.

Case 1: the same rainfall depth does not guarantee the same collected volume

Suppose two storms each deliver 12 mm of rainfall over a 25 m² roof.

The ideal incident rainfall volume is:

0.012 × 25 = 0.300 m³ = 300 L.

If the first storm is gentle and the synthetic collection efficiency is assumed to be 90%, the collected amount is:

0.90 × 300 = 270 L.

If the second storm is intense enough that gutters spill and effective collection falls to 65%, the collected amount is:

0.65 × 300 = 195 L.

The rainfall total is identical. The operational mechanism is not. A model that uses rainfall depth alone has omitted a potentially important variable.

Case 2: sensitivity to roof-area measurement

Suppose roof area is estimated as 25 m² but may actually lie between 24 m² and 26 m². With 12 mm rainfall and 80% collection efficiency:

24 m² → 0.012×24×1000×0.80 = 230.4 L;
25 m² → 240.0 L;
26 m² → 249.6 L.

A ±1 m² area uncertainty changes the prediction by ±9.6 L for this event. Whether that matters depends on the decision. If the tank has 400 L spare capacity, perhaps not. If overflow margin is 5 L, it matters greatly.

Case 3: sensitivity is decision-relative

A parameter can be mathematically sensitive but operationally unimportant for one decision and critical for another.

Suppose two plausible models predict 242 L and 250 L collected. If the question is whether at least 100 L will be collected, both support the same decision. If the question is whether a 245 L spare tank volume will overflow, the model difference becomes decisive.

Validation should therefore ask not only “How wrong might the model be?” but “Could that error change the decision?”

Case 4: a linear tank-height model can be geometrically wrong

Imagine a tank whose cross-sectional area increases with height. Equal additions of volume produce smaller increases in depth near the top because the water spreads across a wider area.

If a learner assumes:

height = constant × volume

the arithmetic may be flawless but the model is structurally wrong unless the tank cross-section is constant.

The correct relationship depends on tank geometry. A cylindrical vertical tank has constant horizontal cross-section; a tapered tank does not.

Case 5: capacity creates a hard bound

Suppose a 700 L tank currently contains 500 L. A model predicts an additional 260 L during a storm.

Physical storage cannot rise to 760 L without overflow. The model should separate:

inflow arriving at the tank;
volume stored;
overflow leaving the system.

If 260 L arrives, maximum stored volume is 700 L and at least 60 L must overflow, assuming no simultaneous outflow.

A physical bound can invalidate a naive result before any advanced statistical validation is attempted.

Case 6: demand timing changes storage even when total demand is unchanged

Suppose a household synthetic model uses 180 L total demand during a six-hour interval. If demand occurs steadily at 30 L/h, a storage tank may remain above its minimum level. If 150 L is drawn in the first hour and only 30 L over the next five hours, the same total demand can create a temporary shortage.

Totals alone do not always preserve operational behaviour. Event order can matter.

Case 7: same daily average, different peak demand

Two days each use 240 L over 24 hours, so average demand is 10 L/h.

Day A uses water nearly uniformly. Day B uses 100 L between 7:00 and 8:00 and the rest slowly. A model based only on daily average can underestimate the flow capacity or storage needed at peak times.

This is a general modelling lesson: averages can hide timing structure.

Case 8: leak detection from a night-time baseline

Suppose a synthetic meter records 18 L between 2:00 a.m. and 4:00 a.m. when no intentional water use is reported. A simple average unexplained flow estimate is:

18 L / 2 h = 9 L/h.

This does not prove a leak. Possible explanations include an appliance cycle, inaccurate reporting, meter resolution or a genuine leak.

The Mathematics can quantify unexplained flow. Diagnosis of the physical cause requires more evidence.

Case 9: validation through repetition

If similar unexplained flow appears over several comparable nights, the hypothesis becomes more credible. If the reading disappears when a known appliance is disabled, the model changes again.

Validation is iterative: measure, model, test, revise.

Case 10: measurement resolution limits conclusions

Suppose a meter reports only to the nearest litre. Differences of 0.2 L between model and observation cannot be treated as meaningful empirical superiority because the instrument does not resolve that difference.

The numerical model may produce decimals. The measurement system may not justify them.

Case 11: rainfall measurement uncertainty

Assume a rain gauge reading is 10 mm with plausible uncertainty of ±0.5 mm. For a 30 m² collection surface and 80% efficiency:

9.5 mm → 228 L;
10.0 mm → 240 L;
10.5 mm → 252 L.

The rainfall measurement uncertainty alone creates a ±12 L range before uncertainty in area or efficiency is considered.

Case 12: parameter uncertainty can compound

Suppose both rainfall depth and collection efficiency are uncertain. Rainfall lies between 9.5 and 10.5 mm, while efficiency lies between 75% and 85%.

For 30 m²:

Low-end collection:

0.0095×30×1000×0.75 = 213.75 L.

High-end collection:

0.0105×30×1000×0.85 = 267.75 L.

The combined range is much wider than a single best-estimate calculation suggests.

Case 13: sensitivity table

Rainfall (mm)	Efficiency	Predicted collection for 30 m² (L)
9.5	75%	213.75
9.5	85%	242.25
10.5	75%	236.25
10.5	85%	267.75

A small table can reveal which assumptions matter enough to deserve better measurement.

Case 14: change one assumption, not five

When a model fails, changing many parameters simultaneously can make the new fit impossible to interpret. A better diagnostic changes one assumption at a time where practical.

If a tank model overpredicts volume, first test whether inflow rate is lower than assumed. Then inspect outflow or leakage. Then inspect geometry or measurement. This preserves causal interpretability.

Case 15: model fit versus mechanism

A quadratic equation may fit six observed points better than a straight line. That does not prove the physical process is quadratic.

A flexible curve can absorb noise. A mechanism-based model asks why the terms should exist. Better fit is evidence, not automatic explanation.

Case 16: overfitting in a tiny synthetic dataset

Suppose five tank readings are available. A fourth-degree polynomial can pass through all five points exactly. It has zero training residual at those points.

That does not make it a good operational model. Predictions just outside the sample can behave wildly, and the polynomial may have no physical interpretation.

A simpler model with small residuals and a defensible mechanism can be more useful.

Case 17: out-of-sample checking

Split synthetic observations into a fitting set and a checking set. Build the model from the first set only. Then compare predictions with the withheld observations.

This prevents the model from receiving credit merely for reproducing data it already used.

Case 18: residual direction matters

Suppose residuals are:

-2, -5, -9, -15, -23.

The growing negative pattern suggests systematic overprediction. The model may be missing a slowing mechanism.

By contrast, residuals such as +3,-2,+1,-4,+2 may be more consistent with small noise around an adequate simple model, depending on measurement scale.

Case 19: residual size needs a reference scale

An error of 5 L may be negligible in a 50,000 L system and critical in a 20 L container. Absolute residuals should be interpreted relative to system scale and decision tolerance.

Case 20: extrapolation deserves a separate warning

A model validated between 0 and 60 minutes has not automatically been validated at 6 hours. Long extrapolation can amplify small rate errors and cross physical regime changes.

The further the model travels beyond observed conditions, the stronger the justification required.

Case 21: interpolation is not risk-free either

Predicting inside the observed interval is usually safer than far extrapolation, but it can still fail if the mechanism changes between sparse observations.

A model should not treat “inside the range” as a guarantee.

Case 22: piecewise models can encode regime changes

Suppose inflow is 12 L/min for the first 20 minutes and 8 L/min afterwards. A piecewise model is more honest than forcing one average rate onto the entire interval.

If initial volume is 100 L:

V(t)=100+12t for 0≤t≤20.

At 20 minutes, V=340 L.

For t>20:

V(t)=340+8(t−20).

The model records the changed operating regime explicitly.

Case 23: but a piecewise model still needs evidence

Choosing 20 minutes as the change point because it fits the data neatly is not enough. The modeller should ask whether a pump setting, valve change, pressure effect or other mechanism supports the break.

A fitted breakpoint is a hypothesis until independently justified.

Case 24: volume balance as a conservation law

A useful water model begins with accounting:

change in storage = inflow − outflow

over a stated interval, with units aligned.

This identity is more durable than any specific numerical rate. It provides the structural spine from which simple or complex models can be built.

Case 25: conservation does not tell you the rates automatically

The balance identity can be correct while the estimated inflow and outflow are wrong. Structure and parameter estimation are different jobs.

Validation has to test both.

Case 26: unit conversion as model governance

Suppose inflow is 0.2 L/s and the model time step is 5 minutes.

Convert:

5 min = 300 s.

Volume added is:

0.2×300 = 60 L.

Using 0.2×5 would mix seconds and minutes and understate inflow by a factor of 60.

Case 27: dimension checks can catch silent spreadsheet errors

If a column meant to represent litres per minute is added directly to a column representing litres, the spreadsheet may calculate without warning. Dimensional reasoning reveals that the operation is invalid unless a time interval converts rate into volume.

Case 28: daily totals can hide impossible instantaneous flows

A model may correctly match total daily consumption while implying a flow rate above the pipe or pump capacity during some interval.

Validation should check both aggregate totals and local physical constraints.

Case 29: model purpose should be declared

A model suitable for rough household planning may not be suitable for engineering design. A model suitable for classroom illustration may not support a public operational decision.

The required precision, validation burden and safety margin depend on purpose.

Case 30: synthetic data must stay labelled synthetic

Original practice data are useful because they allow controlled examples and known mechanisms. They must not be presented as measured household behaviour, learner results or empirical research.

Labelling protects the boundary between teaching illustration and evidence about the world.

Case 31: source data need provenance

If real data are used, record where they came from, what units they use, the time period, any missing values and whether the measurement process changed.

A clean calculation cannot repair uncertain provenance.

Case 32: model validation needs a failure condition

Before testing, decide what would make the model unacceptable. Examples:

prediction error exceeds 20 L;
overflow is predicted incorrectly;
residuals show systematic drift;
unit or physical constraints are violated;
performance collapses under a modest parameter change.

Without a failure condition, validation can become a search for confirming evidence.

Case 33: sensitivity to demand rate

A storage model begins with 500 L and receives 40 L/h inflow. Demand is estimated at 35 L/h, giving net gain 5 L/h.

If actual demand is 38 L/h, net gain is only 2 L/h. If actual demand is 42 L/h, storage declines by 2 L/h.

A 7 L/h span in demand changes the qualitative direction of storage.

Case 34: threshold sensitivity

Suppose an alarm triggers below 450 L. Starting at 500 L:

net −2 L/h reaches threshold after 25 h;
net −5 L/h reaches threshold after 10 h.

Small uncertainty in net rate can produce large uncertainty in threshold time.

Case 35: forecast horizon amplifies rate error

If rate estimate error is ±0.5 L/min, then after:

10 min → ±5 L;
60 min → ±30 L;
240 min → ±120 L.

Long forecasts are more sensitive to persistent rate bias.

Case 36: a model can be locally useful and globally false

A linear approximation may work well over a narrow range even if the true relationship is curved. This is not a contradiction. Models are often intentionally local.

The validity interval should be stated so users do not extend the approximation beyond its evidence.

Case 37: rainfall intensity and drainage capacity

Two storms may both deliver 20 mm total rainfall. If one lasts 10 hours and another 20 minutes, the intensity differs dramatically.

A collection or drainage model based only on total depth can miss short-term capacity limits.

Case 38: flow rate versus total volume

A pump may deliver 600 L over one hour. That average is 10 L/min. It does not prove the instantaneous rate was constant at 10 L/min throughout the hour.

Average rate is a summary. A dynamic model may need higher-resolution timing data.

Case 39: validate the transformation from sensor reading to quantity

A sensor may measure water depth while the model needs volume. The depth-to-volume conversion depends on tank geometry and calibration.

If that transformation is wrong, every downstream calculation inherits the error even if the spreadsheet formulas are correct.

Case 40: checking a model with a second representation

Plot predicted and observed storage over time. A table may show exact residual values; a graph may reveal drift or regime change visually.

Neither representation replaces the other. Together they provide stronger diagnostic resolution.

Case 41: model revision should preserve the audit trail

When changing a rate, efficiency or functional form, record what changed and why. Otherwise a model can improve numerically while losing transparency.

In classroom work, a short note is enough: “Revised from constant 12 L/min to piecewise 12 then 9.75 L/min because withheld observations showed growing overprediction after 40 minutes.”

Case 42: avoid tuning to the validation set indefinitely

If the modeller repeatedly changes the model after seeing every validation observation, the validation set gradually becomes part of training.

Where possible, reserve fresh information for a later check or describe honestly that the model has been revised using the previous validation data.

Case 43: validation can reject a beautiful model

A model may be elegant, easy to calculate and easy to explain. If it violates observed behaviour or physical constraints, elegance is not enough.

Case 44: a messy model can also be inappropriate

Adding parameters until every observation is reproduced can destroy interpretability and generalisation. Complexity should earn its place.

Case 45: solve versus validate

Solving asks: given the model and parameters, what output follows?

Validating asks: is this model a defensible representation for the intended use?

The two questions must remain separate.

Case 46: model comparison table

Criterion	Model A	Model B
Training fit	Very good	Good
Fresh-data fit	Poor	Good
Physical bounds	Violated after 60 min	Respected
Interpretability	Low	High
Parameters	Many	Few

Model B may be preferable even though Model A fits the original data more closely.

Case 47: validation question for students

Ask a learner: “What observation would make you stop trusting your model?”

If the student cannot answer, the model has no operational failure boundary yet.

Case 48: sensitivity question for students

Ask: “Which assumption would you measure more carefully if you could improve only one?”

This forces the learner to connect parameter uncertainty with decision impact.

Case 49: transfer beyond water

The same modelling habits apply to electricity, finance, transport, population, packaging and scheduling:

define variables;
align units;
state assumptions;
calculate;
test bounds;
inspect sensitivity;
validate on fresh evidence;
revise or restrict the model.

Case 50: model release checklist

Purpose stated?
Variables defined?
Units aligned?
Assumptions visible?
Physical or logical bounds checked?
Parameter sensitivity inspected?
Training and validation evidence separated?
Residual pattern inspected?
Validity interval stated?
Fresh transfer task completed?

Final modelling compact

Correct arithmetic is necessary. It is not enough. A usable model must also survive assumptions, units, bounds, sensitivity, withheld evidence and the decision context for which it is being used.

Return to IB Mathematics AI | Modelling and Functions for the curriculum-specific modelling route, or How to Check Maths Answers for the wider verification system.

Model Release Tests: When Is the Water Model Good Enough to Use?

A model does not need to describe every physical detail to be useful. It needs to be good enough for its stated purpose, within a stated range, with known assumptions and a checking process proportionate to the decision.

Release test 1: purpose

State the decision before judging the model. A rough household planning estimate has a different burden from an engineering safety calculation. The same equation may be acceptable for one purpose and inadequate for another.

Release test 2: variable identity

Every symbol should have one clear meaning. If V is stored volume, do not later use the same symbol for inflow volume. If r is net rate, state whether outflow has already been subtracted.

Ambiguous variables create errors that no calculator can detect.

Release test 3: units

Write units beside each input before calculation. Convert litres per second, litres per minute, millimetres of rainfall and square metres of collection area into a coherent system.

A dimensionally inconsistent model fails before any numerical answer is considered.

Release test 4: physical bounds

Ask whether the model can predict negative storage, volume above capacity, impossible flow rates or collection greater than incident rainfall.

Known physical limits are among the strongest and cheapest validation checks.

Release test 5: parameter sensitivity

Change one uncertain parameter by a plausible amount. Does the output barely move or change enough to alter the decision?

Highly sensitive parameters deserve better measurement, more frequent updating or a larger safety margin.

Release test 6: residual pattern

Compare predictions with observations. Random-looking small residuals and systematic drift tell different stories.

A model that is always too high after a certain point may be missing a regime change. A model whose residuals grow with time may contain a persistent rate bias.

Release test 7: fresh evidence

Use at least one observation that was not used to set the model parameters where possible. This tests whether the relationship travels beyond the data that created it.

Release test 8: changed condition

Test the model under a different rainfall intensity, demand pattern, starting volume or flow regime. A model that works only under one narrow setup should say so explicitly.

Release test 9: decision threshold

If the decision depends on a threshold—overflow, minimum storage, pump activation or shortage—inspect uncertainty near that threshold.

A model that predicts 498 L versus a 500 L threshold should not be treated with the same confidence as one predicting 300 L.

Release test 10: failure statement

Write one sentence describing when the model should not be trusted. Examples:

“Do not extrapolate beyond 60 minutes.”
“Assumes constant net inflow.”
“Not valid once the tank reaches capacity.”
“Collection-efficiency estimate is illustrative, not measured.”

A visible failure statement is a mark of model maturity, not weakness.

Mini validation lab

A synthetic tank contains 250 L at time zero. The proposed model is:

V(t)=250+7t, with t in minutes and V in litres.

The tank capacity is 600 L.

At what time does the model predict capacity?
If a withheld observation at 40 minutes is 515 L, what is the residual?
If a withheld observation at 45 minutes is 535 L, does the residual pattern support or weaken the constant-rate assumption?
What happens if the true rate is 6.5 L/min rather than 7 L/min?
Which conclusion is mathematical, and which conclusion requires physical evidence?

The model reaches capacity when:

600=250+7t, so t=50 minutes.

At 40 minutes the model predicts 530 L, so residual is 515−530=−15 L. At 45 minutes it predicts 565 L, so residual is 535−565=−30 L. The growing negative residuals weaken the constant-rate model.

If the rate were 6.5 L/min, the 45-minute prediction would be:

250+6.5(45)=542.5 L, much closer to 535 L.

That does not prove the rate is 6.5 L/min. It identifies a plausible revised hypothesis that should be tested on fresh evidence.

What the learner should now be able to say

“I can solve the equation” is only the first layer. The stronger statement is:

“I know what the variables mean, which assumptions create the equation, what units are required, which bounds the output must respect, how sensitive the forecast is to uncertain parameters, and what fresh observation could make me revise the model.”

Final release compact

Build → calculate → challenge → validate → restrict or revise.

A model becomes trustworthy enough for a stated classroom decision only after the learner has tried to make it fail.

Final Model Note: Arithmetic Answers the Equation; Validation Answers Whether the Equation Deserves Use

The water examples on this page deliberately keep those two jobs separate. Once a relationship is chosen, calculation may be routine. The harder judgement comes before and after the arithmetic: whether the variables represent the right quantities, whether rates and units are aligned, whether physical bounds are respected, and whether the model survives information it did not use when it was built.

A student who can calculate tank volume, rainfall collection or net flow accurately has learned an important part of the Mathematics. A student who can also state the assumptions, identify the most sensitive parameter, recognise a validity boundary and propose a fresh validation observation has moved into mathematical modelling.

That distinction protects against false precision. A spreadsheet can return many decimal places. A fitted curve can pass perfectly through a small dataset. Neither result guarantees that the system has been represented well enough for the intended decision.

The release standard is therefore practical: solve the model correctly, then try to break it. Change an assumption. Test a boundary. Compare with withheld information. Inspect units. Ask what measurement uncertainty could change the conclusion. If the model survives those challenges within its declared use, confidence becomes earned rather than assumed.

For modelling, the strongest final habit is to write down what would make the equation stop being trustworthy. A model with a visible failure boundary is safer and more useful than a beautifully calculated model whose assumptions remain hidden.