Skip to content

Engineering Equation Sanity Check

Sanity-check review — instantiates Dimensional Consistency Check

Checks a formula and its computed result for both dimensional coherence and physically plausible magnitude before the number is trusted.

Engineering Equation Sanity Check is the fast, judgement-heavy pass an experienced practitioner runs over a formula and its output before acting on it. It asks two questions at once: do the dimensions work out, and is the answer physically believable in size? Its defining feature is the second half — the plausibility test. A calculation can be dimensionally perfect and still land three orders of magnitude off because of a dropped factor, a wrong exponent, or a mis-entered constant, and only a sense of what the number should be catches that. Where a unit check compares labels and a table proves homogeneity, this mechanism compares the result against physical reality and tolerances, including how the formula behaves at its extremes.

Example

An engineer computes the electrical power a pump motor will draw and the spreadsheet returns 4.2 megawatts. The units are clean — watts, exactly what power should be — so a pure unit check passes. The sanity check does not. A pump for this duty should draw a handful of kilowatts; a megawatt-scale answer is roughly a thousand times too large, which is the fingerprint of a unit-prefix slip. Tracing back, flow rate was entered in litres per second but the constant assumed cubic metres per second — a factor of 1000, dimensionally invisible because both are volume-per-time.[1]

The check also probes the edges. What does the formula give as flow approaches zero, or as head approaches the pump's maximum? If power fails to fall toward zero at zero flow, or blows up where it should plateau, the equation is structurally wrong regardless of any single number. And the plausible answer is accepted only within a tolerance band — "single-digit kilowatts, give or take" — rather than to a false five-significant-figure precision. The output is a pass, a flag, or a rebuild, decided by whether the magnitude sits inside that band and behaves sanely at the limits.

How it works

  • Check dimensions first. Confirm the operations are dimensionally legal — you are not adding a rate to a total or comparing incompatible quantities — as the cheap precondition.
  • Estimate what the answer should be. Form an independent order-of-magnitude expectation from first principles or a known comparable, before looking at the computed value.
  • Compare against a tolerance band. Accept the result only if its magnitude sits within a plausibility range; a result outside the band is treated as suspect no matter how precise it looks.
  • Probe the limits. Send inputs to their extremes (zero, maximum, negative if meaningful) and check the output stays physical — a formula that misbehaves at the boundary is wrong in the middle too.

Tuning parameters

  • Plausibility tolerance — how wide the acceptable-magnitude band is. Tight bands catch subtle errors but raise false alarms; loose bands only catch gross ones.
  • Independence of the estimate — whether the expectation is formed from scratch or anchored on a similar prior result. A fully independent estimate catches more but costs more thought.
  • Edge-probe set — which extremes you test and how many. More limits examined means more structural errors caught, at more effort.
  • Rigor level — a ten-second gut check versus a documented back-of-envelope derivation; match it to how consequential and how novel the calculation is.

When it helps, and when it misleads

Its strength is speed and reach: it is the cheapest way to catch the errors that hurt most — order-of-magnitude blunders and structurally wrong formulas — and it needs no tooling, only judgement and a feel for the domain.

Its weakness is exactly that reliance on judgement. It depends on the checker already knowing the right ballpark, so it is blind in unfamiliar domains and can wave through an error that happens to land inside a too-wide plausibility band. Its classic misuse is motivated sanity-checking — deciding the surprising-but-correct answer "can't be right" and forcing it back toward the expected value, using the check to reject good news rather than test it. The discipline is to treat a plausibility flag as a trigger to investigate, not to overwrite, and to widen the band when the domain is genuinely unfamiliar.

How it implements the components

  • consistency_test — the dimensional-and-magnitude pass is the test, extended past units to physical plausibility.
  • operation_compatibility_rule — the precondition it enforces: the operations in the formula must be dimensionally legal before any magnitude is judged.
  • tolerance_threshold — the plausibility band that decides pass versus flag is an explicit tolerance on the result.
  • edge_case_quantity_check — sending inputs to their extremes to confirm the output stays physical is a core move, not an afterthought.

It does not lay out the full variable-and-dimension table it draws on (that is Dimensional Analysis Table), nor perform the correction once an error is found (that is Unit Conversion Workflow); it judges whether the result can be believed.

  • Instantiates: Dimensional Consistency Check — this is the archetype in its fastest, most judgement-driven form, adding magnitude plausibility to the dimensional test.
  • Sibling mechanisms: Unit Check · Dimensional Analysis Table · Cross-Scale Transfer Review · Dimensionless Ratio Construction · Finance / Accounting Unit Check · Model Input / Output Contract · Normalized Metric Design · Per-Capita or Per-Unit Conversion · Spreadsheet Unit Audit · Stock / Flow Separation Check · Unit Conversion Workflow

References

[1] Fermi estimation — reasoning to an order-of-magnitude answer from first principles — is the standard technique for forming the independent expectation this check compares against. Its value here is not precision but a yardstick precise enough to expose a factor-of-1000 error.