Unverified Precondition

Prime #

1260

Origin domain

Computer Science & Software Engineering

Subdomain

failure modes and invariants → Computer Science & Software Engineering

Core Idea

An action presumes some referent — object, capability, counterparty, channel, resource — exists and is available at the moment of commit, but the existence is not checked at the action site. When the presumption fails, the action crashes or proceeds with a corrupted result that surfaces downstream. The existence dimension — is it there at all? — is load-bearing and separate from any property of the value.

How would you explain it like I'm…

Grabbing Without Looking

Imagine you reach for a glass of milk without looking to see if a glass is even there. If it's gone, your hand grabs nothing and milk spills everywhere. You assumed the glass was there but never checked right at that moment.

Is It Even There?

An Unverified Precondition is when you do something that *assumes* a thing is there and ready — a file, a tool, a person to answer — but you never actually check, right where you act, that it really exists. Your plan is perfectly fine *if* the thing is there. The mistake isn't that the thing is wrong or old; it's that you never asked the most basic question: is it there at all? When it isn't, things either crash on the spot or quietly go wrong later, far from where the thing was missing.

The Unchecked Existence

An Unverified Precondition is when an action presumes some object, tool, counterparty, channel, or resource *exists and is available at the moment of commit*, but that existence is never checked at the action site. This is different from 'wrong value' or 'bad input,' because the *existence* dimension — is it there at all? — is a separate load-bearing requirement from any property of the value like its correctness or freshness. The logic is correct *given* existence; the failure is blindness to the existence question itself. When the presumption fails — deleted object, exhausted resource, unreachable counterparty, closed channel, missing tool — the action either crashes or proceeds with a corrupted result that surfaces *downstream*, far from the actual gap. The fix isn't 'check the value's correctness' but 'check whether the referent exists at this moment, here.'

 

An Unverified Precondition is the structural pattern in which an action presumes that some object, capability, counterparty, channel, or resource exists and is available *at the moment of commit*, but the existence is not verified at the action site. When the presumption fails — the object was deleted, the resource exhausted, the counterparty unreachable, the channel closed, the tool missing — the action either crashes, produces undefined behavior, or proceeds with a corrupted intermediate result that surfaces as a failure downstream, far from the missing existence. It is structurally distinct from 'incorrect input' or 'wrong value' because the value's *existence dimension* — is it there at all? — is a load-bearing precondition separate from any property of the value, such as correctness, freshness, schema-conformance, or authority. The action's logic is correct *given* the existence; the failure mode is blindness to the existence question itself. Four pieces are load-bearing: an action site that will operate on a referenced entity; a referenced entity whose existence is the precondition for success; a trust-the-reference-resolves posture at the action site, with no explicit existence check; and a failure surface appearing either as a crash or as a corrupted continuation that treated an absence as a presence. The distinctive bite is that the fix is not 'check the value's correctness' but 'check whether the value exists at this moment at this site.'

Broad Use

• Software: null dereference and use-after-free — a reference used without checking it points to a live object.
• Distributed systems: a call presuming a service is reachable when partition or token-expiry made it absent.
• Supply chain: a process plan presuming a part is in inventory at this station now when a stock-out made it absent.
• Emergency response / healthcare: dispatch presuming a unit in service or a bed available, producing a halt or a mislabeled specimen.
• Legal / database: a contract presuming a solvent counterparty; a query presuming a table or column exists in the current schema.
• Build and configuration: a recipe presuming a file or tool is present, or code presuming a config value is set.

Clarity

Raises the existence dimension to a first-class precondition layer distinct from correctness or freshness, and makes explicit that existence has a site and a moment — "was it there here, now?" — which is the question the failure was always about.

Manages Complexity

Compresses a heterogeneous family of failures into one procedure: catalogue the action site's referents, characterise each verification posture, install missing checks, and decide what to do in the absent case.

Abstract Reasoning

Sharpens existence as a precondition dimension, verification-site versus action-site separation (the time-of-check-to-time-of-use bug), and the fact that existence assumptions compose — a chain of referents has geometrically decaying success.

Knowledge Transfer

• Software → distributed systems: type-level existence encoding became reachability checks and circuit breakers.
• Aviation → surgery: pre-flight-check culture transferred into surgical pre-procedure checklists.
• Database → workflow: referential-integrity discipline transferred as saga patterns and idempotent retries.

Example

A null-pointer dereference: the call site presumes the reference resolves; the object's value, when present, may be perfectly correct, but the action is blind to whether it exists at all, so an absence becomes a crash — and a time-of-check-to-time-of-use bug arises when the referent is freed in the gap between check and use.

Relationships to Other Primes

Foundational — no parent edges in the catalog.

Children (1) — more specific cases that build on this

• Time-Of-Check To Time-Of-Use Flaw is a kind of Unverified Precondition — The file names the relation in its Structural Signature: "the time-of-check-to-time-of-use gap is the time-window-sensitive INSTANCE" of the existence-precondition pattern. Direction: unverified_precondition is the general action-presumes-referent-exists-at-commit prime; TOCTOU (real candidate slug, listed cross-ref) is its time-window special case (check drifts stale between verification and use). Medium because TOCTOU is also a well-established standalone security concept; the in-file "instance" framing nonetheless supports a parent_of edge. NOT a reparent to constraint (0.815 nearest, unrelated).

Not to Be Confused With

• Unverified Precondition is not a Constraint because a constraint is a standing restriction on the values a system may take, whereas this is the failure to check that a referent exists at the action site — presence at a moment, not a value-space restriction.
• Unverified Precondition is not a Transaction because a transaction bundles operations to commit or roll back together, whereas this is the narrower failure of presuming a referent resolves, which can occur inside a perfectly atomic transaction.
• Unverified Precondition is not Idempotence because idempotence concerns whether repeating an action changes the result, whereas this concerns whether the referent is present at the moment of first commit.