Skip to content

Unverified Precondition

Prime #
1260
Origin domain
Computer Science & Software Engineering
Subdomain
failure modes and invariants → Computer Science & Software Engineering

Core Idea

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 behaviour, or proceeds with a corrupted intermediate result that surfaces as a failure downstream, far from the missing existence.

The pattern is structurally distinct from ordinary "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 its correctness, freshness, schema-conformance, or authority. The action's logic is correct given the existence; the failure mode is the action's blindness to the existence question itself.

Four pieces are load-bearing. There is an action site that will operate on some referenced entity. There is a referenced entity whose existence is the precondition for the action's success. There is a trust-the-reference-resolves posture at the action site — no explicit check that the referent currently exists. And there is a failure surface that appears either as a crash (the action could not proceed) or as a corrupted continuation (the action proceeded with an absence treated 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."

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.'

Structural Signature

the action site that will operate on a referent — the referenced entity whose existence is the precondition — the trust-the-reference-resolves posture (no existence check at the site) — the existence dimension distinct from any value property — the failure surface (crash or corrupted continuation) — the here-and-now invariant separating verification site from action site

The pattern holds whenever these components co-occur:

  • The action site (role). A locus that will operate on some referenced entity at the moment of commit.
  • The referenced entity (role). An object, capability, counterparty, channel, or resource whose existence-and-availability is the precondition for the action's success.
  • The trust posture (relation). No explicit check at the action site that the referent currently exists — the action presumes the reference resolves.
  • The existence dimension (invariant). Existence — is it there at all? — is a load-bearing precondition separate from any value property (correctness, freshness, schema-conformance, authority); the action's logic is correct given existence, and blind to the existence question itself.
  • The failure surface (relation). When the presumption fails, the action crashes or proceeds with an absence treated as a presence, surfacing downstream far from the missing existence.
  • The site-and-moment invariant. Existence must be verified here and now: verification at the planning site or at an earlier time does not establish existence at the action site at commit — the time-of-check-to-time-of-use gap is the time-window-sensitive instance.

The components compose into the signature: an action presumes its referent exists at the moment of use without checking at the site of use, so an absence resolves into a crash or a travelling corrupted value.

What It Is Not

  • Not constraint. A constraint is a standing restriction on the values a system may take; an unverified precondition is the failure to check that a referenced entity exists at the action site — about presence at a moment, not about a value-space restriction.
  • Not incorrect input or wrong value. Value correctness, freshness, schema-conformance, and authority are properties of a value that is there; this prime is blindness to the prior question of whether the referent exists at all.
  • Not idempotence. Idempotence concerns whether repeating an action changes the result; the unverified precondition concerns whether the action's referent is present at the moment of first commit, a separate existence dimension.
  • Not authority_delegation_under_uncertainty. That prime concerns who is permitted to act; this one concerns whether the thing acted upon exists here and now, regardless of permission.
  • Not transaction atomicity. A transaction bundles operations to succeed or fail together; the unverified precondition is the narrower failure of presuming a referent resolves without a here-and-now existence check, which can occur inside or outside any transaction.
  • Not mathematical_induction. Induction establishes a property over all cases from a base and a step; this prime is the runtime blindness to existence at a single action site, with no inductive structure.
  • Common misclassification. Validating a value's content (well-formed, recent, authorised) while never asking whether the referent exists at the action site, so a correct-looking reference resolves to nothing — the check confirmed properties on the assumption of presence.

Broad Use

  • Software. Null dereference and use-after-free: a reference is used without checking it points to a live object, so the program crashes or proceeds with corrupted state — the canonical computing case.
  • Distributed systems. A call presumes a service is reachable; partition, crash, or DNS failure makes it absent at this moment, and vanished cloud resources, dropped queue messages, and expired tokens are the same shape.
  • Supply chain. A process plan presumes a part is in inventory at this workstation now; a stock-out or an expedite pull makes it absent, and the plan that was correct given the part halts.
  • Emergency response and healthcare. Dispatch presumes a unit is in service or a bed is available; the unit is out for maintenance or the bed was filled in the interim, producing a halt or a corrupted continuation such as a mislabeled specimen.
  • Legal and database contexts. A contract presumes a counterparty is solvent and licensed; an application query presumes a table or column exists in the current schema; failure surfaces at runtime rather than at planning or deploy time.
  • Build and configuration. A recipe presumes a file, tool, or version is present, or code presumes a config value is set; absence crashes deep in the build or falls through to a default that silently mis-routes.

