How one catalog file becomes a product
One file describes the product
The team adds products/shop.store.ordering.orders.yaml to the catalog: the owning team, the stack, the criticality, the recovery objectives and the monthly budget. The catalog's schema and lint check the file in the merge request's pipeline.
The owners approve
The catalog names the leads of every journey, domain and context, and the team of every product. The gate approves the request only once current owners have approved it, and binds its own approval to the commit it checked; neither the author's approval nor a committer's counts.
The platform derives the rest
After the merge, the catalog's pipeline starts a chain of Terraform roots that read it. The domain's project factory creates the product's two Google Cloud projects and their identities, operations creates its dashboards, and the domain's GitLab root creates the repository from the golden path. The hostname follows on the shared edge once the product's first pipeline has deployed it.
The merge request follows the work
One note on the merged merge request follows the chain as it runs: each pass with its time and link, the new repository's first pipeline, and the moment the product answers at its hostname behind single sign-on. A failure names its job and the next step. A new product runs only once its projects are billed, which is a separate landing-zone merge request within the billing account's project quota.
Retiring is the same file
Setting the product's status to retiring takes its services off the edge and down to zero instances, and keeps its data. After the entry's retirement date, removed destroys what the product runs and deletes its projects and its repository. Each change of status needs two approvers besides the author, and a removed name stays in the catalog as a tombstone, so it is never reused in its domain.