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.There is no override — not even for the domain owner. An RFC with no reviewer group assigned therefore cannot be approved at all; the page says so, and the fix is for the domain owner to assign one.

​
Revising resets the review

Saving a new revision clears the review sign-off, and the RFC has to be reviewed again before it can be approved. The audit entry for the save records review_invalidated, so the reset is visible in the trail rather than silent. The same happens if the domain owner changes the reviewer group. The review covers a specific text; changing the text means nobody has reviewed what is now in front of the approver. Changing an RFC’s number or domain after creation is the one exception — the content did not change, so the sign-off survives, though an approved or enforced RFC drops back to proposed for re-approval. Members with the viewer role can never review or approve, even if someone adds them to a reviewer or approver group. Viewer is read-only throughout the app.

​
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 — any non-viewer member of the approver group, or the domain owner — chooses Approve. Group membership is what grants the authority: an author who sits in the approver group for a given RFC may approve it, which is why groups are assigned per RFC. 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.
Nothing is ever deleted. Archiving files an RFC away and freezes it — an archived RFC cannot be reviewed, approved, promoted or revised until it is unarchived. To reuse its content, duplicate it: the copy starts as a fresh draft with no groups and no sign-off.
There is no separate rejection state. Leave the RFC at proposed, record what needs changing in a review note, and let the author revise.