# Explore Entities and Relationships Use the product model in **Technical Docs** to examine the entities that make up your application and the relationships between them. This helps you validate that technical documentation reflects how your product is actually structured and connected. ## Overview Technical documentation is most useful when it explains more than isolated files or features. The product model helps you explore the important parts of an application—such as components, pages, layouts, services, repositories, stores, hooks, and routes—and understand how they relate to one another. When you open **Technical Docs**, you can use the entity explorer to find a specific entity and review its connections. For example, you may want to confirm that a component renders another component, that a page uses a hook, that a service calls an API, or that a repository queries a model. Reviewing these relationships is a practical way to check whether generated or imported documentation describes the real technical design. The model supports several types of entities, including **COMPONENT**, **HOOK**, **PAGE**, **LAYOUT**, **ROUTE**, **CONTEXT**, **PROVIDER**, **STORE**, **CONTROLLER**, **SERVICE**, **REPOSITORY**, and **MIDDLEWARE**. It also organizes findings into categories such as **FRONTEND**, **BACKEND**, **DATABASE**, **API SCHEMA**, **CONFIG**, **DOCUMENTATION**, and **INFRASTRUCTURE**. > 📷 _Screenshot pending: The Technical Docs screen showing the entity search field and the product model tree._ ## Prerequisites Before you begin, make sure that: - You have access to the relevant project in Atloria. - Your project contains technical documentation or product-model information to review. - You can open the **Technical Docs** area for the project. - You know the feature, screen, service, or technical concern you want to validate. - If documentation has not yet been created, you have generated it using **Generate Documentation →** or imported it using **Or import existing documentation**. ## Step-by-Step Instructions 1. Open your project’s **Technical Docs** area. Start from the project where you want to validate documentation. Select **Technical Docs** to work with the project’s technical documentation and product model. Depending on the state of your project, you may see options such as **Generate Documentation →**, **Or import existing documentation**, or **View Your Documentation →**. Generate or import documentation first if there is no model available to explore. 2. Locate the entity search field. In the entity explorer, select the field labeled **Search entities…** or **Search entities...**. The label may appear with either a typographic ellipsis or three dots. Enter a name or keyword related to the entity you need to inspect. For example, search for a page name, component name, service, hook, or store. Searching is especially helpful in larger projects where manually expanding categories would take time. 3. Select the entity you want to inspect. Choose the matching entity from the available results or from the product model tree. The model may organize entities by technical area, such as **FRONTEND**, **BACKEND**, **DATABASE**, **API SCHEMA**, **CONFIG**, **DOCUMENTATION**, or **INFRASTRUCTURE**. Use these categories to narrow your review: - Review **FRONTEND** for user-facing components, pages, layouts, hooks, contexts, providers, and stores. - Review **BACKEND** for controllers, services, repositories, and middleware. - Review **DATABASE** when you need to confirm model or data-access relationships. - Review **API SCHEMA** when validating how APIs are described across the application. 4. Review the entity type. Confirm that the selected item is classified correctly. For example, a reusable visual element should normally appear as a **COMPONENT**, while navigation-level content may be a **PAGE** or **LAYOUT**. Application logic may appear as a **HOOK**, **SERVICE**, **CONTROLLER**, or **REPOSITORY**. Correct classification matters because it gives readers context. A relationship from a **PAGE** to a **COMPONENT** means something different from a relationship between a **SERVICE** and a **REPOSITORY**. 5. Examine the relationships connected to the entity. Review the links shown for the selected entity. The product model can represent relationships such as: - **RENDRERS** — a component renders another component. - **USES HOOK** — an entity uses a hook. - **USES CONTEXT** or **PROVIDES CONTEXT** — an entity consumes or supplies shared context. - **USES STORE** or **DISPATCHES ACTION** — an entity interacts with application state. - **CALLS API** or **IMPLEMENTS API** — an entity consumes or provides an API. - **DEPENDS ON** — an entity relies on another entity. - **USES SERVICE** or **INJECTS** — an entity uses a service or dependency. - **QUERIES MODEL** — an entity accesses a data model. Check that each relationship tells a meaningful story about the selected entity. For example, a frontend component may **USES HOOK** and **CALLS API**, while a controller may **USES SERVICE**, and a repository may **QUERIES MODEL**. 6. Trace the relationship in both directions. Do not validate only one connection. Follow the connected entities to check whether the documented flow remains consistent. For instance, if a page is shown as using a component, confirm that the component is connected to the expected hook, context, store, or API behavior. This is useful for identifying incomplete documentation. A technical explanation may mention an API call, but the model can help you confirm which component, hook, or service initiates that call. 7. Compare the model with your technical documentation. Open the relevant technical documentation content and compare its explanations with the entity types and relationships you reviewed. Look for missing dependencies, incorrect ownership, or vague descriptions of how parts work together. If you are reviewing generated documentation, use the model as the grounding source for your validation. If you need a different presentation, use the available **StyleSelector** options before generating documentation again. You can also select **Export Documentation** when you need to share the reviewed documentation outside Atloria. > 📷 _Screenshot pending: A selected entity showing its type and relationship links, such as USES HOOK, CALLS API, or QUERIES MODEL._ ## Tips and Best Practices - **Start with a user-facing entity.** Begin with a **PAGE**, **LAYOUT**, or **COMPONENT** when validating documentation for a feature. This gives you a clear entry point, then lets you trace toward hooks, stores, APIs, services, and data access. - **Use relationship verbs as validation questions.** Treat each relationship as a question: “Does this component really **RENDRERS** this child component?” “Does this service actually **CALLS API**?” “Does this repository **QUERIES MODEL**?” This makes documentation reviews more specific and repeatable. - **Check category boundaries.** A complete technical explanation often crosses categories. For example, a **FRONTEND** entity may call an endpoint described in **API SCHEMA**, which is implemented through **BACKEND** services and connected to **DATABASE** entities. - **Distinguish implementation relationships from general dependencies.** Prefer precise relationships such as **USES HOOK**, **USES SERVICE**, or **QUERIES MODEL** when they are available. Use **DEPENDS ON** for a broader dependency that does not fit a more specific relationship. - **Review the full chain, not just one link.** A single relationship can look correct while the overall flow is incomplete. For example, a component may call an API, but documentation should also explain the service or controller that implements the corresponding behavior where relevant. - **Regenerate when the model changes.** If your application structure has changed, generate updated documentation using **Generate Documentation →** before relying on it for a review. A model-based review is most valuable when the documentation represents the current project. ## Related Pages - [Generate Technical Documentation](#) - [Import Existing Documentation](#) - [Choose a Documentation Style](#) - [Export Documentation](#) - [Use API Explorer](#) ## Troubleshooting ### I cannot find the entity I need Use **Search entities…** and try a shorter or more distinctive part of the name. If no result appears, check whether you are working in the correct project and whether technical documentation has been generated or imported. ### The relationships do not match what I expected Review the connected entities and their types before concluding that the documentation is incorrect. A relationship may be represented through an intermediate entity—for example, a component may use a hook that calls an API rather than calling the API directly. Trace the full chain to validate the documented behavior. ### I only see options to generate or import documentation Your project may not yet have documentation available to explore. Select **Generate Documentation →** to create documentation from the project, or select **Or import existing documentation** to bring in existing material. After documentation is available, return to **Technical Docs** and search for entities.