Use Time Precondition Binding¶

Act on a precondition only when the condition is still bound to the state at the moment of use, not merely when it was true during an earlier check.

Orientation¶

Use-Time Precondition Binding is the solution pattern behind the target prime time_of_check_to_time_of_use_flaw. The prime names a failure: a system checks that something is true, waits, and then acts as if the old check still authorizes the action. The archetype names the repair: bind the action to a state that is still valid at use time.

The pattern matters whenever a prior lookup, approval, verification, eligibility result, identity verdict, safety status, or resource-availability check is consumed later. The right question is not only “was the check correct?” but “what exactly did the later action consume, and was that checked condition still bound to it?”

Structural problem¶

A check and a use can be individually reasonable while the pair is unsafe. The check may correctly report that a file, account, seat, permission, consent state, custody chain, resource balance, medication order, or clearance status is valid. The later action may correctly execute its operation. The flaw appears when the state changes in between and the action still treats the old check as live authority.

This makes the pattern easy to miss. Teams often respond by adding more checks, more warnings, or more confirmations. Those help only when they reduce or bind the check-use gap. A confirmation dialog that does not refresh the state may simply add another delay. A cached status indicator may make stale authority look more official. A token that never expires may convert one check into uncontrolled durable permission.

Intervention logic¶

The intervention has four moves:

Name the precondition and the use action. The design must know what condition is being consumed by what action.
Expose the check-use gap. This includes elapsed time, actor handoff, queues, network hops, asynchronous callbacks, custody transfers, and events that may invalidate the old state.
Choose a binding strategy. Strong cases use atomicity, locks, reservations, holds, leases, revocation epochs, version tokens, final revalidation, or explicit snapshot pinning.
Treat mismatch as a real outcome. A stale, revoked, expired, changed, or inconclusive precondition should abort, retry, escalate, compensate, or require fresh authority.

Key components¶

Component	Description
Checked Precondition Claim ↗	This is the condition the system thinks authorizes action. It must be specific enough to re-evaluate. “Approved” is weak unless the approval specifies subject, action, scope, time, authority, and revocation status.
Use-Action Boundary ↗	The action boundary prevents scope creep. A precondition checked for one action should not silently authorize a different use. For example, checking identity for login does not automatically authorize a later high-value transfer unless that transfer is inside the checked scope.
Check–Use Gap Window ↗	The gap window is the distinctive diagnostic object. It asks what can change after the check and before the use. A high-risk one-second gap may matter in concurrent code; a multi-day administrative gap may matter in law, medicine, logistics, or finance.
Use-Time State Evidence ↗	Use-time evidence proves that the relevant state still matches the condition. It may be a fresh read, stable handle, version marker, revocation response, custody hash, balance hold, signed timestamp, or human witness record.
Validity Window or Lease ↗	Sometimes the system cannot eliminate the gap, so it bounds it. A lease, hold, or validity window says exactly how long the prior check may be consumed, for which action, and under which invalidation events.
Conflict, Abort, and Retry Policy ↗	A stale check should not become an unhandled exception or a silent success. It needs a named path: retry after refresh, reserve anew, escalate, compensate, degrade, or abort.

Common mechanisms¶

Atomic transactions, locks, and two-phase commit collapse or protect the check-use gap. Version tokens and compare-and-swap checks allow optimistic progress while refusing stale commits. Leases and scoped capability tokens preserve short-lived authority. Stale-data revalidation gates and revocation checks update the action at the point of use. Snapshot-pinned decisions are appropriate when the action is intentionally about a historical state rather than the current one.

The mechanism must fit the harm model. A critical file-system or payment operation may need strong atomicity. A dashboard may only need timestamped snapshot labeling. A clinical or legal workflow may need final human review plus current evidence.

Parameter dimensions¶

Dimension	Design question
Gap duration	How long can the old check safely authorize action?
State volatility	How often can the checked condition change?
Harm of stale use	What happens if the action consumes a changed state?
Reversibility	Can the action be rolled back, compensated, or appealed?
Observability	Can the system see version, revocation, custody, or freshness at use time?
Contention	Will locking or reservation create unacceptable blockage?
Authority scope	Which actor, action, resource, time, and context does the check authorize?
Invalidation channel	How are changes propagated to pending actions?
Failure posture	Should mismatch fail closed, retry, escalate, or proceed with warning?

Invariants to preserve¶

