Documentation management
Documentation management
A documentation page does not announce when it goes wrong. The JSON it describes gets a new attribute, a capability it recommends gets deprecated, a screenshot shows a UI that was replaced months ago, and the page carries on looking exactly as polished as the day it was published. Readers trust it right up until it fails them.
Documentation Management treats your documentation library as governed operational content rather than a folder of files someone checks when they remember. It tracks page ownership, editorial and validation status, factual claims, media assets, review cycles, and release readiness, so you always know which pages are current, which are drifting, and which are blocking a release.
From version 1.2 the schema extends Core Schema. Every person involved in the governance loop, the owner, the reviewer, the validator, the approver, is a real Person object reference rather than a name typed into a text field.
What you get
| Object Type | Purpose | Key Attributes |
|---|---|---|
| Schema | Reference data: the LaunchPad schemas your documents cover | Schema Key, Version, Tier, Category, Object Type Count, Status |
| Document | Core object: one documentation page with ownership and dual status tracking | Section, Tier, Doc Type, Owner, Reviewer, Editorial Status, Validation Status, Review Cadence |
| Validation Run | A single verification pass against a document, with findings | Validation Type, Scope, Result, Severity, Checked By, Date Checked |
| Capability Claim | A factual claim that may drift and needs verification | Claim Type, Claim Text, Platform, Verified, Risk Level, Last Verified |
| Media Asset | Screenshot, diagram, GIF, video, or icon used in a document | Asset Type, Media Status, File Path, Alt Text, Placement, Last Updated |
| Review Cycle | Scheduled or ad hoc document review with an outcome | Review Type, Scheduled Date, Completed Date, Reviewer, Outcome |
| Release Gate | Readiness checkpoint before a document can be released | Gate Type, Gate Status, Blocking, Required For Release, Approved By |
7 object types · 10 reference types
Pro tip: This schema extends Core Schema. Deploy Core first so the Person references on Document, Validation Run, Review Cycle, and Release Gate have real people to point at. Then filter Document objects for "Published + Unchecked" to find the pages your readers are using right now that nobody has verified.
When to use this schema
This schema suits any team that runs a documentation library, knowledge base, runbook collection, or governed content set where accuracy matters. Deploy it when:
-
Documentation must stay aligned with product behaviour, platform capabilities, or production configuration (JSON templates, AQL queries, automation rules)
-
Multiple contributors maintain content and you need clear, queryable 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 rarely change, 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.
Not quite right? If you only need to track software systems and services without documentation governance, Core Schema covers that. If your focus is IT asset management rather than content governance, look at Standard CMDB or Enterprise IT CMDB.
Schema at a glance
Core Schema (Person)
▲
Owned By / Reviewed By / Approved By
│
Schema ◀──(Applies To)── Document
│
┌──────────┬────────┼──────────┬──────────┐
▼ ▼ ▼ ▼ ▼
Validation Capability Media Review Release
Run Claim Asset Cycle Gate
The Document object type is the centre of the model. Everything else connects to it: validation runs verify it (Validated By), capability claims belong to it (Claims Made In), media assets illustrate it (Illustrated By), review cycles govern it (Reviewed Under), and release gates control when it ships (Gates Release Of). Above the document layer, the people doing the governing live in Core Schema: Owned By, Reviewed By, and Approved By link documents, validation runs, review cycles, and release gates to Person objects.
How the Core references resolve at deploy time
Five attributes point at the Person object type in Core Schema: Document Owner (required), Document Reviewer, Validation Run Checked By, Review Cycle Reviewer (required), and Release Gate Approved By. During deployment, LaunchPad detects each cross-schema reference and asks you how to resolve it:
- Link to Core: connect the attribute to the Person object type in your existing Core Schema deployment. This is the recommended option and gives you one shared people register.
- Create here: create a Person object type inside the Documentation Management schema from the Core template definition. Use this if you run the schema standalone without Core.
- Keep as text: skip the relationship and create the attribute as a plain text field instead. Names become free text, so you lose people-based queries.
Documentation
Quick start guide Deployment guide covering all seven object types: schema references, document records, validation runs, capability claims, media assets, review cycles, and release gates, plus the Core Schema reference resolution choices.
Governance playbook (part of LaunchPad IP) Review cadence management, the two-dimensional status model (editorial and validation), capability claim verification practices, and release readiness gating.
Forms specification (part of LaunchPad IP) Form layouts for all seven documentation management object types.
Design details: status model, integrations, and use cases
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 changed last week and nobody checked. 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" (still being written but technically checked), or any other combination. That is the key design insight: editorial quality and factual accuracy are separate concerns, and conflating them hides problems.
How it connects to other schemas
The schema extends Core Schema, and the connection runs in two directions.
People first. Document ownership and review accountability are object references to Core Person objects: Owner (required) and Reviewer on Document, Checked By on Validation Run, Reviewer (required) on Review Cycle, and Approved By on Release Gate. One AQL query answers "which published pages does this person own, and which reviews are they behind on?" because the person is an object, not a string.
Coverage second. The Schema object type holds structured records of the LaunchPad schemas your documents cover (key, version, tier, category, object type count), and each Document links to one via the Applies To reference type. From any Schema object you can query back to every document that covers it, which gives you a coverage map of your library.
The Documented By reference type is also included as a general-purpose link from governance records to documents, available for your own extensions.
Common use cases
Documentation library governance. Track every page with an owner, an editorial status, and a 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 or platform capabilities. When the product changes, query which claims need re-verification, starting with the high-risk ones.
Review cadence management. Set a review cadence (Monthly, Quarterly, Biannual, Annual, Ad Hoc) per document and record each review cycle with a named reviewer and an outcome. No more guessing when a page was last checked, or by whom.
Release readiness tracking. Define release gates (blocking and non-blocking) that must be satisfied before documentation ships, each with a named approver. 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 parent document. When the UI changes, query which assets are now Outdated.
Audit trail for content accuracy. Every validation run records what was checked, when, by whom, and what was found. When someone asks "how do we know this page is correct?", you have the answer, with a person attached.
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 they contain, and whether they are ready to ship. Think of it as the governance layer that sits alongside your content, not inside it.