Clarity

Naming the pattern raises the existence dimension to a first-class precondition layer, distinct from value correctness, freshness, authority, or schema-conformance. A class of failure usually filed under domain-specific labels — null pointer, missing resource, out of stock, unavailable partner, bad config — acquires a shared structural identity, and the diagnostic question becomes precise: which preconditions in this action assume existence, and where is the existence verified? The framing clarifies a recurring class of post-mortem findings in which the action's logic was correct, the value when present was correct, and the data flow was correct — and yet the action failed because the referenced entity was not there at this moment.

A third clarification makes explicit that existence verification has a site and a moment. Verifying that an entity existed yesterday, or at the planning site, is not the same as verifying it exists now at the action site, and many failures are precisely the gap between the verification site and the action site. Once that gap is named, the practitioner stops asking only "was it there?" and starts asking "was it there here, now?" — which is the question the failure was always about.

Manages Complexity

The pattern compresses a heterogeneous family of failures — null dereferences, missing RPC targets, out-of-stock parts, missing beds, bankrupt counterparties, missing schema objects, missing config values — into one diagnostic procedure: catalogue the action site's referenced entities, characterise each referent's verification posture (verified-at-site, verified-elsewhere, or merely presumed), install missing existence checks at the action site, and decide what to do in the absent case. The procedure is the same regardless of whether the referent is a memory object, a network endpoint, a physical part, or a hospital bed.

The intervention catalogue is portable. Make the existence assumption explicit — typed optionality, contract preconditions, named-resource invariants, pre-flight checks. Decide ex ante what to do in the absent case — fallback path, fail-fast with a clear error, graceful degradation, retry-with-backoff, deferred action. Push the existence check to the earliest verifiable site — compile-time over deploy-time over startup-time over runtime. Treat absence as a routine input class, not an exception — absence-handling living in the main flow rather than in error paths. Maintain referential integrity at the referent's side — cascade-delete semantics, lease-based holding with re-verification on use. Each move attaches to one of the pattern's four pieces, so the catalogue covers the structure rather than enumerating tricks.

Abstract Reasoning

Several abstractions sharpen the pattern. Existence as a precondition dimension: every action referencing an entity has an existence precondition separate from any value precondition, and the structural move is to reason about it explicitly rather than folding it into "the value is correct." Verification-site versus action-site separation: the site at which existence was verified may not be the site at which the action operates, so the structural question is what duration separates check from use and what can happen in that window — the time-of-check-to-time-of-use bug is this pattern's specifically time-window-sensitive instance. Reference versus value: a reference is a promise of a value, and the value's existence at resolution time is independent of the reference's own value, so the pattern forces a clean separation of the reference layer from the resolution layer.

Two further abstractions extend the analysis. Existence assumptions compose along action chains: an action using three referents carries three existence assumptions, and under an independence approximation the action's success probability is the product of the resolvability probabilities, so long chains of unverified preconditions have geometrically decaying success rates. And failure-site versus cause-site distance: the failure surface often appears far from the missing existence because downstream modules consume the corrupted intermediate and surface the failure where its connection to the missing precondition is no longer obvious — which is exactly what makes these failures forensically hard and what the framing predicts.

Knowledge Transfer

Because the pattern is a relation between an action site and a referenced entity's existence rather than anything substrate-specific, both its diagnosis and its repairs transfer across fields that share no content. The type-level existence-encoding pattern transferred from single-process software into distributed-systems libraries, where reachability checks and circuit breakers treat "is the downstream available?" as a routine question. The just-in-time inventory model's vulnerability to unverified-precondition failure was a major lesson of recent supply disruptions, shifting operations toward on-site inventory and multiple-source verification — the same recipe of verifying at the action site and treating absence as routine. The pre-flight-check culture of aviation transferred into surgical pre-procedure checklists, a substrate-general way of installing existence verification at the action site. And the referential-integrity discipline of database design transferred into workflow systems as saga patterns, compensating transactions, and idempotent retries.

