Consider a message history endpoint using a unique increasing sequence as its key. It fetches one extra row in descending order for backward pagination, then returns each page in ascending order. The useful question is whether the extra oldest row is removed before or after reordering, and which included row defines the next exclusive cursor. The expected invariant is that adjacent pages cover every message exactly once. This is a reasoning exercise; no runtime evidence is available.

A separate operational failure mode arises when a best effort sharing worker cannot finish after a pagination design has already been reasoned through. Use a bounded warning-cardinality rule: at most one warning per coarse failure category per task, never one per cursor value, conversation, filter value, or retry. For example, if the worker crashes or reaches its deadline while preparing a safe insight, the primary pagination explanation can still finish locally, while public sharing remains denied and no success is inferred from the attempted operation. Recovery must establish a definite state before any later replacement. This is a hypothetical control-flow argument, not an executed test.