ACTIVEEXPIREDROLLBACKDO NOT RESURRECT

Four invariants.

I35

SAME WALL-CLOCK VALUE ≠ SAME TEMPORAL STATE AFTER HISTORY ADVANCESA timestamp does not identify the execution epoch.

I36

EXPIRED / RETIRED SAFETY EPOCH MUST NOT BE RESURRECTED BY CLOCK ROLLBACKOld permission does not return with old clock values.

I37

TIME-BASED EXECUTION AUTHORIZATION SHOULD BIND TO A MONOTONIC EPOCH OR MONOTONIC TIME BASISUse a history signal that cannot move backward with the wall clock.

I38

CLOCK ROLLBACK AFTER IRREVERSIBLE TEMPORAL TRANSITION IS EVIDENCE CONFLICTFence or reconcile before consequential execution.

Reference decision path.

WALL CLOCK+TEMPORAL EPOCH / WATERMARKEXECUTION PRECONDITION
history advancesexpiry / cleanup / revocation / rotation
clock moves backwardcompare monotonic historyFENCE / RECONCILE

Why a wall clock is not enough.

Wall-clock predicates can move in both directions. A lifecycle transition such as expiry cleanup, revocation or lease rotation may be irreversible from the protocol's point of view. If the clock later returns to an earlier value, the old predicate can become numerically true again even though the system has moved to a new execution epoch.

The value can return. The history cannot.

Verified #019.

The same idempotency record was observed ACTIVE → EXPIRED → ACTIVE when logical wall-clock time moved forward and then backward. After cleanup removed the record and advanced the temporal epoch, an un-fenced same-key replay produced two effects.

Binding the retry to the old epoch caused the service to reject it with HTTP 409 / fenced_out after the epoch advanced. A separate monotonic time watermark kept the effective decision time at the maximum previously observed value, preserved EXPIRED, and reconciled COMMITTED without another POST.

Evidence required.

A proof path that depends on temporal fencing should preserve wall-clock observations, bound temporal epoch or watermark, the history-changing transition, current epoch at execution, fence result, remote authoritative state and final effect count.

Scope.

This rule does not prescribe NTP/PTP behavior, operating-system clock handling, hardware timing, a universal fencing mechanism or production TTL values. It defines protocol semantics for preventing old temporal permission from being revived solely by a backward-moving clock value.

  1. Verified Report #019
  2. Canonical extension source
  3. Transactional Trust Protocol v1.0

Short form: SAME WALL-CLOCK VALUE ≠ SAME TEMPORAL STATE.