Every product's documentation is built from the same core set of sections, so a reader who knows one product's docs can predict where to find things in another.
Consistency is enforced, not optional. A product may add sections that it genuinely needs, but those additions are additive: a product never renames, restructures, or redefines a core section because a different shape "makes more sense" for it. Keep the core the same, and grow around it.
This page defines the shared core at the section (folder) level. To choose the type of an individual page, refer to Content types.
Every product includes at least these two pages, from its first release:
- Overview, which orients a new reader and routes them onward.
- Get started, which takes a new user from nothing to a first working result.
Beyond the required pair, use these standard sections whenever your product has the content they describe. Use the standard name so that readers and agents navigate every product's docs the same way.
| Section | What it contains | Related content type |
|---|---|---|
| Overview | Orients a new reader to the product and routes them onward. Required. | Overview |
| Get started | The shortest path from nothing to a first working result. Required. | Get started |
| Concepts | What the product's key ideas are and why they work the way they do. | Concept |
| Features | Groups the task and settings content for a major feature of the product. | How to |
| Guides | Task-focused pages for completing one specific job. | How to |
| Tutorials | End-to-end lessons where the reader builds a real project. | Tutorial |
| Examples | Complete, runnable samples that show how something is done. | None |
| Configuration | The settings, values, and options for a configuration-intensive feature. | Configuration |
| Reference | Complete, neutral lookup details such as parameters, values, and options. | Reference |
| API | The product's API documentation and command guidance. | API content strategy |
| Models | The available models and their details, for AI products. | Reference |
| Observability | Testing, metrics, analytics, and local development. | None |
| Best practices | Recommended patterns and guidance for using the product well. | None |
| Platform | Product-wide pages such as pricing, limits, changelog, betas, and known issues. | Changelog |
| Glossary | The product's defined terms. | Glossary |
- Make each core section a folder, even when it currently holds a single page. A lone
get-started.mdxbecomes aget-started/folder. - Place the core folders before any product-specific folders, in the order given under Core sections.
- Give every product a Platform folder that holds at least one page, so this section is present consistently rather than only on some products.
- Name any product-specific folder uniquely and clearly. A product-specific folder is additive: it adds to the core, and it never replaces or reshapes a core section.
- Add sections freely, but do not edit the core. If a core section does not fit your product as written, raise it through docs governance rather than renaming or restructuring it locally.
Audit the product against the core, then close the gaps:
- Rename non-standard folders to the standard names. For example, rename a
getting-startedfolder toget-started, and rename ahow-tofolder to the standardguides. - Fold loose files into their core folder. A single
concepts.mdxbecomes aconcepts/folder. - Pull core content up to the top level when it sits inside
platform/but belongs to a core section. - Create the core sections your product is missing.
- Keep useful product-specific folders, and confirm each one is uniquely named and additive.
The core applies across every product category, including Compute, Storage, AI, Media, and the vertical products. A category can share additional sections that its products all need. For example, AI products commonly add a Models section. As a product matures it keeps the same core and grows by adding sections, not by reshaping the core.