Enforce authority at the resource with fencing tokens

An authority service can issue a strictly increasing generation whenever ownership passes to a new holder. Each protected operation carries that generation and identifies its resource scope. The resource records a high-water mark for the scope and rejects an operation with a lower generation. A resumed holder with an older token can still run code and send requests; it simply cannot make the protected effect after the newer fence is established. This changes the safety boundary from a client's recollection of ownership to a check coupled with the resource's actual state change.

The comparison and effect must be one atomic resource operation under a justified synchronization or transactional mechanism. Checking a token, releasing protection, and applying the write later permits the fence to advance between those actions. The high-water mark also needs a suitable durability and failover contract; forgetting it after restart can make an old generation appear acceptable again. Generations must not silently repeat within the same resource incarnation. If a resource is deliberately recreated, its new identity and old-request rejection need an explicit design rather than an assumption that resetting a counter to zero is harmless.

Suppose a service issues generation 42 while a resource has only observed 41. A request carrying 41 may still pass a simple high-water comparison until 42 is installed there. Therefore, a proof must define when the new owner is allowed to consider itself active and how it establishes its fence before relying on exclusion. Depending on the system, that can be an explicit resource operation, a validated grant check, or another protocol. Do not infer that the resource has learned a new generation merely because a remote coordinator has assigned it to someone else.

Fencing also has a narrower purpose than duplicate suppression. Many valid operations can carry the same holder generation. Accepting generation 42 twice does not establish whether the second request repeats the first operation or represents new work. Use an operation identity and an idempotency or sequencing contract when retries need that distinction. Likewise, possession of an arbitrary large integer is not authorization; the resource must accept generations only through the intended authority scheme. Clock timestamps are not an automatic replacement for monotonic grants, because skew, repeated readings, and corrections can violate the required generation contract.

A worker might update a database, publish an object, and call an external payment service during one ownership interval. Fencing only the database does not automatically protect the other effects. List the effect boundaries and determine which can enforce generations, provide idempotency, participate in a transaction, or support a different coordination mechanism. Even perfect fencing at several resources does not by itself make a multi-resource workflow atomic. Failure recovery must account for which effects actually occurred. Test the resumed-old-owner case with requests delayed across ownership changes, not only orderly release followed by acquisition.

The modular lab isolates why generation reuse is dangerous. Reset, set both modulus m=4 and step a=1, predict when the orbit returns to zero, then Play or Step through four additions. The displayed residue identifies neither age nor unique ownership once it repeats. For any fresh comparison, Reset and re-set both controls. A production fence needs an explicit non-reuse or incarnation policy rather than this toy wraparound. The instrument does not issue grants, persist a high-water mark, validate authorization, or atomically reject a write; those are the mechanisms that make the resource-side rule meaningful.