1. Introduction
Most technical writing arrives with the wrong posture. A blog post is published the way a verdict is handed down: finished, confident, and structurally hostile to the possibility that it is wrong. The comments, if they exist at all, sit below the fold in a different typeface, clearly an afterthought to the main event.
This series inverts that. Every document here is a proposal. It takes a position clearly enough that you can tell exactly where you disagree, and it treats your disagreement as the mechanism by which it improves rather than as noise arriving after the fact. That is what the format is for, and it is why the site is named after an instruction instead of a subject.
2. Why this form
In April 1969, Steve Crocker needed to circulate notes among the handful of people building the ARPANET, and worried that anything resembling a specification would seem presumptuous coming from a graduate student. He called the notes Requests for Comments. The name was an act of hedging, and it turned out to be the most durable design decision in the series: a document that asks for objections gets them, and a document that gets objections gets better. The form has carried working ideas for over fifty years, largely because it never pretended to be finished.
The borrowed conventions here are not costume. Numbering documents means I cannot quietly revise a bad argument out of existence: the number stays, the status changes, and the correction is legible. Dating them means an argument about tooling from two years ago is visibly an argument from two years ago. Publishing a status field means the difference between “I believe this” and “I am thinking out loud” is stated rather than inferred from tone.
3. Scope
The subject is building software in the age of models: the part where a capability becomes a product and the interesting problems stop being about the model at all.
In practice that means interaction design for systems that are probabilistic: what a streaming response should feel like, what a prompt surface teaches someone in the first ten seconds, how an interface should behave when it is confident and how it should behave when it is guessing. It means product judgment: which capabilities are worth shipping, which demos are load-bearing and which are theater, and how to tell the difference before you have built the thing. And it means the occasional working demo, embedded in the document, because some arguments about interaction can only be settled by moving a slider.
What is out of scope: model benchmarks, release commentary, and predictions about the next eighteen months. Those are well covered elsewhere, and they age badly in a series that keeps its old documents around on purpose.
4. How to read a document here
Every document opens with a four-line header. It is dense on purpose, and once you can read it you can skip the rest of this section forever.
The first line names the author. The second gives the document number, which is permanent. RFC-0009 will always be RFC-0009, whatever happens to its contents. The third gives the category and the date of publication. The fourth gives status and, where useful, an estimated reading time.
The category says what kind of claim the document is making:
INFO is informational: an explanation, an observation, or a position. Most documents are this.
EXP is experimental. The document includes something running: a demo, a prototype, a thing you can operate in the browser while reading. The argument is partly in the artifact.
BCP is best current practice, a recommendation I would actually defend in a design review, with the emphasis on current.
The status says how settled it is. Draft means comments are requested and the document may still move. This is the default, and the honest state of most writing. Final means I have stopped revising it, not that it became true. Obsoleted means a later document supersedes it; the original stays published, because deleting a wrong argument also deletes the evidence that it was wrong.
Figures are numbered and captioned. An Interactive Figure carries a green dot indicating that it runs in your browser. Nothing on this site sends your input anywhere.
5. How to comment
The name is an instruction, so here is the mechanism.
Comments belong on the document itself, threaded under the Request for Comments heading at the foot of each post. There is no private channel, and that is deliberate: an objection worth making is usually worth other readers seeing, and a correction is more useful attached to the thing it corrects than sitting in an inbox.
Useful objections get folded into the document, with the revision noted, or answered in a follow-up that the original then references. A comment that changes my mind is the best outcome available to anything published here. It is cheaper to be corrected in a thread than in production.
6. Status of this memo
This document is itself a draft, and it is the one most likely to be revised: it describes conventions that a series of one document has not yet had the chance to violate. When the conventions change, this is where the change gets recorded.
Comments are requested on all documents, including this one.