The action should consume the state it was allowed to consume. If it consumes a snapshot, the snapshot should be explicit. If it needs current authority, the authority should be current. If a precondition expires, is revoked, changes subject, or no longer matches the state version, the action should not silently proceed.

Neighbor distinctions¶

Transactional Atomicity¶

Transactional Atomicity is the closest neighbor. It ensures all-or-nothing completion. Use-Time Precondition Binding asks whether the check that allowed the action is still valid at the instant of use. Many implementations use transactions, but the archetype is broader: it includes leases, final revalidation, revocation checks, snapshot labels, custody holds, and administrative validity windows.

Concurrency Control¶

Concurrency Control handles simultaneous actors and shared-state interference. TOCTOU failures often arise from concurrency, but they also arise from delayed evidence, revoked permissions, stale consent, physical custody changes, and asynchronous workflows. The parent problem is stale precondition authority, not all concurrency.

Guarded State Transition¶

Guarded State Transition says a transition should require defined preconditions. Use-Time Precondition Binding adds that those preconditions must remain valid until the action consumes them.

Coupling Latency and Time-Delay Effects¶

Latency analysis treats delays as design variables across coupled systems. This archetype narrows the lens to delays that make an old verification authorize a later action.

Evidence-Bound Authentication¶

Authentication can produce a valid identity or origin verdict. Use-Time Precondition Binding asks whether the verdict is fresh, scoped, unrevoked, and still bound at the privileged action that depends on it.

Examples¶

In software security, a process checks a pathname, then opens the actual file only through a stable handle or final identity check to prevent substitution. In commerce, a checkout reserves the inventory item before accepting payment. In clinical work, medication administration refreshes patient identity and allergy state at bedside. In governance, a filing or publication system refreshes embargo, injunction, or authority status before final release.

Non-examples¶

This is not the right archetype for a report that intentionally acts on a declared historical snapshot. It is not needed when stale information is read-only and cannot authorize action. It is not the whole of Transactional Atomicity, Concurrency Control, or Guarded State Transition, though it often uses all three.

Implementation checklist¶

Identify every precondition that authorizes a later action.
Measure the gap between check and action under normal, delayed, queued, and exceptional paths.
Classify which states can change, expire, be revoked, be consumed, or be substituted.
Choose a binding strategy for each risk tier.
Define use-time pass, stale, revoked, expired, changed, inconclusive, and conflict states.
Make mismatch behavior safe and explicit.
Record check state, use state, time, actor, scope, and invalidation evidence.
Periodically review incidents where checks passed but actions still consumed wrong state.

Review note¶

This draft is intentionally merge-sensitive. It should be accepted only if reviewers want a top-level archetype for stale-precondition authority across security, medicine, logistics, finance, law, and administration. If the catalog prefers narrower machinery, this record can be converted into a recognized variant linked primarily to Transactional Atomicity, Concurrency Control, Coupling Latency and Time-Delay Effects, and Evidence-Bound Authentication.

Common Mechanisms¶

Abort-and-Retry After State Mismatch — When a use-time check finds the state has changed since it was first read, it abandons the stale attempt cleanly and re-runs the operation on fresh state — instead of forcing the old decision through.
Compare-and-Swap Version Token — Reads a value together with a version marker and writes back only if the version is still unchanged — so a write computed from stale state is refused instead of silently overwriting a newer one.
Confirmation Dialog with State Refresh — Re-fetches the live state the instant a person clicks confirm and shows it — with what changed highlighted — so the human commits against current reality, not the stale screen they were looking at.
Final Revalidation Before Commit — Re-runs the original precondition check as the very last step before the irreversible commit, so the action fires only if the condition that justified it still holds at the instant of use.
Lease-Bound Capability Token — Grants permission as a self-expiring token whose short validity window bounds the check–use gap, so a stale grant simply stops working instead of needing to be revoked.
Lock or Hold Until Use — Takes an exclusive hold on the resource at check time and keeps it through the use, so the checked condition cannot change inside the gap.
Reservation-Commit Protocol — Takes the resource out of contention the moment it is checked — an expiring hold that the commit later consumes — so the precondition cannot drift between check and use.
Revocation Status Check at Use — At the point of use, queries a live revocation source to confirm a previously-granted authority has not since been withdrawn before acting on it.
Snapshot-Pinned Decision — Computes and records a decision against one frozen, versioned snapshot of the state, binding the action to the exact evidence it was based on.
Stale Data Revalidation Gate — Refuses to act on state older than its validity window, forcing a refresh before a decision is allowed to ride on data that may already be wrong.
Timestamp and Freshness Badge — Stamps every datum with its capture time and shows its age at a glance, so whoever acts on the state can see whether it is fresh enough to trust before they rely on it.
Two-Phase Commit with Freshness Check — Coordinates a multi-party action as prepare-then-commit and re-verifies every precondition is still fresh at the commit boundary before any change is allowed to land.

