- Document set
- Policy and documentation library
- Audience
- Public readers, staff, maintainers
- Applies to
- Anyone checking a rule that affects them
- Status
- Open and under scheduled review
Official policy and documentation for Obscyra Digital
Philadelphia · Mon–Fri, 9:00 AM – 6:00 PM ET
This site is the policy and documentation library for Obscyra Digital. It holds the governance documents, standards, accessibility rules, versioning records, and reading guides that describe how our documents are written, reviewed, and maintained.
Every page here is meant to be scanned, not read cover to cover. Use the index below to jump straight to the document that answers your question.
What this library contains
The library is organized into five document families: governance, standards, accessibility, versioning, and reader guides. Each family has its own entry point and its own audience.
Governance
Covers how a policy moves from draft to approval, who signs off, and how a retired rule is archived.
Governance and Review ProcessStandards
Covers how we write and structure pages: sentence length, headings, plain-language rules, and accessibility requirements.
Standards and AccessibilityVersioning
Records what changed, when it changed, and why a rule moved to a new version. This is where you confirm you are reading current text.
Versioning and Change LogReader guides
Explain how to move through a document once you open it, including the scope, roles, exceptions, and review fields you will see on the page.
How to Read Our DocumentsIf you already know the topic you need, the full index in the Documentation Library sorts every document by topic and audience.
Two readers, one library
- Reader
- Members of the public
- Arrives with
- One question about a rule
- Needs first
- Scope, so they can stop early
- Reader
- Staff, reviewers, maintainers
- Arrives with
- A document to correct or update
- Needs first
- Owner, reviewer, review date
Some pages are written for members of the public checking a rule that affects them. Others are written for staff, reviewers, or teams who maintain the documents themselves.
A policy on scope and applicability reads differently from a change log, and we label each page so you know which one you are on before you start. If a page assumes background you do not have, the reading guide points you to the prerequisite.
Scope sections do the first filter for a reader. They state plainly who a document applies to and what it does not cover, so a visitor can confirm relevance within seconds of opening the page.
The document set at a glance
Five entry points cover the whole set. Open the one closest to your question; every page links sideways to the others when you need the next layer of detail.
Governance and Review Process
How policies are proposed, reviewed, approved, and retired.
Standards and Accessibility
The writing, structure, and accessibility rules every page must meet.
Versioning and Change Log
How documents are numbered and what changed between releases.
How to Read Our Documents
The scope, roles, exceptions, and review fields you will see.
Documentation Library
The full index, sortable by topic and audience.
Scope and applicability
A scope section states plainly who a document applies to and what it does not cover. We put scope near the top of every policy because readers arrive with a specific question and need to know within a few seconds whether the document is even relevant to them.
If your situation falls outside the stated scope, the document will tell you where to look instead. That handoff matters: a reader who lands on the wrong policy should leave with a direction, not a dead end.
- In scope
- Rules that bind a named team, role, or public process
- Out of scope
- Product pricing, marketing claims, and promotional content
- When unclear
- Read the more specific document; the overview links to it
Roles and responsibilities
Each document names an owner and, where relevant, a reviewer. The owner is accountable for the document's accuracy. The reviewer checks it against the standards before publication.
Roles are listed explicitly, not implied, so a reader who needs a correction knows whom to contact and a maintainer knows who signs off on a change.
- Owner
- Accountable for accuracy
- Reviewer
- Checks against standards
Exceptions and how they are recorded
Not every rule applies in every case, and we would rather document the exceptions than let readers guess. An exception is written down with its condition, its approver, and its review date.
When an exception expires, the document is updated to reflect that. This keeps the policy text and the real practice from drifting apart over time.
- Condition
- When the exception is allowed to apply
- Approver
- Who agreed to it, on the record
- Review date
- When the exception is checked again
- Review date
- When the text was last checked against practice
- Not the same as
- The date it was first published
- If the date has passed
- The document is being revised or flagged
- To confirm currency
- Compare the version number with the change log
Review dates and currency
Every policy page carries a review date. It tells you when the document was last checked against current practice, which is different from when it was first published.
We treat a review date as a commitment: if the date has passed, the document is either being revised or flagged. The versioning page explains how to confirm you are reading the current text.
A passed review date does not mean a rule stopped applying. It means the document is due for a check, and the change log is where that check is recorded.
How the hierarchy works
The library uses a fixed hierarchy so that pages do not compete with each other for the same job. When two pages seem to overlap, the more specific one governs and the overview links to it. This is the same pattern federal design systems and large developer documentation hubs use to keep depth without duplication.
Overview pages
Orient you across a family of documents and point to the one that carries the rule.
Reference pages
Define terms and rules in the form you check against, with scope and dates attached.
Task pages
Walk through a procedure step by step, in the order the work actually happens.
Why plain language matters here
Policy text is only useful if people can act on it. We write in short sentences, avoid stacked clauses, and define a term the first time it appears.
Plain language is not a lower register; it is the register that a reader checking a rule on a phone at midnight can follow. The standards page sets out the sentence-length and heading rules we apply to every document in this set.
Standards and Accessibility
What you will not find in this library
This library documents policy and process. It does not host marketing content, product pricing, or promotional claims. We do not publish testimonials, ratings, or outcome promises on these pages, and we do not use before-and-after material.
If a claim cannot be traced to a written policy or standard, it does not belong in this set. That rule is what makes the pages here safe to cite in a review, a ticket, or a compliance check.
Keeping documents current
Documents move through a review cycle rather than being edited in place without notice. A change to a policy creates a new version with a recorded reason. Readers can compare versions, and maintainers can see why a rule changed.
The change log is the single place where those updates are listed in order.
Where to start
If you know the topic, open the Documentation Library and scan the index. If you are new to the set, read How to Read Our Documents first; it explains the fields you will see on every page.
If you need to report an error or ask for a clarification, the Contact page routes your message to the documentation team. Questions about scope, review dates, and exceptions are all welcome there.
Common questions about this set
Three questions come up most often from first-time readers. The answers below link to the page that carries the detail.
Is this a marketing site?
No. This is a policy and documentation library. Pages here define scope, roles, standards, and review details rather than promote a product.
Where do I find the rule that applies to me?
Start with the Documentation Library index, which groups every document by topic and audience. Each policy states its scope near the top so you can confirm relevance quickly.
How do I know I am reading the current version?
Check the review date and version number on the page, then confirm it against the Versioning and Change Log.