Content freeze checklist.

Freeze the launch-foundation docs posture without blocking safe fixes: inventory the public routes, confirm owners, resolve risk labels, and decide every unresolved claim before launch review.

Freeze Snapshot

Freeze levels: 4
Inventory areas: 8
Risk areas: 5
Story: DOCS-084

Freeze Levels

IA freeze

Docs lead for route or navigation changes.

Top-level sections, product hub structure, route naming, public navigation model, and redirects.

Allowed after freeze

Broken links, accessible labels, breadcrumb fixes, and clarifying copy that does not move routes.

Claim posture freeze

Product SME and docs lead for claim changes.

Maturity labels, compatibility rows, known limits, and evidence-backed product wording.

Allowed after freeze

Narrowing, removing, or relabeling risky wording when it reduces customer misunderstanding.

Release-reference freeze

Product SME, docs QA, and release owner.

API, CLI, configuration, SDK, error, limits, changelog, and release-note references.

Allowed after freeze

Corrections backed by source, generated output, release notes, or reviewer-run validation.

Known-limit coverage freeze

Product SME plus docs lead; sensitive reviewer when triggered.

Product limits pages, unsupported-scenario notes, and links from hubs, quickstarts, references.

Allowed after freeze

Adding a missing limit or stronger caveat when the current page would otherwise overstate behavior.

Content Inventory Checklist

Launch content inventory freeze checks
Inventory area	Owner	Freeze check	Evidence
Top-level IA and navigation	docs-lead	Every public section route is intentional, findable, and free of internal-only source or dev links.	Product and section routes
Product hubs and availability	product SMEs	Each product hub shows private-beta posture, public-beta date, maturity split, and next safe path.	Status dashboard
Quickstarts and tutorials	docs QA reviewer	Runnable pages retain smoke evidence, prerequisites, expected output, cleanup, and known limits.	Tutorials
References and compatibility	product SMEs	Reference items and compatibility rows match source, generated output, fixture, or reviewer record.	Compatibility
Known limits and unsupported paths	docs lead	Material unsupported behavior is linked from product hubs, quickstarts, references, and matrices.	Errors and limits
Evidence and claim governance	docs-product-lead	Risky claims have evidence, limits, reviewers, or a deliberate Verification Required boundary.	Evidence indexes
Community and support handoff	support reviewer	Public reporting, contribution, feedback, and triage copy avoids private repo paths and unsupported promises.	Community
Release notes and changelog	release owner	User-visible docs changes have a changelog entry, release-note link, or no-change rationale.	Changelog

Claim-Risk Checklist

Claim-risk freeze questions
Risk area	Freeze question	Required disposition
Product maturity	Does the page imply a broader release state than the status page or compatibility row?	Match the maturity label, narrow the wording, or block until product owner signs off.
Security/privacy	Does the page describe auth, secrets, tenant data, logs, traces, support bundles, or retention?	Add sensitive reviewer approval or remove the claim.
Support/operations	Does the page imply response time, escalation, monitoring, rollback, or production operation?	Link approved runbook/support scope or relabel as Verification Required.
Durability/availability	Does the page imply persistence, recovery, uptime, failover, replication, scale, or performance?	Tie to evidence and limits, or rewrite as a bounded local or preview behavior.
Compliance/legal	Does the page imply certification, regulated use, contractual coverage, or legal assurance?	Remove the claim unless legal/compliance review is recorded.

Unresolved Claim Disposition

Unresolved claim outcomes
Disposition	Use when	Required record
Accept	The claim has evidence, owner, last-reviewed date, limits, and required reviewer approval.	Evidence source, reviewer, date, and owning page.
Narrow	The claim is useful but currently too broad.	Rewritten claim, excluded behaviors, and reviewer who accepted the narrower wording.
Relabel	The claim is useful as a boundary but not approved as current behavior.	Maturity label, compatibility row, known limit, or Verification Required note.
Defer	The claim is not needed for launch foundation.	Owner, target date, follow-up work item, and route that no longer depends on it.
Block	The claim would mislead customers or hide a material known limitation.	Blocking owner, affected route, required reviewer, and next action.

Post-Freeze Change Rules

Allowed without reopening freeze

Typos, grammar, broken links, anchor fixes, and formatting corrections.
Build, test, metadata, accessibility, and responsive-layout fixes.
Corrections that weaken or remove an unsupported product claim.
Date, owner, or evidence-status updates that do not strengthen public claims.

Requires freeze owner review

New public routes, renamed routes, navigation changes, or redirect behavior.
Stronger product, security, privacy, support, durability, availability, scale, performance, legal, or compliance wording.
New examples, commands, compatibility rows, known-limit removals, or release-note claims.
Any change that turns Future, Preview Contract, Alpha, or Verification Required wording into current customer-facing behavior.

Freeze Exit Criteria

Inventory owners have reviewed their areas and recorded blockers, accepted risks, or no-change rationale.
Product hubs, status, compatibility, limits, evidence, quickstarts, references, operations, community, roadmap, and changelog routes have an accountable owner.
P0/P1 defects are fixed or block launch. P2/P3 issues have owner, target date, and accepted-risk rationale.
Unresolved claims are accepted, narrowed, relabeled, deferred, or blocked with reviewer evidence.
Final validation evidence names the commit or build, commands run, and remaining launch-watch follow-up.