How-to guide · Documentation structure
How to read an Obscyra Digital document
Every page on this site opens the same way
Every policy and documentation page on this site follows the same structure. Once you know the fields a page carries, you can find the answer you need without reading the whole document. This guide walks through what each field means and where to look first.
Nothing here is a rule of its own. It is a reading method: five fields, one order to check them in, and a short list of the moments when the method is not enough and the full text is worth the time.
The scope field
- Answers
- Does this document apply to me?
- Find it
- Near the top, before the first numbered section
- If it misses you
- The scope names the document that does cover your case
- Takes
- About thirty seconds
Start with the scope
The scope field, near the top of every policy, states who the document applies to and what it does not cover. Read it first. If your situation falls outside the stated scope, the document will point you to the one that covers it, which saves you from applying the wrong rule.
Scope is written in plain sentences rather than a list of job titles, because many decisions on this platform are made by a role that several people hold at once. When a scope names a role, it means whoever currently holds that role, not a named person.
A scope that feels too broad usually means the rule is shared. A scope that feels too narrow is worth reporting: if the document clearly should cover your situation but does not say so, that gap is useful information for the next review.
The fields you will see
Five fields repeat across every policy and guide. They appear in the same order each time, so once you recognise the pattern you can scan a document instead of reading it end to end.
Who and what the document covers, and what it deliberately leaves out.
The owner, reviewer, and approver, with the decision each one holds. This is the row that tells you who can correct the document.
Documented deviations from the rule, each with a condition, an approving role, and an expiry date.
The current version number. Quote it when you ask a question, so the answer refers to the same text you are reading.
When the document was last checked against practice, and therefore how much confidence the date on it supports.
Reading the roles field
The roles field names the document owner and, where relevant, the reviewer and approver. The owner is accountable for accuracy. A reader who needs a correction can use this field to see who signs off on the document, and a maintainer can see which role holds which decision.
Roles are listed by function rather than by name. That is deliberate: a policy outlives the person who signed it. When a role changes hands, the document stays valid and only the roles field is updated, which is the change most often recorded in a minor version.
If you are unsure who to write to, the roles field removes the guesswork. Name the document and the section, and address the message to the owner; the reviewer or approver is copied in only when the question touches a decision they hold.
Understanding exceptions
An exception is a written deviation from a rule, not a gap in it. Each exception states the condition that triggers it, the role that approved it, and when it expires. If you are checking whether a rule applies to you, read the exceptions before you conclude that it does not.
An exception does not quietly stop the rule. It names the situation in which the rule is set aside, the role that approved that decision, and the date the exception ends. Past that date, the rule applies again in full.
Obscyra Digital — documentation practice
Does an exception mean the rule does not apply to me?
Only inside the situation it names. If your situation matches nothing in the exceptions list, assume the rule applies. Reading exceptions last is the most common reading mistake on this site because it reverses the answer when the condition is met.
What happens when an exception expires?
The rule applies again from that date, unless a new exception has been written and approved. Expiry dates exist so that an old allowance is not mistaken for standing practice. If you are working to an exception, note its end date in your own plan.
Who approves a new exception?
The approving role is named in the roles field of the document the exception belongs to. If that role is not listed, the document owner is the right first contact, and they will route the request to whoever holds the decision.
Using the table of contents
Long documents carry a table of contents at the top. It lists the actual sections in the order they appear, so you can jump straight to the one you need. The heading text is written to be specific, which means you can often answer your question by scanning the table of contents alone.
Scan the numbered headings first
Headings are written as complete statements of the rule or the topic, so a heading alone can confirm whether a section is worth opening.
Follow the contents order, not your instinct
Sections run from the general rule to the specific case. Jumping to a later section before the general one is the easiest way to read a conditional as an absolute.
Note the section name when you ask a question
The heading text is what the documentation team uses to find the passage you mean, so quoting it shortens the round trip.
The difference between a policy and a guide
A policy states a rule. A guide explains it, with reasoning and examples. If you want to know what is required, read the policy. If you want to know why, or how a rule was decided, read the guide. The two are linked, and the policy always takes precedence when they seem to disagree.
The practical difference shows up in the wording. Policies use short, closed sentences and no illustrative examples on purpose: an example inside a rule tends to become the rule in practice. Guides carry the examples, the reasoning, and the notes on what was considered and set aside.
A guide can be revised without changing what is required; a policy cannot. That is also why the two carry separate version numbers and why the change log records them as different entries.
When to read the full document
Read the full document when you need to apply a rule rather than just check it, when the scope is close to your situation, or when an exception might apply. For a quick confirmation, the scope field, the table of contents, and the version number are usually enough.
The dividing line is consequence. If getting the answer wrong would mean redoing work, briefing someone else on a decision, or writing something that has to hold up later, read the full text. If you only need to know whether a document is the right one to open, the summary fields will do.
Checking that you have the current text
Before acting on a document, confirm its version and review date, then check the change log for anything newer. This takes a moment and prevents the common mistake of following a rule that has since been revised.
The version and review date match what the change log shows as current. You are reading the text that applies today.
The review date is old enough that the wording may no longer match practice. Treat the rule as still in force and flag the document for a review.
The change log lists an entry that supersedes this version. Open the newer text before you act on the rule in front of you.
The change log itself is the record to trust. Each entry names the document, the version, and what changed, so you can confirm an update without opening the full text first.
Asking for a clarification
If the document does not answer your question, or if a sentence is ambiguous, that is worth reporting. Use the Contact page and name the document and section. A clarification request is logged against the document, and it can start a revision if the ambiguity affects other readers too.
Reports are more useful when they quote the sentence you found unclear and say what you expected it to mean. That is usually enough for the owner to either correct the wording or add a definition to the guide that explains it.
Requests are read during working hours, Monday to Friday, 9:00 AM to 6:00 PM Eastern Time. You can also write to [email protected] or call +1-202-478-1904 if the question is time-sensitive.
Two questions readers ask first
Where do I find the rule that applies to me?
Read the scope field first. It tells you whether the document applies to your situation and points to the right document if it does not.
What should I read if I only have a minute?
The scope field, the table of contents, and the version and review dates. Those three usually answer a quick check.
Read for one answer, not for the whole rulebook
The five fields exist so you can stop reading as soon as your question is answered. Start with the scope, check the version and review date before you act, and treat an exception as the named situation it is rather than a general permission.