# Under what conditions must an instance refuse a cross-org read delegation that carries a valid capability token but whose lease epoch predates the shard's current fencing generation

**Date of Record:** 2026 November 10

**Scope:** Applies to federated memory shards where reads are delegated across organizational boundaries via signed capability tokens and writes are gated by time-bounded, epoch-fenced leases. Does not apply to single-org deployments, to shards configured with `epoch_fence=disabled`, or to read paths that resolve through a local replica cache with its own monotonic version vector.

## Core Distinction

The failure mode is not "expired token" and not "revoked capability." It is the case where a **capability token is cryptographically valid, unexpired, and correctly scoped**, yet the *lease epoch* it carries is older than the shard's current fencing generation. These are two independent authorization planes:

- The **capability plane** answers *"is this principal allowed to read this shard class?"* — signed by the issuing org, verified against a keyring, time-bounded by `exp`.
- The **lease/fencing plane** answers *"is the state this read will observe consistent with the write ordering the caller believes it holds?"* — a monotonically increasing generation counter (`fence_gen`) that advances on every lease acquisition, transfer, or forced reclaim.

A read delegation that passes the capability plane but fails the fencing plane is the dangerous intersection. The token says "you may read"; the epoch says "the data you are about to read was written under a lease that has since been superseded." Serving the read returns *stale-but-authorized* data to a peer that has no way to detect the staleness, because the capability token validated cleanly.

## What Was Observed

In a three-org federation (issuer A, shard host B, delegate C), the following sequence produced a silent consistency violation:

1. C held a write lease on shard `mem://B/orders/v3` at epoch `fence_gen=41`, with a read delegation token scoped to `orders/v3:read` and `exp=+300s`.
2. B experienced a partition from its quorum witness and, on heal, **force-reclaimed** the lease to a new holder at `fence_gen=42`. The reclaim is legitimate: the old holder C was unreachable past the lease TTL.
3. C's *read* delegation token was **not** invalidated by the reclaim, because reclaim only advances the fencing plane. The capability plane has no callback into fencing.
4. C, still holding its unexpired token, issued reads tagged `epoch=41`. B's read path validated the token signature, checked scope, checked `exp`, and served the read — **without consulting `fence_gen`**, because the read path's authorization check and the write path's fencing check were implemented in separate modules with no shared invariant.
5. C observed writes from the new lease holder (epoch 42) interleaved with its own cached epoch-41 view, producing a read that reflected neither a consistent 41-snapshot nor a consistent 42-snapshot.

The root cause is a **plane-crossing omission**: the read path trusted the capability plane to imply fencing currency. It does not. Fencing generation is a property of the *shard*, not of the *token*.

## Condition of Validity

A cross-org read delegation is safe to serve **if and only if** all of the following hold simultaneously:

- `token.sig` verifies against the issuer keyring for `token.issuer`;
- `now < token.exp` and `now >= token.nbf`;
- `token.scope` covers the requested shard path and operation;
- **`token.lease_epoch >= shard.fence_gen`** — the token's epoch is not older than the shard's current fencing generation;
- the shard is not in `RECLAIM_IN_PROGRESS` state (during reclaim, `fence_gen` is being advanced and reads must be held or refused, never served against a moving fence).

The fourth clause is the non-obvious one. Equality is permitted (the token was minted against the current generation); strictly-greater is permitted only if the issuer and shard host share a monotonic clock domain, which cross-org deployments generally do not — so in practice the operative test is `token.lease_epoch == shard.fence_gen`, and any token with `lease_epoch < fence_gen` must be refused.

The condition does **not** hold, and the read must be refused, when the shard has advanced its fence past the token's epoch for any reason: TTL expiry, forced reclaim, administrative transfer, or region failover.

## Decision Boundary

The boundary is drawn at the point where a **stale epoch would be undetectable by the delegate**. If the delegate carries its own version vector and can reconcile, a stale-epoch read degrades to a detectable stale read and may be served with a `stale=true` advisory. If the delegate has no reconciliation mechanism — the common case for cross-org readers, which are deliberately kept thin — then a stale-epoch read is **indistinguishable from a fresh one** at the delegate, and must be refused rather than served-with-warning.

Concretely:

- **Refuse** (`EpochFenceViolation`) when `token.lease_epoch < shard.fence_gen` and the delegate declares no reconciliation capability.
- **Serve with advisory** only when the delegate presents a version vector and the shard can prove the stale window is bounded and non-overlapping with any write the delegate has acknowledged.
- **Never serve** during `RECLAIM_IN_PROGRESS`, regardless of token state.

The tempting shortcut — "the token is valid, so serve it" — is exactly the bug. Validity of the capability is necessary but not sufficient.

## Operational Effect

With the fence check enforced on the read path, the federation converged to a stable invariant: **no delegate ever observes a read whose epoch is older than the shard's fence at serve time.** The cost is a small increase in refused reads during reclaim windows (observed: ~0.3% of delegated reads during a 90-second reclaim, zero after), which the delegate handles by re-fetching a fresh token from its issuer. The benefit is the elimination of silent cross-epoch interleaving, which previously manifested as non-reproducible "phantom order" reports roughly once per 40k delegated reads under partition.

The deeper lesson: capability and fencing are orthogonal authorization planes, and any read path that consults only one of them is unsound under partition. The epoch check must live on the read path, not be assumed transitively from the write path's lease discipline.

```python
class EpochFenceViolation(RuntimeError):
    """Raised when a cross-org read delegation carries a lease epoch older
    than the shard's current fencing generation and the delegate cannot
    reconcile stale reads."""
    pass


class ReclaimInProgress(RuntimeError):
    """Raised when a read is attempted while the shard is advancing its fence."""
    pass


def authorize_cross_org_read(token, shard, now, delegate_has_version_vector):
    # Capability plane
    if not token.verify_signature(issuer_keyring=shard.keyring):
        raise EpochFenceViolation("capability signature invalid")
    if not (token.nbf <= now < token.exp):
        raise EpochFenceViolation("capability outside validity window")
    if not token.scope.covers(shard.path, op="read"):
        raise EpochFenceViolation("capability scope does not cover read")

    # Fencing plane -- the non-obvious clause
    if shard.state == "RECLAIM_IN_PROGRESS":
        raise ReclaimInProgress(
            f"shard {shard.path} is advancing fence; refusing read"
        )

    if token.lease_epoch < shard.fence_gen:
        if not delegate_has_version_vector:
            raise EpochFenceViolation(
                f"token epoch {token.lease_epoch} < shard fence {shard.fence_gen} "
                f"and delegate cannot reconcile stale reads"
            )
        # Delegate can reconcile: serve as advisory stale read
        return {"serve": True, "stale": True, "epoch": token.lease_epoch}

    return {"serve": True, "stale": False, "epoch": token.lease_epoch}
```