Glossary

Airframe uses a few dozen terms that come from Google Cloud, from GitLab, from Terraform or from the platform itself. Each one is explained here in plain words, in alphabetical order, with a link to the page that goes deeper where there is one. If a page uses a term you do not know, it should be here.

Architecture catalog

One website that maps every product: its services, the events it publishes and consumes, its owners, its runbook and its decisions. Each repository publishes its own part when a change merges, and the map rebuilds itself. It is built with EventCatalog, at catalog.projectairframe.dev, and is not the same thing as the catalog, from which it takes its list of products. See the architecture catalog.

Attestation

A signed statement that something happened to a specific container image. Once the trusted builder has built an image from an approved commit, a separate signing identity, which only the executor may use, signs a build attestation after the executor has checked the build against Cloud Build’s own record; promoting the image toward production adds a second one. See zero standing privilege.

Binary Authorization

A Google Cloud service that decides, when a service is deployed, which container images may run. In a billed product’s production project, its policy admits only an image that carries both attestations. A service has to opt in; every service deployed through the golden path’s Cloud Run module does.

Catalog

The git repository of small YAML files that describes the organization: its journeys, domains and contexts, its teams and people, and its products. It is the single source of truth: everything else on the platform is derived from it. See the catalog.

CODEOWNERS

A file in a GitLab repository that names whose approval each path needs. On Airframe a product repository’s CODEOWNERS file is written once, when the repository is made. Only the catalog’s own file is rendered from the catalog’s ownership model and checked against it, after every catalog merge and every day. Either way, the gate reads the model itself. See the catalog.

Coding agent

An AI assistant that writes and changes code. On Airframe, a coding agent contributes through merge requests under exactly the same checks as a person, and only a named person who did not write a change can give the approval that lets it merge. See agent-ready.

Component

A reusable piece of pipeline, published by the control-plane repository: for example, the one that validates a change or the one that applies Terraform. A product’s pipeline file may include only these components. See policy as code.

Context

The level of the catalog below a domain: a group of closely related products and the teams that build them, such as ordering in the domain store. Every product and every team belongs to exactly one context. See the catalog.

Domain

The level of the catalog below a journey, such as store in the journey shop. A domain has leads, and some changes need one of them, for example raising a product’s budget. See the catalog.

Drift

A difference between what the code says and what really exists in the cloud, usually because something was changed outside a merge request. A scheduled plan of every root finds it each day and opens an issue for the root that drifted. See drift.

Edition

One of the platform’s two copies of its shared infrastructure: production and non-production. Each has its own network, its own place to store Terraform state and its own perimeter. A product gets one project in each.

Executor

The trusted pipeline that plans a product’s changes, and builds its previews, with the product’s own short-lived identities. It runs on the platform’s trusted runner, and only the gate can start it, when a merge request is approved. See the gate and the executor.

Gate

The service that judges a merge request. It checks that the change’s current owners, as the catalog names them, have approved it, then adds its own approval and starts the executor. It also fails any pipeline that still uses a revoked release. See the gate and the executor.

Golden path

The recommended way to build a product: a template that generates a new product’s repository for Java, Node or Python, and Terraform modules that encode the platform’s patterns. It is a default, not a requirement. See any stack.

Journey

The top level of the catalog: a broad area of the organization’s business. The demo organization has three, shop, fulfil and settle, each containing domains. See the catalog.

Merge request

GitLab’s proposal to change a repository: a branch with its commits, the checks that run on it, the discussion and the approvals. On Airframe every change, to a product or to the platform itself, is a merge request. See a change’s path.

Module

A reusable piece of Terraform code from the golden-path repository, such as a Cloud Run service or a database, that a product can use instead of declaring every cloud resource itself.

Observability

Being able to see what a running product does, through its logs, metrics and traces. On Airframe they travel to one Grafana Cloud stack, where every product gets dashboards and alert rules from its catalog entry. See observability.

Ownership model

The catalog file ownership/protected-paths.yaml, which says whose approval each kind of change needs, in a product’s repository and in the catalog itself. The gate reads it directly on every merge request, from the catalog’s protected main branch. See the catalog.

