Checklist
What a good RFC includes
01Motivation and problem statement
02Detailed design and invariants
03Alternatives considered
04Backwards compatibility and migration notes
05Security considerations
06Test plan / conformance impact
Community · RFCs
Request for
Comments
Every meaningful change to the Open Agent Specification should be discussed in public. RFCs are the mechanism: a written proposal, open review, a recorded decision, and implementation work that matches the contract.
Review
Public
Decisions
Recorded
Bias
Contract-first
§ 01Lifecycle
From idea to specification
The goal of the RFC process is predictable change: everyone can see what's proposed, what's accepted, and what a verifier is expected to enforce.
01
Draft
Write the proposal with motivation, design, and trade-offs.
02
Review
Discuss publicly; revise based on technical merit.
03
Accepted
Decision recorded in the open; the contract is updated.
04
Implemented
Reference implementations and conformance follow.
01
Draft
Write the proposal with motivation, design, and trade-offs.
02
Review
Discuss publicly; revise based on technical merit.
03
Accepted
Decision recorded in the open; the contract is updated.
04
Implemented
Reference implementations and conformance follow.
§ 02Canonical source
Where RFCs live
RFCs should be tracked in the open, alongside the specification source. The repository is the canonical index.
§ 03Quality bar
Write RFCs that hold up in production
A standard earns trust when it is explicit about authority, failure modes, and verifier behavior. Use this checklist to keep proposals concrete.
Checklist
How to review an RFC
01Check that the contract is precise (not prose-only).
02Look for implicit authority or ambiguous verifier rules.
03Ask for examples a verifier can test offline.
04Demand explicit failure modes and edge cases.
Next
Have a proposal?
Start by writing down the contract and the verifier rules. Then open a pull request against the specification repository so the discussion is public from day one.