Summary
Use this guide when writing or editing docs so the public site sounds like one product, not a pile of unrelated pages.Who this is for
Internal contributors maintaining the docs site and content standards.Writing rules
- write in active voice
- prefer plain English before technical detail
- explain the user-facing meaning before implementation detail
- keep sentences concrete and operational
- avoid vague AI-marketing filler
Product language preferences
- prefer organization over workspace
- prefer communications for the unified operating surface
- use campaign run when you mean an execution event, not the reusable campaign definition
- use public report for tokenized shared analytics links
Tone rules
- sound like a confident product guide, not a legal document
- do not overclaim features that are not fully public or stable
- do not teach transitional route structure as if it is the long-term model
- use “simple version” callouts only where they genuinely reduce confusion
Avoid these patterns
- “This page will explain…”
- filler that repeats the title without adding meaning
- internal engineering jargon when a customer-facing term is available
- route-heavy instructions when the stable product area is more important