# Documentation Strategy URL: /documentation-strategy Type: concept Description: How Stylo documentation is organized for customers, operators, and machine-readable retrieval. Keywords: documentation, strategy, llms.txt, retrieval, style guide Use this page to understand how the Stylo docs are structured and what they are meant to do. This is the orientation page for the documentation system itself, not a product setup guide. What the docs are for [#what-the-docs-are-for] The Stylo docs have three jobs: 1. Help a new customer set up the product in a practical order 2. Help operators and admins run Stylo safely once workflows are live 3. Give retrieval systems and other AI tooling a stable, machine-readable product corpus That means the docs are part of the product surface. They are not only reference material. They also guide rollout, operational review, and AI-safe configuration. Who the docs are written for [#who-the-docs-are-written-for] The current docs are designed for three main reader groups: * Support leaders and workspace admins who configure integrations, knowledge, access, and automation * Agents and reviewers who need to understand how assist, approvals, and response workflows behave * Retrieval systems and AI tooling that consume the docs through stable pages and text exports How the docs are organized today [#how-the-docs-are-organized-today] The docs corpus is structured around the main customer workflows in Stylo: * **Getting Started** for first-run workspace setup * **Using Stylo** for assist, settings, integrations, and knowledge * **Response Workflows** for response automation * **Workflow Builder** for broader workflow automation * **Operations** for execution review and diagnostics * **Trust** for access, credentials, and content handling * **Supporting Guides** for troubleshooting and shared terminology This structure is meant to help customers move from setup to controlled automation without jumping between unrelated concepts on the same page. What good Stylo docs should do [#what-good-stylo-docs-should-do] Each page should help the reader answer a real operational question quickly. Good pages in this docs set should: * Start with the outcome or task the feature supports * Stay focused on one main concept or workflow * Use the real product terms consistently * Show where a feature appears in the product * Explain boundaries, failure cases, or escalation paths when they matter * Link to the next useful page when the follow-up step is clear What the machine-readable outputs provide [#what-the-machine-readable-outputs-provide] The docs app currently exposes two machine-readable exports: * [`/llms.txt`](/llms.txt) for a navigable page index with recommended starting pages * [`/llms-full.txt`](/llms-full.txt) for a single-file export of the full docs corpus These exports matter because Stylo documentation is also meant to work well for retrieval systems, crawlers, and other AI tools that need a cleaner text representation than the rendered site alone. How `llms.txt` is organized [#how-llmstxt-is-organized] The current `llms.txt` route includes: * A short corpus description * A list of recommended starting pages * A full page index * Links to both machine-readable exports Today, the recommended starting pages are: * [Getting Started](/getting-started) * [Assist](/assist) * [Brand Settings](/brand-settings) * [Knowledge Base](/knowledge-base) * [Response Workflows](/response-workflows) * [Documentation Strategy](/documentation-strategy) How `llms-full.txt` is organized [#how-llms-fulltxt-is-organized] The `llms-full.txt` route exports the full page corpus as one text file. Each page section includes: * The page title * Its canonical path * Its description when available * The processed page text This makes the corpus easier to ingest for systems that prefer one complete document instead of a page-by-page crawl. Writing standards for this docs set [#writing-standards-for-this-docs-set] The authoritative rules for voice, structure, terminology, components, and frontmatter live in the **docs style guide** (`apps/docs/STYLEGUIDE.md`). Every page is held to it, and CI enforces the mechanical parts. In short, Stylo docs follow a consistent pattern: * Lead with the user outcome in the first paragraph * Prefer short sections and strong headings * Keep examples concrete and support-oriented * Avoid vague feature claims that are not grounded in the product * Preserve stable slugs and titles where possible * Avoid duplicate pages that compete for the same topic Current operating principle [#current-operating-principle] Stylo documentation should stay close to the product that exists today. If a behavior is unclear, the docs should not guess. They should wait for product confirmation or carry a clear docs clarification note until the behavior is confirmed. Related [#related] * [Getting Started](/getting-started) * [Glossary](/glossary) * [Troubleshooting](/troubleshooting)