Skip to content

Use Time Referent Validation

Verify that the thing an action depends on still exists and is valid at the moment of use, then bind, use, or fail safely.

Version
v1 · 2026-08-24 · History
Solution archetype #
1105
Problem family
Identity, Provenance & Integrity Failure
Problem subfamily
Execution-Time Referent & Repeat Integrity

Overview

Use-Time Referent Validation prevents an action from relying on a stale or missing thing. The pattern applies when a workflow has selected, cached, remembered, reserved, or authorized a referent earlier, but the action will only become correct if that same referent still exists and is valid at the moment of use.

The core move is to turn an implicit assumption into a current-validity gate: identify the referent, state what valid-now means, check as close to the action as possible, bind the checked referent to the action, and fail safely when the referent is missing, changed, expired, revoked, unavailable, ambiguous, or unknown.

Core pattern

  1. Name the action and the referent it depends on.
  2. Define the use-time validity predicate.
  3. Identify where state can change between check and use.
  4. Validate immediately before use or bind the check to the action.
  5. Distinguish valid, invalid, unknown, changed, expired, and unavailable states.
  6. Abort, refresh, retry, escalate, or fallback when validation fails.
  7. Preserve audit linkage from the validation evidence to the actual action.

When This Archetype Applies

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

Diagnostic problem

A system or workflow treats a reference, resource, record, identity, condition, or dependency as still present and valid because it was expected, selected, checked, or true earlier. At the moment of use, the referent may be missing, revoked, replaced, expired, moved, consumed, concurrently modified, no longer authorized, or semantically ambiguous. Without use-time validation, the action executes against the wrong thing, no thing, an unsafe state, or an authority condition that no longer holds.

Applicability expression6 distinct conditions

Use-dependent referent validityandPreviously checked referentandCheck-use state changeandHarmful stale referentandImplicit missing handlingandRecurring stale-reference incidents
Algebraic1∧2∧3∧4∧5∧6

groundedpartly groundedopen

6 conditions, all required.

6Required in every casenumbered 1–6

These hold no matter which pattern applies.

1

Use-dependent referent validity · open

An action depends on a resource, object, record, permission, identity, inventory item, state, or external service being present or valid.

2

Previously checked referent · grounded

The referent was identified, cached, checked, reserved, promised, or inferred before the action actually uses it.

primeTime-Of-Check To Time-Of-Use Flaw— A precondition verified at one instant authorizes an action taken at a later instant, and the relevant state changes in the gap between them, so the defect lives in the temporal binding between check and use rather than in either operation.

3

Check-use state change · grounded

Time, concurrency, distributed propagation, human handoff, or external update can change referent state between check and use.

primeTime-Of-Check To Time-Of-Use Flaw— A precondition verified at one instant authorizes an action taken at a later instant, and the relevant state changes in the gap between them, so the defect lives in the temporal binding between check and use rather than in either operation.

4

Harmful stale referent · open

Missing, stale, or changed referents create correctness, safety, security, legal, financial, or reputational harm.

5

Implicit missing handling · open

A null, missing, expired, revoked, or moved referent is currently handled by implicit assumptions, silent defaults, or late failure.

6

Recurring stale-reference incidents · open

The workflow has repeated retries, ghost records, stale approvals, inventory mismatches, expired tokens, broken links, dangling references, or race-window incidents.

Other requirements and context (1)

Why these sit outside the expression

Supporting context — it may accompany or help interpret the situation, but it is not a load-bearing condition in a sufficient diagnostic set.

  • Supporting contextStakeholders need a reliable distinction among valid-now, missing-now, unknown, changed, unauthorized, and fallback cases.

Coverage

2 of 6 conditions grounded · 4 open.

Read the methodologyDownload the trigger-logic data

Key components

The referent dependency names what must exist. The current-validity predicate says what must be true now. The identity/sameness test prevents a reused name or handle from standing in for the same thing. The freshness window states how long a check remains usable. The check-use binding boundary closes the temporal gap. Failure semantics keep missing or unknown states from being silently treated as valid.

Common mechanisms

Common mechanisms include just-in-time existence checks, atomic check-and-use operations, lease or reservation tokens, compare-and-swap guards, preflight probes, revocation and tombstone checks, transactional precondition guards, stale-reference monitors, authorization revalidation, and safe fallback paths.

Parameter dimensions

Important parameters include referent volatility, harm from wrong use, reversibility, check latency, acceptable staleness, authority source reliability, distributed consistency model, lock contention, user recovery cost, and audit requirements.

Invariants to preserve

Do not treat checked-earlier as valid-now unless a binding or freshness rule warrants it. Do not treat a name as identity when names can be reused or repointed. Do not treat unknown as valid. Do not let expired or revoked authority pass. Do not log the check without proving that the checked referent was the used referent.

