Kaspelon Policy & Documentation
Information architecture for policy documentation
How a policy library gets named, grouped, numbered, and cross-linked so a reader finds the right document on the first attempt — and what to fix when they cannot.
What this page covers
Information architecture is invisible when it works. When it fails, readers open four files, give up, and ask a colleague — which is the same as having no library at all. This page walks through the five decisions that make a policy library navigable: how content is grouped, how files and titles are named, how headings earn their numbers, how cross-references carry their purpose, and how navigation stays shallow enough to use.
Each section below pairs a rule with the reader problem it solves, so you can take one piece at a time. Where a decision belongs in a wider standard, the link goes to the page that owns it.
Grouping
Grouping by topic before document type
Readers arrive with a subject, not a document type. They want the expense rule; they don't yet know whether it lives in a policy or a procedure. Grouping by topic at the top level and separating by document type one level down matches how the question actually arrives.
Finance contains policy, procedure, standard, and form subfolders. Every other topic repeats those same four names. A reader who learns the pattern once can predict where anything lives — the folder names stop being a lookup and start being a habit.
File name / title
Document title
Records Retention Policy
Subject first, type second. Two nouns, no abbreviations, no code.
File name
records-retention-policy
Lowercase with hyphens. No version numbers, no dates, no author initials.
Where the version lives
Inside the document
The version note sits at the top of the file, not in its name. Renaming breaks every link pointing at it.
Naming convention and typography are governed by the same published rule set.
Read the documentation standardsNaming documents and files
Document titles state subject and type. A reader scanning a list of two hundred titles can tell what a file is before opening it, which is the whole job of a title. The title is written for the reader; the file name is written for the link.
Versioning belongs in the version note inside the document, because renaming a file breaks every link pointing at it. A library with dated file names accumulates broken cross-references faster than it accumulates policies — and a broken cross-reference is worse than no cross-reference, because it looks authoritative and leads nowhere.
Two tests keep the convention honest. First: can a new colleague predict the file name from the title alone? Second: does any file name carry information that will go stale — a year, a version, a person? If it does, move that information into the document body and leave the name stable.
Structure
Heading structure and visual hierarchy
Heading levels map directly to the document's numbering. Level one headings become 1, 2, 3. Level two becomes 1.1, 1.2. Level three becomes 1.1.1. A reader citing a clause and a reader scanning a page use the same structure, which means the table of contents, the numbering, and the visual hierarchy are three views of one thing.
When they disagree, a reader who cites section 4.2 finds a paragraph numbered 4.3, and trust in the document drops. That mismatch is the most expensive kind of documentation defect, because it is invisible until someone relies on it in a meeting.
Level one
1, 2, 3
A new obligation group. Always starts a page or a fresh section of the manual.
Level two
1.1, 1.2
A distinct requirement inside one obligation group. Citable on its own.
Level three
1.1.1
A sub-clause that qualifies the requirement above it. Rarely cited alone.
Cross-references
Cross-references that actually help
Every cross-reference names its purpose. "See the Records Retention Policy for retention periods" is useful; "See also Records Retention Policy" is not, because the reader doesn't know what they'll find there. Dependencies, definitions, and exemptions get separate labels so a reference can be judged before it is followed.
If a procedure depends on three other documents to make sense, that's a sign the procedure should absorb one of them rather than link to everything. A link is a claim that the reader needs the other document to act — if that claim is false, the link is noise.
A dependency reference should say what the reader must do with the other document — not just that it exists.
Definition and exemption labels get their own field, so a reader can skip a clause that does not apply to them.
When one procedure needs three others to make sense, absorb the smallest and reference the rest once.
Navigation
Navigation in a minimalist documentation site
Navigation should be visible, predictable, and shallow. Open-source documentation themes in this space, such as the textlog Jekyll theme and the Pinexio documentation template, both lean toward the same pattern: a persistent sidebar or a small top-level menu, minimal chrome, and content given the full width of the page.
That's a good model for a policy library, where the reader's job is to find a document, not to explore the site. Keep primary navigation to topics, and put everything else in the footer. A reader who has to learn a navigation scheme before they can read a rule has been charged twice for the same information.
Two habits keep navigation shallow. Cap the top level at topics a reader would name out loud. And never bury a policy behind a second menu of document types — that distinction belongs inside the topic, where the reader already is.
What a shallow menu looks like
-
Topics
The only top-level choice: Finance, People, Records, Operations.
-
Document type
A subfolder inside the topic, not a second global menu.
-
Search
Available from every page, with the topic already applied where the reader is.
-
Everything else
Standards, guidance, archive history, contact — kept out of the reading path.
Two systems
What users expect from support and help documentation
Help centers
Miro's and OpenAI's help centers organize around the question a user is actively asking, grouped by task and searchable from any page. The reader arrives mid-problem and wants an answer in one step.
Organizing principle: the task the reader is doing right now.
Policy libraries
Policy libraries organize around the obligations a reader must follow, grouped by governed subject. The reader may arrive with a question, but what they leave with is a requirement they are accountable for meeting.
Organizing principle: the subject being governed.
Both benefit from the same underlying principles — topic grouping, consistent naming, visible navigation — but merging them produces a document that's neither a rule nor a fix. Keep the two systems distinct and link between them where they genuinely overlap, so a policy can point to a how-to without pretending to be one.
Compliance
Making compliance content approachable
A reader should be able to see the requirement, the owner, and the evidence on one screen. Compliance material often fails this because it interleaves justification and warning with the rule itself.
Split them into separate fields in the document template. Qualtivate's framework, which sits at the intersection of policy, compliance, and operations content, shows how that structure stays approachable without losing authority: state the requirement, state the owner, state the evidence, stop.
Requirement
One sentence the reader must comply with. No justification, no history, no warning.
Owner
The role accountable for the rule, named by role rather than by person, so it survives a staff change.
Evidence
The form, log, or record that shows the rule was followed. This is the field reviewers actually ask for.
Justification still matters — it explains why the rule exists and helps a reader apply it to a case the document did not anticipate. It just doesn't belong in the same field as the rule. Move it to a short rationale section below the requirement, where a reader can skip it when they already know the reason and read it when they don't.
Superseded guidance
Superseded files keep their names
When guidance is replaced, the old document moves to an archive folder with an archive note at the top — its file name is unchanged, because links elsewhere still point at it. Review and maintenance owns the schedule for that move.
Archive folder sits at the topic level, beside the four type subfolders, so the pattern stays predictable.
The archive note names what replaced the document and when the replacement takes effect.
Nothing is deleted. A reader who finds an old reference can follow it to the current rule.
Questions about organizing a policy library
The questions that come up most often when a library is being rebuilt or audited.
Ask an architecture questionShould the library be organized by department or by subject?
By subject, in most cases. Departments change; obligations do not. A reader looking for the expense rule is not thinking about which team owns it, and a library organized by department forces them to learn an org chart before they can read a rule. Department is useful as a field on the document — the owner field — not as the top-level folder.
Where should the version number live?
Inside the document, in a version note at the top, never in the file name. A file name carrying a version bumps every time the rule is edited, which breaks every link and reference pointing at it. Keep the file name stable for the life of the subject, and let the version note carry the history.
How deep should the topic levels go?
Two levels of topic, then document type, then the document. If a topic needs three levels of folder to reach a rule, the rule is probably two subjects at once and should be split. Depth in a folder tree is a symptom, not a feature — each additional level is a place a reader can take the wrong turn.
Can a policy and a help article cover the same topic?
Yes, and they usually should. The policy states the obligation; the help article explains how to meet it in the tool the reader is using. Keep them in separate systems with separate navigation, and link from the policy to the article where the overlap is real. Merging them produces something that is neither enforceable nor helpful.
What is the fastest sign that an architecture is broken?
People asking each other where a document lives. That question means the naming, grouping, and navigation have stopped being predictable. The fix is rarely a new page — it is usually one inconsistent folder name, one title that bury a second subject, or one section numbering that drifted from its heading level.
Give the library a shape readers can predict
Group by topic, name for the reader, number headings the way the document is cited, and keep navigation shallow. If you are reworking an existing library and want a second read on the structure, the standards and guidance pages show the conventions in full — and our contact page is the place to describe what you are working with.
Contact
1600 Pennsylvania Avenue NW, Washington, DC 20500 · +1 202-404-8117 · [email protected]
Monday to Friday, 9:00 AM – 6:00 PM Eastern Time
Kaspelon Policy & Documentation — information architecture