Get in touch

Corrections

This is the category we care about most and the one that moves fastest.

A useful correction identifies the article, quotes the specific sentence, states what is wrong with it, and where possible points at a source. That last part is not a requirement. If you know something is wrong and cannot immediately produce the citation, send it anyway and we will do the looking.

What happens next: the claim gets checked against primary sources. If it was wrong, the article is edited and a note goes at the foot recording what it said before, what it says now, and the date. If the error changed the conclusion of the piece rather than a detail within it, the note goes at the top instead. If we cannot determine who is right, the article gets a note saying the point is disputed, with your objection summarised.

If you turn out to have been wrong, you get an email explaining why, with the source. Nobody is embarrassed by this. Several of the more useful exchanges this site has had started with a correction that turned out not to be one and ended with a paragraph being rewritten anyway, because the fact that a careful reader misread it meant it was badly written.

You will be credited by name unless you ask not to be.

If you work on a system we described

Please write. Descriptions of how a system works are assembled from papers, documentation and observed behaviour, and the people who built the thing know where those diverge.

We will correct factual errors regardless of who reports them. We will not remove a critical characterisation because the subject disagrees with it, though we will publish the disagreement alongside it, at whatever length is proportionate.

Two things are always worth telling us. First, if an article describes a behaviour that has since been fixed, because articles about model capability age fast and we would rather date-stamp than mislead. Second, if a benchmark number we quoted was run under conditions different from what we stated, since evaluation conditions move results by more than most reported differences.

Pitches

Open to outside contributions, with a strong preference for pieces that go deeper on a single specific thing over broad surveys.

What works here: a detailed account of a formalisation project and what it cost, a careful look at a benchmark's construction and what it actually measures, a piece of history involving a specific system and a specific result, a mechanism explanation aimed at someone with secondary-school mathematics and no machine learning background.

What does not: predictions about what will happen in five years, general commentary on whether AI is good or bad, anything whose argument would survive unchanged if the specific technical details were swapped for different ones.

Send a paragraph on the idea and a link to something you have written. Not a full draft. If it fits, we will talk about length and approach before you write it, which saves everyone the awkward conversation later. Pieces here run between 1,200 and 2,500 words and there is no payment, which we mention up front rather than at the end of a negotiation.

Technical disagreements

Distinct from corrections. A correction says a fact is wrong. A technical disagreement says the reasoning is wrong, or that a conclusion does not follow from the evidence given.

These are welcome and they get read carefully, but they are slower, because settling one usually means going back to sources rather than checking a number. Expect a couple of weeks.

If a disagreement produces something worth publishing, it gets published as a response piece under your name, not folded anonymously into the original article. Several of the framings this site relies on arrived that way.

Permissions and reuse

Quote freely with attribution and a link. No permission needed for excerpts, in any context including commercial, academic and educational.

For republishing a full article, ask first. The answer is usually yes for non-commercial use, and usually a conversation for commercial use, mostly about whether the piece would be presented in a way that keeps its caveats attached. Articles here frequently contain a paragraph that undercuts the headline claim, and that paragraph is not optional.

The code for the step solver is available and reusable. If you want to build on it, take it.

For translation: yes, please, and tell us where it goes. If you translate a piece we will link the translation from the original.

What happens to what you send

The form hands your message to FormSubmit, a third-party relay that forwards it to the inbox above. It exists because this site is static files with no server of its own, and a form has to post somewhere.

That is the one place on this site where something you type leaves your browser, and it happens only when you press send. There is no script from that service loaded on the page, no cookie set, and nothing recorded while you type. Nothing at all is transmitted until you press send, and if you close the page before then, nothing was.

Messages are read by the editors and kept while the matter is open. Correspondence about a correction is retained alongside the article's revision history, because a correction note needs to be traceable to what prompted it. Everything else is deleted when it is no longer needed. The privacy page sets this out in full.

What we do not respond to

Requests to review a product. Link exchange proposals. Requests to add a link to an existing article in return for anything. Content marketing pitches of any kind, including ones dressed as corrections. Claimed proofs of Millennium Prize problems, which arrive more often than you would think and which we are not equipped to evaluate.

Nothing here is a support channel for any AI product. If a system is giving you wrong answers, the company that built it has a support process and we have no ability to affect it.

If a message matters and has gone unanswered, send it again. This is a small operation run alongside other work, and the failure mode is silence rather than a decline.