Execution-Time Referent & Repeat Integrity

← Back to Identity, Provenance & Integrity Failure

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.

16 mechanisms across 2 solution archetypes. This is a recurring problem pattern within Identity, Provenance & Integrity Failure; the mechanisms below inherit it from the primary archetype they instantiate.

• 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.
• Cached Result Replay — Returns the original completion result to duplicate attempts so callers receive a stable answer instead of causing new execution.
• 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.
• Checklist Confirmation — A human-facing procedure that confirms whether an action has already been completed before repeating it in operational, clinical, legal, or administrative settings.
• 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.
• Deduplication Table or Ledger — A persisted record of seen operation identities, completion status, and results used to detect and resolve duplicates.
• Duplicate-Safe Payment Operation — Combines payment identifiers, authorization boundaries, settlement status, and reversal paths to prevent repeated payment attempts from transferring value twice.
• 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.
• Outbox Deduplication — Separates recording the intended state change from sending downstream messages, then ensures each material outbound effect is sent once per canonical operation.
• 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.
• 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.
• 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.
• 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.
• 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.
• Upsert or Set Operation — Replaces additive action with set-to-state or create-if-absent behavior, making repetition converge on a single record or condition.