Just-in-Time Existence Check¶
Use-time check procedure — instantiates Use-Time Referent Validation
Re-resolves the referent through the same path the action will use, at the last possible instant before use, refusing to trust any earlier lookup.
A plan, a cache, or a prior check tells you the referent was there; Just-in-Time Existence Check refuses to act on that word and looks again, right now. It re-resolves the exact thing the action is about to touch — through the same channel the action itself will use — at the latest feasible moment, and gates the action on a fresh exists-and-valid-now verdict. Its defining trait is that it is the cheapest guard in the family: a single fresh observation with no lock, no version token, and no coordination. That thrift is also its limit — it narrows the window in which a referent can vanish but, unlike an atomic operation, it does not close it. It answers "is this still here?" and nothing more; who may touch it, whether it changed underneath you, and what to do if the answer is no all belong to siblings.
Example¶
A warehouse pick-and-place robot is dispatched a task built from a plan a few minutes old: grab SKU 4471 from bin A-12. In those minutes a human restocker may have emptied A-12, or an earlier pick may have taken the last unit. Just before the gripper closes, the robot re-reads the bin's barcode and load-cell weight through its own sensors — the very channel the grasp will rely on — and confirms SKU 4471 is present now, not that it was present when the plan was drawn. The fresh reading disagrees: the bin is empty. The robot doesn't grab air and report a phantom pick; it aborts the task and requeues it. The plan was treated as a hint; the last-instant observation was treated as truth.
How it works¶
- Pin the exact referent. Resolve the single thing the action will touch (this bin, this SKU, this file handle), so the check targets precisely what the use targets — not a category or a stale alias.
- Observe through the use path. Read the referent through the same channel the action will use, so the check can't pass on a cheaper proxy that disagrees with reality at use time.
- Check as late as possible. Fire the verdict at the last feasible instant before the action, shrinking the interval in which the world can change.
- Gate, don't hold. Proceed only on a fresh valid verdict; add no lock and keep no version — it declines to act on a stale resolution rather than reserving anything.
Tuning parameters¶
- Check-to-use proximity — how close to the action the check fires. Closer shrinks the residual gap but adds latency and can never reach zero without becoming an atomic operation.
- Validity depth — existence only, versus deeper tests (right type, not corrupted, still usable). Deeper catches more but costs more on every use.
- Observation-channel fidelity — whether you check through the exact path the action uses or a cheaper proxy. A proxy is faster but can pass while the real referent is already gone.
- Failure disposition — whether a failed check aborts, retries, or hands off. Sets how disruptive a miss is, and hands the routing to a fallback policy.
- Granularity — per-item versus batched re-check. Batching amortizes cost but reopens a window for items checked early.
When it helps, and when it misleads¶
Its strength is reach and cheapness: it is the most general defense against dangling references and link rot, drops in almost anywhere, and needs no coordination with other actors. It is the right first guard whenever a referent might have quietly disappeared since it was last seen.
Its limit is structural. Between the last observation and the action there remains a gap — the classic time-of-check to time-of-use window — into which a fast or hostile change can still slip.[1] For adversarial races or exactly-once guarantees, a fresh look is not enough; you need an atomic operation or a version guard. The classic misuse is checking through a cheaper channel than the one the action uses — validating against a cached index, then acting on the live store — so the check passes while the referent is already gone. The disciplines: observe through the use path, as late as possible, and treat the check as reducing, never removing, race exposure.
How it implements the components¶
use_moment_observation_channel— it makes the observation through the same path the action will use, at the last feasible instant, so what it checks is what the action gets.current_validity_predicate— it evaluates an exists-and-valid-now verdict and gates the action on it (the general existence facet, distinct from Revocation or Tombstone Check's revoked/superseded facet).action_referent_dependency— it pins the single referent the action will touch, so the check and the use aim at the same thing.
It re-resolves one referent but does not make the check and the use indivisible — that residual gap is closed by Atomic Check-and-Use Operation — nor does it enumerate the whole dependency set up front (Preflight Resource Probe) or decide the recovery route when the verdict is no (safe_abort_or_fallback_path, Safe Missing-Referent Fallback).
Related¶
- Instantiates: Use-Time Referent Validation — Just-in-Time Existence Check supplies the last-instant "is this still here?" verdict the pattern is built on.
- Sibling mechanisms: Atomic Check-and-Use Operation · Safe Missing-Referent Fallback · Preflight Resource Probe · Compare-and-Swap or Version Guard · Capability or Authorization Revalidation · Lease, Lock, or Reservation Token · Revocation or Tombstone Check · Stale Reference Monitor · Transactional Precondition Guard
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Immediately before use, the mechanism re-resolves the referent through the live action path and blocks operation if existence is not confirmed.
Nearest alternative: Decision, Gate & Allocation — Use is allowed or refused, but state-dependent last-moment runtime validation is the defining form.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Software and database engineering developed last-moment referent validation to narrow time-of-check/time-of-use races.
Related originating lineages:
- Security Studies & Intelligence Analysis — Security engineering materially shaped resistance to time-of-check/time-of-use races and stale authorization assumptions.
Review resolution: Both independent reviews place the primary lineage in computer_science. The queued differences (alternate_origin_disagreement, origin_mode_disagreement, domain_reach_disagreement) concern secondary metadata rather than primary provenance. The final retains security_intelligence only where a reviewer supplied a formative-lineage rationale; downstream application by itself is not treated as origin. origin_mode=cross_disciplinary_synthesis records the relationship among origin traditions, while domain_reach=multi_domain records application breadth separately. encyclopedia_synthesis=true reflects whether either reviewer identified a corpus-specific synthesis, and confidence=high preserves the more cautious evidence assessment.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
This is the baseline the harder guards refine rather than replace: Atomic Check-and-Use Operation closes the residual gap it leaves, Compare-and-Swap or Version Guard adds "and unchanged since I read it," and Lease, Lock, or Reservation Token removes the need to repeat the check at all by binding the referent for a window. When the check-to-use gap is negligible and no one contends for the referent, the plain existence check is often all that's warranted.
References¶
[1] Bishop, Matt; Dilger, Michael. "Checking for Race Conditions in File Accesses". Computing Systems 9(2): 131–152 (1996). Formalizes file-access races in which an attacker changes state between a security check and the subsequent use of its result. registry ↩ Show verification details
SupportedVerified against the work's full text
Bishop and Dilger define the time-of-check-to-time-of-use flaw and the 'programming interval' in which an attacker can invalidate a check's result before use.
“During the interval between the two events (see Figure 4), certain as- sumptions from the results of the first system call influence the second. If some action during that interval invalidates those assumptions, the results of the second action may not be what was intended.”