How a product comes to exist
A team proposes
Everything starts as a file. To create a product, a team adds one entry to the catalog: who owns it, its stack, its criticality, its monthly budget. That is the whole request.
Tested rules judge the change
The policy pack checks the change against tested rules: names, labels, public exposure, the pipeline's components. A rule that fails says what is wrong, and often what to do instead, in words written for the person or coding agent who wrote the change.
Owners approve the intent
The catalog says who owns what. The gate approves the merge request only once current owners have approved it, and binds its own approval to the commit it checked; nobody's approval of their own change counts.
The budget becomes a limit
The monthly budget in the entry is a limit, not a note. Once the product exists, each merge request on its repository is planned and priced at the approval, and a status check keeps the merge closed while the plans add up to more than that budget. Raising it is another catalog merge request.
Pipelines build it
After the merge, a chain of pipelines reads the catalog and builds the product: its Google Cloud projects and identities, its repository from the golden path, its dashboards and its hostnames on the shared edge. No person runs a command.
The product is live
Once its projects are billed, which is a separate landing-zone merge request, the team has a repository whose pipeline already deploys, a hostname behind single sign-on, and dashboards that show its service and its cost.