Prompt Session Assignment Consistency: Bundle Stickiness, Emergency Revocation, and Stale-Worker Fencing

Prompt Versioning and CI already covers Git, offline evaluation, shadow traffic, canary percentages, and fast rollback. This article no longer asks “is the candidate better than the baseline?” It starts after the release system has selected an approved digest and addresses only three runtime questions: does a session remain pinned to the same bundle, can a stale worker replay an assignment, and can emergency revocation take effect before the next model or tool dispatch? Prompt Engineering Systems remains responsible for template content.

Assignments Must Reference a Complete Bundle

A bundle content-addresses the system fragments, few-shot examples, tool descriptions, output schema, security rules, and renderer together. After the registry validates every reference, model compatibility range, and policy, it generates a digest. Version names exist only for humans; any change to a partial or renderer produces a new digest. An assignment cannot point to latest or a mutable directory.

{
  "assignmentId": "pa-01K2...",
  "sessionId": "s-918",
  "bundleDigest": "sha256:5a9d...",
  "rolloutGeneration": 44,
  "policyEpoch": 18,
  "revocationEpoch": 7,
  "operationFence": 12,
  "issuedAt": "2026-07-19T11:20:00Z",
  "expiresAt": "2026-07-19T11:35:00Z",
  "state": "ACTIVE"
}

The resolver may select a digest using an OpenFeature-style context, but the result must be persisted as a server-side assignment; the stable subject must come from authenticated context. The only states are ACTIVE/DRAINING/REVOKED/EXPIRED. Ordinary weight changes affect only new assignments; existing sessions retain a consistent bundle, renderer, toolset, and schema for the duration of the lease.

When an asynchronous task is created, it persists an OperationAttempt bound to (assignmentId, bundleDigest, rolloutGeneration, observedFence, operationId, payloadDigest); the worker carries only an unforgeable attempt ID. The gate reads the tuple from the record, so a stale worker cannot reread the current assignment and absorb a new fence. Reassignment, cancellation, or revocation monotonically advances the fence or cancel generation. Trace content is still handled according to Prompt Trace Redaction.

Dispatch Requires a One-Shot Operation Permit

Before dispatching a model or tool, the system must obtain an OperationPermit from the same linearly consistent gate used for revocation. The gate atomically verifies that the assignment is ACTIVE, validates the lease, bundle, epoch, observed fence, and cancel generation, and transitions the attempt from PLANNED -> PERMITTED. The permit is bound to the operation ID, digest, epoch, fence, and expiration time; it cannot be transferred or refreshed.

Immediately before dispatch, the gate verifies the tuple again in the same transaction, preregisters the provider/effect attempt and idempotency key, and then uses CAS to transition the one-shot permit from PERMITTED -> DISPATCHING. This CAS is the linearization point in the revocation race; external I/O occurs only after it succeeds. A stranded DISPATCHING attempt transitions to UNKNOWN_RECONCILING. TTL expiration cannot prove that no call occurred, and a consumed permit cannot be replayed. Short-Lived Capability Leases govern tool permissions; the permit here additionally binds the bundle and session generation.

Emergency Revocation Is Not an Ordinary Rollback

When quality declines, stop new assignments or select the previous digest and allow existing sessions to drain. During a security incident, the same gate must use CAS to advance the revocation epoch, mark the bundle as revoked, stop issuing permits, and close all unconsumed permits. If DISPATCHING commits first, the operation is treated as accepted, its response is quarantined, tool calls that have not been released must not execute, and UNKNOWN side effects enter reconciliation.

Affected sessions receive new assignments pointing to a safe bundle that has passed compatibility checks for the current model, tools, and policies. The ID of an old assignment cannot be rewritten to point to another digest. Rendering, length, and prefix cache keys must all include the bundle digest, policy epoch, and revocation epoch. Revocation first makes old keys unacceptable; physical cleanup can happen asynchronously. Prompt Caching handles performance; this protocol only requires that stale caches cannot bypass revocation.

During a registry partition, a process may serve existing low-risk assignments only within the brief validity period of a signed state lease, and it must stop creating new assignments. Once the state lease expires, or for any high-risk operation, it must fail closed. It cannot use the last-known bundle indefinitely because the node may have missed a REVOKED state. After recovery, it must synchronize the current revocation epoch before issuing permits again.

Validate by Injecting Races at Precise Points

Tests should insert revocation between reading the assignment and obtaining the permit, and immediately before and after the PERMITTED -> DISPATCHING CAS, asserting that only one side can commit first at the acceptance point for revocation or sending. Then inject stale-attempt replay, a crash after CAS but before the external response, assignment expiration, replacement of a bundle under the same name, two control planes advancing the epoch, a registry partition, stale caches, and response loss. The following must hold: new permits for a REVOKED bundle are zero, external calls without a DISPATCHING attempt are zero, replays of consumed permits are zero, and mixed-bundle sessions are zero.

Runtime metrics should measure only this responsibility: assignment resolution failures, unknown or expired digests, stale-fence rejections, permit acquisition and closure, dispatches after revocation, mixed-bundle sessions, in-flight convergence time, and UNKNOWN effects. Task quality, cost, and canary outcomes still belong to the release evaluation described in the previous article; do not duplicate those metrics here.

Begin rollout by creating assignments and permits in shadow mode without controlling requests, and check discrepancies involving stale workers and caches. Then enable the protocol for sessions without tools, and finally extend it to asynchronous tool chains. A rollback implementation must not remove the revocation epoch or permit gate; it may only have the resolver select the previous compatible digest. Security controls must remain monotonic so that restoring an older Prompt does not reauthorize revoked workers.

Further Reading

• Prompt Versioning and CI
• Prompt Trace Redaction
• Short-Lived Capability Leases
• Prompt Caching