The RFC Process

How the language changes

Osmol changes in public, on the record, or not at all. Anyone may propose a change by opening an RFC: a pull request to the osmol-lang/rfcs repository describing the change, its motivation, and its effect on the spec and conformance suite. Maintainers accept or decline with written reasons, so a declined RFC leaves behind an argument, not a silence. Also, grammar or semantics changes ship only in editions: accepted language changes wait for the next coherent snapshot rather than trickling into a moving target, so a deployed mesh never breaks under anyone's good idea.

The process is deliberately lightweight. In the engineering dissertation's words, it is "lightweight at population two, but installed now, because governance retrofitted after adoption is how open protocols quietly become products." The full constitution, including the two clauses no RFC can amend (irrevocable open licenses; lossless portability of membranes, models, and logs), lives in Governance and Licensing.

The template, walked

Every RFC starts from 0000-template.md, five sections long:

  • Summary: one paragraph on what changes. If you cannot say it in a paragraph, the RFC is not ready.
  • Motivation: why the language needs this, and (the template's own requirement) "Which of the five axioms it serves." An RFC that serves no axiom is probably a feature for a different language.
  • Design: the change stated precisely, with grammar diffs against the EBNF, semantics, and diagnostics. If your change deserves a new error, name its O-code and write its message; in this language the errors are the ethics.
  • Effect on spec and conformance suite: which spec sections change, and which new test programs must exist. This section has teeth: the conformance suite defines the language, so a change that adds no golden program has not really been specified.
  • Drawbacks and alternatives: what this costs, and what else was considered. An RFC that cannot argue against itself is a brochure.

What makes a good RFC

Practical guidance, all of it derived from canon:

  • Cite the axiom. Not as decoration: show which of the five axioms your change strengthens, and check that it weakens none.
  • Bring the golden test case. Arrive with the .osmol program and its expected trace or diagnostic. A change you can express as a golden file is a change two implementations can agree about.
  • Respect the constitutional clauses. Nothing that closes a license; nothing that traps a membrane, model, or log.
  • Supersede pragmas explicitly. The v0.1 interpreter's documented simplifications are normative until replaced. An RFC that says "the circles pragma is retired; audience classes now resolve like this" is a gift; an implementation that silently diverges is a bug with a personality.

RFC-shaped work already waiting

This book has been quietly leaving invitations in its margins. Collected:

  • Theorems 2-5 formalizations: enrich the Theorem 1 oracle back into structure; see the open theorems.
  • Retraction semantics: un-asserting a hold that has already equalized needs revocation-deltas; spec ยง10 defers it to you.
  • Gap privacy: seeking is itself revealing; membranes should govern the visibility of gaps, not only holdings.
  • Lattice registry entries: standard grains per domain; see the granularity lattice.
  • The lexicographic tie-break: mandated by the determinism rule, unimplemented in the reference; see the interpreter walkthrough.
  • role and stake implementation: two constructs the grammar promises and v0.1 does not yet parse; see roles and stake.

Pick one, open the pull request, and argue it well. The stone belongs to whoever keeps carving it faithfully.