Content Lifecycle
The content lifecycle keeps public material from becoming silent institutional debt. A security lab site cannot rely on the assumption that readers understand which pages are current, which pages are examples, and which pages are reserved for later records. Every page needs a status, owner, review cadence, and correction path so stale material can be identified before it misleads researchers or vendors.
The lifecycle applies to policies, operations pages, tool pages, schemas, reports, examples, and advisory records. It does not require every page to be long. It requires every page to be useful for its state. An empty-state publication index is acceptable when it explains what will appear there, what is intentionally absent, and where the reader should go next.
States
| State | Meaning | Public Behavior |
|---|---|---|
| Active | Current public guidance or working tool surface | Indexed, linked, and included in review cadence |
| Empty State | Stable route with no public records yet | Indexed only when it helps users understand absence of records |
| Template | Structure used to prepare future records | Linked from templates and process pages |
| Example | Sanitized illustration without operational authority | Linked with clear non-authorizing language |
| Draft | Incomplete material not suitable for production publication | Must not be linked from production navigation unless intentionally noindexed |
| Deprecated | Replaced material retained for historical reference | Must point to replacement or removal rationale |
Review Cadence
Policies and operational pages should receive scheduled review even when no incident forces an update. Tool pages should be reviewed when browser APIs, input limits, or dependency assumptions change. Data schemas should be reviewed when validators or publication formats change. Advisory and report records should not be edited casually after publication; corrections should be explicit.
Review work should answer four questions. Is the page still authoritative for its stated audience? Does the page contain any unsupported promise or implied authorization? Does the page link to the correct controlling policy, contact path, or schema? Does the page still reflect the current implementation of the site or tool?
Retirement Rules
A page should be retired when it duplicates stronger content, describes an abandoned feature, or creates maintenance cost without user value. Retirement should not mean silent deletion if external users could have linked to the page. Prefer a redirect, a deprecated status page, or a changelog entry when removal affects public records.