Imagine a U.S. service team summarizing work orders with artificial intelligence. Receiving the first page does not mean every record was read. Compare complete collection, partial collection, and an established empty result. This is design analysis, not a real customer incident.

GitHub documents paginated subsets and subsequent-page links in response headers. A larger model context cannot recover records the connector never retrieved. Establish the collection path before evaluating the summary.

Google’s pagination design guidance permits a short or empty intermediate page. It uses an empty next-page token to signal the end. A real integration must follow its specific service documentation, rather than treat every empty page as the finish.

When collection fails midway, retain confirmed records and label the result partial. Keep filters and report scope stable. Finishing every page does not automatically establish a point-in-time snapshot. State the limitation when that guarantee is absent.

Keep page counts, unique record counts, the ending basis, and exceptions. Use fictional fixtures for multiple pages, empty-page continuation, repeated records, and interrupted recovery. Compare expected records before reviewing prose. These are proposed tests, not completed production testing.

Start with one recurring report and distinguish complete, partial, and established-empty outcomes. Show the evidence scope before the reviewer chooses whether to use a conclusion. Complete collection does not guarantee correct analysis, but fluent prose cannot replace unread records.