The deepest transfer is the recipe itself — explicit existence verification at the action site, pre-flight checks, fallback paths, fail-fast with clear errors, type-level absence encoding — recognisable across every substrate instance because each treats existence as a first-class precondition to be checked here and now. A practitioner who has learned to encode optionality in software can recognise, in an admission desk or a production line, that an action is trusting a reference verified elsewhere and earlier, and that the repair is to re-verify at the point of use. The substrates differ — memory references, network endpoints, parts, beds, contracts, schema objects — but the structural shape and its repair are preserved, so the reasoning carries from one to the next without re-derivation.

Examples

Formal/abstract

A null-pointer dereference in software is the canonical formal instance, and it isolates the existence dimension with maximal clarity. The action site is a line of code that will call a method on, or read a field from, a referenced object. The referenced entity is the object the reference is supposed to point to, whose existence-and-availability is the precondition for the call to succeed. The trust posture is the absence of any check at the call site that the reference is non-null — the code presumes the reference resolves. The existence dimension is what the example makes vivid: the object's value, when present, may be perfectly correct, well-formed, fresh, and authoritative — the action's logic is correct given the object exists; the failure is the action's blindness to whether it exists at all. The failure surface is the crash (or, worse, a proceed-with-corrupted-state path where an absence is treated as a presence). The site-and-moment invariant sharpens it: verifying the reference was valid at the planning site or an instant earlier does not establish it is valid here, now at the call — and the time-of-check-to- time-of-use bug is the specifically time-window-sensitive instance, where the referent is freed in the gap between check and use. The repair catalogue attaches to the pattern's pieces: make the assumption explicit (typed optionality forcing the absent case to be handled), push the check to the earliest verifiable site (compile-time non-nullability over runtime), and treat absence as a routine input class rather than an exception. The composition abstraction quantifies the stakes: an action using three references carries three existence assumptions, so under independence the success rate is the product of resolvability probabilities — long chains decay geometrically. Mapped back: the call site is the action site, the pointed-to object is the referenced entity, the missing null-check is the trust posture, the crash is the failure surface, and the freed-in-the-gap case is the site-and-moment invariant.

Applied/industry

Just-in-time supply-chain inventory is the applied worked case, exercising a manufacturing-operations domain. The action site is a workstation about to execute a process step that consumes a specific part. The referenced entity is that part, whose existence-and-availability at this station, now is the precondition for the step. The trust posture is a process plan that presumes the part is on hand because it was ordered and "should be here" — no explicit verification at the moment of use. The existence dimension is distinct from any value property: the part, when present, may be exactly the right specification, in-tolerance, and correctly labelled — the plan is correct given the part; the failure is the plan's blindness to whether the part is physically present at this station at commit. The failure surface is the line halting (the step cannot proceed) or, worse, a corrupted continuation where a substitute or mislabelled part is used as though it were the right one, surfacing as a defect downstream far from the stock-out. The site-and-moment invariant is the lesson recent disruptions taught operations: verifying a part existed in the regional warehouse yesterday is not verifying it exists at this station now, and the gap between the verification site and the action site is exactly where JIT systems broke. The repair is the same recipe as the software case — verify existence at the action site and treat absence as routine — realised as on-site buffer inventory, multiple-source qualification, and pre-flight kitting checks before a run begins. Two further genuine domains share the structure: emergency dispatch presuming an ambulance is in service when it is out for maintenance, and the aviation/surgical pre-flight checklist culture that installs existence verification at the action site precisely to close this gap. Mapped back: the workstation is the action site, the part is the referenced entity, the "it should be here" plan is the trust posture, the halted line or downstream defect is the failure surface, and the warehouse-yesterday-versus-station-now gap is the site-and-moment invariant — repaired by re-verifying at the point of use.

Structural Tensions

T1 — Existence Dimension versus Value Properties (scopal). The prime isolates existence — is the referent there at all? — as a precondition separate from any value property (correctness, freshness, schema, authority). The two are easily merged. The failure mode is validating the value's content (it's well-formed, recent, authorized) while never asking whether the referent exists at the action site, so a correct-looking reference resolves to nothing. Diagnostic: ask whether the checks at the action site confirm the referent's presence, or only constrain its properties on the assumption it is present.

