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.

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.

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

• atomic_check_and_use_operation
• capability_or_authorization_revalidation
• compare_and_swap_or_version_guard
• just_in_time_existence_check
• lease_lock_or_reservation_token
• preflight_resource_probe
• revocation_or_tombstone_check
• safe_missing_referent_fallback
• stale_reference_monitor
• transactional_precondition_guard

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.

Related Abstractions

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.

▸ Show 12 more

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.

• Distinct from parent: The parent can validate directly at the instant of use; this variant validates by maintaining an explicit availability lease.
• Use when: Availability can be reserved temporarily; The action may happen after a short delay; Expiry and refresh semantics can be stated explicitly.
• Typical domains: logistics, scheduling, cloud resource allocation
• Common mechanisms: lease lock or reservation token, preflight resource probe

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.