How Cortex handles data modeling
Cortex is built to mirror how your organization actually works. You get the flexibility to model your business logic across your data, and the structure to make sure that logic stays consistent everywhere it appears so your workspace reflects reality instead of forcing your team to work around it. Cortex solves for this by giving you the flexibility to mirror your unique business logic across your data, and the structure to persist that logic everywhere:- Foundational, configurable data models. A strong starting point you can shape to fit your environment.
- Available, extensible integrations. Connect the tools you already use, and extend them as your needs grow.
- Complete, customizable experience. A polished workspace out of the box, ready to be tailored to your team.
Connecting your data
Connecting your data in Cortex comes down to three building blocks: entities, catalogs, and integrations. Together, they determine what lives in your workspace and how it stays accurate over time. Entities are the foundation. An entity is an object that represents a software construct such as a service, a piece of infrastructure, a team, or anything else worth tracking. Entities are defined in YAML, can pull in data from your integrations, can have dependencies, can be organized into hierarchies, and can connect to other entities through entity relationships. You can also enforce standards across them using Scorecards. Catalogs are how you organize entities into meaningful groups. A catalog is a defined selection of entities used to track and store information about the components that make up your infrastructure. Integrations are how the data flows in. Cortex supports a broad set of integrations that pull live data from the tools your team already uses, creating a single pane of glass across your engineering ecosystem.Want to learn more? Check out the Cortex Academy course on Catalogs, Entities, and Relationships.
Cortex data concepts reference table
Learn about the basic data concepts for Cortex below.| Concept | Definition |
|---|---|
| Team | A group of humans responsible for something |
| Service | A running technical component (API, job, infra service) |
| Domain | A foundational grouping layer that represents a logical or functional area of your organization. Domains form the base hierarchy that organizes entities under stable, high-level boundaries. Each domain reflects a cohesive area of ownership, business function, or technical responsibility. |
| Custom entity | Any other trackable thing - ML models, Clients, environment, release, Products. Use this when “service” doesn’t fit. |
| Catalog | A folder-like visual container, for UI organization only |
| Group | A logical collection for search, filtering, and reporting—similar to a label or tag |
| Dependency | One entity relies on another; enables impact analysis and notifications |
| Ownership | The accountability link between a team and entity |
| Entity relationship | The generic link between entities |
| Hierarchy | Parent-child or part-of structure; enables inheritance ownership |