# Use Analyzed Source Context This page explains how to use source analysis results to create more accurate Technical Docs in Atloria. Reviewing the analyzed context before you generate or edit documentation helps you describe the right product surfaces, relationships, and user flows. ## Overview Source analysis gives you a structured view of the application materials that Atloria has identified. Use this context when you need to understand what documentation should cover before you begin writing. It is especially useful when a project contains multiple product areas, shared components, services, or documentation types. When you create Technical Docs, use the analyzed source context to confirm the scope of the material. For example, analysis can group findings by categories such as frontend, backend, database, API schema, configuration, documentation, and infrastructure. It can also identify relationships, such as one component rendering another component or a service calling an API. You should use the source context before selecting **Generate Documentation β†’** or editing generated content. This helps you avoid documenting assumptions, omitting dependent areas, or mixing user-facing instructions with implementation-focused Technical Docs. > πŸ“· _Screenshot pending: The Technical Docs area with options to review analyzed source context before generating documentation._ ## Prerequisites Before you start, make sure you have: - Access to the relevant Atloria project. - A completed or available source analysis for the project. - Permission to view **Technical Docs** and source-related information. - A clear documentation goal, such as documenting a product surface, a user flow, or a set of related entities. - An understanding of whether your content belongs in **User Docs** or **Technical Docs**. - Any existing documentation you want to compare against or import using **Or import existing documentation**. ## Step-by-Step Instructions 1. Open the project that contains the source analysis you want to use. 2. Select **Technical Docs** from the project documentation options. 3. Select **View Source** to review the source material associated with the project. 4. Select **Source** if you need to focus on the analyzed source context rather than generated documentation content. 5. Review the available analysis findings to identify the product area you need to document. 6. Check the analysis categories to understand where the selected area belongs in the project, such as frontend, backend, database, API schema, configuration, documentation, or infrastructure. 7. Review the identified entities to determine the type of item you are documenting, such as a component, hook, page, layout, route, context, provider, store, controller, service, repository, or middleware. 8. Review relationship findings to understand how the selected item connects to other items, such as **RENDERS**, **USES HOOK**, **USES CONTEXT**, **PROVIDES CONTEXT**, **CALLS API**, **IMPLEMENTS API**, **DEPENDS ON**, or **USES SERVICE**. 9. Select the relevant item or area in the source context to narrow the scope of your documentation. 10. Return to **Technical Docs** after you have identified the relevant context. 11. Select **Generate Documentation β†’** when you are ready to create documentation based on the reviewed context. 12. Review the generated documentation for alignment with the source analysis before you publish, export, or share it. 13. Select **Export Documentation** if you need to provide the completed documentation outside Atloria. > πŸ“· _Screenshot pending: The View Source area showing analyzed categories, entities, and relationships used to prepare Technical Docs._ ## Tips and Best Practices - Use the source analysis to define the documentation boundary before generating content. If the analysis shows a frontend component that calls an API and depends on a service, decide whether your document should cover only the component or the complete flow. - Follow the analysis organization when planning your content. Analysis may progress through categories such as frontend, backend, database, API schema, configuration, documentation, and infrastructure. Use this progression to identify related areas that may need cross-references. - Treat relationships as context, not as a substitute for a documentation purpose. For example, a **CALLS API** relationship can explain why two areas are connected, but your documentation should still focus on the user’s intended task or the technical topic you selected. - Keep documentation types separate. Use **Technical Docs** for implementation-oriented information and **User Docs** or **πŸ“‹ User Manuals** for instructions that explain what end users see and do. This prevents the dual-documentation-type issue of placing user-manual content beside technical material without a clear distinction. - Use **View Source** when generated content seems too broad, incomplete, or unrelated to your intended topic. Confirm the selected entities and relationships before generating again. - If you already have material to preserve, select **Or import existing documentation** before generating new content. This can help you compare existing coverage with what the analysis identifies. ## Related Pages - [Generate Technical Documentation](#) - [View Source Analysis Results](#) - [Use User Docs and Technical Docs](#) - [Import Existing Documentation](#) - [Export Documentation](#) - [Create User Guides](#) ## Troubleshooting ### You cannot find the area you need in the source context Select **View Source** again and review adjacent categories or related entities. The item you need may be represented as a related component, service, route, or context rather than as the product surface name you expected. ### Generated documentation covers the wrong topic Return to **Source** and narrow your review to the specific entities and relationships relevant to your documentation goal. Then select **Generate Documentation β†’** again after confirming the correct context. ### You are unsure whether to use User Docs or Technical Docs Use **User Docs**, **πŸ“‹ User Manuals**, or **User Guides** when you are writing instructions for people using the product. Use **Technical Docs** when the material needs to explain analyzed structure, relationships, or technical behavior.