Data

Every timeline as JSON and Markdown

The same entries, sources and quotes that the pages show, in a shape a program or an AI agent can read. Data version 1.

Where the files are

/index.json: every timeline with its URLs, size and last update, plus topics, parties and feeds. Start here.
/events/<slug>.json: one timeline in full, for example /events/iphone-generations.json.
/events/<slug>.md: the same timeline as plain-text Markdown, and /llms-full.txt for all of them in one file.
/who/<id>.json: one company, person or regulator across every timeline, for example /who/nvidia.json. The parties that have one are listed under parties in /index.json.
/search.json: every entry on every timeline in one flat list (timeline, id, date, title, summary, parties, url), for searching without fetching the timeline files. /upcoming.json: the scheduled dates as JSON.
/feed.xml for new entries, /events/<slug>/feed.xml per timeline, /upcoming.ics for scheduled dates.

Questions answered as chains

A chain answers one why or how question with an ordered set of dated entries that already exist on the timelines, each with one line on why it led to the next. It is written by the editor, not generated when asked; it changes when the entries it points at change. Every chain is a page at /why/<slug>, JSON at the same URL plus .json (question, aliases, answer, and steps, each with label, why, kind of cause or counter, group (the strand of the argument; strands run in argument order, steps inside a strand forward in time, and a step dated before the one above it inside its strand is marked out_of_order), and the full entry with its URL, date, summary and sources), and Markdown at .md. The list is at /why/index.json and under questions in /index.json.

MCP server

The same data as tools for an AI agent: https://whatledto.com/mcp is a remote Model Context Protocol server over Streamable HTTP, no login, no session. Add it to Claude, ChatGPT, Cursor or any MCP client as a custom connector with that URL. Seven tools: ask (a why/how question answered as a chain of entries, or the questions that exist), list_timelines, get_timeline (with since for what changed after a date), get_entry (the quotes and sources to cite), get_party (one company, person or regulator across every timeline), search_entries (keywords, party, timeline, date range) and upcoming. Every result carries entry URLs; the server's instructions ask agents to cite entries by URL and name the outlet the quote came from. The endpoint reads the files above, so it is exactly as current as they are.

A timeline page also answers content negotiation: request /events/<slug> with Accept: application/json or Accept: text/markdown and you get the JSON or Markdown file, with Content-Location naming it. Every page links its alternates from its <head>. The JSON files allow cross-origin requests from any page, and, unlike the HTML pages, they are not rate limited.

What a timeline file contains

Top level: slug, title, url, vertical and topic, tags, tldr, created_at and updated_at, then the sections below. Timestamps are ISO 8601 in UTC; event dates are YYYY-MM-DD, or YYYY-MM / YYYY when date_precision says the day or month is not known.

nodes: The entries, oldest first. Each has an id that is stable for the life of the entry, a url that addresses it on the page, the date the thing happened, a title, a two-to-three sentence summary, a type (announcement, launch, regulatory, legal, financial, report, response, delay, shipment or other), the entities it is about, published_at, and an editor's note when a date was corrected or a source disagreed. sources lists every page the entry was taken from with its url, outlet, publication date and the verbatim quote that supports the summary.
entities: The parties on this timeline: id, name, kind (company, person, regulator, product, other) and a one-line role. Names match the strings used in each entry's entities; the id is the same for one party in every file, whatever spelling a timeline used (Amazon Web Services and AWS are both amazon-web-services), and each entry lists its parties' ids as parties. A party with a page carries its url and the json of its party file.
relations: Links between two entries, from the earlier to the later, that the dates alone do not show: causes (a source says the earlier brought the later about), responds_to, contradicts (with the disagreement spelled out in note) and follows (the later completes what the earlier began). Every relation carries a note saying what the link is. Treat causes as the editors' reading of the sources, not as a fact of the same standing as an entry.
links: The same three explanatory kinds, but with one end on another timeline. Each end gives its event slug, entry id, date, title and url, so a link can be followed from either file. A link is written once and appears in both timelines' files. The same rule of evidence applies: it exists only where one entry's own text names the other's fact.
key_node_ids: The entries that carry the story, chosen when the summary is refreshed.
catalysts: Dated things to watch next, each with a why and, where one exists, a source_url.
open_questions: What the sources have not settled yet.
metrics: Series charted on the page, such as a price or a rate: key, name, unit, kind (step, line or bar) and points. A point exists only where a published entry states the value verbatim; each carries the node_id and the quote it was read from.
related: Timelines the editor has linked to this one.
changelog: Every change to the timeline, newest first: research passes, published entries (with their node_ids), summary refreshes and corrections. Entries are never silently edited, so a diff of this list is a diff of what the site knew.
hero_image, hero_credit, image, image_credit: Photographs and the attribution they are shown with. They are licensed to this site as described under Images; the credit travels with the file, the licence does not.

Not included, on purpose: unpublished candidate entries, the research brief and search queries each timeline runs on, and the instructions the pipeline uses to read chart values. Those are how the site is made, not what it says.

What a party file contains

/who/<id>.json is the graph seen from one node: id, name, kind, description and same_as (Wikipedia or official pages), then timelines, one per timeline the party is on with its role there and the number of entries that name it, and entries, every dated entry from every timeline that names the party, newest first, each with the timeline it sits on, its id, url, date, title, summary, type, the other parties it names and its sources with quotes. often_with lists the parties that share the most timelines with it. "Names it" means the entry's editors listed the party among the entities the entry is about, not that the name appears in the text.

Stability

Fields are added, never renamed or removed, within a data version; data_version in every file changes only when a field changes meaning. Entry ids do not change. A timeline that is retired keeps its files with status set to archived. Fetch /index.json and compare updated_at to know which timelines to re-read; the RSS feed and each file's changelog say what changed.

Terms

The reuse terms apply to the files exactly as they apply to the pages: quote and cite entries with a link to the entry's url, use the data in research, articles and AI answers with attribution, and do not republish whole timelines or train models on the text. Every response says so with a Content-Signal header. Bulk use of the files, use of the text to train or fine-tune models, and commercial redistribution of the data are not covered by these terms and are licensed separately. For such a licence, or to ask for a field or a format, write to editor@whatledto.com.