The measurement is not the number: a practical guide to uncertainty

A display says 21.37 °C. The temptation is to treat every digit as knowledge.

It might be. It might also be a sensor accurate to half a degree, mounted beside a warm power supply, reporting a value rounded from a noisy conversion. The display has resolution. The measurement still has a history.

That distinction matters well beyond laboratories. It appears in server benchmarks, health trackers, energy monitors, API timings, battery estimates, and almost any dashboard that turns a physical or digital process into a number.

A measurement is not a fact extracted cleanly from the world. It is an estimate produced by a method.

Define what is actually being measured

Before worrying about decimal places, define the quantity of interest. In metrology this is called the measurand: the particular quantity intended to be measured.

“Room temperature” sounds clear until the measurement has to be repeated. Temperature where? At desk height or ceiling height? Beside the window or in the centre? At what time, after how long, and with what air movement?

The same problem appears in software:

• “API latency” might mean time measured at the server, at a load generator, or in a user’s browser.
• “CPU usage” might mean one busy core, an average across the machine, or a container’s share of a quota.
• “Sleep duration” might mean time in bed, time inferred as asleep, or the interval between two device events.

A precise answer to a vague quantity is still a vague result.

Write the definition before collecting the data. It is often the most valuable line in the eventual report.

Repeatability is not accuracy

Repeated observations help reveal random variation. If a scale reports the same mass ten times, it is behaving repeatably under those conditions.

That does not prove it is accurate. A stable calibration error can move every reading in the same direction. Repetition makes the cluster easier to see; it does not tell you whether the cluster is centred on the right value.

This is why “I ran it five times” is useful but incomplete. Repeated runs can describe run-to-run scatter. They cannot, by themselves, detect:

• a clock that consistently runs fast;
• a temperature probe with a calibration offset;
• a benchmark that omits an important part of the workload;
• a health tracker that classifies one kind of movement poorly;
• a load test running from an unrealistically fast network position.

The practical question is not only “does it repeat?” It is also “what could make all of these observations wrong together?”

Resolution is not uncertainty

Resolution describes the smallest change an instrument or system can display. It does not automatically describe how closely the result represents the quantity of interest.

Consider a hypothetical temperature probe that displays tenths of a degree, varies by only 0.1 °C when left in place, and has a manufacturer accuracy specification of ±0.5 °C.

Reporting the average as 21.37 °C would create an impression the setup cannot support. Repeated observations may justify confidence about short-term stability, but they do not remove the larger instrument specification or the uncertainty caused by placement.

The display can generate more digits than the experiment has earned.

Build an uncertainty budget

An uncertainty budget is simply an organised list of the effects that could move the result. Formal work assigns each contribution a value and combines them according to an accepted method. A practical investigation can begin with the list.

Useful categories include:

• Instrument: calibration, resolution, drift, sampling rate, and conversion behaviour.
• Method: timing boundaries, setup choices, definitions, and data exclusions.
• Environment: temperature, power, network position, competing workloads, and operator effects.
• Sample: whether the observed devices, people, requests, or time periods represent the intended population.
• Processing: rounding, filtering, clock synchronisation, missing values, and aggregation.

NIST separates uncertainty evaluations into two broad types. Type A uses statistical analysis of observations. Type B uses other available information, such as calibration reports, specifications, previous data, and knowledge of the method. “Type B” does not mean inferior; it describes a different route to an estimate.

That is a useful mental model for everyday technical work: calculate what the data can reveal, then account for what repeated data cannot reveal on its own.

Use significant digits as an editorial decision

Rounding is not cosmetic. It communicates how much confidence the reader should place in the result.

Suppose a timing tool emits:

mean response time: 18.734928 ms

If run-to-run variation is several milliseconds, reproducing six decimal places in an article adds visual precision without adding information. 18.7 ms or even 19 ms may be the more honest report, accompanied by the spread and test conditions.

Keep the raw data at its available resolution. Round the published result to a precision supported by the uncertainty and the decision being made.

Match the effort to the decision

Not every measurement needs a formal laboratory uncertainty calculation. Uncertainty work should be proportionate to the consequence of being wrong.

For a rough check that a fan curve changed in the expected direction, a consistent sensor and repeatable workload may be enough. For a purchasing recommendation, health claim, safety threshold, or public-sector business case, the standard should be considerably higher.

Ask:

1. What decision will this number support?
2. How large a difference would change that decision?
3. Which uncertainty source could plausibly be that large?
4. Can it be reduced, estimated, or made visible?

This prevents two opposite mistakes: pretending a rough estimate is exact, and spending days refining a value that is already adequate for the decision.

Report the result as a small argument

A useful measurement report contains more than a value:

• the quantity and conditions;
• the result at defensible precision;
• the important sources of uncertainty;
• the number and spread of repeated observations, when relevant;
• the limits on interpretation;
• the decision the evidence can and cannot support.

For the hypothetical temperature example, an honest summary might be:

The probe indicated approximately 21.4 °C at desk height after 20 minutes in position. Readings varied by 0.1 °C; the instrument specification is ±0.5 °C, and temperature variation across the room was not measured.

That statement is longer than 21.37 °C. It is also much more useful.

The useful insight

More digits answer “what did the system print?” Uncertainty answers “what can this result support?”

Once that distinction becomes habitual, dashboards and benchmark tables look different. The first question is no longer whether a number appears precise. It is whether the definition, method, and uncertainty make it meaningful.

Sources and further reading

• NIST Technical Note 1297: Guidelines for Evaluating and Expressing the Uncertainty of NIST Measurement Results
• NIST measurement uncertainty resources