Final Revalidation Before Commit¶

Pre-commit revalidation rule — instantiates Use-Time Precondition Binding

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.

The simplest way to bind a check to a use is to move the check next to the use. Final Revalidation Before Commit does exactly that: whatever precondition was verified earlier — approval granted, resource available, no freeze in effect — is re-tested one more time as the last step before the point of no return, and the commit proceeds only if it still holds. Its defining move is relocating the decisive check to the commit boundary so the check–use gap shrinks to near zero, and re-evaluating the actual predicate against fresh state rather than trusting a proxy or a stale earlier pass. It holds nothing and reserves nothing; it simply refuses to fire on a condition that has quietly stopped being true.

Example¶

A release has been sitting in a CI/CD pipeline for an hour, having passed every gate: tests green, security scan clean, change approved. Just before the deploy job flips production traffic to the new build, Final Revalidation Before Commit re-runs the decisive preconditions at the commit boundary: is this still the approved commit SHA, are the required checks still green (nothing reverted since), is there no active incident or deploy freeze, is the target fleet still healthy? Suppose an incident commander declared a change freeze forty minutes ago. The earlier checks all passed — but this last one catches the freeze and blocks the deploy, even though everything looked ready an hour before.

The mechanism earns its place on exactly the cases the hour-old checks cannot see: the world changed after approval and before the irreversible act. The same shape appears far from software — the surgical "time-out" immediately before incision re-confirms patient, site, and procedure for precisely this reason^[1].

How it works¶

It sits at the commit boundary. Positioned as the last step after all preparation, so almost no time — and almost no opportunity for drift — remains between it and the irreversible act.
It re-tests the real predicate. The decisive condition itself is re-evaluated against fresh state, not a version marker or a cached proxy that could pass while the real condition has failed.
It fails closed. If the re-check fails, or cannot be completed, the commit is refused — the default is "don't act," not "act anyway."
It stays narrow and fast. Only the few conditions that actually gate the decision are re-checked, so the re-validation does not itself become a slow new gap.

Tuning parameters¶

Predicate set — re-check only the decisive conditions or re-run everything. Broader catches more but costs time and can re-open the gap it is closing.
Fail-open vs. fail-closed — on an inconclusive re-check, block by default or proceed with a warning. Fail-closed is safer; fail-open favors availability.
Freshness bound — how recent the state read backing the re-check must be to count.
Placement — a single final gate, or a re-check at every stage boundary in a long pipeline.
Blocking vs. advisory — a hard stop versus a logged warning that still lets the commit through.

When it helps, and when it misleads¶

Its strength is leverage: a cheap, well-placed re-check that catches the precise failure this whole archetype is about — the world moving between approval and action — and it is most valuable right before irreversible, high-blast-radius commits, where being wrong is expensive and unwindable.

It misleads by inviting false confidence. The re-check only shrinks the gap to the width of the re-check itself: a race can still slip in the moment between the re-validation and the commit unless the two are made atomic (which is where a version token or lock comes in). A slow re-check widens the very gap it means to close. And re-checking a convenient proxy instead of the real condition — something cheap that "looks like diligence" while the decisive predicate goes untested — is the classic misuse. The discipline is to re-check the actual decisive condition, keep it fast and fail-closed, and, where even a microsecond residual race is unacceptable, fuse the re-check to the commit with an atomic mechanism rather than leaving them as two separate steps.

How it implements the components¶

Final Revalidation realizes the re-check-at-the-boundary side of the archetype — closing the gap by moving the decisive check to the point of use:

use_time_revalidation_rule — its core: the rule that the precondition must be re-evaluated at the commit boundary, and that the commit proceeds only if it still holds.
checked_precondition_claim — it re-tests the exact claim verified earlier, against fresh state, rather than trusting a proxy or the original pass.
check_use_gap_window — by placing the decisive check at the commit boundary, it is the mechanism that directly drives the check–use gap toward zero.

It re-checks by rule, silently — the human-consent version is Confirmation Dialog with State Refresh — and it does not make the re-check and the commit atomic; the atomic_or_exclusive_use_boundary and state_version_or_freshness_token that would close the residual race are Compare-and-Swap Version Token and Two-Phase Commit with Freshness Check.

Instantiates: Use-Time Precondition Binding — Final Revalidation binds the precondition by re-testing it at the last possible instant before the commit.
Sibling mechanisms: Confirmation Dialog with State Refresh · Two-Phase Commit with Freshness Check · Compare-and-Swap Version Token · Abort-and-Retry After State Mismatch · Stale Data Revalidation Gate · Reservation-Commit Protocol · Snapshot-Pinned Decision · Revocation Status Check at Use · Lease-Bound Capability Token · Lock or Hold Until Use · Timestamp and Freshness Badge

Notes¶

Final Revalidation minimizes the gap but does not eliminate it — a residual race remains between the re-check and the commit. It is therefore often the last step inside a stronger mechanism: the freshness re-check in Two-Phase Commit with Freshness Check, or the re-validation before consuming a hold in Reservation-Commit Protocol. Used alone it is a high-value, low-cost guard; used as the finishing check inside an atomic commit, it is airtight.

References¶

[1] The surgical "time-out" — a moment immediately before incision when the team re-confirms patient identity, surgical site, and procedure — is the canonical real-world Final Revalidation, formalized in the WHO Surgical Safety Checklist. It exists because the earlier verifications, however thorough, were done before the irreversible act, and the decisive facts must be re-confirmed at the point of use. ↩