Problem
An RFC here is a living document: the status log at its end records what was built and when. Those lines are written by hand, after the fact, by whoever remembers. Some RFCs are current; others stopped being current the week a second repository started implementing them. A reader cannot tell whether "open" means nobody started, or that four pull requests merged and the feature has been live for a week.
The facts already exist elsewhere: the pull requests on GitHub, the rolls to production, the change verdicts the chaos bench will give (RFC 0040.14), and the monitors that keep checking what was built (RFC 0037, 0040.1). Nothing connects them to the document.
Proposal
Each RFC, on the site and in the console Lab, gains an Implementation panel built from events, not from prose. The status log stays for what a person has to say.
1. Implemented by: pull requests that say so
A pull request implements an RFC when its description carries a trailer line, one per RFC, in the form Git's trailers use:
Implements: RFC 0040.1
Implements: RFC 0041Only the trailer counts. Mentioning an RFC in a title or a paragraph does not: our pull requests mention RFCs all the time for context, and a link list built from mentions would be noise. One RFC can have many pull requests across repositories (core, the data plane, the SDKs); one pull request can implement several RFCs.
The source is the GitHub App of RFC 0036 and its pull_request events: opened, edited,
closed, merged. Each implementation records the repository, the number, the title, the
state, the merge commit and when each happened. A trailer added or removed by editing
the description updates the RFC. For a lab bound to repositories (RFC 0036), the
trailer's number is resolved in that lab.
2. Live since: rolls are events
A merged change is not a shipped one. Every way the platform is rolled out records a
roll: which components it rebuilt, the commit they were built from, when, and by what
(the deploy workflow, or a named task such as the site's). Today two paths roll the
platform (the deploy workflow on the production machine, and tasks run by hand for one
host) and neither records anything an RFC could read; both start writing a roll, as an
event (platform.roll.finished) and a row.
A pull request is live once every component its changed files belong to has been rolled from a commit that contains its merge commit. Which component a file belongs to is the same map CI already uses to decide what a change can affect, so there is one answer to "what does this change touch". An RFC is live since the day its last implementing pull request went live; the panel shows each date.
3. Verdict: what the bench said
Once the change verdicts of RFC 0040.14 exist, each implementing pull request shows its verdict (pass, fail, regressed, incomplete) with a link to the evidence the bench kept.
4. Proved since: what keeps checking it
A monitor (RFC 0037) or an agent-declared check (RFC 0040.1) can name the RFC it proves. The panel then shows "proved since" (the start of the current unbroken run of passes) and the uptime over 30 days. A failing proof is shown as failing, with when it started; it never disappears.
A diagram is drawn here in the RFCs product; this page does not show diagrams yet.
5. Progress for a family
A parent RFC (RFC 0035's sub-RFCs) shows one row per child, each in one of four states: written (the document exists), built (an implementing pull request merged), live (rolled), proved (a monitor or check passes). A child moves forward only on the evidence for that state.
A diagram is drawn here in the RFCs product; this page does not show diagrams yet.
6. Open questions and decisions, dated
Two sections the build reads, like the status log: ## Open questions, a list of
- [ ] YYYY-MM-DD: question that becomes - [x] YYYY-MM-DD: question; answer when
answered, and dated bullets under ## Decision. Both appear in the lab's timeline, so an
open question older than a month is visible.
7. People: who owns it, who wrote it, who builds it
An RFC is rarely one person's. Each document names its people, in four roles:
| Role | How many | Means |
|---|---|---|
| Owner | one | accountable for driving it to a decision; whoever created it until they hand it over |
| Authors | any | who wrote it, co-authors included |
| Implementers | any | who builds it |
| Reviewers | any | the review requests and approvals the Lab already records |
People are chosen from the members of the lab's account, from the same list a review request uses; in a personal account the owner is the only member. The owner, the authors and the account's owners and admins may change them, and every change is in the document's history. The reading view shows them at the top; the lab's table filters by person ("mine"); the Lab's home lists what each person owns, writes, builds and is asked to review. The Implementation panel puts the implementers next to the authors of the pull requests that landed, so assigned and actual are side by side.
Someone outside the account (a contractor, a customer's architect, a reviewer from a partner) can be named by e-mail address, never silently. Naming them sends a request to that address; they appear as invited, not as an author, until they open it, sign in with that same verified address and accept. Accepting gives them that role on that one document and nothing else in the account: they read the document and its discussion, and write only what their role allows. A request expires after 14 days, can be withdrawn, and a declined or expired one names no one. Anyone added this way is removed from the document the day they leave it, and their acceptance is in the document's history.
People are kept by the platform, never in the document's file: a repository bound by RFC 0036 holds the text, and names in a public file would publish people who did not choose to be published. The public site shows people only for someone who chose to appear there.
What the public site shows
Core is private: its pull request links do not open for a visitor, and a title can name internals. So the two places show different amounts:
| Console Lab (the team) | Public site | |
|---|---|---|
| Pull requests | every one: repository, number, title, state, link | counts by state; title and link only for public repositories (the data plane, the SDKs) |
| Live | each date, per pull request | the RFC's date |
| Verdict | each, with its evidence | the latest per RFC |
| Proof | monitor names, uptime, failures | "proved for N days", uptime |
Everything the public site shows from these events passes the redaction check first, like the documents themselves.
Admin-only first
Like every new Lab feature, the panel is built and shown to admins first; the public site gets its part after the console has run it for a while.
Alternatives considered
Keep writing status lines by hand, with a reminder. What we do, and why the logs go stale: the person who merges is rarely the person who wrote the RFC.
Link from mentions in titles and descriptions. Easier to adopt and wrong: every pull request that discusses an RFC would claim to implement it.
Read the repository's history instead of events. Possible for core, slow for several repositories, and blind to pull requests that are open or were closed unmerged.
"Merged" as "shipped". Simpler, and false on a platform that rolls by hand and in parts: a merged change can wait days for its roll.
Decision
Open. Proposed: the Implements: RFC NNNN[.N] trailer as the only link; GitHub App
events (RFC 0036) as the source; a roll event from every deploy path and live computed
from the components a change touched; verdicts and proofs linked when RFC 0040.14 and
monitors exist; a per-child progress row for families; dated open questions; a team view
with everything and a public view with counts, dates and public links only.
Publication
The console Lab and the site's lab gain the Implementation panel on every RFC and the progress rows on parents. The contribution guide gains the trailer. The deploy workflow and the hand-run roll tasks gain the roll record.
Status log
- 2026-10-03: opened, at the owner's request, after status logs that were written by hand went stale across repositories.
- 2026-10-03: people added at the owner's request: an owner, authors, implementers and reviewers per RFC, chosen from the account's members, several per role but one owner; someone outside the account only after they accept a request sent to their address.
- 2026-10-03: people are built in the Lab, admin-only like the rest of it. A document has one owner (whoever made it, until they hand it over), authors and implementers chosen from the account's members, and its reviewers; every change is in the document's history, and people never go into the file. Someone outside the account is asked by e-mail, shown as invited, and after accepting with that verified address reaches that one document and nothing else of the account. A request expires after 14 days and can be withdrawn. The console shows people at the top of a document, a "Mine" filter and what each person owns, writes, builds and reviews on the Lab's home.
- 2026-10-07: Checked: people on a document (#256) run in labs and console-ui. Not
built: the implementations list fed by the GitHub App and the
Implements:lines (on the board for the RFCs product). Open.