Editorial and AI policy
How Field Guide content is drafted, checked and reviewed, what AI assistance means on a site about AI, and the limits we know about.
This page says plainly how the words on this site are produced. Content on the AI/ML Field Guide is drafted with AI assistance. On a site about AI that deserves more than a footnote, so the sections below describe each step, in the order it happens, and end with the weaknesses we know about.
What AI assistance means here
A large language model writes first drafts from a brief. The brief names the topic, the audience, the house style and the sources. The model is instructed to explain from understanding and to write in its own words. It is not given competitor tutorials, courses or textbooks as text, and it is not permitted to quote more than one short passage per source.
For news briefs, the model is given the collected source articles for one story and must write a summary in which every number, date, model name and claim appears in at least one of those sources. For lessons and reference pages, the model works from papers, model cards and official documentation, and writes Python that is then executed.
The editor sets the topics, writes and maintains the briefs, reviews what comes back, and is responsible for everything that is published. AI assistance means the drafting is faster. It does not mean nobody read the page.
Sources and attribution
Every page lists its sources. News briefs link each source article. Reference pages and lessons end with a list of the primary documents they rely on: papers, model cards, framework documentation, textbooks. We prefer primary sources over secondary ones and say “according to” or “the vendor reports” when a claim is a maker’s rather than something we checked.
We do not use other tutorial sites as source text. We may look at them to see what topics people struggle with, but the words here are written from the primary documents and from experience.
Originality checks
Every draft is compared, by software, with every source it used.
| Check | Rule |
|---|---|
| Verbatim overlap | No run of 8 or more identical words shared with a source, with names, model identifiers and document titles excepted |
| Overall similarity | The share of 5-word phrases in common with any source must stay below a fixed threshold |
| Quotations | At most one quotation under 15 words per source, in quotation marks and attributed |
A draft that fails is regenerated with a stronger instruction to paraphrase. After two failures it goes to the editor rather than being published.
Fact grounding for news
A news brief may only state what its listed sources state. The pipeline extracts every number, date, model name and specification from the draft and looks for it in the source text. Anything not found holds the brief for review. This does not make the sources true, but it does mean we do not add claims of our own to a news story.
Code
Python in lessons, projects and reference pages must run. Every code block is checked for syntax and undefined names, then executed in the same environment the site is built in, on a CPU, with no network access and a time limit. A page whose code fails is held, not published. Code is also read by a person, because running is not the same as being correct or being good practice.
Blocks that call a hosted model API are marked as such, read their keys from environment variables, and are checked for syntax only. No key or token appears in any page.
House style
British English spelling, metric units, short sentences, no marketing language, no hype about the field itself. When a model is introduced we give its parameter count, context length, licence and release date, or say which the maker has not disclosed. We distinguish open weights from open source. In security content we write “security” and avoid the marketing prefix that usually replaces it. The style guide is applied automatically where it can be (banned words, spelling, hype terms) and by the editor where it cannot (tone, clarity).
Human review
Lessons, topic hubs, platform pages, projects and reference pages wait for the editor’s approval before they go live. News briefs that pass every automated check publish without a person reading them first, because they are short, sourced and time-sensitive. The editor reads them afterwards and corrects or withdraws any that are wrong. That split is deliberate and this page will be updated if it changes.
Freshness
Reference pages carry a “last verified” date in their header. A weekly job re-checks framework versions, model availability, prices and links, and marks a page stale when it cannot confirm them. A stale page stays online, because an old reference is usually better than none, but the date tells you how old.
What is never done
- Copying vendor figures, diagrams or screenshots. Our diagrams and charts are drawn here, as inline SVG.
- Reusing another tutorial’s text, structure or code.
- Publishing a news brief without sources.
- Publishing Python that has not been executed.
- Presenting a vendor’s benchmark claim as a measured fact, or a leaderboard number without its benchmark and date.
- Inventing a quotation, a person, a paper or a measurement.
- Promising that any model is free of confident wrong output.
Limits and known weaknesses
We would rather say these than have you discover them.
- A language model can produce fluent text that is wrong. The automated checks catch copied text and ungrounded numbers. They do not catch a confidently wrong explanation. The human review gate exists for this reason and it is only as good as the reviewer’s attention on the day.
- Fact grounding checks that a number appears in a source, not that the source is right or that the number means what the brief says it means. Launch posts are sources, and launch posts are marketing.
- Running code proves it executes on our machine with our versions. It does not prove the method is sound or that it scales beyond the toy dataset in the lesson.
- News briefs publish before a person reads them. A wrong brief can be live for several hours.
- Coverage follows the sources we collect. Labs with good blogs and open-source projects with release feeds get more coverage than quieter work, which is a bias.
- The site is drafted with models made by companies we write about. We have no commercial relationship with any of them, and the house style forbids repeating their claims without attribution, but you should know it.
- The site started in November 2026 and most pages are young. Expect gaps, and expect the corrections log to grow.
If you find a mistake, the corrections page says what to do. If you think this policy is missing something, the contact page says how to tell us.