Compression statement¶

Identify the checked precondition, the later action it authorizes, the gap in which relevant state may change, the freshness or validity evidence needed at use time, and the abort, retry, reservation, lease, lock, transaction, or revalidation rule that prevents stale precondition evidence from authorizing an unsafe action.

Canonical formula: Authorize(A) only if valid_at_use(P, S_t_use, scope(A)) is true, where P is the checked precondition, S_t_check is the observed state at check time, G = [t_check, t_use] is the check-use gap, and S_t_use must either equal the bound state version, be protected by a reservation/lease/lock, or pass a use-time revalidation rule before action A commits.

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

Built directly on (9)

Concurrency: Manage simultaneous processes.
Data Integrity: Accuracy and consistency preserved.
Evidence-Latency Window: A decision must be committed by a deadline while the evidence that would inform it arrives on a separate clock, and the signed gap between the two clocks governs the decision's information state and its repair options.
Latency: The irreducible delay between an input and the system's response.
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.
Transaction: All-or-nothing operations.
Unverified Precondition: An action presumes a referent exists at the moment of use without checking.
Verification: Check that an object conforms to its specification via a defined procedure yielding evidence and a verdict.

Also references 30 related abstractions

Access Control: Restrict system access.
Accountability: Responsibility for actions.
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.
Authority Handoff: A role with binding authority and attached state transfers between occupants without breaking either.
Backtracking: Extend a partial solution one step at a time and reverse the most recent commitment as soon as a constraint proves it cannot succeed, preserving earlier work.
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.
Capability Separation: Issuance is restricted to a privileged party while verification is open, tied by a forgery-prevention mechanism.
Change Notification: Advance warning, directed at those who depend on a system, that it is about to change in a way they need lead time to prepare for.
Commitment: An agent binds itself in the present to a future course of action or to the truth of a proposition, creating a new constraint on future behavior that others can rely on.

▸ Show 20 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

Collapses the check and the use into a single atomic or exclusive operation so the checked state cannot change before consumption.

Distinct from parent: The parent covers several binding strategies; this variant relies specifically on atomicity, isolation, or exclusivity.
Use when: The relevant state can be locked, transacted, or exclusively held; The cost of contention is acceptable for the risk tier; The action requires strong consistency rather than eventual correction.
Typical domains: database transactions, file system security, inventory reservation
Common mechanisms: lock or hold until use, two phase commit with freshness check, reservation commit protocol

Version-Checked Use · implementation variant · recognized

Allows action only when the state version observed at check time still matches the state version at use time.

Distinct from parent: The parent includes locking, leases, revalidation, and snapshot pinning; this variant centers compare-before-commit semantics.
Use when: State can change but carries a comparable version marker; Optimistic concurrency is preferred to exclusive locking; Abort and retry are acceptable on mismatch.
Typical domains: collaborative editing, database updates, policy workflows
Common mechanisms: compare and swap version token, abort retry after state mismatch

Lease-Bound Authority · temporal variant · recognized

Turns a verified authorization or resource state into a scoped, expiring, revocable lease that can be consumed only within its validity window.

Distinct from parent: The parent covers all check-use binding; this variant specifically uses temporary delegated authority.
Use when: A resource, identity claim, or permission can be reserved or tokenized; The action can be scoped by subject, action, audience, and expiry; Revocation or expiry must be honored at use.
Typical domains: access control, commerce checkout, capacity reservation
Common mechanisms: lease bound capability token, revocation status check at use

Snapshot-Bound Action · temporal variant · recognized

Makes explicit that the action consumes a named historical snapshot rather than claiming current-state validity.

Distinct from parent: Most parent cases seek current validity; this variant makes stale state explicit and acceptable.
Use when: Acting on the current state is impossible or unnecessary; The snapshot can be named, timestamped, and bounded; Downstream users will not mistake snapshot validity for present validity.
Typical domains: regulatory reporting, data science, historical archives
Common mechanisms: snapshot pinned decision, timestamp and freshness badge

Near names: TOCTOU, TOCTTOU, Stale Precondition Guard.