How an explainer is made
intuitivepapers.ai explains one AI research paper per page: the intuition first, then the math, with figures you can change. This page says who writes the explainers, what is checked before a page ships, and how to report a mistake.
What the site is
A library of long-form explainers for machine learning papers, from foundational work such as ResNet and the Transformer to papers published this year. Each explainer builds the background a reader needs, states the paper’s idea in plain words, works through its equations, and reports its results with the paper’s own numbers. It is written to be read next to the paper, and each page names the paper’s arXiv id at the top.
Who writes them
The prose is drafted by an AI model, Anthropic’s Claude, run by a pipeline built for this site. The pages are not written by hand. The pipeline builds each page from the paper and its code, then checks the draft against both before it publishes; the steps are below. The site is an independent project run by one engineer, who maintains the pipeline and reads every report that comes in.
How a page is checked
The paper and its code are the sources
The pipeline reads the paper from its arXiv HTML version and copies out the equations, the method and the results verbatim. The concepts the paper builds on are checked against the primary literature, one at a time. Where the paper leaves a mechanism unclear, such as which tensor feeds which layer or the value of a default constant, the authors’ official code decides, and the page’s Provenance panel cites the file and line.
A reference card and a fact ledger
The math on the page is drafted from a checked reference card of every key equation, never straight from the paper, so a typo in the paper does not carry over. The page’s load-bearing facts (results, settings, equations, sign conventions, corrections) go into a fact ledger, each entry checked against the paper and cited. Every later edit to the page is held to its ledger. Ledgers exist for the pages rewritten under the current process, and the rest of the library is being rewritten onto it one page at a time.
Corrections are flagged in the Provenance panel
When the paper, or the usual account of it, is wrong on a point that can be checked (a sign, a constant, a claim its own code contradicts), the page teaches the correct version and marks it as a correction in the Provenance panel at the end of the article. Notes about scope or interpretation are marked as caveats.
Adversarial review before anything ships
Separate reviewers read every draft, each a fresh model run with one job: correctness against the paper, clarity, voice, or the figures. A finding counts only after a second pass confirms it. Confirmed findings go back for fixes, and the page is rebuilt and reviewed again. A page that is still not clean after five rounds does not publish on its own. It waits for a person.
Figures are tested at desktop and phone widths
Every figure is interactive: its sliders, toggles and play buttons change the quantity the text is discussing. Each one is rendered in a real browser at desktop and phone widths and checked for clipped or overlapping labels and for text too small to read.
A rewrite has to beat the page it replaces
When an older page is rewritten, the new version ships only if it keeps every verified fact and every figure concept of the old one, and a blind comparison, run twice with the order swapped, prefers it both times.
What the checks do not promise
The checks catch many errors, and they do not catch all of them. A page can still simplify too far, or get wrong a detail that no reviewer looked at. Read an explainer as a guide to the paper, and go to the paper itself for anything you plan to rely on.
Report an error
Every explainer ends with a feedback form headed “Got feedback?”. Say what is wrong and where it is on the page. An email address is optional and is used only to reply. A report is checked against the paper before a fix goes in, and a page that changes materially gets a new modification date. You can also write to me@skz.dev.
How papers are chosen
Some papers are picked by hand because later work builds on them. Some come from the queue, where readers submit arXiv links and vote on what comes next. Others are recent papers the field is discussing. The library lists every explainer published so far.
