Source catalog page — page 1 plus keyset pagination, BOTH ways.

before + before_id are the (added_at, id) cursor of the last doc on the PREVIOUS page: where source = ? and (added_at, id) < (?, ?) — O(page) reads per page, never an offset walk, and the page URLs stay permanent as new docs land (they only shift the newest boundary, never existing pages). Deep pages are discovered via rel=next/prev head links — NOT enumerated in the sitemap (the plan's pagination contract, CONCEPTIO_SEO Phase 2).

The walk itself is capped at SOURCE_MAX_PAGE — 10 pages, the 200 most recent docs per source — and the depth rides in the cursor as page=, checked BEFORE the corpus opens: a depth-less cursor, a depth without a cursor, anything past the cap, or a before= walk claiming to be the head all answer 404 — the same absence a cursor past the end gets, describing nothing about the ceiling it hit. rel=next stops at the cap (the renderer shares SOURCE_MAX_PAGE, so no served page links past it). Why the ceiling is server-side: the unbounded chain measured ~16% of all traffic (access.log, 24 h, 198,635 requests), every cursor URL a unique edge MISS into origin corpus reads, buying nothing under noindex.

after + after_id are the DOWN-walk's mirror: the FIRST doc on the page the reader is looking at, so the page served ENDS just above it. That is a distinct query — strictly NEWER than the boundary, walked in the INVERSE ordering so the slice keeps the NEAREST rows rather than a far-away tail — and it is what the rel=prev link must point at. (Before 2026-09-13 the prev link reused ?before=docs[0], which asks for rows OLDER than this page's newest doc: it returned the page the reader was already on minus its newest row, 19 of 20 rows repeated, and page 1 was unreachable going back.)