Target outcomes

Successful use reduces stale references, null dereferences, broken links, stale approvals, check/use races, inventory mismatches, ghost records, and late failures. It also improves auditability, recovery behavior, and trust in dynamic systems.

Neighbor distinctions

This is not only guarded_state_transition; the guard here is specifically about a referent being valid at the moment of use. It is not only transactional_atomicity; transactions are one way to bind check and use. It is not transition_readiness_assessment, which checks broad readiness for a phase transition. It is not domain_codomain_delimitation, which defines static valid inputs and outputs.

Examples

  • A database update proceeds only when the record version still matches the version read.
  • A booking hold expires unless it is converted to a confirmed booking before the lease ends.
  • A user permission is rechecked at request time after a role change or revocation.
  • A clinical team verifies patient, site, and consent immediately before an irreversible procedure.
  • A contract workflow checks that a certificate remains valid at execution time.

Non-examples

  • A type signature that validates data shape but not a dynamic referent.
  • A launch readiness review for an entire migration.
  • A deliberately stale cache read whose staleness is harmless and documented.
  • A rollback mechanism with no current-referent validation.

Failure modes

The common failures are leaving the check/use gap open, treating names as stable identities, recoding unknown as valid, reusing expired bindings, validating against stale replicas, ritualizing human confirmation, and overchecking low-risk operations until operators bypass the gate.

Review note

This draft is justified because unverified_precondition has zero reported coverage and the accepted catalog only contains adjacent patterns. Human review should focus on the boundary with guarded_state_transition and on whether TOCTOU-specific controls should remain variants or become separate mechanisms.

Common Mechanisms

10 documented mechanisms across 4 implementation forms.

The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.

Control, Automation & Runtime · 7 mechanisms

  • Atomic Check-and-Use Operation — Fuses the validity check and the dependent action into one indivisible operation, so no other actor can change the referent in between — there is no window to lose a race in.
  • Capability or Authorization Revalidation — Re-evaluates at the moment of use whether the authority presented still permits this actor to perform this action on this referent, rather than trusting a grant decided earlier.
  • Compare-and-Swap or Version Guard — Carries the version, state, or token seen when the referent was read, and permits the action only if the referent still bears that exact marker at commit — otherwise it rejects rather than clobbers.
  • Just-in-Time Existence Check — 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.
  • Lease, Lock, or Reservation Token — Binds a referent to one actor for a bounded window with an expiry, so within the window the holder may act without re-checking, and on expiry, release, or commit the binding dissolves for others to claim.
  • Safe Missing-Referent Fallback — Pre-defines the recovery ladder — retry, refresh, degrade, escalate, abort — so that when a referent can't be confirmed valid, the action lands in a defined safe state instead of proceeding blindly or crashing.
  • Transactional Precondition Guard — Runs the precondition check and the use inside one atomic boundary so nothing can change the referent in between — and if the precondition fails, the entire unit rolls back to a consistent state rather than half-completing.

Monitoring, Sensing & Alerting · 1 mechanism

  • Stale Reference Monitor — Watches use-time outcomes over time to find which references keep going stale — measuring observed age against a freshness window and logging the recurring offenders so the rot gets fixed at its source rather than one failure at a time.

Protocol, Workflow & Routine · 1 mechanism

  • Preflight Resource Probe — Sweeps every referent a high-stakes operation depends on in one go/no-go check just before the point of no return, so a single missing dependency blocks the whole action rather than surfacing mid-flight.

Record, Log & Register · 1 mechanism

  • Revocation or Tombstone Check — Looks a referent up against an authoritative record of things that are still named but deliberately killed — revoked, deleted, merged, or superseded — so a well-formed name is never mistaken for a still-valid one.

Compression statement

Use-Time Referent Validation applies when an action is about to operate on something named, selected, cached, promised, authorized, reserved, or remembered earlier. The intervention makes the presumed referent explicit, checks its current existence, identity, validity, authority, and freshness immediately before use, and closes the gap between check and action by binding, locking, snapshotting, leasing, versioning, or atomically coupling the check with the use. If the referent is absent, changed, revoked, expired, ambiguous, or no longer authorized, the action aborts, refreshes, retries, escalates, or moves to a safe fallback rather than proceeding on a stale assumption.

