Every RFC occupies exactly one lifecycle status, and every transition between them is recorded in the audit trail with an actor and a timestamp.
The workflow stepper at the top of an RFC page shows where a document has reached.
An enforced RFC showing the workflow stepper with Draft, Proposed, Reviewed, Approved and Enforced steps complete

​
The statuses

Visible to the organisation, edited freely by authors, no statements extracted and no effect on agents or CI. Every RFC starts here.
The author has put it forward. Awaiting sign-off from the assigned reviewer group, then approval. Still no effect on agents or CI.
Signed off by an eligible approver. Statements are extracted on approval and served to agents. CI findings are advisory — reported on the pull request, never blocking.
Promoted deliberately by a domain owner. MUST-level findings now fail the check and block the merge. SHOULD findings continue to warn.
No longer in force. Retained in full, with its history intact, so past violations still resolve against the statements that were live at the time.

​
Why approved and enforced are separate

This is the most important design decision in PolicyCodex, and the one that decides whether a standards programme succeeds. A standard that starts blocking merges the day it is approved gets one reaction: resentment, then workarounds. The grace period at approved gives you a period where the rule is real — agents follow it, findings appear on pull requests, teams can see how much work compliance actually is — but nobody’s Friday deploy is blocked by a document approved on Thursday.
1

Approve

Statements go live to agents. Findings appear on pull requests as advisory comments. Teams see the shape of the work.
2

Watch

The dashboard shows how many findings the standard produces and where. If it’s generating hundreds, the standard needs tightening — not the teams.
3

Promote

When the backlog is manageable, promote to enforced. The audit trail records who made that decision and when.
Promotion is the adoption unlock, not a formality. Treat “when do we enforce this?” as a real decision with a date on it, or standards will sit at approved forever.

​
Who can do what

The domain owner may always approve RFCs in their own domain, whether or not they are in the assigned approver group. Ownership carries accountability, so it carries authority.
An RFC at proposed cannot be approved until it has been reviewed — the page says so explicitly, and the approval action is unavailable until the review step is recorded.

​
Revisions after enforcement

Saving a new revision on an enforced RFC creates a new immutable version; the enforced status carries forward and statements are re-extracted with their existing slugs reused wherever the requirement is materially unchanged. Changing an enforced RFC’s number or domain, however, resets it to proposed for re-approval. Moving a document to another domain changes who is accountable for it, and that requires fresh sign-off.

​
Everything is audited

Each transition appends a row: rfc.proposed, rfc.reviewed, rfc.approved, rfc.enforced, rfc.meta_changed, rfc.archived, statements.extracted. The row carries the actor, the subject, and a hash chaining it to the previous entry. See Audit trail.