The catalog data model

Every IDP has a catalog. The catalog is the data model the platform uses to talk about your engineering org. Get it right and every screen in the app — scorecards, dependency graphs, on-call routing, deployment dashboards — falls out of it naturally.

Six entity kinds

The shape mirrors Backstage’s entity model because the model has converged across IDPs. If you’re moving off Backstage, the entity-kind mapping is 1:1; only the field names differ.

Hierarchy

Domains contain Systems. Systems contain Components, APIs, and Resources. Teams own Components, APIs, and Resources directly (not Systems or Domains — those are organizational, not operational).

Domain ── contains ──> System ── contains ──> Component
                              ├── contains ──> API
                              └── contains ──> Resource

Team ── owns ──> Component
     ├── owns ──> API
     └── owns ──> Resource

A component can belong to multiple systems (a shared library component might land in three product systems); an API is owned by exactly one team but consumed by many.

Dependency edges

Cross-entity dependencies are first-class — they’re not derived from imports or call traces (though MarBoba can auto-detect and suggest edges from a project’s package.json / go.mod / OpenAPI consumers, which you then review).

An edge connects two entities and carries an optional kind (runtime, build-time, data) and blastRadius (high, medium, low). High-blast-radius edges paint red on the resource graph and raise the approval requirement on agent actions that touch them.

Per-entity scorecards

Scorecards live alongside the catalog — they’re not a separate inventory.

Each scorecard has:

• Rules — atomic checks (e.g., “has a connected runbook”, “has a primary-team owner”, “has a verified domain”). Three built-in rule types: presence, threshold, and custom-callable. Rules are weighted; the score is a weighted average.
• Tier thresholds — bronze / silver / gold (pre-2026 docs call these levels).
• Exemptions — per-(scorecard, rule, entity) opt-outs with a reason and an optional expiry. Exempted rules neither help nor hurt the score.
• Initiatives — time-bound campaigns bundling scorecards + a target tier. Renders a per-entity leaderboard for engagement.

A score is computed at scorecard-evaluation time and cached. The cache refreshes automatically when underlying state changes (a runbook gets deleted, an entity’s lifecycle flips, etc.).

How the data flows

There’s intentionally no second model. Whatever you create with the wizard, the API, Terraform, or the CLI all lands in the same catalog and surfaces in the same screens.

Versioning + drift

The catalog tracks two kinds of “this was the truth as of”:

1. Catalog drift — when the deployed reality (a config in a live environment) doesn’t match what the catalog says. Drift detection records a snapshot each time it runs.
2. Workload spec drift — when a project’s Workload Spec (YAML in the repo) doesn’t match what’s actually deployed. The Workload Spec is the declarative deploy primitive; drift detection is the reconciliation gap.

Both surface in the per-project Drift tab.

See also

• Plan tiers — what entity-count caps each plan enforces.
• How agent actions work — the two-person approval framework for catalog operations.