Editorial Policy

Every claim carries its source

A technical claim on this site is either something measured here, or something taken from a named source. There is no third category. Measured claims reference an experiment record by its identifier, and sourced claims link to vendor documentation, project documentation or an issue thread at the point where the claim is made. An automated check runs before publication and fails the build when a paragraph reports a number without either.

The five verification labels

Every article shows one of five labels at the top, in text rather than colour alone, so it survives a monochrome screen and a screen reader.

Directly tested

Run on the hardware listed in the test environment block on that page. An article cannot carry this label without an experiment record attached to it.

Official source

Taken from vendor or project documentation, linked where it is used.

Inferred

Derived from measurements taken on a different configuration. The article says which configuration, and what changing it would affect.

Not tested

Reported by other people and repeated here without reproduction. Used rarely, and never for a headline claim.

Logbook

The owner's own record of a run, written down while it happened and read back later. The run was not repeated, the seed and the versions were not captured at the time, and the numbers in it are records rather than measurements. Build log articles carry this label.

Measurements expire

Drivers, runtimes and model weights change often enough that a six month old measurement can be wrong in both directions. Any article or database record whose last verification date is more than 90 days old is marked stale on the page itself. Stale content is not deleted and not hidden. An old number with a visible date beats a missing answer, as long as the reader can see how old it is.

Re-verification means running the measurement again on the current versions and updating the verification date. It does not mean editing the date without rerunning anything.

Failed attempts belong in the article

Articles about errors list the configurations that did not fix the problem, not only the one that did. Readers arrive having already tried three things, and the list of dead ends is what lets them rule out their own case quickly.

What blocks publication

Seven automated checks run on every change, and any one of them stops it from going out:

1. Article frontmatter that does not match the required schema.
2. A technical claim with no evidence identifier and no source link.
3. An experiment record that fails the experiment JSON schema.
4. A broken internal link.
5. A draft article that would appear in the sitemap.
6. An article whose final human review flag is not set.
7. An article whose text changed after it was reviewed.

The last of those is why the review is worth anything. A flag on its own only records that a review happened and survives every later edit, so an article now carries a checksum of the text that was actually read. Every build recomputes it from the article as it stands: change a word and the checksum stops matching, and the article has to be read and approved again before it can go out. Articles published before this was introduced are being back-filled.

An eighth check compares paragraphs across articles and warns when they overlap, which catches the same experiment being spread thin across several posts.

Images

Screenshots, charts and video frames are produced here from runs done here. Frames captured from other people's videos, blog posts or broadcasts are not used, whatever their licence appears to be.

Independence

No vendor pays for coverage, previews articles, or approves conclusions. If that ever changes for a specific piece, the arrangement is stated in that piece before anything else. Affiliate links, once they exist, are covered separately in the affiliate disclosure.