# Backward Pagination with Scope-Bound Opaque Cursors

Implement chronological backward pagination with opaque scope-bound cursors and accurate snapshot guarantees.

Exact reference: {"kind":"skill_version","skill_id":"skl_BMRfXWNZdvZPonaLz6O0Qg","version_id":"skv_ZHoNLaH6mLKAgI4vYbpztw"}

Applicability: []

# Backward Pagination with Scope-Bound Opaque Cursors

## Trigger

Use this guidance when an API reads older records in descending order, returns each page chronologically, and accepts a user-controlled cursor that may survive resource or filter changes.

## Practical steps

1. Define a unique, immutable total order. If one field is not unique, use the full ordering tuple plus a tie-breaker. Ensure later inserts cannot receive ordering values at or below an existing high-water boundary unless a stronger snapshot mechanism is used.
2. On the first request, independently authorize the caller for the selected resource, canonicalize the effective filters, fix the backward direction and ordering version, and capture the snapshot boundary.
3. Fetch page size plus one rows in descending order. When overflow exists, remove the final and oldest fetched row before reversing. For an exclusive continuation predicate, derive the resume position from the oldest retained row, not the discarded lookahead.
4. Return an opaque authenticated cursor. Prefer a signed random handle whose server-side state binds caller or tenant, resource, canonical filter digest, direction, ordering, snapshot, resume tuple, version, and expiry. A readable signed payload protects integrity but not confidentiality; use authenticated encryption when the cursor must be self-contained.
5. On continuation, independently authorize the currently requested resource, authenticate the cursor, and compare every stored binding before querying. Preserve the original snapshot and change only the resume tuple. Treat forgery, expiry, missing state, and every scope mismatch as the same generic invalid-or-stale cursor response.
6. Clear the cursor in the interface when scope changes, but keep the server checks because the client state is untrusted.

## Limits

A high-water mark excludes later inserts only when ordering assignment is monotonic and cannot be backdated below the boundary. It does not freeze edits, deletions, mutable ordering, or filter membership. Full stable-view semantics require temporal reads, versioned records, or a server-held database snapshot. Cursors never replace authorization. Bound token size and lifetime, rotate keys safely, and keep cursor contents out of logs.

## Failure prevented

This prevents skipped lookahead records, duplicated boundaries, cross-resource or cross-filter replay, direction confusion, resume-position tampering, internal identifier disclosure, and incorrect claims that a high-water mark is a complete snapshot.

## Evidence

Support is reasoned analysis with a manual sequence trace and an independent reasoning audit. No tests were executed.

## Supporting basis and limitations

The cited task conversation provides reasoned analysis, a manual sequential trace, and an independent reasoning audit. No tests were executed.

## Change and rationale

Clarify the monotonic-order precondition for high-water snapshots and tighten continuation validation while preserving the overflow, confidentiality, and authorization invariants.

The selected skill is an exact match for the pagination and cursor-scope problem. The update corrects an overbroad snapshot claim by covering later records that can be assigned below the captured boundary.