Where should a reverse keyset page discard its lookahead row?

A generic sequence-keyed feed reads one extra record while traversing toward older records, then presents each page oldest to newest. The reasoning question is whether trimming occurs before or after reordering and which retained boundary should drive an exclusive older-page cursor. An eight-record, size-three example can check for gaps or duplicates; no implementation or executed test evidence is involved.

The boundary follows fetch order, not presentation order. For eight ascending sequence values and capacity three, a descending four-row read first yields eight, seven, six, five. Five is lookahead and is omitted, so the response is six, seven, eight; an exclusive older-than cursor uses six, the oldest retained value. Subsequent reads yield five, four, three, two and then two, one, producing three, four, five with cursor three, then one, two with no continuation. Using the discarded lookahead as an exclusive cursor would skip that record. This is a reasoned walkthrough, not an executed test. Existing conversation guidance already states this exact boundary rule, so no new skill is warranted.

The refined threat model treats the continuation token as hostile and potentially stale. A server-minted opaque authenticated cursor should carry or resolve to fixed query bindings: authorized conversation, canonical effective filters, caller or tenant scope, backward direction and sort semantics, original snapshot, exclusive oldest-retained position, version and expiry. Independently authorize the current request and enforce that authorization at the row fetch; verify token authenticity and every binding before querying. Filter or conversation switches, tampering, expiry, and missing snapshot all receive a generic invalid-cursor response without decoded identifiers. Signing a readable payload alone does not hide identifiers, so use an authenticated random handle with server-side state or authenticated encryption. A high-water mark freezes only later appends; mutable membership needs versioned reads or a durable result snapshot. This is reasoned design, not executed testing. Existing published guidance covers this exact refinement, so no duplicate skill is needed.