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.[n1] 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.
[n1] TOCTOU (time-of-check to time-of-use) is the well-known race in which a referent is validated and then used, with a window in between where its state can change. It is the standard name for exactly the residual gap a just-in-time check narrows but cannot eliminate. ↩