T2 — Check Site versus Action Site (scopal). The site-and-moment invariant requires verification here, at the action site — verification elsewhere does not establish existence where the action commits. The failure mode is checking existence at the planning or admission site and trusting it to hold at a distant action site, so a referent verified upstream is gone by the time it is used. Diagnostic: ask whether the existence check and the action are co-located, or whether a hand-off separates the place that verified from the place that uses.

T3 — Time-of-Check versus Time-of-Use (temporal). Even at the same site, existence verified at time t does not guarantee existence at commit time t+δ — the classic TOCTOU window. A check that passes can be invalidated by concurrent deletion before use. The failure mode is treating a recent successful check as a standing guarantee, leaving a race window where the referent vanishes between check and act. Diagnostic: ask whether anything can remove the referent between the check and the commit, and whether the check-and-act is atomic or merely sequential.

T4 — Crash versus Corrupted Continuation (sign/direction). The failure surface bifurcates: the action either crashes (loud, local, halts) or proceeds treating absence as presence (silent, travelling corruption). These have opposite remediation. The failure mode is engineering against the loud crash (null guards that abort) while leaving the silent path open, or tolerating silent continuation to "stay available" and propagating corruption far downstream. Diagnostic: ask which branch the absence takes — does the missing referent stop the action or get substituted by a default/zero that travels — since the dangerous case is the quiet one.

T5 — Defensive Checking versus Check Proliferation (scalar). The repair is an existence check at every action site, but checking everywhere is costly, clutters logic, and itself can be wrong or skipped under pressure. Competing with a fail-fast/contract discipline that establishes existence once at a trust boundary. The failure mode is either no checks (the original pattern) or defensive checks at every site that still miss the one path that matters, providing false assurance. Diagnostic: ask whether existence can be guaranteed by a boundary invariant (non-null types, ownership) so interior sites need not re-check, versus genuinely requiring a here-and-now check.

T6 — Existence Precondition versus Establishing the Referent (coupling). The prime treats existence as something to verify; but often the right move is to ensure it — create-if-absent, provision-on-demand, retry-until-reachable — collapsing the check into a guarantee. The two postures diverge on what to do when the referent is missing. The failure mode is verifying-and-aborting where the referent could have been established, or blindly creating where absence was itself the meaningful signal. Diagnostic: ask whether a missing referent is an error to report or a state to repair, and whether the action site should check, establish, or distinguish the two.

Structural–Framed Character

Unverified precondition sits on the structural side of the middle of the structural–framed spectrum — a mixed-structural prime with a low aggregate of 0.3. Its skeleton is a crisp relation among an action site, a referenced entity whose existence is the precondition, a trust-the-reference-resolves posture, and a failure surface — with a here-and-now invariant separating the verification site from the action site. That structure is genuinely substrate-light, and two diagnostics read clean at the structural end. Evaluative weight is 0: an unverified precondition is value-neutral; the existence dimension — is the referent there at all? — carries no approval or disapproval, and a null dereference, a stock-out, and a missing bed are the same value-free structural absence. Institutional origin is 0: the action-site-plus-reference-plus-existence-check structure is a formal property of any action operating on a referent, owing nothing to a human institution, and the entry's cleanest worked instance (a null-pointer dereference) involves no institution at all.

Two diagnostics read mid, landing the 0.3 just structural-of-center. Human_practice_bound is 0.5: although the canonical case is purely mechanical (a CPU dereferencing a null pointer, with no human in the loop), several load-bearing instances are practice-bound — JIT inventory at a workstation, emergency dispatch, surgical pre-flight checklists — so the criterion is half rather than zero. Vocabulary travels at 0.5 ("action site," "referenced entity," "existence dimension," "time-of-check-to-time-of-use" are portable across memory references, network endpoints, parts, beds, and contracts), and invoking the prime imports the precondition/invariant frame rather than merely spotting a wired-in pattern (import_vs_recognize 0.5). The structure itself is stripped and formal — which is why it is mixed-structural rather than framed — and it runs in indifferent physical substrates (the null deref) as readily as in human workflows, with the 0.3 aggregate recording a pattern that leans structural while its richest examples are practice-bound.

Substrate Independence

