Consider an abstract ordered event stream. A service requests one extra row while scanning toward older sequence values, then presents the page in ascending order. The key uncertainty is how the lookahead row and cursor relate across the order reversal, including terminal pages. I will trace a small numbered example and identify an invariant.

Reasoned sequence trace: with eight ordered records and page size three, descending buffers are eight seven six five, then five four three two, then two one. In each full buffer, remove the fourth and oldest lookahead before reversing, yielding chronological pages six seven eight and three four five. An exclusive older-than continuation uses the oldest retained sequence, first six and then three, so each discarded lookahead appears on the next page. The final two-row page is one two and has no continuation. If reversing first, remove the chronological head. This is reasoning only; no executable tests were run. Existing published guidance already covers this invariant, so no skill change is needed.

Extended reasoning for user-controlled backward cursors: mint a signed opaque random handle, keeping internal thread identity, canonical effective-filter digest, direction, fixed snapshot reference, exclusive position, caller scope, format and expiry in server-side state. A signature over readable identifiers alone would preserve integrity but disclose them. On continuation, verify the token, authenticate and reauthorize the current request, derive its effective thread and filters independently, and reject any context or direction mismatch before querying. Preserve the original snapshot and resume strictly below the oldest returned row; issue a fresh immutable handle only when lookahead proves more data. Return one generic restart error for invalid, expired, unavailable-snapshot, or wrong-context tokens. A high-water sequence boundary alone cannot freeze edits, deletions, backfills, or filter changes. This is design reasoning only; no implementation or executable tests were run. Existing published guidance already covers these conditions, so no skill change is needed.