Catalog
The Catalog is your inventory of what exists in your engineering organization: services, the teams that own them, the people on those teams, and the repositories behind them, plus the relationships between them.
Where Skills are the procedures you author, the Catalog is the structure agents reason over. When an agent needs to know who owns payments-api, which services depend on it, or which repository to check for a recent change, it reads the Catalog. Most of it arrives automatically from integrations you have already connected.
Find it under Engineering Context → Catalog in the sidebar.
Entity types
| Entity | What it represents | Key relationships |
|---|---|---|
| Service | A software service or application component | Depends on other services · owned by a team · has contributors |
| Team | An engineering team or squad | Has members · owns services and repositories |
| Person | A team member or on-call engineer | Belongs to teams |
| Code Repository | A repository from a code-hosting integration | Owned by a team · part of a service |
Each type has its own tab. A fifth tab, Other entities, holds anything that doesn't map to the four above, including Slack channels, ServiceNow configuration items, and any entity type your organization defines for itself.
Where entities come from
Most of the Catalog populates itself. When you connect an integration, Autoheal imports the entities it knows about:
| Integration | Contributes |
|---|---|
| GitHub | Repositories, services, teams, people |
| GitLab, Azure DevOps, Bitbucket | Repositories |
| PagerDuty | Services, teams, people |
| ServiceNow | Services, teams, people, configuration items (see Catalog Sync) |
| Datadog | Services, teams |
| Jira | Services, people |
| Slack | People, teams, channels |
Every entity records which integrations contributed to it, shown as Sources on its detail page. An entity described by several tools keeps all of them, so a service known to both PagerDuty and Datadog is one entity with two sources rather than two duplicates.
Keeping it current
Every source except ServiceNow re-syncs automatically once a day, staggered through the early morning (UTC) so no single tool gets hit by two syncs at once.
You can also refresh on demand without waiting for the next run:
- Repositories: Sync now pulls from every connected code-hosting integration at once.
- People: Refresh re-reads your identity sources.
- Other entities: refreshable kinds show a Refresh button and a last synced timestamp.
ServiceNow syncs on demand only, because a CMDB can hold tens of thousands of items.
Re-running a sync updates entities in place rather than duplicating them. Repository syncs also prune, so a repository deleted upstream is removed from the Catalog. The other sources only add and update, so an entity deleted in PagerDuty or ServiceNow stays until you remove it.
Creating and editing entities
You can author entities yourself where an integration doesn't supply them.
- Create is available for services and teams. Give the entity a title, and the identifier is generated for you, then fill in its properties and pick its owner or members.
- People come only from integration imports, so that a person in Autoheal always corresponds to a real account in your identity provider.
- Edit any entity to change its properties, labels, and relationships.
- Delete warns you first if other entities reference the one you're removing.
Curate with AI on the Catalog page lets you describe the change you want in plain English and have an agent make it, which is usually faster than editing entities one at a time.
Properties
Each entity type has its own fields. A service, for example, carries a description, a tier (tier-1 through tier-4), its primary language, and links to its repository and documentation. Integrations may add their own fields on top; those appear in a separate properties section named for that integration on the detail page so you can tell imported values from ones you set.
Labels are free-form key-value tags you can attach to any entity and filter on, which is useful for grouping that doesn't fit the built-in properties.
Relationships
Relationships are what make the Catalog a graph rather than a list. A service depends on other services; a team owns a service; a person is a member of a team.
Edit them from an entity's edit page, where each relationship is a picker over valid targets, single-select where only one target makes sense (a service has one owner team) and multi-select otherwise.
Some relationships carry their own details: a service's contributors record each person's role, and a team's members record when each person joined.
You can also point a relationship at an entity that doesn't exist yet. Autoheal records it as a soft link and resolves it automatically once something with that name arrives, so an import that references a team before the team is imported doesn't lose the connection.
Table and graph views
Every tab offers two views:
- Table: the scannable inventory. Search by name, filter by source integration, and page through results. Best for finding a specific entity or auditing what you have.
- Graph: the topology. Entities are nodes, relationships are edges; click a node to highlight what it connects to and open a side panel with its details. Best for understanding blast radius and ownership at a glance.
The Services graph draws dependency and ownership edges, Teams shows the services each team owns, and People shows team membership.
How agents use the Catalog
The Catalog is part of the built-in Autoheal context available to every agent, so you don't grant access to it the way you grant an integration. During a run an agent reads it to resolve ownership ("who owns this service, and what's their Slack channel?"), walk dependencies to reason about blast radius, and find the right repository for a service before checking recent changes.
This is why filling ownership gaps pays off quickly: an agent that can resolve a service to a team to an on-call person can route its findings itself instead of asking.