catalog

The catalog repository is the source of truth for the whole platform: small YAML files that say which products, teams and people exist and who owns what. It runs nothing in the cloud itself. Its job is to check that every change to those files makes sense, and then, once a change is merged, to start the pipelines that make the real world match. The ideas behind it are on the catalog concept page; this page is about the repository.

What it is for

The catalog exists so that there is one place to change the organization, and one record of every change. A new product, a new team member, a raised budget or a retired product is a merge request here, approved by the people the catalog itself names.

What is in it

The hierarchy: one file per journey, domain and context, each named by its path and naming its leads.
Products: one file per product, with its team, criticality, data classification, recovery objectives, budget, stack and lifecycle.
Teams and people: who belongs to which team, in which role, and each person’s status.
The ownership model: ownership/protected-paths.yaml, which says who must approve which change, here and in every product repository.
Approved services: one file per Google Cloud service the platform has approved beyond the ones every product gets, such as Memorystore for Redis.
Tombstones: one file per removed product, so its name is never reused.
The schema and the checks: JSON Schemas for every kind of file, and the scripts that check the rules a schema cannot express, such as “a product’s team lives in the product’s context”.

How it connects

Nothing in the catalog reads anything else; everything else reads the catalog.

After a merge, the catalog’s pipeline starts the pipelines of landing-zone, operations and control-plane, in that order, and then landing-zone once more. Each one plans and applies its roots against the catalog’s new content. The reconcilers page explains the chain.
The gate reads the ownership model from the catalog’s protected main branch to decide whether a merge request anywhere has the right approvals.
golden-path’s template takes a product’s values from its catalog entry when it generates the product’s first commit.
The architecture catalog, the platform’s map of every product, receives a page of journeys, domains, teams and people from this repository’s pipeline.

Who changes it, and how

Anyone with access to the repository may propose a change. Who must approve it depends on what it touches: a product file needs its team or its leads, a budget rise a domain lead, a lifecycle change two people, and the structure two members of the platform team. The gate checks this on every merge request, and its approval is required to merge.

The pipeline does two things:

On a merge request, it validates every file against its schema, runs the consistency checks, checks that a lifecycle change carries the lifecycle label and moves through the states in order, and runs the checks’ own tests when they change.
On main, after a merge, it first lets a product whose lifecycle changed apply that change through its own pipeline, then starts the chain of reconcilers, publishes its page of the architecture catalog, and keeps a note on the merged merge request that follows the chain.

The catalog has no Terraform roots of its own and holds no identity that can change a cloud project. Its always-on cost is nothing.

Where it lives

In the catalog repository: