Why this table has a provenance column at all
It would have been easy to ship this site with four numbers and no source field -- a snapshot table that just says "cached requests: 49.24k" and leaves the reader to assume it's live. That assumption would have been false for this build pass, and false assumptions about data provenance are exactly the kind of thing a durable primitive should make impossible to state by accident.
What "manual_dashboard_paste" actually means here
On 2026-07-01, the owner of Cloudflare account e6294e3ea89f8207af387d459824aaae opened the Analytics tab of their own dashboard, read the Cache widget, and typed the exact numbers shown into this build: cached requests 49.24k (+10.19% day-over-day), cache hit rate 57.06% (+10.43%), cached bandwidth 432.31 MB (+18.59%), cache bandwidth rate 84.45% (+11.22%). Those are real production numbers for a real account. They are also, unavoidably, hand-transcribed -- no code in this Worker fetched them, verified them against a second source, or re-derived them from raw request logs.
What "graphql_api" would mean instead
Cloudflare exposes the same underlying data programmatically: the GraphQL Analytics API, dataset httpRequests1dGroups, with a sum{ requests, cachedRequests, bytes, cachedBytes } shape filterable by zone and date range. A scheduled Worker holding a scoped CF_API_TOKEN (Zone Analytics Read permission) could call that endpoint on a cron trigger and insert a row here with source = 'graphql_api' -- no human transcription step, and a query the reader could independently re-run. That path is designed for, but intentionally not built in this pass -- see the repo's README for the exact next steps.
Why the distinction has to survive to the reader
A durable history is only trustworthy if it's honest about how each row got there. So the source column isn't metadata hidden in a database column nobody renders -- every snapshot card on /snapshots, every detail page, and every row returned by /api/cache-snapshots shows its source badge. A reader six months from now, looking at a mix of manually-pasted and API-sourced rows, should be able to tell at a glance which is which without reading this page.
The pattern this follows
This is the same discipline subagentcontracts.com's durability concept applies to its own contract_ledger.survives column, and the same one subagenttasks.com applies by seeding with this session's real 44 tasks instead of synthetic demo rows. Durable primitives in this ecosystem are grounded in something real and are explicit about exactly how real each piece of it is.