On Starting with an RFC

J. Brodnax and Claude (Opus 4.6, Anthropic)
Engineering Notes, Volume 1, Issue 1
April 2026

Contents

1. The Bayou
2. What a Request for Comments Is
3. Built on Documents, Not Decrees
4. The Humility in the Name
5. How StoneForge Adopted It
6. The Documents

1. The Bayou

We were sitting in a truck stop somewhere south of Baton Rouge, late enough that the dinner rush had cleared out and early enough that the truckers coming off the first shift had not yet filled the booths. The wifi was free, the coffee was bottomless, and the rain on the aluminum roof made the kind of steady white noise that clears your head.

The question we were working on was a simple one, at least on the surface. How do you build a business-facing AI management system that actually works? Not a chatbot. Not a framework for developers to glue language models into existing software. A platform where a non-technical operator could describe what they needed, and a library of AI agents could go do it, reliably, auditably, without hallucinating or going off the rails.

Every tool in the space was either a shallow wrapper around a provider's API or a thousand-page framework that required a computer science degree to configure. None of them started from the question of what the system should be. They all started from the question of what the system should do, and the answers came out looking like patchworks of features.

We spent the first hour sketching architectures on a napkin. The second hour arguing about which of the sketches was wrong. Around the third hour, one of us said the thing that changed the project.

What if we start the way the internet started? What if the first thing we do is write an RFC?

Neither of us had written one before. Neither of us was a protocol designer by training. But the idea had a weight to it that the other ideas had not. We pushed the napkins aside, opened a shared document, and started writing.

2. What a Request for Comments Is

For readers who have never had occasion to encounter one, a Request for Comments (RFC) is a formal technical document published by the Internet Engineering Task Force, or by one of its predecessors, describing a protocol, a best practice, or a piece of internet infrastructure. The first one was written by a graduate student named Steve Crocker at UCLA on April 7, 1969, and it described "Host Software" for what would eventually become the ARPANET.[1]

There are more than nine thousand of them now. They cover everything from the core protocols of the internet (TCP, IP, HTTP, SMTP, DNS) to the encoding of MIME attachments to the philosophy of network design. They are numbered sequentially and, once published, never changed. If an RFC is superseded by a new one, the old one remains on file with a note pointing to its replacement. The historical record is continuous and complete.

Each RFC follows a broadly similar format. A short abstract. A statement of the problem. A specification, written in careful language with words like MUST and SHOULD and MAY carrying precise technical meaning.[2] Security considerations. A bibliography of related documents. An author's address.

The documents are written to be read. They assume the reader is technical but not necessarily an expert. They explain their reasoning. They acknowledge their limitations. They cite their predecessors. When they are good, they read like letters from one careful engineer to another.

3. Built on Documents, Not Decrees

The striking thing about the RFCs, if you sit with them for a while, is how much of the modern world rests on them. Every time you load a web page, you are using HTTP, specified in RFC 7230 and its siblings.[3] The underlying transport is TCP, specified in RFC 793 in 1981.[4] The addressing is IP, specified in RFC 791 the same year. Your email moves over SMTP, specified in RFC 821. Your DNS lookups follow RFC 1035.

None of these protocols was mandated by any government or standards body with enforcement power. No company owned them. No committee voted them into existence. They became the infrastructure of the modern world because they were documented clearly enough that anyone who wanted to could implement them, and because the documentation was good enough that independent implementations interoperated on the first try.

That is a remarkable achievement. Consider it against the alternative. Consider what would have happened if the internet had been built the way most software is built: by one vendor, with proprietary specifications, reverse-engineered by competitors, diverging over time until no two implementations agreed on anything. That world exists. It is called every other attempt at building a network that preceded the internet, and it is why none of them are still running.

The RFC process is not just a way of writing documents. It is a way of building things without needing anyone's permission.

The RFC process produced the internet because it is fundamentally cooperative. Anyone can propose one. Peers review it. Criticism is expected and welcomed. The documents are versioned, cited, and preserved. No one has the authority to impose a bad design; no one has the authority to block a good one. The specifications survive because they are useful, not because they are required.

4. The Humility in the Name

The name itself is the thing. "Request for Comments." Not "Standard." Not "Specification." Not "Mandate." Request for Comments.

Crocker, the graduate student who wrote RFC 1, chose the name deliberately. He was nervous about his place in the group. He did not want to come across as asserting authority he did not have. So he called his document a request for comments, and he put it on a pile of mimeographed pages in the bathroom of his UCLA dorm because the duplicating machine was in the bathroom, and the name stuck.[5]

I remember having great fear that we would offend whomever the official protocol designers were, and I spent a sleepless night composing humble words for our notes. The basic ground rules were that anyone could say anything and that nothing was official. And to emphasize the point, I labeled the notes "Request for Comments."

