Take the whole thing

Everything, as one file

• /dataset/addictedtoai.json

One table at a time (CSV)

• Entries — identity, lifecycle, indexability/dataset/entries.csv
• Facts — resolved values with their state and source/dataset/facts.csv
• Timelines — dated, sourced lifecycle events/dataset/timelines.csv
• Model catalog — raw per-token prices/dataset/catalog.csv
• Deprecations and retirements/dataset/deprecations.csv
• Impossible → Routine — dated pairs with both sources/dataset/deltas.csv

Live siblings

• The model catalog as JSON/catalog.json
• Deprecations and retirements as JSON/catalog/deprecations.json
• Changed in 30 days as JSON/catalog/changed.json
• The name index the search box uses/search-index.json
• This build’s stamp/status.json

Feeds

• What changed/feeds/changes.xml
• Blog/feeds/blog.xml
• Tutorials/feeds/tutorials.xml

The contract

These files are meant to be built on. Every JSON payload carries a schema_version and a contract field pointing back at this section, and every one of them is served with Access-Control-Allow-Origin: *, so a page in a browser can fetch them directly. The current versions are 1 for the standing tables and 1 for the dataset.

What is stable. The URLs. The licence, and its presence inside the payload. The top-level key names. Every existing field name on a row, and what it means. That row_count equals the length of rows. That rows is in the order sort_criterion names.

What is not, and is never claimed to be. Which rows are present, what their values are, and how many there are. Those move — that is what the files are for. generated_on changes whenever the site is rebuilt.

What a version change means. A new key on a payload or a row can appear without the version moving, so write a reader that ignores keys it does not recognise. The version increases only when an existing key is renamed or removed — that is the only thing it means, and the only thing worth acting on.