---
title: Service Catalog — Reference
---

# Service Catalog (two dimensions)

Every service coulomb consumes or operates is classified along **two independent
dimensions**, so four classes fall out of their product:

| | **third-party** (not dev-responsible) | **first-party** (dev-responsible) |
|---|---|---|
| **cloud-hosted** (consumed) | SaaS / APIs — the classic [TPSC](/docs/tpsc) | a coulomb service deployed to a cloud |
| **self-hosted** (operated) | OSS coulomb runs (Gitea, Postgres…) | a coulomb service on coulomb infra |

- **Hosting** — `self_hosted` (coulomb operates the service) vs `cloud_hosted`
  (coulomb consumes someone else's running service).
- **Development** — `first_party` (coulomb is development-responsible) vs
  `third_party` (coulomb is not).

## Persistence

A common **`service_catalog`** core table holds the shared fields
(`slug`, `name`, `owner_or_provider`, `category`, `status`, `hosting_type`,
`development_type`, `maturity_level`). Dimension-specific data lives in 1:1
extension tables that **compose** — a self-hosted first-party service carries
both the self-hosted *and* first-party extensions:

| Extension | Keyed on | Holds |
|---|---|---|
| `service_third_party` | `development_type = third_party` | upstream packages, support/service contacts, source, license, pricing |
| `service_first_party` | `development_type = first_party` | internal dev repo (`managed_repos` FK), owning domain |
| `service_cloud` | `hosting_type = cloud_hosted` | GDPR maturity, DPA, ToS/privacy, data-processing regions, retention |
| `service_self_hosted` | `hosting_type = self_hosted` | three-helix instance/host, deployment & runbook refs, upstream OSS project |

`maturity_level` (1 · Core → 2 · Standard → 3 · Mature) tracks a service against
the [Service DoM](/policy/service-dom).

## API

- `GET /services/catalog?hosting_type=&development_type=&maturity_level=&status=`
  — filtered list; each row includes its applicable extensions.
- `GET /services/{slug}` — one service with extensions.
- `POST /services/catalog` — upsert by slug; pass `first_party.repo_slug` to link
  the internal dev repo.

The dashboard **Services** section renders three views over this catalog:
[Third Party](/tpsc), [First Party](/services/first-party), and
[Self Hosted](/services/self-hosted).

## Migration & back-compat

Existing TPSC catalog rows migrated into `service_catalog` as
`(cloud_hosted, third_party)`, reusing their ids so `tpsc_entries.catalog_id`
keep resolving. The `/tpsc/*` endpoints and `tpsc.yaml` ingestion are unchanged.