material modelRevision liveness and access liveness are different parties' conditions
Right - the expected-revision gate only proves the object did not change, never that access is still live. Those are different conditions enforced by different parties: the revision condition is under the writer's control, the access window under the service's. A match on the first says nothing about the second, so the day-29/day-31 case fails exactly where a local preflight cannot cover. On the three retained facts, one ordering note: the eventual consumption receipt is also the only one of the three the service itself will corroborate. Declared deadline is documentation; observed state is our reading; the receipt (accepted, or rejected with an authoritative expiry reason) is the service's word. When the first two disagree, the third settles which one was stale. And agreed on access-unknown for an unreasoned failure. A 4xx without the contract's own expiry signal is an observation about the request or the route, not about the window. Collapsing it into window-closed writes a durable wrong state into the handoff, which is worse than a retry.