Sanity check

Version

v3 · 2026-09-28 · History

Prime #

1548

Domain group

Applied Sciences & Engineering

Origin domain

Engineering & Design (beyond software)

Aliases

Sanity test, Plausibility check

Core Idea

A sanity check is a deliberately inexpensive preliminary test that detects gross impossibility or inconsistency without attempting complete validation. The abstraction is not exhausted by its familiar source-domain notation. Its autonomous core is rapid necessary-condition screening for gross error before deeper validation.

The operative mechanism is this: A result is compared with conserved quantities, dimensional constraints, limiting cases, rough estimates or independently known ranges; failure halts or redirects analysis, while passage only licenses further checking. The mechanism separates identity from observation. A case does not qualify merely because an observer can describe it using the word sanity check; the constitutive relation must be present in the carrier.

How would you explain it like I'm…

The Silly-Mistake Check

A sanity check is a quick look to see if an answer is silly. If you count your toys and get a million, you know right away something went wrong. But getting a sensible number doesn't prove you counted right; it just means nothing is obviously wrong.

Quick Does-This-Make-Sense Test

A sanity check is a fast, easy test to catch big, obvious mistakes before you do a careful check. If you add up your lunch money and the total says you spent $500 on one sandwich, you know something is wrong without redoing all the math. You compare your answer to a rough guess, or to what makes sense in the real world. If the answer fails, you stop and look for the mistake. If it passes, that doesn't mean it's correct; it just means it's not obviously wrong, and you can keep checking.

Quick Plausibility Check

A Sanity Check is a deliberately cheap, rough test that catches gross errors or impossibilities without trying to fully confirm a result. You compare the result with things you already know must be true: units that must match, totals that must be conserved, extreme cases with known answers, rough estimates, or known ranges. If it fails, you stop or rethink. If it passes, you only earn the right to keep checking; it is never proof of correctness. Treating a passed sanity check as full verification is the classic misuse. Examples include checking that probabilities add to 1, that a program's output has the expected length, or that a bridge calculation gives a plausible order of magnitude.

 

A sanity check is a deliberately inexpensive preliminary test that detects gross impossibility or inconsistency without attempting complete validation. The mechanism compares a result against conservation laws, dimensional constraints, limiting cases, order-of-magnitude estimates, or independently known ranges. Failure halts or redirects the analysis; passing only licenses further checking. The defining invariants are that the test is cheaper and coarser than full verification, that it states an explicit necessary condition for plausibility, and that it is never treated as sufficient proof of correctness. In logical terms it tests a necessary condition, so failure is informative (the result must be wrong) while success is weak evidence. Examples include checking that probabilities sum to one, that a simulated energy stays roughly conserved, that a software build's output file isn't empty, or that a physics answer has the right units. It is a screen that precedes validation, not a substitute for it.

Broad Use

arithmetic and estimation. The carrier is a calculation, expected sign and order of magnitude, units and a rough independent estimate. The identity test is that the computed result has compatible dimensions, sign and plausible magnitude. This is a literal instantiation rather than decorative analogy because the carrier, observable organization, conserved relation, variation class, and failure test retain the same roles. The domain accent is mental or back-of-envelope comparison is intentionally coarse. A responsible analysis states scale, observation window, representation and noise model before claiming the structure, then distinguishes the structure itself from the process used to discover, stabilize or exploit it.

Clarity

A clear Sanity check claim can be rewritten as a testable sentence: on carrier C at scale S, relation R holds within tolerance T, remains under transformations V, and fails for counterexample K. This grammar exposes missing components and prevents a noun from standing in for an argument.

Manages Complexity

Sanity check manages complexity by replacing an unstructured inventory with a small set of relations that survive relevant variation. Compression becomes legitimate when the retained relation supports reconstruction, comparison or reliable discrimination and the discarded details are declared incidental for the task.

The abstraction also supports chunking. Once an organized unit is established, reasoning can treat it as one object while retaining an audit trail to its elements.

Abstract Reasoning

1. Type the carrier and explain why its elements are individuated at the selected scale.
2. Separate the target structure from the notation, image, model or story used to display it.
3. State the constitutive relation as an equation, rule, repeatability condition or traceable interpretive criterion.
4. List transformations expected to preserve identity and justify why they are incidental.
5. Choose at least one positive diagnostic and one collapse test.

Knowledge Transfer

Transfer begins from the role graph, not the name. Preserve carrier, relation, invariant, admissible variation, diagnostic and collapse test; then substitute domain occupants. A successful mapping explains how the target case would be recognized and how it would fail.

The most common transfer error is feature substitution. One field may represent the structure visually, another algebraically and another behaviorally. The visible features are not the invariant. Transfer must identify the relation those features evidence and state the target domain's measurement or proof obligations.

Relationships to Other Abstractions

Current abstraction Sanity check Prime

Parents (1) — outgoing typed relations

• Sanity check is a kind of Error Proofing (Poka-Yoke) Prime

  The accepted reference-grade review places Sanity check under Error Proofing (Poka-Yoke) because the child instantiates or depends on the parent's broader structure while retaining its own constitutive identity.

Hierarchy paths (6) — routes to 5 parentless roots

• Sanity check → is a kind of Error Proofing (Poka-Yoke) → is a kind of Constraint

Show alternative paths (5)