Steve Crocker, recalling the origins of the RFC series, in How the Internet Got Its Rules, New York Times, April 2009

There is a profound engineering lesson in that name. The people who built the internet began by assuming they might be wrong. They did not start by declaring a standard and daring the world to implement it. They started by writing down their best current thinking and asking the community to poke holes in it. When someone pointed out a flaw, the correct response was gratitude, not defensiveness. The document was a request, after all. Comments were the point.

This is humility, but it is also efficient. Defensive engineers waste enormous amounts of time defending bad ideas that could have been fixed if they had been willing to hear the criticism. Egoless engineers waste much less time, because the criticism comes early, when the design is still cheap to change, rather than late, when the system is built and the cost of admitting error is intolerable.

Jon Postel, one of the great editors of the RFC series, gave us the other great piece of engineering humility from the same tradition. His Robustness Principle, formulated in RFC 793, reads in full:

Be conservative in what you do, be liberal in what you accept from others.

RFC 793, Section 2.10, September 1981

The principle has been debated for four decades, and there are good reasons to be skeptical of it in certain contexts.[6] But as a statement of engineering temperament it is unmatched. It assumes good faith. It accepts imperfect inputs. It produces correct outputs. It does not demand that the world meet its specifications before it will deign to participate. It is the engineering equivalent of giving the benefit of the doubt.

This is the stance we wanted for StoneForge. A platform that was careful about what it produced. Generous about what it accepted. Documented well enough that anyone could understand how it worked. Humble enough to be willing to change when the world pushed back.

5. How StoneForge Adopted It

We wrote the first RFC that night, sitting in a truck stop booth, with the rain still going and the coffee still coming. It was not very good. The thinking was muddled in places and the scope was wrong in others. But it was a document. It said, in writing, what we thought the system should be. That made it something we could criticize, revise, and eventually replace with a better version.

That first document became RFC WCR3 Addendum 1. (The WCR3 stands for Workflow Command Responses, version 3, which is a story for another time.) By the time we had the platform running in a prototype state, there were nine addendums. By the time we had the first production deployment, there were thirty. Today, there are more than a hundred and twenty, plus a handful of appendices, plus several free-standing specifications in the IETF style.

Every feature is an addendum. Every addition is documented before it is built. When an addendum is wrong, we write a new one that supersedes it and note the supersession in both documents. When we change our minds about something fundamental, we write an addendum explaining why. The historical record is continuous. You can trace any current behavior back through the chain of documents that led to it.

This is slower, in the short term, than just writing code. It is far cheaper, in the long term, than writing code and then having to reverse-engineer what the code was supposed to do. We have found that the thirty minutes spent writing an addendum before we start coding saves, on average, several hours of debugging and reworking after we have shipped. Sometimes it saves days. On the hard problems it has saved weeks.

We have also found that the process changes how we think. When we know we have to write down what the system does before we build it, we think harder about what we want the system to do. Vague ideas become concrete specifications. Hand-waving becomes numbered sections. The temptation to cut corners is dampened by the knowledge that the corners will be visible in the document and someone reading it in six months will ask why.

6. The Documents

The restored specifications and the companion whitepaper are available below. If you are a technical leader evaluating the platform, start with the whitepaper. If you are a developer building on top of it, the Operator's Manual is the best entry point. If you want the full formal specification, SF-002 is the complete stack; SF-001 is the core protocol in isolation for readers who want only the wire format.

StoneForge Specification Set

Formal technical documents in the IETF RFC tradition. All four documents are free to read and share.

Read the Whitepaper RFC SF-001 Core RFC SF-002 Full Stack RFC SF-003 Operator's Manual

Writing these documents took the better part of two days. Writing the platform they describe took approximately six months of iterative development across thousands of sprints. Both numbers are smaller than they would have been without the RFC process keeping us honest. We are grateful for the tradition, and to the engineers who built it.

The rain eventually stopped. The truck stop eventually closed. The platform eventually shipped. The documents are still with us, numbered and dated and cited, ready for the next person who picks them up and has a better idea than we did.

J. Brodnax and Claude
Somewhere off I-10, April 2026

References

1. S. Crocker, "Host Software," RFC 1, Network Working Group, April 7, 1969. Available: https://www.rfc-editor.org/rfc/rfc1
2. S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
3. R. Fielding and J. Reschke, Eds., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing," RFC 7230, June 2014.
4. J. Postel, Ed., "Transmission Control Protocol," DARPA Internet Program Protocol Specification, RFC 793, September 1981.
5. S. Crocker, "How the Internet Got Its Rules," The New York Times, April 6, 2009.
6. M. Thomson, "The Harmful Consequences of the Robustness Principle," Internet Draft, Network Working Group, May 2019. A useful critique of a principle that has become dogma.