Post-launch triage

Verification Required

Keep launch feedback moving.

DOCS-091 defines how support reports, issue templates, no-result searches, broken journeys, stale-page signals, release-doc updates, and public feedback intake move through the first 30 days after the public launch foundation.

Triage Summary

Signal sources: 8
Launch watch: 30 days
Severity levels: 4
Feedback controls: Intake route available

Signal Sources

Post-launch docs triage signal sources
Signal	Route or artifact	Owner	Triage use
Support reports	Support	support reviewer	Classify customer-reported docs gaps, product questions, redaction needs, and launch-impacting confusion.
Public-safe issue templates	Issue templates	docs product lead	Collect route, product, content type, observed problem, expected outcome, evidence, and impact without exposing private source links.
No-result searches	Page health	docs platform reviewer	Find missing keywords, poor route titles, broken product facets, and docs gaps readers cannot discover.
Broken journeys	Page health	docs QA reviewer	Catch missing routes, invalid entry paths, confusing redirects, and dead-end navigation after launch.
Stale-page signals	Page health	docs lead	Prioritize pages whose review cadence is due or stale while launch feedback is still fresh.
Release-linked docs changes	Changelog	release owner	Connect triage outcomes to docs-impact entries, limitation changes, claim-status changes, and migration notes.
Validation failures	`validate:links:strict`, `validate:seo-crawl`, and `validate:llms`	docs platform reviewer	Treat broken internal links, unapproved external failures, missing route manifests, and generated asset drift as launch hygiene signals.
Public feedback intake	Feedback	support, privacy, and docs platform	Route docs gaps, product questions, sensitive evidence, and launch-impacting reports through approved intake paths.

Cadence

Launch triage cadence and required actions
Window	Cadence	Owner	Required action
Before launch handoff	One setup pass before go-live	docs product lead	Seed the triage log from DOCS-104, confirm support and docs owners, and capture the launch commit, route count, validation commands, and accepted risks.
Launch day	Same-day watch	support reviewer and docs QA reviewer	Scan support reports, issue templates, page-health signals, and validation output; escalate any P0 or P1 before routine backlog work.
First business week	Daily scan	docs triage lead	Classify new signals, merge duplicates, assign owners, and record whether each issue is fixed, accepted with limits, deferred, or blocked.
Days 8 through 30	Weekly triage at minimum	support and docs	Review open P1/P2 items, no-result searches, broken journeys, stale pages, release-note triggers, and product-owner decisions.
After day 30	Normal docs operations	docs lead	Move unresolved P2/P3 work into the normal backlog and keep P0/P1 launch issues on the release watch until closed or owner-accepted.

Severity And Response

Severity rules for post-launch docs issues
Severity	Examples	Response expectation	Escalation
P0	Docs site unavailable, public route exposes private systems or credentials, primary navigation is unusable, or support/legal/privacy safety is at risk.	Immediate owner assignment during launch watch; fix, rollback, hide, or block launch state before routine triage continues.	Release owner, docs lead, security/privacy/legal as applicable, and product owner.
P1	Core product hub, quickstart, reference, known limit, status, support, or legal page materially misleads or strands a reader.	Acknowledge and classify within one business day; fix, relabel, route to owner acceptance, or file a launch blocker within two business days.	Docs lead, docs QA reviewer, affected product SME, support reviewer, and release owner.
P2	Secondary page gap, unclear search keyword, minor example polish, stale review signal, low-risk broken journey, or non-blocking copy issue.	Review in the next weekly triage, assign an owner and target date, and keep the accepted launch posture visible.	Owning docs lead, docs platform reviewer, product SME, or support reviewer.
P3	Optional visual polish, alternate wording, non-critical taxonomy suggestion, or backlog-quality improvement.	Move into normal docs backlog unless it combines with other signals into a higher-severity issue.	Docs product lead only when backlog priority or ownership is unclear.

Owner Lanes

Post-launch triage ownership
Owner	Owns	Response
Docs triage lead	Weekly agenda, severity calls, duplicate merging, owner assignment, and final triage notes.	Keeps a dated issue list with status, owner, severity, evidence, next action, and accepted-risk notes.
Support reviewer	Customer-reported docs gaps, redaction expectations, support impact, and safe acknowledgement path.	Routes product questions to support while keeping docs corrections separate from customer commitments.
Docs QA reviewer	Broken journeys, code blocks, examples, responsive findings, browser evidence, and route-smoke follow-up.	Confirms whether the signal is reproducible, isolated, and covered by existing validation or DOCS-100.
Docs platform reviewer	Search metadata, route manifests, generated assets, links, SEO crawl controls, and page-health instrumentation.	Fixes platform regressions or records whether a signal is expected, local-only, or owner-accepted.
Product SME	Product behavior, maturity labels, compatibility rows, known limits, and claim disposition.	Accepts, rewrites, narrows, defers, or blocks product-specific wording before stronger public claims ship.
Sensitive reviewer	Security, privacy, legal, compliance, support, availability, durability, scale, and performance-sensitive reports.	Keeps sensitive issues private, redacted, and blocked from public wording until the required reviewer accepts them.
Release owner	Launch watch decisions, release-note triggers, changelog entries, accepted risks, and go/no-go evidence.	Decides whether an unresolved P0/P1 blocks launch state or is accepted with explicit owner signoff.

Required Outputs

Outputs required from launch triage
Output	Owner	Required by
Triage log	docs triage lead	Every launch-watch meeting or weekly triage pass must leave a dated record of new, changed, and closed items.
Customer-safe acknowledgement	support reviewer	Every externally reported issue gets a safe response path that avoids private source links and unapproved product commitments.
Fix, accepted risk, or deferral	owning reviewer	Every P0/P1/P2 item gets a disposition, owner, target date, and evidence link before it leaves triage.
Release-docs update	release owner and docs lead	Launch-significant limitations, maturity changes, migration notes, or support-policy changes are reflected in changelog or release-note artifacts.

Remaining Owner Work

Follow-up work outside DOCS-091
Work item	Owner	Disposition
DOCS-092	support, privacy, and docs platform	Available. Use the public feedback route for approved issue-template, support, redaction, page-health, privacy, retention, acknowledgement, triage, and browser coverage boundaries.
DOCS-100	docs QA reviewer	Release-candidate full-route smoke coverage remains the browser automation expansion for launch watch.
DOCS-103	operations docs owner	Available. Use the launch observability operations view for deployment health, 404s, failed searches, client errors, page-load regressions, feedback signals, watch cadence, and escalation paths.
DOCS-104	docs product lead and release owner	Final launch acceptance still ties exact build, validations, reviewer signoffs, unresolved risks, and launch-watch plan together.