Canonical formula: For action A on referent R at time t_use, proceed only if valid(R, A, t_use) is verified and bound to A; otherwise abort, refresh, retry, or route to fallback.

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (11)

  • Consistency: A set of commitments cannot jointly derive a contradiction.
  • Constraint: Limits possibilities to guide outcomes.
  • Data Integrity: Accuracy and consistency preserved.
  • Dependency: Directed relation in which one element relies on another being present, prior, compatible, or supplied, with a specifiable failure mode if the condition is unmet.
  • Fail-Safe: Default to safe state on failure.
  • Observability: Infer internal state externally.
  • State and State Transition: Captures system condition and evolution.
  • Time-Of-Check To Time-Of-Use Flaw: A precondition verified at one instant authorizes an action taken at a later instant, and the relevant state changes in the gap between them, so the defect lives in the temporal binding between check and use rather than in either operation.
  • Unverified Precondition: An action presumes a referent exists at the moment of use without checking.
  • Validation: Confirming that an artifact actually solves the intended problem in its real operational context, as distinct from confirming it was merely built to specification.
  • Verification: Check that an object conforms to its specification via a defined procedure yielding evidence and a verdict.

Also references 22 related abstractions

  • Access Control: Restrict system access.
  • Attestation: A verifiable, principal-binding, tamper-evident mark lets a third party confirm who committed to what.
  • Authentication: Binding an asserted identity or origin to admissible evidence through a procedure that yields a verdict, before trust, access, or weight is granted.
  • Boundary: Defines system limits.
  • Bypassed Safeguard: A protective control is systematically routed around by the very operators it was meant to protect, because it imposes friction against a production task and the workaround is locally rewarded and globally invisible until the rare hazard arrives.
  • Closure: Ensures operations remain within a set.
  • Consistency Model: An explicit contract over which observations of shared state are legal when updates are concurrent.
  • Coupling: Interdependence among subsystems.
  • Designed-Out Misuse: Affordances and defaults are arranged so the misuse path is costly or impossible while the legitimate path stays easy, preventing harm before enforcement has to act.
  • Eventual Consistency: Distributed copies of shared state are allowed to diverge under local updates, with a deterministic merge guaranteeing they reconverge once updates stop.

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Atomic Check-Use Binding · implementation variant · recognized

Combines validation and action inside one atomic or isolated operation so the referent cannot change between check and use.

  • Distinct from parent: The parent also covers leases, preflight checks, human confirmations, and fallback semantics; this variant uses atomicity or isolation as the primary closure method.
  • Use when: Concurrent actors can alter the referent; A stale check would create security, integrity, or safety harm; An atomic primitive, transaction, or isolation boundary is available.
  • Typical domains: software engineering, database design, security
  • Common mechanisms: atomic check and use operation, compare and swap or version guard, transactional precondition guard

Lease-Bound Availability Guard · temporal variant · recognized

Allows action only while a reservation, lease, hold, or token keeps the referent available and unexpired.

Stale-Reference Invalidation Guard · risk or failure variant · recognized

Blocks use of cached handles, links, approvals, or records after the referent has been deleted, superseded, revoked, merged, or repointed.

  • Distinct from parent: The parent covers all use-time referent validation; this variant centers invalidating old references and approvals.
  • Use when: References persist longer than the referents or permissions they name; Caches, links, handles, or approvals are reused across time; The system can publish invalidation, tombstone, or version-change signals.
  • Typical domains: content management, identity governance, records management
  • Common mechanisms: revocation or tombstone check, stale reference monitor, compare and swap or version guard

Human Use-Point Confirmation · domain variant · recognized

Uses a deliberate human confirmation at the action point to verify identity, availability, consent, or readiness of the referent.

  • Distinct from parent: The parent is channel-neutral; this variant handles checklist fatigue, rubber-stamping, and confirmation authority.
  • Use when: Automation cannot fully observe the referent; The action is high-stakes or irreversible; A human actor can inspect the relevant state immediately before action.
  • Typical domains: clinical safety, aviation, field operations
  • Common mechanisms: preflight resource probe, safe missing referent fallback

Near names: Use-Time Precondition Check, Referent Existence Guard, Stale Reference Guard, TOCTOU Guard, Null Reference Guard.

Editorial Notes

Problem Classification

Classification: Identity, Provenance & Integrity Failure → Execution-Time Referent & Repeat Integrity

Problem kernel: an earlier reference is assumed valid at use time

Rationale: Earliest causal condition: A system or workflow treats a reference, resource, record, identity, condition, or dependency as still present and valid because it was expected, selected, checked, or true earlier. At the moment of use, the referent may be missing, revoked, replaced, expired, moved, consumed, concurrently modified, no longer authorized, or semantically ambiguous. Without use-time validation, the action executes against the wrong thi

Independent corroboration: The earliest necessary condition in the frozen evidence is: A system or workflow treats a reference, resource, record, identity, condition, or dependency as still present and valid because it was expected, selected, checked, or true earlier. That is a execution time referent and repeat integrity problem because An action or retry applies to a stale, missing, replaced, or already-acted-on referent because identity and prior execution state are not revalidated at use time.

Review outcome: Independent reviewer agreement; high confidence.