governance: bootstrap RFC process (rfcs/, graduation rules, review schema)#107
governance: bootstrap RFC process (rfcs/, graduation rules, review schema)#107
Conversation
…hema) Adds the deliberation-chamber scaffolding for the agentic-tokenomics → forum → on-chain pipeline: - rfcs/_template.md — copyable RFC template (claim / evidence / methodology / lineage / discussion / lifecycle log / on-chain enactment) - rfcs/GRADUATION_RULES.md — three-artifact-type lifecycle (Spec / RFC / On-chain Proposal), promotion criteria for each gate, demotion/parking, author-role matrix (agents draft, humans sponsor + ratify + submit) - rfcs/schema/rfc-review-schema.yaml — machine-readable rules an agent runs over an RFC (always-rules + per-gate rules; process vs content; blocker/warning/info severity) - rfcs/schema/rfc-review-judgment.yaml — structured output shape for agent verdicts (pass / needs-revision / fail + per-rule findings) - rfcs/schema/README.md — agent flow + division of labor Designed so the cheap parts of governance review (header completeness, status log integrity, deadline math) automate cleanly, while judgment- heavy parts (claim decisiveness, evidence sufficiency, counter-position adequacy) are flagged for humans to decide. Two-eyes principle preserved throughout: ratifier must be distinct from sponsor; agents never submit on-chain proposals. This is v0.1. Smallest first cut: write RFC-0001 for the M013 fee split and run the lifecycle end-to-end to surface gaps before scaling. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a structured Request-for-Comment (RFC) process to bridge the gap between design exploration and on-chain execution. It includes comprehensive graduation rules, a standardized template, and a machine-readable governance review schema for both human and agent reviewers. The review feedback identifies several critical improvements for the schema: removing brittle hardcoded agent names, correcting the conflict check logic to allow superseding ratified RFCs, adding missing steward confirmation checks, and defining the verification method for human-signed transactions.
| severity: blocker | ||
| rule: "Sponsor is human, not an agent ID" | ||
| passes_when: "sponsor field resolves to a human contributor" | ||
| fails_when: "sponsor matches agent-id pattern (codex-*, eliza-*, brawlaphant, *-bot)" |
There was a problem hiding this comment.
Hardcoding a specific agent name (brawlaphant) in the schema makes it brittle and less reusable. It is better to use a generic pattern or reference a registry of known agent IDs to maintain the schema's flexibility as the agent roster evolves.
fails_when: "sponsor matches agent-id pattern (codex-*, eliza-*, *-bot)"| category: content | ||
| severity: blocker | ||
| rule: "No live conflicting RFC exists on the same question" | ||
| passes_when: "no RFC in state in {draft, forum-posted, ratified} addresses the same decision" |
There was a problem hiding this comment.
The conflict check rule R-G-S2R-002 incorrectly includes the ratified state in its failure criteria. According to GRADUATION_RULES.md (§Promotion criteria, item 5), a new RFC can be initiated once a previous conflicting RFC is ratified, typically to supersede it. Including ratified here would block the legitimate creation of superseding RFCs.
passes_when: "no RFC in state in {draft, forum-posted} addresses the same decision"| rules: | ||
| - id: R-G-S2R-001 | ||
| category: process | ||
| severity: blocker | ||
| rule: "A human sponsor has volunteered (header §0 Sponsor is non-empty and human)" | ||
| delegates_to: [R-HEADER-002] | ||
|
|
||
| - id: R-G-S2R-002 | ||
| category: content | ||
| severity: blocker | ||
| rule: "No live conflicting RFC exists on the same question" | ||
| passes_when: "no RFC in state in {draft, forum-posted, ratified} addresses the same decision" | ||
| fails_when: "one or more conflicting RFCs exist; must be resolved/withdrawn first" | ||
| check_method: "scan rfcs/ for RFCs whose claim semantically overlaps; surface candidates for human disambiguation" | ||
|
|
||
| - id: R-G-S2R-003 | ||
| category: content | ||
| severity: blocker | ||
| rule: "Reference accessibility gate is passable for declared audience tier" | ||
| passes_when: "every reference in §9 either resolves at the declared audience tier, OR has a noted elevation plan" | ||
| fails_when: "any reference is workspace-local or otherwise inaccessible to declared audience without an elevation plan" | ||
| cite: "workspace CLAUDE.md — Reference Accessibility Gate" |
There was a problem hiding this comment.
The spec-to-rfc gate rules are missing a check for steward confirmation, which is explicitly required by the graduation rules: "Decision authority: the named sponsor (proposes promotion) + a steward confirms" (GRADUATION_RULES.md line 45). A rule should be added to verify this confirmation, for example by checking the status log in §6.
| rule: "On-chain proposer is human" | ||
| passes_when: "the on-chain submission tx is signed by a human key (not an agent service key)" | ||
| cite: "GRADUATION_RULES.md §RFC → on-chain proposal, critical rule" |
There was a problem hiding this comment.
Rule R-G-ENA-004 is missing a check_method definition. Unlike other rules in this section (e.g., R-G-ENA-002), it does not specify the mechanism an agent should use to verify that a transaction was signed by a human key rather than an agent service key. This makes the rule difficult to implement consistently.
1 participant
Summary
Adds the deliberation chamber scaffolding for the agentic-tokenomics → forum → on-chain pipeline. Today the code chamber works (agents ship PRs, CI gates merges, mechanism specs accumulate); the deliberation chamber barely exists in the repo. This PR closes that gap.
Three artifact types, three lifecycles:
mechanisms/,phase-N/rfcs/RFC-XXXX.mdphase-4/proposals/RFC-XXXX-proposal.jsonWhat's in this PR
rfcs/_template.md— copyable RFC template. Sections: claim, evidence, methodology, lineage, discussion surface, append-only status log, on-chain enactment, open questions, references. Borrows the claims-engine 4-layer pattern (claim/evidence/methodology/status).rfcs/GRADUATION_RULES.md— three-artifact-type lifecycle, promotion criteria for each gate (spec→rfc,rfc→forum-posted,rfc→ratified,rfc→enacted), demotion/parking/withdrawal, author-role matrix.rfcs/schema/rfc-review-schema.yaml— machine-readable rules an agent runs over an RFC (alwaysrules + per-gate rules; process vs content; blocker/warning/info severity).rfcs/schema/rfc-review-judgment.yaml— structured output shape for agent verdicts (pass | needs-revision | fail+ per-rule findings + recommendations + audit trail).rfcs/schema/README.md— agent invocation flow + expected division of labor between mechanical checks (agents reliable) and judgment-heavy checks (agents flag, humans decide).Design principles
internal | partner | commons | public); references must resolve at the declared tier before graduation. Threads with the existing Reference Accessibility Gate in the workspace CLAUDE.md.What this does NOT do
Recommended first end-to-end run
Per
GRADUATION_RULES.md§Smallest possible first cut:Test plan
rfcs/README.mdcold and can answer: "what's an RFC, when do I write one, what makes it ratifiable?"_template.mdis copyable toRFC-0001.mdwithout manual edits beyond filling in contentrfc-review-schema.yamlparses as valid YAMLGRADUATION_RULES.mdOpen questions for review
Called out in
GRADUATION_RULES.md§Open questions andrfcs/README.md:🤖 Generated with Claude Code