Documentation contribution guide

Ownership model#

• Product owns information architecture and release-level messaging.
• Engineering owns API accuracy, examples, and operational guidance.
• Security/compliance reviewers own trust and assurance statements before publication.
• Support owns triage of docs gaps discovered from customer tickets.

When a docs update is required#

• New endpoint, parameter, or behavior changes in existing contracts.
• Operational policy updates (versioning, rate limits, incident process, residency).
• Trust claims that affect procurement, legal, or security review outcomes.
• Any customer-facing workflow change that would alter runbooks or onboarding.

Review checklist#

• Technical accuracy validated against current implementation and tests.
• Examples use valid request and response shapes with realistic values.
• Role/permission statements match the RBAC reference matrix.
• Security and compliance claims are factual, dated, and non-promissory.
• Internal-only terms, secrets, and customer identifiers are removed.
• Cross-links to related docs pages are present and not broken.

Publish and maintenance cadence#

Merge docs updates with product changes whenever possible. For delayed updates, create a tracked follow-up task and target publication within one business day for operationally significant changes.

Related pages: changelog and RBAC reference.