About this glossary
A glossary is only worth reading if you know how it was made. This page says who writes it, what counts as a source, how often entries are re-checked, and what happens when something here turns out to be wrong.
- Primary sources only: vendor documentation, specifications and papers, never a listicle.
- Every page is dated, so you can see how old a claim is before you trust it.
- Both readings get named where the industry uses a word two different ways.
- One editor, Derek Wonk, is accountable for every entry on the site.
Who writes it
Derek Wonk edits this glossary. The subject is the vocabulary developers hit when they start building with language models, written from the position of someone who has to make the thing work rather than describe it at a conference.
The house rule is that an entry earns its place by being useful on the first read. That means naming what a term is not, saying where the industry disagrees with itself, and preferring one worked example to three paragraphs of definition.
What counts as a source
Primary material only: documentation published by the people who built the thing, specifications, and the original research papers. Vendor documentation is the source for how a vendor's API behaves. A paper is the source for a technique's actual claim, which is often narrower than the way the technique gets described later.
What is deliberately not used: roundup articles, listicles, and secondhand summaries of any of the above. They are how a wrong number propagates for years, and they are the reason so many definitions of the same term disagree. Every page lists its sources with a note on what each one supports, so you can check a claim without taking the page's word for it.
How entries are kept current
Each page carries the date it was last checked, and re-checks are scheduled rather than occasional. Entries whose facts move, such as published limits and API shapes, are re-read more often than entries describing a concept, which change only when the field's usage genuinely shifts.
New terms are added on a schedule too, drawn from a queue of candidates rather than written on impulse, which is how a glossary avoids becoming fifty entries about whatever was fashionable in one quarter.
If something here is wrong
Say so, and say which claim. The most useful report names the sentence, names the primary source that contradicts it, and gives the date you checked. That is enough to fix an entry the same day rather than after an argument about interpretation.
Corrections are made in place and the page's date is updated, because a glossary that quietly edits itself without moving its date is not much better than one that is out of date.
Common questions
Questions about this glossary
Is this glossary tied to one vendor's models?
No. Definitions are written to hold across providers, and where behaviour genuinely differs the entry says so and links the vendor's own documentation. That matters most for tool calling and context windows, where the API shape and the published limit are decided per model rather than per concept.
Why are there no listicles in the sources?
Because they are how errors survive. A number copied from a roundup that copied another roundup can be years stale while looking well cited, and the original page it came from has often changed. Reading the vendor's own documentation takes longer and is the only way to know what is currently true.
How often does a page change?
It depends on what the page claims. Concept definitions are stable and get re-read on a slow cycle. Anything quoting a published limit, an API shape or a price is checked far more often, because those move without announcement. The date on the page is always the date of the last check, not the date it was first written.
Sources
Where these facts come from
- Schema.org: DefinedTerm: the vocabulary each entry is marked up with, so definitions are machine readable
- Google Search Central: creating helpful, reliable content: the expectations on authorship and sourcing this glossary is written against