Documentation management
Documentation management
Documentation looks after itself, right? You publish it, it sits there, it helps people. Except it does not. Documentation drifts. The JSON changes but the page still says the old value. A capability gets deprecated but the guide still recommends it. A screenshot shows a UI that was redesigned three months ago. The page looks polished, reads well, and is factually wrong.
Documentation Management treats your documentation library as operational content that needs governance, not a folder of files that somebody checks on when they remember. It tracks page ownership, review cadences, validation status, capability claims, media assets, and release readiness, so you always know which pages are current, which need attention, and which are blocking a release.
Who this schema is for
This schema is for any team that manages a documentation library, knowledge base, runbook collection, or governed content set where accuracy matters. It is particularly useful when:
-
Documentation must stay aligned with product behaviour, platform capabilities, or production configuration (JSON templates, AQL queries, automation rules)
-
Multiple contributors write and maintain content, and you need clear ownership and review accountability
-
Compliance or quality standards require an audit trail for content accuracy and review cadence
-
You publish documentation in release cycles and need readiness gates before content goes live
If your docs are a handful of internal notes that change rarely, you probably do not need this. If your docs are a product in their own right, with claims that must be verified against reality, this is the schema for that.
What it tracks
Seven object types, 68 attributes, and 7 reference types covering the full documentation governance lifecycle.
| Object Type | Attributes | Purpose |
|---|---|---|
| Schema | 6 | Reference data: deployed LaunchPad schema templates that documents cover |
| Document | 18 | Core object: each documentation page with ownership, editorial status, and validation status |
| Validation Run | 10 | Discrete validation passes (JSON alignment, AQL verification, capability checks) |
| Capability Claim | 9 | Factual claims in documentation that can drift from product reality |
| Media Asset | 10 | Screenshots, diagrams, and GIFs with status tracking and placement |
| Review Cycle | 7 | Scheduled and ad hoc review events with outcomes |
| Release Gate | 8 | Readiness checkpoints before documentation can be released |
The Document object type is the centre of the model. Everything else connects to it: validation runs verify it, capability claims belong to it, media assets illustrate it, review cycles govern it, and release gates control when it ships.
The two-dimensional status model
Most documentation systems have one status field. A page is either draft or published. That is not enough.
A page can be published and factually wrong. It passed editorial review, the grammar is fine, the formatting is correct, but the JSON it references was updated last week and nobody checked. Or a capability claim describes behaviour that was changed two releases ago. The page is published. It is also invalid.
Documentation Management separates these into two independent dimensions:
Editorial Status tracks where the page is in the content lifecycle:
- Draft
- In Review
- Published
- Archived
Validation Status tracks whether the page is factually correct:
- Unchecked
- JSON Validated
- Capability Verified
- AQL Verified
- Fully Validated
These are independent. A page can be "Published + Unchecked" (live but not yet verified against production), "Draft + JSON Validated" (content is being written but the technical claims have been checked), or any other combination. This is the key design insight: editorial quality and factual accuracy are separate concerns, and conflating them hides problems.
Pro tip: Filter your Document objects by "Published + Unchecked" to find the pages most likely to contain outdated claims. These are the ones your users are reading right now, and nobody has verified them recently.
How it connects to other schemas
The Schema object type provides structured references to the LaunchPad schemas that each document covers. Rather than a free-text field saying "this page is about Core Schema", the Schema object holds the actual schema metadata (name, version, prefix, object type count) and the document links to it via the Applies To reference type.
When deployed alongside Core Schema, people references on Document objects (Owner, Last Reviewed By) could be converted from text attributes to object references pointing at Person objects. This gives you proper relationship-based ownership rather than names typed into text fields.
The Documented By reference type works in reverse too: from any Schema object, you can query which documents cover it, giving you a complete coverage map of your documentation library.
Common use cases
Documentation library governance. Track every page in your docs site with ownership, editorial status, and validation status. Know at a glance which pages are current, which are stale, and which have no owner.
Capability claim verification. Log every factual claim your documentation makes about product behaviour, platform capabilities, or configuration. When the product changes, query which claims need re-verification. This is where credibility breaks are caught: platform claims, product claims, assumptions, workarounds presented as features.
Review cadence management. Set review cadences (Monthly, Quarterly, Biannual, Annual, Ad Hoc) per document and track review cycles with outcomes. No more guessing when a page was last checked.
Release readiness tracking. Define release gates (blocking and non-blocking) that must be satisfied before documentation ships. A blocking gate stops the release. A non-blocking gate flags a known gap but lets you proceed.
Media asset management. Track screenshots, diagrams, and GIFs with their placement, status, and the document they illustrate. When the UI changes, query which media assets need updating.
Audit trail for content accuracy. Every validation run is recorded: what was checked, when, by whom, and what the result was. When someone asks "how do we know this page is correct?", you have the answer.
What it does not do
This schema does not store your documentation content. It does not replace your CMS, wiki, Confluence space, or docs site. The actual words, images, and pages live where they always lived.
What it tracks is the operational metadata around those documents: who owns them, when they were last reviewed, whether their claims have been verified, what media assets they contain, and whether they are ready to ship. Think of it as the governance layer that sits alongside your content, not inside it.
Quick start
Ready to deploy? The quick start guide walks through creating the schema, populating the object types, and setting up your first document records with validation runs and review cycles.