Skip to content
Qtangl logo mark
Qtangl

Developer portal

Documentation contribution guide

How product, engineering, and security teams collaborate to keep docs current and trustworthy.

Last updated: 2026-06-09

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.

Engineer runbook

Use this checklist when changing product behavior that customers see in docs.

  • Narrative guide — add web/app/docs/guides/<slug>/page.tsx using GuidePageLayout; register in web/lib/docs/nav.ts.
  • API reference — add defineEndpoint(...) in web/lib/docs/endpoints/*.ts. Tenant/admin/public routes auto-render via [slug]/page.tsx; core PQC routes may need a static page under web/app/docs/reference/pqc/.
  • Run npm run check:docs, then npm run generate:docs-index and npm run generate:docs-export when nav or endpoints change.
  • Status policy — do not use pilot in nav or endpoint registries. Omit status or set ga. Use deprecated only when sunsetting an endpoint.

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.

Found an issue? Report documentation feedback