Approval in PolicyCodex is attributable. Every sign-off names a person, and that name is what makes the corpus audit-grade: you can answer “who decided the agents should follow this?” without a meeting.

​
Assigning reviewers and approvers

The domain owner assigns a reviewer group and an approver group on the RFC page. Both are role groups — named sets of members, so a person leaving the team doesn’t strand a document.
An RFC page showing the author, reviewer group and approver group panel above the lifecycle actions
The panel above the lifecycle buttons shows:
  • Author — who created the RFC
  • Reviewer group — who is expected to review, and once reviewed, who did it and when
  • Approver group — who can approve. The domain owner may always approve regardless.
Only the domain owner sees these as editable dropdowns; everyone else sees the current assignment as text.

​
The review step

A member of the reviewer group opens the RFC and chooses Submit review. That records rfc.reviewed in the audit trail with their identity and the timestamp, and unlocks approval.
An RFC at proposed cannot be approved until it has been reviewed. The page shows “Awaiting review before this can be approved” and the approval action stays unavailable. This is deliberate: two-person integrity on anything that will govern agent behaviour.

​
Review notes

Below the document body is an append-only notes thread.
The review notes thread on an RFC, showing notes with author and timestamp and a box to add a new one
Notes are for reasoning — why you approved, what you’d want tightened in the next revision, which team you consulted. The audit trail records what happened; notes record why, and the two together are what makes a standard defensible a year later. Notes cannot be edited or deleted once posted. Each one carries its author and timestamp.

​
Approving

An approver — a member of the approver group, or the domain owner — chooses Approve. Two things happen immediately:

Audit row

rfc.approved is appended with the approver’s identity, hash-chained to the previous entry.

Statement extraction

Statements are extracted from the approved revision and become visible to agents over MCP. See Statements.
At this point the standard is advisory — findings appear on pull requests but never block. Promotion to enforced is a separate act by the domain owner.

​
Practical advice

A reviewer group of twelve people is a group of nobody. Three or four named engineers who actually work in the domain will produce better standards and faster turnaround.
The most consequential decision in an RFC is whether a requirement is MUST or SHOULD — that is the difference between a blocked merge and a comment. Review it explicitly.
“Approved — matches what the platform team already does, no migration needed” takes ten seconds and saves an archaeology session next year.
There is no separate rejection state. Leave the RFC at proposed, record what needs changing in a review note, and let the author revise.