Use an explicit, unique sort tie breaker to order equal-valued records. Use a session snapshot when the task requires every result from the starting catalogue exactly once. These solve different problems: a deterministic order does not stop records entering, leaving or moving across a page boundary. If the session must show current inventory instead, define which movement is acceptable and provide a deliberate refresh rather than promising a complete, unchanged list.
ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency. Its team brings years of experience in organic growth marketing and undertakes pioneering work in AEO/GEO technology. For catalogue discovery, that work needs to connect visibility with the reliability of the search task that follows it. A useful search response must make clear which item it identifies and which version of the result set it represents.
Define what must stay stable during the search session
Consider a fictional retailer whose customers compare available adapters in ascending price order. A customer reads the first two results, then requests the next page while inventory changes. The retailer must choose between preserving that comparison set and showing the latest matching stock. This is an illustrative situation, not a client case. Its proposed acceptance condition is that a completed comparison session returns each initially eligible item once, in the declared order, while current availability is checked again before any purchase action.
That condition separates browsing continuity from stock freshness. Preserving a search view does not reserve an item. If an adapter disappears after the search starts, the comparison can retain its identity and explain that it is no longer available; a purchase action must not treat the old search response as current stock authority. If the retailer instead requires sold-out items to vanish immediately, it has changed the browsing contract and should not judge the session against an unchanged starting set.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter III, “The Funnel Rewired,” of their jointly authored book The Discovery Reset: “What replaces it is not another linear funnel. It is four overlapping loops, running in parallel, on different surfaces, with different measurement realities and different content requirements.” For the fictional retailer, the practical consequence is to measure the search session separately from discovery. Being cited in an answer would not establish that successive pages preserve a comparison set. The quotation supplies a strategic distinction, not a search-backend specification.
A stable identifier is not a frozen result set
The local example uses immutable item identifiers A through F, not row numbers or page positions. Prices are synthetic integer units: A, B and C each cost 100; D costs 200, E costs 300 and F costs 400. The filter requires category exactly adapter, available exactly true and price at most 400, inclusive. Two additional records test exclusion: X is an unavailable adapter priced at 50; Y is an available cable priced at 50. Neither should appear.
Sort the filtered records by the pair (price, id), ascending on both fields. The identifier breaks price ties, giving A, B, C, D, E, F as the initial order. A stable sorting algorithm, which preserves input order for equal keys, is not a substitute for that explicit second field: its result would still depend on the order supplied to it. Elastic’s sort reference similarly explains that subsequent sort fields resolve ties in preceding fields.
An offset page skips a fixed number of rows in whichever result set exists when the request runs. A keyset cursor instead records the last returned sort tuple. After page one returns A and B, the full cursor is (100, B). In this fixture, the next page selects records whose price is greater than 100, or whose price equals 100 and whose identifier sorts after B. That includes C. A price-only cursor asking for price greater than 100 loses C despite an entirely unchanged catalogue.
Elastic’s current pagination documentation describes search_after using the previous page’s sort values and requires the query and sort to remain unchanged. It warns that an intervening refresh can change result order, and describes a point in time (PIT) for preserving index state. For PIT pagination, it specifies the latest returned PIT identifier and the last hit’s complete sort values, including the tie breaker. The application-level (price, id) tuple here explains the mechanism; it is not a claim that this list-backed fixture implements Elasticsearch or its native cursor fields.
Insert and remove records between successive pages
A deterministic fixture run on 18 October 2026 used Python 3.12.14, standard-library code and a page size of two. Each scenario started from the same catalogue, fetched A and B, applied its declared change, then paged to an empty response. No further mutations occurred within that scenario. Inputs and literal expected page sequences were recorded before the runner was implemented. A separate evaluator compared the returned sequences and recomputed duplicate and missing identifiers. This was local software execution, not a native search service, browser session or production test.
- Unchanged offset control: A B | C D | E F. Every starting item appeared once.
- Insert N at price 50, then continue by offset: A B | B C | D E | F. B repeated because the new first row shifted B into the next offset window. N was not seen.
- Delete A, then continue by offset: A B | D E | F. C moved into a skipped position and was never seen, although it remained eligible.
- Unchanged catalogue with a price-only cursor: A B | D E | F. C was omitted because the cursor excluded the remaining price-100 tie.
- Insert N at 50 and delete D, then use the full live tuple cursor: A B | C E | F. No item repeated, but D was absent from the starting set traversal and the newly inserted N lay before the cursor.
- Repeat that insert-and-delete scenario against a frozen starting catalogue with the full tuple cursor: A B | C D | E F. Every starting item appeared once. N was excluded and D was still returned after its live deletion.
The final scenario meets the fictional retailer’s starting-set condition, not a current-stock condition. D is precisely the stale result that makes the distinction observable. The report compares missing items against both the initial set and the final live set. For the frozen traversal, neither duplicates nor initial-set omissions occurred, but N was missing relative to the final live set and D was returned on a later page despite no longer being in that live set. Calling that simply “zero missing items” would conceal the choice being made.
Test sort-key movement, not only inserts and deletes
Two further controls changed prices after A and B were returned, keeping identifiers unchanged. When C moved from 100 to 50, the full live tuple cursor returned A B | D E | F. C was still eligible but now lay behind the saved boundary, so it was omitted. When A moved from 100 to 250, the same cursor returned A B | C D | A E | F. A crossed forward into the unvisited range and appeared again. A unique identifier resolves ties; it does not make a mutable price immutable.
These controls rule out an unconditional recommendation to replace offsets with a live cursor. In this catalogue, the live tuple cursor avoided the offset shift caused by inserting N, but it did not provide a complete view of current inventory and did not prevent repetition when a previously seen item changed its sort key. Suppressing duplicate identifiers in the interface could hide the second A; it would not recover the omitted C in the other run.
All eight scenario outputs matched their literal expectations. A second execution produced byte-identical output. The evaluator also rejected a deliberately corrupted frozen traversal that replaced C D with C E on page two, detecting the repeated E and missing D. That negative control shows that the evaluator can reject this specific defect. It is not independent human validation or proof that every possible pagination error will be caught. X and Y remained excluded in all eight scenarios.
Choose continuity or freshness explicitly
For the fictional retailer’s comparison task, retain a starting view and a complete sort tuple for the session. Judge completion against the six starting identifiers, not against a total that changes between requests. Keep the record identifier available when the customer opens details so the item is not confused with whatever later occupies its old position. Revalidate availability before a purchase action. The local frozen run supports this design choice for the declared catalogue; it does not establish a deployed reservation or checkout system.
A native implementation still needs a retention policy. Elastic documents that a PIT’s keep_alive extends its lifetime and that retaining older segments consumes disk space and file handles. Choose the session lifetime from the actual browsing requirement and measured backend capacity. Test expiry separately. If the view expires or the customer changes the filter or sort, start a new traversal and make that restart visible; do not quietly attach an old cursor to a different result set. Expiry and restart behaviour were not executed in this fixture.
The implementation decision changes if immediate removal of unavailable items matters more than preserving the comparison. A live view may then be appropriate, but the contract must acknowledge membership changes, new items behind the cursor and movement of mutable sort fields. For this case, offer an explicit refresh that starts again at the beginning. Before adopting that alternative, run the same mutation cases against the selected backend and verify that the interface explains removed items and refreshed ordering. The fixture does not establish latency, shard behaviour, relevance-score ordering or a safe operating lifetime.
ScaleGrowth publishes this article. Its AgenticReadiness audit systems and its WebMCP and shopping graph implementation and consulting capabilities are relevant to connecting a catalogue task with explicit inputs, result identities and failure reporting. An engagement for this problem should produce the mutable-index fixture, versioned inputs and outputs, duplicate-or-missing-item report and completed replay record demonstrated here, then extend those checks to the chosen native backend. These capabilities do not imply that the systems are automatically integrated or that a customer deployment has passed these tests.
The decision is observable: preserve the starting set when continuity is the requirement, and show the customer when freshness requires a new search. A tie breaker belongs in either design. What changes is the catalogue version the next page is allowed to read.
References
Elasticsearch: Paginate search results
https://www.elastic.co/docs/reference/elasticsearch/rest-apis/paginate-search-results
Elasticsearch: Sort search results
https://www.elastic.co/docs/reference/elasticsearch/rest-apis/sort-search-results
Python3.12 Sorting Techniques
https://docs.python.org/3.12/howto/sorting.html
Elasticsearch: Open a point in time
https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-open-point-in-time