Sensitive claims review
Verification RequiredDOCS-087 records security, privacy, legal, support, operations, availability, durability, performance, scale, compatibility, and feedback claim review. No unapproved broad sensitive claim remains in the launch foundation when these limits and gates stay attached.
| Claim area | Required reviewers | Reviewed surfaces | Disposition | Limits to keep |
|---|---|---|---|---|
| Legal, contract, and compliance | legal reviewer, docs lead, product SME when product-specific | Terms, status, product hubs, compatibility matrices, limits, and roadmap review routes. | Accepted with limits. Do not publish compliance, certification, contractual, pricing, SLA, uptime, or agreement-changing claims without legal approval. | Keep customer agreements or beta terms as the controlling source, and keep docs examples from implying production, compliance, availability, or support commitments. |
| Security, auth, and secrets | security reviewer, privacy reviewer when data is involved | Tenancy and security, product references, support bundle privacy, operations runbooks, and support guidance. | Accepted with limits. Security-sensitive copy names exact auth modes and redaction boundaries instead of broad assurance language. | Keep API keys, mTLS trust files, bearer tokens, trusted headers, tenant isolation, secret handling, and vulnerability wording review-bound unless accepted for exact scope. |
| Privacy, telemetry, and redaction | privacy reviewer, security reviewer, support reviewer | Privacy, support bundle privacy, support, examples, page health, and future feedback surfaces. | Accepted with limits. Public docs use synthetic examples, require support-evidence redaction, and keep remote analytics plus page feedback unapproved for launch. | Do not publish customer data, credentials, raw payloads, retained telemetry, retention promises, cookies, remote tracking, or feedback intake without privacy/legal approval. |
| Support and operations | support reviewer, operations reviewer, docs lead | Support, operations index, product runbooks, troubleshooting, observability, and support bundle privacy. | Accepted with limits. Docs route readers to assigned private-beta channels, runbooks, and sanitized evidence without promising response windows or managed operations. | Keep escalation, response-time, retention, incident, operational-safety, and customer-handoff language tied to approved support paths. |
| Durability, availability, and recovery | operations reviewer, product SME, legal reviewer for commitments | Product hubs, evidence indexes, operator runbooks, compatibility matrices, and shared limits. | Accepted with limits. Current docs describe bounded local, WAL, segment, replication-status, and recovery evidence without SLA or no-loss commitments. | Do not publish failover, disaster recovery, high availability, zero downtime, no data loss, replicated-everywhere, or guaranteed retention claims unless evidence plus required review exists. |
| Performance and scale | product SME, docs QA reviewer, operations reviewer | Product references, configuration pages, known limits, status, examples, and evidence indexes. | Accepted with limits. Docs avoid benchmark, throughput, latency, tenant-count, and unbounded-scale claims beyond explicit configuration or request limits. | Keep performance and scale wording evidence-bound with method, environment, workload, version, raw results, date, owner, and known bottlenecks before publication. |
| Compatibility and competitive positioning | product SME, legal reviewer, docs lead | Compatibility, product compatibility matrices, limits pages, product hubs, and examples. | Accepted with limits. Compatibility rows separate supported, partial, unsupported, preview, future, and verification-required behavior without full-parity claims. | Avoid drop-in replacement, full compatibility, complete protocol support, competitor superiority, or equivalent-to wording unless product and legal reviewers accept the exact comparison. |
| Analytics, feedback, and reader signals | privacy reviewer, legal reviewer, docs platform reviewer | Privacy, page health, footer support links, and future feedback intake. | Accepted with limits. No third-party analytics tags, analytics cookies, remote telemetry collection, or customer-facing page feedback intake is approved for launch foundation. | Keep browser-local diagnostics local, and require vendor, disclosure, consent, retention, environment, and browser-coverage approval before enabling remote analytics or feedback. |
| Route | Boundary | Use when reviewing |
|---|---|---|
| Terms | Customer agreements, beta terms, and approved support paths control where they differ from docs examples or summaries. | Use when a docs page could imply contractual, production, support, pricing, availability, or compliance commitments. |
| Privacy | Docs examples stay synthetic, no third-party analytics tags or analytics cookies are enabled, and future feedback needs privacy/legal approval. | Use when a page touches telemetry, logs, traces, search, feedback, cookies, customer data, retention, or redaction. |
| Support | Private beta support uses assigned channels and sanitized evidence without publishing response-time or escalation commitments. | Use when a page directs product questions, docs gaps, operational evidence, or support handoff. |
| Support bundle privacy | Support bundles must minimize, redact, and route sensitive operational evidence through the required reviewer path. | Use when examples, runbooks, troubleshooting, or support records include diagnostics, logs, traces, payloads, customer identifiers, or topology. |
| Tenancy and security | Security concepts explain current auth and tenant boundaries without turning controls into broad security guarantees. | Use when docs mention auth modes, tenant visibility, trusted headers, bearer tokens, or current review gaps. |
| Shared errors and limits | Common error, retry, unsupported behavior, request-size, and product-specific limits stay near claim-sensitive references. | Use when docs mention unsupported scenarios, retry guidance, fixed limits, and product-specific references. |
Do not use production-ready, enterprise-grade, mission-critical, or fully supported wording because it would overstate private-beta launch posture.
Use the route maturity label, product status, evidence link, and known limit instead.
Do not publish SLA, zero downtime, high availability, no data loss, guaranteed retention, or replicated-everywhere wording without operations evidence plus legal review.
Describe the exact local, WAL, segment, replication-status, or recovery behavior and name what remains verification-required.
Avoid secure, encrypted by default, isolated, compliant, certified, audit-ready, or regulator-ready wording without exact control evidence and required reviewer approval.
Name the specific auth, redaction, tenant-boundary, or approval gate that is currently documented.
Do not use drop-in replacement, fully compatible, better than, cheaper than, or equivalent-to language without scoped comparison evidence and legal review.
Use compatibility rows with explicit supported, partial, unsupported, preview, future, and verification-required states.
| Work item | Owner | Disposition |
|---|---|---|
| DOCS-088 | product SMEs and docs lead | Known-limit link completeness is recorded separately. DOCS-087 accepts the claim posture, not every required cross-link. |
| DOCS-090 | docs QA reviewer | Browser, device, navigation, search, code-block, accessibility, responsive, and route-smoke validation remain launch QA. |
| DOCS-091 and DOCS-092 | support, docs, privacy, and platform owners | Post-launch triage and public page feedback intake remain open. Feedback controls stay hidden until approved routing, retention, and browser coverage exist. |
| DOCS-094 and DOCS-107 through DOCS-114 | launch-review owners | Verification Required label disposition remains tracked separately for final launch-review closure. |