Paldorin Digital
Policy Center
This guide sets how we write and format every policy, standard, and help page we publish. It exists so a reader moving between two of our documents does not have to relearn the conventions at each one. The rules below are specific on purpose. “Write clearly” is not a standard anyone can follow or check. “Use sentence case in headings and the active voice in requirements” is both.
Plain language is the base rule, and the others serve it. We prefer the short word when it is as precise, the concrete noun over the abstraction, and a direct sentence over a construction that makes the reader hold two clauses in mind to get one fact.
This is not dumbing anything down. Policy text is read under time pressure, often by someone looking for a single answer, and complexity that costs nothing to the writer costs the reader real time. Every document we publish follows this documentation style guide, whether it is a policy, a compliance note, or a step-by-step help page.
Requirements are written in the active voice with a named actor. The examples below show the rewrite we ask for, and why the original leaves the reader guessing who is on the hook.
Passive voice still has a place when the actor genuinely does not matter or is not known, and we use it there. What we avoid is passive voice as a way of distributing responsibility so widely that nobody holds it.
Headings use sentence case: capitalize the first word and proper nouns only. It reads faster than title case, it removes a category of judgment calls about which small words to capitalize, and it keeps our documents consistent with the technical documentation conventions our readers already encounter elsewhere.
Heading levels follow the document outline. We do not skip a level to get a smaller-looking font, and we do not use bold paragraphs in place of a real heading.
One date format across the library: month spelled out, day, year, as in March 4, 2025, with no ordinal suffix. It is unambiguous to readers in the United States and to anyone parsing the document later. Numbers under ten are spelled out in prose; measurements, version numbers, and statutory references keep their numerals.
We use the serial comma, consistently, including in the last item of a list of requirements. In policy text an ambiguous list is a real problem rather than a stylistic quibble.
The tone target is conversational but not casual: plain sentences, no jargon where a common word works, and no jokes in a document someone may read because something went wrong. Contractions are fine. Slang, exclamation marks, and rhetorical questions are not.
We also do not use “simply,” “just,” or “obviously” in instructions, since those words tell a confused reader that the confusion is their fault.
Documents are broken into discrete modules with descriptive headings, and paragraphs stay short. Requirements become lists rather than prose when there are two or more of them. Tables are reserved for genuine comparisons; they are hard to read on small screens and worse with a screen reader.
The goal is that a reader can find the relevant section from headings alone, without reading the whole page.
We pick one term for one thing and use it everywhere. If the guide says “document owner,” no policy calls the same role a “page steward.” Synonyms that read as variety in an essay read as ambiguity in a standard, and readers reasonably ask whether two different words mean two different things. New terminology gets added to the shared word list rather than invented per document.
See the shared word list
Style rules extend to how text behaves for assistive technology. Alt text describes the function of an image rather than its appearance. Link text stands alone. Headings are real headings, not bold paragraphs that look like them.
Section 508 practice is covered in full on the Accessibility Standards page; the writing guide only notes where word choice and structure feed into it. When a screen reader reads a link out of context, the words in that link are the entire message, so the rule is short and firm: name what the reader will get.
Read accessibility standardsThis document is maintained on an ongoing basis, like the rest of the library. Proposed changes go through the Content Governance review process and are recorded in the version history rather than edited silently. Editors who find a rule unworkable should say so through the Contact page; a standard that people quietly ignore is worse than one that gets revised.
Questions about a rule? Call +1 202-432-8110, write to [email protected], or visit 1201 Wilson Boulevard, Suite 700, Arlington, VA 22209. Office hours are Monday to Friday, 9:00 AM – 6:00 PM Eastern Time.
It applies to anything published or shared beyond its author. Drafts can be looser, but formatting review is faster if conventions start early.
It reads faster, reduces capitalization judgment calls, and matches the technical documentation conventions our readers already see.
The legal text wins and the deviation is noted. Style rules serve clarity, not the other way around.
These rules apply across every document we publish, from policy handbooks to help pages, so readers can move between them without relearning the format. If a convention here does not fit your document, propose the change through the governance process instead of inventing a local exception.