Unverified precondition is a strongly substrate-independent prime — composite 4 / 5 on the substrate-independence scale. Its domain breadth is wide: the existence-precondition failure — an action presuming a referent exists at the moment of use without checking — recurs across software (null dereference, use-after-free), distributed systems (a call presuming a service reachable when partition or token-expiry has made it absent), supply chain (a plan presuming a part in inventory now), emergency response and healthcare (dispatch presuming a unit in service or a bed available, producing a halt or a mislabeled specimen), legal and database contexts (a contract presuming a solvent counterparty, a query presuming a table exists), and build and configuration (a recipe presuming a file or config value present). Its structural abstraction is high: the signature is a clean, near substrate-free relation — an action-site, a reference to a presumed-existent entity, and the absence of an existence-check at the moment of use — carrying essentially no normative or institutional content, which is why it is recognized rather than translated whether the referent is a memory pointer, an ambulance, or a contractual party. Transfer evidence is concrete: the same failure shape and the same repair (verify existence at the point of use, fail fast rather than continue corrupted) carries across null-deref, stock-out, and bed-unavailability with named instances. What holds it at 4 rather than 5 is that many canonical cases are embedded in engineered or institutional workflows rather than reaching every conceivable substrate, but the clean action-site/reference/existence-check structure and the breadth across computing, logistics, and clinical settings keep it a strong 4.

  • Composite substrate independence — 4 / 5
  • Domain breadth — 4 / 5
  • Structural abstraction — 4 / 5
  • Transfer evidence — 4 / 5

Relationships to Other Primes

One-hop neighborhood: parents above, mutual partners to the right, children below.UnverifiedPreconditionsubsumption: Time-Of-Check To Time-Of-Use FlawTime-Of-Check ToTime-Of-Use Flaw

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).

Neighborhood in Abstraction Space

Unverified Precondition sits in a sparse region of abstraction space (64th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.

Family — Logical Moves & Precondition Gating (10 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-06-14

Not to Be Confused With

The embedding-nearest neighbour is constraint (similarity 0.81), and the two share a surface — both are about conditions an action must satisfy — but they concern different dimensions. A constraint is a standing restriction on the values a system may take: a range, an invariant, a rule that admissible states must obey. It is a property of the value space. An unverified precondition is not about which values are admissible but about whether a referenced entity exists at all at the action site at the moment of commit — an existence dimension orthogonal to any value constraint. The prime's whole content is that the action's logic can be perfectly correct given existence, and every value constraint can be satisfied, yet the action still fails because the referent was not there. A practitioner who folds the prime into constraint reaches for value validation (is it in range? does it satisfy the invariant?) and never adds the existence check the failure actually demands — confirming the referent is present here, now, which no value-space constraint addresses.

A second genuine confusion is with transaction atomicity. Both are invoked when an action "should have succeeded but didn't," and both concern the integrity of an operation. But a transaction bundles multiple operations so they commit or roll back together, defending against partial completion under concurrency or failure. The unverified precondition is narrower and prior: it is the failure to check that a single referent exists before operating on it, and it can occur entirely inside a perfectly atomic transaction (the transaction commits an operation on a referent that was never there) or entirely outside one. The time-of-check-to-time-of-use window (T3) shows the relationship and the distinction at once: atomicity of check-and-act is one defence against the prime (it closes the race window), but the prime itself is the existence-blindness, not the non-atomicity. Conflating them leads to wrapping everything in transactions while leaving the existence check absent, so the action atomically commits a corrupted continuation.

A third worth separating is idempotence. Idempotence concerns whether repeating an action leaves the result unchanged — a property about repetition and retries. The unverified precondition concerns whether the referent is present at the moment of first commit — a property about existence at a site. They meet in the repair catalogue (idempotent retries are one way to handle a referent that is intermittently absent), which is why they get associated, but they answer different questions: idempotence asks "is doing this twice the same as once?", the unverified precondition asks "is the thing I am about to operate on actually there?". A defence built only for idempotent retry does nothing for a referent that is permanently absent at the action site.

For a practitioner the distinctions decide where the check goes. constraint calls for value validation in the admissible-value space; transaction calls for atomic bundling against partial completion; idempotence calls for safe-to-repeat design; and the unverified precondition calls for an existence check at the action site at commit time — co-located with the action, atomic with it where a TOCTOU window exists, and with an explicit decision about what to do in the absent case. Sending the effort to the wrong neighbour leaves the existence question exactly where it was: unasked.

Solution Archetypes

No catalogued solution archetypes reference this prime yet.