Perimeter

A VPC Service Controls boundary around a group of projects, meant to stop data from leaving them through Google’s APIs. Airframe’s perimeters run in dry-run mode today: they record what they would block, and block nothing.

Pipeline

The set of automated jobs GitLab runs for a commit, such as the checks on a merge request or the plan and apply on the main branch. A job is one step of a pipeline.

Plan and apply

Terraform’s two steps. A plan works out what a change would do to the real infrastructure without doing it; an apply does it. On Airframe, plans run once a merge request is approved, and applies run only after the merge, on the protected main branch. See the gate and the executor.

Policy pack

The set of tested rules, written for Open Policy Agent, that checks every change to a product’s Terraform code, pipeline file and declared Dockerfiles. A rule either denies a change, which stops it, or warns about it, which today holds nothing back. See policy as code.

Preview

A short-lived copy of a product, built for one merge request so that reviewers can try the change, with its own hostname. It is destroyed when the merge request is merged or closed, or when its time to live runs out, whichever comes first. See previews.

Privileged Access Manager grant

Temporary access that a person requests, with a reason, through Google Cloud’s Privileged Access Manager. A grant of administrative roles needs another platform member’s approval and lasts at most two hours; every grant is in the audit log. See identities and access.

Product

A piece of software that one team owns and runs, such as the demo organization’s orders service. It is declared by one file in the catalog, and gets its own projects, repository, dashboards and hostname. See the catalog.

Protected main

A repository’s main branch, protected in GitLab so that changes reach it only through an approved merge request. Only a job on a protected branch can obtain a product’s identity that applies changes.

Ready output

A small document the project factory publishes for each product once its projects exist: for each edition, the project, the plan and apply identities and the places for Terraform state. A product’s own roots, and the platform’s later roots, read it instead of guessing. See reconcilers.

Reconciler

An automated pipeline job that reads the catalog and makes something real match it: GitLab, Google Cloud projects, groups or dashboards. Nothing a reconciler creates is edited by hand. See reconcilers.

Release

A dated set of the platform’s own pipeline tooling, such as 2026.09.30-2, that names the exact commit of each part. Each repository uses one release. A release found to be flawed is revoked, and the gate then refuses every new pipeline that uses it. See releases.

Root

A directory of Terraform code with its own state and its own pipeline identities, planned and applied as one unit. A product has a root per environment, such as infra/prod and infra/np. See reconcilers.

Sandbox

An optional, stable non-production copy of a product that other products test against. A product needs one when another product calls it or reads its events.

Shared edge

The single public entry point for every product’s hostname: a Google Cloud load balancer, managed by landing-zone’s network root, that routes each hostname to its product and puts it behind single sign-on unless the product declares a route public.

Single sign-on

Signing in once with an organization account to reach every internal product. On Airframe it is Google’s Identity-Aware Proxy in front of each product’s hostname, which admits only the product’s users group from the catalog.

Terraform

The tool that describes cloud infrastructure as code and makes the real infrastructure match it, in two steps, a plan and an apply. Every root on Airframe is Terraform code.

Tombstone

A file kept in the catalog’s retired-names/ folder for every removed product, so that its name is never given to another product in the same domain. See the catalog.

Trusted and untrusted runners

The two machines that run the platform’s pipeline jobs. The untrusted runner runs every merge request’s checks and holds no credential a job could use. The trusted runner, inside the platform’s network, runs the jobs that need the platform’s identities: the executor’s runs and the plans and applies on protected main branches. See the gate and the executor.

Trusted builder

The platform’s private Cloud Build pool, which builds every product’s container images from approved commits, so that what runs in production was built by the platform, not by a product’s own pipeline. See a change’s path.

Workload identity federation

The Google Cloud feature that lets a pipeline job trade the signed token GitLab gives it for a short-lived Google identity, with no stored password or key. The identity is given only to a job from the right repository, in the right environment, on a protected branch. See identities and access.

YAML

A plain-text format for structured data, written as indented key: value lines. Every file in the catalog is YAML.