Policy governance guide
How our policies are reviewed and approved
Purpose of this page
This page explains how an Obscyra Digital policy moves from a proposal to a published document, and how it is eventually retired. It is written for maintainers and reviewers, and for any reader who wants to know who owns a document and how a change happens.
If you are looking for the documents themselves rather than the process behind them, start with the documentation library. If you are drafting a change, read on before you edit anything.
Before the edit
Why governance comes before editing
A policy is not a page someone edits when they feel like it. Changing a rule has consequences for everyone the rule applies to, so we treat each change as a governed action. The CFPB design system makes this point directly: establish the governance policy before you change a pattern or a document.
Establish the governance policy before you change a pattern or a document.
CFPB design system guidance
We follow the same logic. Before an edit is made, the question of who is allowed to make it and under what criteria is already answered. That is the difference between a rule that holds and a page that drifts.
The four stages
The four stages of a policy
Every document moves through four stages: proposal, review, approval, and retirement. A stage has a defined entry condition and a defined output. A proposal needs a stated reason. A review needs a checklist. Approval needs a named approver. Retirement needs a record of what replaced the document, if anything.
Proposal
Starts with a written reason for the change. It states which document is affected, what the change is, and why the current text is insufficient. Proposals that skip the reason are sent back.
Review
The document is checked against the standards and accessibility rules and against the scope it claims to cover. The reviewer looks for two things: whether the change solves the stated problem, and whether it creates a new inconsistency elsewhere.
Approval
Approval rests with the document owner, who is accountable for the document's accuracy. Approval also sets the next review date. We do not approve a change without deciding when the document will be checked again.
Retirement
When a document no longer applies, it is retired rather than deleted. Retired documents stay in the library for reference and are marked as no longer in force, and they link to their replacement where one exists.
Stage one: proposal
A proposal starts with a written reason for the change. It states which document is affected, what the change is, and why the current text is insufficient. Proposals that skip the reason are sent back. This is the same discipline a documentation team applies when deciding whether a change is minor or major, and it keeps small edits from quietly becoming large rewrites.
In practice, that means a proposal reads like a short brief: the problem, the document, and the outcome you expect. Reviewers accept it or return it with notes, and nothing is edited before that step is done.
What a proposal must state
- Which document
- What changes
- Why the current text falls short
- Whether the change is minor or major
What a reviewer checks
Stage two: review
During review, the document is checked against the standards and accessibility rules and against the scope it claims to cover. The reviewer looks for two things: whether the change solves the stated problem, and whether it creates a new inconsistency elsewhere in the library.
Review is not a formality. A change that fixes one page but breaks a cross-reference on another is sent back with notes.
Stage three: approval
Approval rests with the document owner. The owner is accountable for the document's accuracy, which is why the owner's name appears on the published page. Approval also sets the next review date. We do not approve a change without deciding when the document will be checked again, because a policy with no review date quietly becomes unreliable.
What approval produces
Stage four: retirement
When a document no longer applies, it is retired rather than deleted. Retired documents stay in the library for reference and are marked as no longer in force. If a replacement exists, the retired page links to it. This preserves the record and prevents old links from resolving to nothing.
Where to see this in practice
Retired entries and their replacements are listed in the versioning and change log, alongside the dates the changes took effect.
Read the Versioning and Change Log
Roles in the process
Roles: owner, reviewer, approver
Three roles carry the process. The owner is accountable for content and signs off. The reviewer checks the document against standards and flags inconsistencies. The approver confirms the change is within scope and sets the review date. On small documents one person may hold two roles, but the roles remain distinct, and the published page lists who held them.
Owner
Accountable for the document's accuracy and visible on the published page.
Reviewer
Checks the change against standards and flags inconsistencies elsewhere in the library.
Approver
Confirms the change is within scope and sets the date for the next check.
Where two roles sit with one person, the review step still happens and is still recorded. The separation exists so a change is seen twice before it reaches a reader.
Handling exceptions
An exception is a documented deviation from a rule. It is written down with the condition that triggers it, the role that approved it, and an expiry date. We do not leave exceptions implicit, because an undocumented exception is indistinguishable from a mistake.
When an exception expires, the document is either updated to make the deviation a rule or corrected to remove it. Either way the document ends the period consistent with the rule it publishes.
Every exception records
An exception with no expiry date is not an exception. It is an unrecorded change, and it is treated as an error.
Minor and major changes
We separate minor edits from major ones. A minor change fixes wording, a link, or a typo and follows an abbreviated review. A major change alters a rule, a scope, or a role and requires full review and owner approval. The distinction matters because it determines how much of the process a given change has to pass through, and it keeps routine cleanup from stalling on a heavyweight path.
Minor edit
Wording, a broken link, or a typo. Reviewed at an abbreviated step and published once the wording matches the rule it describes.
Major change
A rule, a scope, or a role changes. It passes through full review and needs the owner's approval and a new review date before it is published.
Review dates and why they expire
Every approved document gets a review date. When that date passes, the document is flagged for re-check even if nothing appears to have changed. Practice drifts, and a rule that was accurate last year may no longer match how the team works.
Re-checking on a schedule catches that drift before a reader does. If a re-check confirms the document still holds, the owner sets the following review date. If it does not, the change goes back through review as a proposal.
How readers influence the process
A reader who reports an error or asks for a clarification starts a proposal. We do not treat reader reports as noise. A correction request is the most reliable signal that the published text and the real rule have diverged.
The Contact page routes these reports to the documentation team, and each one is logged against the document it concerns. If a report leads to a change, it follows the same four stages as any internal proposal.
Contact the documentation teamStandards the review checks against
Every policy we publish is held to the accessibility rules before it is approved, not after.
Questions readers ask most
Two questions come up more than any other. The answers below apply across every document in the library.
Who decides when a policy changes?
The document owner approves changes and sets the review date. The reviewer checks the change against standards, and the process requires a written reason before any change is made.
Can a rule be bypassed without a record?
No. Any deviation is documented as an exception with its condition, approver, and expiry date. Undocumented exceptions are treated as errors.
Where to go next
Documentation Library
The published policies this process governs, with owners named on each page.
Versioning and Change Log
Approved changes, retirement notices, and the dates they took effect.
Standards and Accessibility
The rules a document is measured against during review.
Frequently Asked Questions
Short answers on ownership, exceptions, and how to request a correction.
Obscyra Digital publishes these documents from 1201 Market Street, Suite 1400, Philadelphia, PA 19107. Questions about the process itself can go to [email protected] during business hours, Monday to Friday, 9:00 AM to 6:00 PM Eastern Time.