Afirmações e mecanismos

Esta página lista cada afirmação que o Airframe faz sobre sua segurança, seu custo e seus registros, com o mecanismo por trás de cada uma e um status honesto. Uma afirmação vale o que vale aquilo que a garante, então cada linha diz se algo recusa hoje uma violação, se a afirmação depende de as pessoas seguirem uma regra, ou se ela está projetada e ainda não construída. A página de limites de confiança explica como as peças se encaixam.

Como ler uma linha

Cada linha tem uma afirmação, seu mecanismo, um status e uma fonte: o repositório e os arquivos onde o mecanismo fica. O status é uma de três palavras:

Aplicado: um mecanismo recusa a violação. Para uma afirmação de que a plataforma fornece algo, como um painel, significa que o próprio código da plataforma o fornece sempre, sem que ninguém escolha.
Convenção: está escrito e é ensinado, mas nada recusa uma mudança que o ignore.
Projetado: especificado no design ou nos registros da plataforma, e não construído.

Os exemplos vêm de uma organização de demonstração, cujos projetos ficam sob uma pasta no Google Cloud. Hoje uma só pessoa opera a plataforma. Onde uma linha nomeia uma segunda pessoa, como quem aprova, essa pessoa é a segunda conta do mantenedor: o mecanismo é aplicado, mas a separação entre duas pessoas ainda não é real.

Cada afirmação das páginas “por quê” aparece aqui com o mesmo mecanismo, e também cada lacuna que as próprias revisões e registros da plataforma listam.

Identidades e acesso

Nenhuma conta de uso diário de uma pessoa tem um papel permanente que possa mudar a infraestrutura de produção.

Mecanismo: A raiz de pastas e as fábricas de projetos dão às pessoas papéis de leitura e de leitura de logs, e a única escrita que uma equipe tem é adicionar uma versão dos seus segredos de produção, nunca ler um. Os papéis administrativos chegam às pessoas só por concessões do Privileged Access Manager. Um job diário do Policy Analyzer falha, e alerta, se essa única conta de administrador tem no nó da organização algum papel que não seja Organization Administrator, ou se qualquer outra pessoa ou grupo tem ali um papel permanente.
Status: aplicado
Fonte: landing-zone roots/folders/main.tf, roots/project-factory/, .gitlab-ci.yml (audit:policy-analyzer)

Só um job do próprio repositório do produto, em uma branch ou tag protegida, no ambiente certo, pode obter sua identidade de apply.

Mecanismo: A fábrica de projetos vincula cada identidade de apply a um valor que combina o caminho do repositório, o ambiente e se a ref é protegida, só com o valor protegido. O provedor de identidade recusa qualquer token de fora do grupo projectairframe no GitLab.
Status: aplicado
Fonte: landing-zone roots/wif/main.tf, roots/project-factory/

Nada do que roda antes de um merge pode mudar a produção.

Mecanismo: O executor pode usar a identidade de plan de cada produto, que lê e não muda nada, e cada identidade de apply de não produção, e nenhuma identidade de apply de produção. O pipeline do próprio merge request não recebe nenhuma identidade.
Status: aplicado
Fonte: landing-zone roots/project-factory/ (as permissões do executor)

Nenhuma chave de conta de serviço pode ser criada ou enviada sob a pasta da organização de demonstração.

Mecanismo: As políticas da organização na pasta desativam a criação e o envio de chaves para todo principal, e a política de negação bloqueia a criação de chaves para todos, exceto o grupo de emergência, a conta de administrador da inicialização e o agente de serviço do Privileged Access Manager. O pacote de políticas também recusa uma chave declarada no Terraform.
Status: aplicado
Fonte: landing-zone roots/organisation/policies.tf, deny.tf; control-plane policy/airframe/iam.rego

O acesso administrativo de um mantenedor é temporário, e outro membro do grupo da plataforma o aprova.

Mecanismo: As permissões do Privileged Access Manager que dão papéis administrativos duram no máximo duas horas e precisam da aprovação de outro membro do grupo da plataforma; quem pede nunca aprova o próprio pedido. Hoje esse membro é a segunda conta do mantenedor.
Status: aplicado
Fonte: landing-zone roots/pam/main.tf

O projeto de não produção de um produto faturado tem uma concessão de nível 1, para ler seus logs e seu estado por uma hora.

Mecanismo: A única permissão de nível 1, autoaprovada por uma hora, fica no projeto de não produção da plataforma, lk-runtime-np. Nenhuma fábrica de projetos cria uma para um produto ainda.
Status: projetado
Fonte: landing-zone roots/pam/variables.tf, docs/guides/identity.md

O próprio Google Cloud recusa os papéis owner e editor em qualquer lugar abaixo da pasta, mesmo fora de um pipeline.

Mecanismo: Uma restrição personalizada da política da organização, aplicada na pasta desde 2026-10-01, recusa uma concessão de qualquer um dos dois papéis por qualquer caminho, o console incluído. Ela admite dois casos: um projeto ainda na janela de inicialização da sua fábrica, e o próprio agente de serviço das APIs do Google, a quem o Google dá editor quando as APIs de um projeto são ativadas. As fábricas de projetos também removem o papel owner que o Google lhes dá em cada projeto que criam. O pacote de políticas também recusa os dois papéis em cada mudança de Terraform (Políticas, abaixo).
Status: aplicado
Fonte: landing-zone roots/organisation/constraints.tf, terraform.tfvars, docs/adr/0026-the-floor-enforced-and-the-audit-record-locked.md

A política de negação também protege a política de firewall e o Binary Authorization.

Mecanismo: A arquitetura 9.3 inclui os dois entre as permissões da política de negação. A política de negação construída cobre a criação de chaves, as mudanças nas políticas da organização, as mudanças no IAM da pasta e o sink de logs da pasta, e nenhum dos dois.
Status: projetado
Fonte: landing-zone docs/architecture.md 9.3, roots/organisation/deny.tf

Cada hostname de produto fica atrás do login único.

Mecanismo: O Identity-Aware Proxy está ativo em cada serviço que atende usuários, para o grupo de usuários do produto: o módulo de Cloud Run do golden path o liga em cada backend de produto, e o pacote de políticas recusa um ingresso aberto, ou um backend de produto, sem ele. A verificação de invocador do Cloud Run continua ativa, com o agente de serviço do IAP como único invocador de um serviço da borda, então uma chamada que contorne o IAP é recusada. O controle de aprovação e este site são as exceções públicas da plataforma. Uma rota que uma entrada declara pública, com ingresso externo, é projetada: nada a constrói ainda.
Status: aplicado
Fonte: control-plane policy/airframe/cloud_run.rego; golden-path modules/cloud-run-service/main.tf; landing-zone docs/contracts.md 8

As aplicações verificam o cabeçalho assinado que o IAP envia, e o endereço padrão de um serviço está desligado.

Mecanismo: A revisão de 2026-09-25 registrou os dois como as próximas camadas depois da verificação de invocador. Hoje só a verificação de invocador impede que alguém contorne o IAP: o módulo de Cloud Run do golden path a mantém ativa (invoker_iam_disabled = false), e o pacote de políticas só alerta quando um serviço da borda a desliga.
Status: projetado
Fonte: landing-zone docs/reviews/2026-09-25-implementation-review.md (F06); control-plane policy/airframe/cloud_run.rego

Cada prévia tem seu próprio hostname, atrás do login único, e nenhuma outra entrada.

Mecanismo: O certificado e o registro curinga do domínio cobrem cada hostname de prévia, então nada é emitido por prévia. O módulo preview-substrate do golden path dá a cada produto um roteador no seu projeto de não produção, atrás do IAP para o grupo de usuários do produto; o roteador lê o número do merge request no hostname, e cada serviço de prévia nomeia o roteador como seu único invocador.
Status: aplicado
Fonte: golden-path modules/preview-substrate/

Um nome removido nunca é reutilizado.

Mecanismo: O catálogo guarda uma lápide para cada nome retirado, e seu lint recusa qualquer outro produto com esse nome no domínio. Uma identidade está vinculada ao caminho do repositório, então um repositório novo não pode herdar o acesso de um antigo.
Status: aplicado
Fonte: catalog scripts/lint.mjs, retired-names/

Controle de mudanças

O pipeline de um merge request não tem nenhuma credencial da nuvem.

Mecanismo: Ele roda no runner não confiável, fora dos perímetros, em uma rede sem rota para as faixas da plataforma; seus jobs não alcançam o servidor de metadados, e nenhum vínculo de identidade aceita uma branch sem proteção.
Status: aplicado
Fonte: control-plane roots/runner-untrusted/, docs/adr/0007-an-untrusted-runner-of-our-own.md; landing-zone roots/wif/main.tf

Só os responsáveis atuais podem aprovar.

Mecanismo: O controle de aprovação lê o modelo de responsáveis a partir da branch main protegida do catálogo, nunca da mudança que julga, não conta nenhuma aprovação do autor nem de quem fez um commit, e vincula sua própria aprovação ao commit que verificou; uma política de aprovação torna essa aprovação uma condição para o merge.
Status: aplicado
Fonte: control-plane gate/src/core/ownership.ts; security-policies .gitlab/security-policies/policy.yml

Só a aprovação de uma pessoa nomeada permite o merge de uma mudança, nunca a do seu autor.

Mecanismo: A política de aprovação lista seus aprovadores pelo nome, as pessoas ativas do catálogo com uma conta no GitLab, e exclui o autor e quem fez commits. Um agente de código com conta própria não está em nenhuma lista; um que age com a conta ou o token de uma pessoa é essa pessoa para o GitLab, e nada distingue os dois. A conta de serviço do controle é a única aprovadora de outra política e não pode dar a aprovação da pessoa. Hoje cada aprovador nomeado é uma das contas próprias do mantenedor.
Status: aplicado
Fonte: security-policies .gitlab/security-policies/policy.yml

Cada arquivo do catálogo é verificado antes do merge.

Mecanismo: O componente validate do control-plane roda o lint do catálogo, validate:catalog, em cada merge request e na main: cada arquivo contra o seu JSON Schema, o pai de cada nível presente, cada líder e cada membro de equipe uma pessoa que não saiu, e o líder de cada equipe um dos seus membros com o papel de líder de equipe. Cada achado nomeia o seu arquivo. O projeto do catálogo só permite o merge de um merge request quando o seu pipeline terminou com sucesso, então um achado impede o merge; na main, um lint que falha para a cadeia de reconciliadores antes que ela comece.
Status: aplicado
Fonte: control-plane templates/validate/template.yml (validate:catalog), roots/gitlab/projects.tf; catalog scripts/lint.mjs, schema/, .gitlab-ci.yml

Só os responsáveis atuais podem aprovar uma mudança no catálogo.

Mecanismo: O controle de aprovação lê as regras de responsáveis, as equipes e as pessoas da branch main protegida do catálogo, nunca da mudança que avalia, e conta só pessoas ativas com uma conta no GitLab, nunca o autor nem os autores dos seus commits. A política required ownership gate no security-policies torna a aprovação do controle uma condição para o merge no catálogo, como em todos os outros repositórios que o controle protege.
Status: aplicado
Fonte: control-plane gate/src/core/ownership.ts, gate/src/adapters/gitlab-ownership.ts, gate/infra/terraform.tfvars (ownership_enforced); security-policies .gitlab/security-policies/policy.yml; catalog ownership/protected-paths.yaml

Um merge no catálogo chega aos leitores sem que ninguém rode um comando.

Mecanismo: O pipeline do catálogo na sua branch main protegida dispara, um após o outro, os pipelines do landing-zone, do operations e do control-plane, e depois de novo o do landing-zone, cada um esperando o anterior; uma falha impede os seguintes. Neles, o componente tf-apply roda só as raízes que declaram reads_catalog, contra a branch main do catálogo, cada uma com a sua própria identidade de pipeline.
Status: aplicado
Fonte: catalog .gitlab-ci.yml (reconcile:landing-zone, reconcile:operations, reconcile:control-plane, reconcile:landing-zone-last); control-plane templates/tf-apply/template.yml (reads_catalog, catalog_ref)

Cada leitor deriva as participações e as aprovações só de pessoas ativas.

Mecanismo: A raiz de grupos sincroniza participações só para pessoas ativas; as raízes do GitLab dão participações e direitos de merge só a pessoas ativas com um nome de usuário no GitLab, e lhes dão acesso aos repositórios da plataforma e ao security-policies por um só grupo, projectairframe/contributors, então uma saída tira a pessoa de todos eles na próxima execução da cadeia; a raiz do Grafana adiciona só pessoas ativas com um nome de usuário no Grafana; o controle de aprovação conta só pessoas ativas. O lint recusa uma pessoa que saiu em qualquer equipe ou lista de líderes, então o merge request que marca alguém como departed também o tira de cada equipe e de cada lista de líderes.
Status: aplicado
Fonte: landing-zone roots/groups/main.tf; control-plane roots/gitlab-config/locals.tf, roots/gitlab-config/memberships.tf, modules/product-repositories/main.tf, gate/src/core/ownership.ts; operations roots/grafana/members.tf; catalog scripts/lint.mjs

Os aprovadores nomeados da política de aprovação acompanham o catálogo.

Mecanismo: O job policy:approvers compara a lista com as pessoas ativas do catálogo com uma conta no GitLab. No security-policies ele roda em cada merge request e na main, e uma falha aparece no merge request. No control-plane ele roda depois de cada merge no catálogo, onde uma pessoa a adicionar ou remover só gera um aviso, então a cadeia do catálogo continua, e todo dia, onde falha e policy:approvers:report mantém uma issue com a mudança exata a fazer. Um papel, um grupo ou um id entre os aprovadores, ou qualquer aprovador que não seja a conta do controle na regra do próprio controle, faz falhar todas as execuções. Enquanto a lista não acompanha, uma pessoa que ainda não está nela não pode aprovar, e uma pessoa que saiu e continua nela não alcança nenhum repositório da plataforma, porque as pessoas chegam a eles só pelo grupo projectairframe/contributors, cujos membros vêm do catálogo. O que sustenta a lista é a aprovação de cada mudança no security-policies por uma pessoa nomeada, nunca o seu autor.
Status: convenção
Fonte: security-policies .gitlab-ci.yml (policy:approvers), scripts/approvers.py; control-plane cli/approvers_lag.py, .gitlab-ci.yml (policy:approvers, policy:approvers:report), roots/gitlab-config/memberships.tf, roots/gitlab/modules/ultimate/policies.tf

A aprovação do controle é exigida em todos os repositórios menos um.

Mecanismo: A política do controle de responsáveis cobre os repositórios que o controle exige, hoje todos menos o security-policies, que guarda as regras de aprovação. Um repositório novo entra com dois merge requests, um no control-plane e outro no security-policies; enquanto isso, ele só precisa da aprovação de uma pessoa nomeada.
Status: aplicado
Fonte: security-policies .gitlab/security-policies/policy.yml; control-plane gate/

Uma mudança ainda pode ser integrada quando o controle está no ar mas não pode aprová-la.

Mecanismo: Um merge request no security-policies, aprovado por uma pessoa nomeada que não o escreveu, tira o repositório bloqueado do alcance da política do controle, e um segundo o devolve. Isso foi ensaiado: a regra deixou um repositório de produto 11 segundos depois do primeiro merge e voltou 35 segundos depois da reversão.
Status: aplicado
Fonte: control-plane docs/security-policies.md; security-policies .gitlab/security-policies/policy.yml

Uma mudança em um repositório da plataforma ainda pode ser integrada quando o controle não pode ser alcançado.

Mecanismo: O security-policies fica fora da política de execução de pipelines do grupo todo, então os seus próprios pipelines não levam o gate:integrity e os seus merge requests não esperam o controle. Um merge request ali, aprovado por uma pessoa nomeada que não o escreveu, tira um repositório do alcance da política required ownership gate e o adiciona às exclusões dessa política de execução; esse repositório então é integrado só com a aprovação de alguém que não é o autor, e um merge request inverso traz as duas de volta. Durante a janela o executor não planeja, não constrói nem promove nada para ele. O ensaio de 2026-10-02 tirou um repositório da plataforma e o trouxe de volta com o controle no ar: a regra saiu em 10 segundos e voltou 16 segundos depois do merge inverso. Depois deixou o controle inalcançável por dois minutos: um pipeline de outro repositório falhou de forma fechada 10 segundos depois de começar, e o pipeline do security-policies passou. O repositório de um produto não pode ser integrado assim, porque o seu merge também espera a verificação de status Airframe cost, que só o controle define; não está decidido se uma mudança urgente de um produto espera o controle ou ganha um caminho por essa verificação. O que uma queda perde: o GitLab não reenvia um evento de auditoria que o controle não conseguiu receber. Em 2026-10-02, 34 dos 35 pipelines do grupo que falharam entre 09:00 e 15:30 UTC têm seu evento de falha no log do controle; o que não tem falhou durante a queda. Desde aquela noite um segundo destino de transmissão envia cada evento ao receptor de auditoria, um serviço do Cloud Run separado que executa a imagem do controle com apenas a rota de auditoria, então o bucket de auditoria bloqueado perde um evento somente quando os dois estão inacessíveis; as detecções leem apenas a cópia do controle, então uma queda do controle continua escondendo delas os seus eventos.
Status: aplicado
Fonte: security-policies .gitlab/security-policies/policy.yml; control-plane docs/adr/0032-a-gate-that-cannot-be-reached.md (pendências 5 e 7), docs/security-policies.md; landing-zone docs/rehearsals/2026-10-02-the-gate-unreachable.md; control-plane gate/infra/audit-receiver.tf, docs/adr/0021-gitlab-ultimate-deployments-vulnerabilities-compliance-and-audit-events.md

Uma queda do controle é tratada por um procedimento escrito, começando pela recuperação do próprio controle.

Mecanismo: O ADR-0032 do control-plane fixa duas etapas. Primeiro o controle é recuperado no Google Cloud, porque ele não consegue se reimplantar pelo próprio pipeline enquanto está fora do ar: com uma concessão de nível 2 do Privileged Access Manager que outro membro do grupo de plataforma aprova, o tráfego do Cloud Run volta para a última revisão que funcionou, cerca de 22 segundos em cada sentido no ensaio. Só se isso não restabeleceu o controle em 30 minutos, e uma mudança não pode esperar, um repositório sai da política de aprovação e da política de execução do controle, por no máximo duas horas, como acima. As aprovações são aplicadas: o Privileged Access Manager recusa que quem pede aprove o próprio pedido, e a política de aprovação recusa a do autor. A ordem, os 30 minutos e o issue que mantém a linha do tempo estão escritos e ensaiados, e nada recusa um merge request de emergência que os pule.
Status: convenção
Fonte: control-plane docs/adr/0032-a-gate-that-cannot-be-reached.md; landing-zone roots/pam/main.tf, docs/rehearsals/2026-10-02-the-gate-unreachable.md

Uma janela de emergência para um repositório termina em duas horas.

Mecanismo: Nada a fecha: encerrar a janela é o merge request inverso de uma pessoa. Quem verifica o limite é o pipeline agendado do control-plane, que roda uma vez por dia, então um excesso aparece na execução do dia seguinte. O breakglass:check compara o arquivo de políticas do security-policies com o estado normal, avisa enquanto uma diferença tem menos de duas horas e falha depois, nomeando os repositórios, e o breakglass:report mantém aberto um issue com o rótulo audit::misconfiguration até as políticas voltarem a coincidir.
Status: convenção
Fonte: control-plane cli/breakglass_bound.py, .gitlab-ci.yml (breakglass:check, breakglass:report), docs/adr/0032-a-gate-that-cannot-be-reached.md

Nenhuma variável de projeto, de grupo ou de pipeline pode apontar o job de integridade do controle para outro lugar nem esvaziá-lo.

Mecanismo: O job roda onde a política do grupo todo o injeta: em cada repositório menos o security-policies e um tirado para uma janela de emergência. Ele mesmo define o endereço do controle, e um endereço vazio falha de forma fechada, como um controle inalcançável. As duas políticas de execução de pipelines não permitem sobrescrever variáveis, então nenhuma variável de projeto, de grupo, de instância nem de pipeline chega aos jobs que elas injetam. Até 2026-10-02 o job lia o endereço de uma variável de grupo e registrava um sucesso quando ela estava vazia; esse recurso não existe mais.
Status: aplicado
Fonte: security-policies templates/airframe.yml, .gitlab/security-policies/policy.yml; control-plane docs/adr/0032-a-gate-that-cannot-be-reached.md

Um produto é criado sem que ninguém rode um comando.

Mecanismo: O pipeline do catálogo inicia a cadeia de raízes de Terraform depois do merge, e cada raiz é aplicada com uma identidade de pipeline que só um job do seu próprio repositório, em uma ref protegida do seu ambiente, pode obter.
Status: aplicado
Fonte: catalog .gitlab-ci.yml; landing-zone roots/wif/

Só uma mudança aprovada recebe uma prévia, e nunca com a identidade de produção.

Mecanismo: O controle de aprovação inicia a execução de prévia do executor só quando aprova o merge request de um produto, e não para um produto em retirada; a execução aplica a raiz infra/eph do produto com a identidade de apply de não produção, depois que o pacote de políticas verificou o plan. Alguém que só pode abrir merge requests não pode inflar a conta.
Status: aplicado
Fonte: control-plane executor/scripts/preview.sh, docs/adr/0016-the-preview-lifecycle-through-the-executor.md

O merge request mostra o quanto o produto avançou.

Mecanismo: Depois do merge, o job de progresso do catálogo acompanha a cadeia, e o controle de aprovação mantém uma nota no merge request integrado até que o produto responda no seu hostname, um job falhe ou se passem três horas.
Status: aplicado
Fonte: control-plane templates/progress/, gate/src/adapters/gitlab-progress.ts

Retirar um produto exige duas aprovações além da do autor.

Mecanismo: A regra de ciclo de vida do controle pede dois aprovadores distintos, nenhum deles o autor: um da equipe do produto e outro dos líderes do domínio ou da equipe da plataforma. O job de ciclo de vida do catálogo exige o rótulo lifecycle e os estados em ordem. Hoje os dois podem ser contas próprias do mantenedor.
Status: aplicado
Fonte: control-plane gate/src/core/ownership.ts; catalog scripts/lifecycle-check.mjs

O Terraform de um produto não pode ler as credenciais do pipeline.

Mecanismo: Antes de qualquer plan, o executor recusa na raiz de um produto toda função de template e toda leitura de arquivo que não seja um arquivo que o commit traz ou um de um módulo fixado, e roda o Terraform do produto como um usuário separado, com um ambiente limpo e um só token. Essa segunda camada é testada no pipeline e ainda não foi exercida pelo plan real de um produto.
Status: aplicado
Fonte: control-plane executor/scripts/security.py, executor/scripts/worker.py, docs/adr/0028-a-products-terraform-runs-as-a-worker-with-one-token.md

Um produto não pode reivindicar o nome de host, o backend nem a identidade de outro produto na rede compartilhada.

Mecanismo: A raiz de rede tira o dono e a edição de cada publicação do nome do objeto, compara com eles cada afirmação que ela contém, e rejeita sozinha uma publicação inválida ou disputada: o nome de host e o backend de uma rota, e a identidade de um alcance ou de um objeto de saída, precisam ser do dono. Guardar a última configuração válida está pendente.
Status: aplicado
Fonte: landing-zone docs/adr/0024-the-edge-publications-are-checked-against-their-owner.md, docs/reviews/2026-09-26-implementation-review.md (R02)

O endereço de um alcance pertence a um serviço do seu próprio dono.

Mecanismo: A raiz de rede só verifica que o endereço de um alcance está na faixa de acesso a serviços privados da rede da edição, não que seja o banco de dados ou o cache do próprio dono. Assim, um produto pode abrir o caminho da sua própria identidade até o endereço do banco de dados ou do cache de outro produto nessa faixa, atrás da autenticação própria desse serviço. Uma verificação do dono do endereço está pendente.
Status: projetado
Fonte: landing-zone docs/adr/0024-the-edge-publications-are-checked-against-their-owner.md, docs/reviews/2026-09-26-implementation-review.md (R02)

Uma aprovação é um login novo, não uma sessão.

Mecanismo: O design exige autenticar de novo a cada aprovação. Isso está desligado, um desvio registrado do design: enquanto não estiver ligado, uma aprovação dada pela sessão ou pelo token de uma pessoa conta como dessa pessoa.
Status: projetado
Fonte: landing-zone docs/adaptations.md (linha 32); security-policies .gitlab/security-policies/policy.yml

Um produto de criticidade 1 é publicado com verificação, um período de observação e um canário.

Mecanismo: As criticidades 2 e 3 seguem a ordem projetada. A criticidade 1 segue a ordem da criticidade 2, porque o componente de implantação das etapas seguintes não está construído; a organização de demonstração não tem nenhum produto de criticidade 1.
Status: projetado
Fonte: landing-zone docs/adaptations.md (linha 48)

Um produto dividido em vários repositórios, cada um implantando sua parte.

Mecanismo: O catálogo aceita os repositórios de uma entrada e os contratos nomeiam seu estado, suas identidades e seus hostnames, mas nada os lê ainda, e a decisão de design continua sendo uma proposta.
Status: projetado
Fonte: landing-zone docs/adr/0017-multi-repository-products-and-adoption-by-moving-the-group.md

Políticas

Os testes do pacote de políticas rodam a cada mudança nele.

Mecanismo: O job policy:test do control-plane roda os testes unitários do Conftest e os casos que devem passar e falhar em cada merge request que muda o pacote, e o GitLab só integra um merge request cujo pipeline termina bem.
Status: aplicado
Fonte: control-plane .gitlab-ci.yml (policy:test), policy/airframe/

Cada regra traz um caso que deve aceitar e outro que deve recusar.

Mecanismo: As convenções de trabalho e a documentação do pacote pedem os dois. A revisão sustenta isso; nenhum job verifica se uma regra nova traz seus testes.
Status: convenção
Fonte: control-plane docs/policy-pack.md

O repositório de um produto não pode pular a validação.

Mecanismo: A política de execução de pipelines de produto injeta os componentes validate e build-test em cada pipeline dos repositórios dos grupos de jornada, e o GitLab não deixa o arquivo próprio de nenhum projeto remover ou substituir um job injetado.
Status: aplicado
Fonte: security-policies .gitlab/security-policies/policy.yml, templates/product.yml

O arquivo de pipeline de um produto inclui só os componentes da plataforma, e nenhum dos seus próprios jobs implanta.

Mecanismo: As regras de pipeline do pacote recusam uma inclusão que não seja um dos oito componentes nomeados do control-plane, um job que declara um ambiente e um job que dispara outro pipeline; a validação injetada as roda sobre o arquivo do produto.
Status: aplicado
Fonte: control-plane policy/airframe/pipeline.rego, docs/adr/0026-a-product-job-never-deploys.md

Uma regra que recusa para a mudança.

Mecanismo: Uma recusa faz falhar o job de validação injetado, e o GitLab só integra o merge request de um produto quando seu pipeline termina bem. Na main, policy:<root> roda o pacote sobre o plan, e o apply precisa que ele passe. As regras de custo rodam no executor e decidem a verificação de status Airframe cost.
Status: aplicado
Fonte: control-plane templates/validate/template.yml, templates/tf-apply/template.yml

Um alerta do pacote precisa da aprovação da plataforma e de uma linha no registro de exceções.

Mecanismo: Hoje um alerta aparece no log do job e não segura nada: o Conftest roda sem falhar por alertas, embora a documentação do pacote e algumas mensagens digam que é preciso uma aprovação.
Status: projetado
Fonte: control-plane docs/policy-pack.md, templates/validate/template.yml

Uma regra nova de recusa passa uma versão da plataforma como alerta, e depois recusa.

Mecanismo: As convenções de trabalho pedem isso, e nada transforma um alerta em recusa. Várias regras marcadas como alertas por uma versão, como as regras do banco de dados sidecar, a verificação de invocador da borda e as inclusões obrigatórias do arquivo de um produto, continuam sendo alertas na versão 2026.10.01-1.
Status: convenção
Fonte: control-plane policy/airframe/cloud_run.rego, pipeline.rego, docs/policy-pack.md

Recursos próprios são permitidos, com um alerta.

Mecanismo: O pacote alerta sobre cada recurso gerenciado que a raiz de um produto declara fora de um módulo, e pede um motivo no merge request; um alerta não faz falhar nada. Suas regras de recusa valem para todo recurso, próprio ou não, e os tipos que são da plataforma, como redes, projetos e perímetros, são recusados na raiz de um produto.
Status: aplicado
Fonte: control-plane policy/airframe/naming.rego, platform_owned.rego

Nenhuma mudança de Terraform dá o papel owner ou editor, nem nada ao público.

Mecanismo: As regras de IAM do pacote recusam owner e editor em qualquer forma, e qualquer permissão a allUsers ou allAuthenticatedUsers, no código e no plan.
Status: aplicado
Fonte: control-plane policy/airframe/iam.rego

Cada recurso rotulado traz o conjunto completo de rótulos da plataforma.

Mecanismo: A regra de rótulos recusa um recurso ao qual falte qualquer um dos seis que os contratos nomeiam, no código e no plan.
Status: aplicado
Fonte: control-plane policy/airframe/naming.rego; landing-zone docs/contracts.md 7

Cada recurso traz os rótulos da plataforma, mesmo um que não declara nenhum.

Mecanismo: Os contratos pedem rótulos em cada projeto e recurso. A regra de rótulos verifica os rótulos que um recurso declara, então um recurso sem nenhum atributo de rótulos passa por ela.
Status: projetado
Fonte: landing-zone docs/contracts.md 7; control-plane policy/airframe/naming.rego

O notebook roda a validação do merge request.

Mecanismo: airframe validate roda os comandos de formatação, terraform validate e pacote de políticas do componente validate, sem backend e sem credenciais; o OpenTofu e o tflint só rodam onde estão instalados. Rodá-lo é uma convenção, e o merge request roda as verificações de qualquer forma. Ele lê o pacote do clone do control-plane a partir do qual foi instalado, não da versão da plataforma do produto, e não roda o lint do catálogo, o controle, os testes da aplicação, o plan nem seu preço; onde o Infracost e sua chave estão presentes, ele mostra uma estimativa a partir do código.
Status: convenção
Fonte: control-plane cli/airframe-validate.sh

`airframe validate` roda os testes de módulos, o lint das especificações de API e a verificação de compatibilidade de API.

Mecanismo: As convenções de trabalho do espaço de trabalho listam as três; o script não roda nenhuma.
Status: projetado
Fonte: control-plane cli/airframe-validate.sh

Cadeia de suprimentos

Seu próprio Dockerfile é construído sobre uma imagem base da plataforma.

Mecanismo: As regras de Dockerfile do pacote recusam um FROM ou um COPY --from fora das imagens base da plataforma, um sem fixar e um calculado a partir de um argumento de build, nos Dockerfiles que .airframe/images.yaml lista. A partir da versão 2026.10.01-1, a validação injetada as roda em cada merge request que muda um Dockerfile listado chamado Dockerfile, Dockerfile.*, *.Dockerfile ou *.dockerfile, e airframe validate as roda localmente. O construtor confiável constrói e atesta exatamente essa lista.
Status: aplicado
Fonte: control-plane policy/airframe/dockerfile.rego, templates/validate/template.yml

Um merge request que muda só um Dockerfile listado é julgado, qualquer que seja o seu nome.

Mecanismo: Um Dockerfile listado com outro nome, como Containerfile, só é julgado quando o merge request também muda outro arquivo que a validação observa.
Status: projetado
Fonte: control-plane templates/validate/template.yml, docs/adr/0014-approved-base-images-built-in-project-and-checked-on-every-from.md

Cada stack é construído e testado quando sua parte do template muda.

Mecanismo: O pipeline do golden-path gera de novo os três exemplos e exige que coincidam com os salvos sempre que o template muda, e constrói e testa o exemplo de um stack quando os arquivos desse stack mudam. O catálogo de demonstração tem um produto ativo em cada stack.
Status: aplicado
Fonte: golden-path .gitlab-ci.yml (template:render, template:test)

Um stack que o template não oferece é construído sobre uma imagem base da plataforma, sem os testes da plataforma.

Mecanismo: As regras de imagem base valem para cada Dockerfile listado. Os jobs injetados de build e teste só conhecem os três stacks do template, então outro stack não roda nenhum deles e não passa no limite de cobertura até que sua entrada baixe quality.minimum_coverage.
Status: aplicado
Fonte: control-plane templates/build-test/template.yml

Um serviço de produto implantado pelo golden path só roda uma imagem que a plataforma construiu e promoveu.

Mecanismo: O módulo de Cloud Run do golden path faz cada serviço aderir à política do Binary Authorization do seu projeto, que no projeto de produção de um produto faturado é aplicada e exige os atestados de build e de promoção; a raiz trusted-builder só deixa assinar o atestador de builds e o promotor de artefatos.
Status: aplicado
Fonte: golden-path modules/service-project/main.tf, modules/cloud-run-service/main.tf; control-plane roots/trusted-builder/

O Binary Authorization vale para cada serviço de Cloud Run, como parte da base.

Mecanismo: A arquitetura 9.3 o conta entre os controles que se mantêm se um pipeline for contornado. O que está construído é uma adesão por serviço, escrita só para produtos faturados: nenhuma política da organização exige que um serviço adira, um serviço de Cloud Run próprio passa pelo pacote com um alerta, e o gateway de telemetria da plataforma roda sem ele.
Status: projetado
Fonte: landing-zone docs/architecture.md 9.3, roots/organisation/policies.tf; golden-path modules/cloud-run-service/main.tf

Cada imagem é analisada em busca de vulnerabilidades conhecidas no build confiável.

Mecanismo: O construtor confiável roda o grype em cada imagem que constrói, com um banco de dados de vulnerabilidades que a plataforma prepara uma vez por dia e só usa se tiver no máximo 48 horas e bater com sua soma de verificação; caso contrário, o grype baixa o banco de dados do fornecedor para esse build. A análise e a lista de materiais de software da imagem ficam guardadas junto ao digest da imagem como evidência, com o registro de qual banco de dados foi usado, e as descobertas chegam ao relatório de vulnerabilidades do GitLab na promoção. Uma descoberta avisa: não bloqueia uma implantação.
Status: aplicado
Fonte: control-plane executor/build/cloudbuild.yaml, docs/adr/0034-the-scan-database-prepared-once-a-day.md, docs/adr/0021-gitlab-ultimate-deployments-vulnerabilities-compliance-and-audit-events.md

O atestado de build é assinado separado do build.

Mecanismo: O construtor confiável constrói e analisa; build-attestor@, que só o executor pode personificar, assina o atestado de build depois que o executor comparou o build com o registro do próprio Cloud Build. A promoção para produção adiciona um segundo atestado.
Status: aplicado
Fonte: control-plane roots/trusted-builder/main.tf, docs/adr/0029-the-build-attestation-is-signed-apart-from-the-build.md

Cada imagem é analisada de novo, separada do build.

Mecanismo: A análise do construtor roda dentro do build, e seu resultado chega ao relatório de vulnerabilidades do GitLab na promoção. Uma análise independente de cada digest fora do build está registrada como pendente.
Status: projetado
Fonte: landing-zone docs/reviews/2026-09-26-implementation-review.md (R03)

Uma versão da plataforma revogada não roda nenhum pipeline novo.

Mecanismo: O job de integridade do controle, que a política de execução de pipelines do grupo injeta em cada pipeline, lê as versões permitidas na main do control-plane e faz falhar um pipeline que inclui uma revogada; o executor faz a mesma verificação antes que uma execução de merge request ou de versão tenha as credenciais de um produto.
Status: aplicado
Fonte: control-plane gate/src/core/releases.ts, executor/scripts/release_check.py, releases/permitted.yaml

Uma versão da plataforma é um conjunto fixo de commits, verificados juntos.

Mecanismo: Uma versão é um manifesto do commit de cada parte, que não muda depois de integrado, verificado nesses commits antes de ser permitido; um componente busca seu pacote de políticas no seu próprio commit e nomeia cada imagem por digest. Um arquivo de pipeline que inclui um componente por branch ou tag recebe um alerta, não uma recusa.
Status: aplicado
Fonte: control-plane releases/, docs/adr/0030-shared-references-are-pinned-to-commits-and-digests.md, docs/adr/0031-the-platform-release-a-manifest-and-a-permitted-list.md

Custo

Uma mudança acima do orçamento não pode ser integrada.

Mecanismo: O controle de aprovação define a verificação de status Airframe cost de cada merge request de produto a partir dos plans com preço do executor de cada raiz no seu último commit: falha quando o total das raízes ou qualquer raiz passa do monthly_budget da entrada, ou quando uma raiz não tem preço. A regra do projeto do produto exige que as verificações de status passem. Um plan na main também para diante de uma recusa registrada. As prévias e os recursos cobrados por uso ficam fora da cifra.
Status: aplicado
Fonte: control-plane gate/src/adapters/gitlab-status-checks.ts, executor/scripts/cost.sh, docs/adr/0025-the-merge-waits-for-the-cost-verdict.md

Aumentar um orçamento exige um líder do domínio.

Mecanismo: A regra de responsáveis do controle exige a aprovação de um líder do domínio para uma mudança do catálogo que aumenta monthly_budget; onde os líderes do domínio não têm conta no GitLab, como na demonstração, a equipe da plataforma os substitui.
Status: aplicado
Fonte: control-plane gate/src/core/ownership.ts

Cada produto tem um painel de custo diante do seu orçamento.

Mecanismo: A raiz de Grafana do operations, que roda quando o catálogo muda, cria um painel de custo na pasta de cada produto: o mês até agora e a previsão diante de monthly_budget, laranja a 80 por cento e vermelho a 100, a partir da exportação de faturamento pelo job diário cost:report.
Status: aplicado
Fonte: operations roots/grafana/pack.tf, roots/cost/

Os orçamentos do Google Cloud seguem o mesmo número.

Mecanismo: A fábrica de projetos do domínio cria um orçamento em cada projeto de produto faturado a partir de monthly_budget, 70 por cento para produção e 30 para não produção, com alertas a 80 e a 100 por cento. Nenhum produto de demonstração está faturado hoje, então nenhum tem ainda os orçamentos dos seus projetos.
Status: aplicado
Fonte: landing-zone roots/project-factory/

Um alerta de orçamento chega à equipe do produto.

Mecanismo: Quando um produto é faturado, os alertas dos seus orçamentos vão por e-mail para os administradores e usuários da conta de faturamento, o padrão do Google, não para a equipe.
Status: projetado
Fonte: landing-zone roots/project-factory/

Um aumento de custo de mais de USD 10 ou de 25 por cento ao mês precisa da aprovação da plataforma.

Mecanismo: Hoje esse aumento é um alerta na nota da raiz no merge request e não segura nada.
Status: projetado
Fonte: control-plane policy/airframe/cost.rego

Uma prévia é destruída quando seu merge request termina.

Mecanismo: O controle de aprovação fica sabendo do merge ou do fechamento pelo webhook do GitLab e inicia a execução de destruição do executor, que verifica sozinha o estado do merge request. O registro de cada prévia tem uma trava, então um apply e uma destruição nunca rodam ao mesmo tempo, e um merge request reaberto começa uma nova geração, então uma destruição atrasada não pode remover a prévia nova.
Status: aplicado
Fonte: control-plane executor/scripts/preview.sh, executor/scripts/preview_record.py

Uma prévia expirada ou esquecida é recolhida.

Mecanismo: preview:collect, no pipeline agendado diário do control-plane, lista as prévias que os registros do executor dizem que continuam no ar e destrói as integradas, as fechadas e as que passaram de preview_ttl_hours (72 por padrão, no máximo 168, contadas a partir do último apply), com uma nota em cada merge request.
Status: aplicado
Fonte: control-plane executor/scripts/preview.sh

Uma prévia quase não custa nada parada, e nunca bloqueia um merge.

Mecanismo: O roteador e os serviços da prévia escalam a zero, o banco de dados sidecar padrão fica na própria revisão do serviço, e o módulo de Cloud Run do golden path roda o serviço de uma prévia com no máximo uma instância. O executor põe preço no plan de cada prévia e o mostra na sua nota, e a verificação de custo que segura um merge deixa as prévias de fora.
Status: aplicado
Fonte: golden-path modules/preview-substrate/, modules/cloud-run-service/; control-plane executor/scripts/preview.sh

Auditoria e observabilidade

Cada concessão, e cada mudança feita com ela, fica registrada.

Mecanismo: O Privileged Access Manager guarda cada concessão com quem a pediu, a justificativa, quem a aprovou e o motivo, e o log de auditoria do Google Cloud guarda cada mudança; os logs de Data Access na pasta também registram as leituras do Secret Manager, Cloud SQL, Cloud Storage, IAM e Cloud KMS.
Status: aplicado
Fonte: landing-zone roots/pam/, roots/audit/main.tf

Cada uso de uma concessão tem uma linha no registro da inicialização.

Mecanismo: A linha nomeia a concessão, quem a pediu e quem a aprovou, a raiz e o commit aplicados, e o plan vazio depois. Está escrito e é ensinado; nada recusa uma concessão sem linha.
Status: convenção
Fonte: landing-zone docs/bootstrap-log.md

Cada log de auditoria do Google Cloud chega a um único bucket, e nenhum pipeline pode desviá-lo.

Mecanismo: Um sink agregado na pasta envia os logs de auditoria de cada projeto, e os eventos de auditoria do GitLab pelo controle e pelo receptor de auditoria, para um bucket em lk-audit criptografado com uma chave que a plataforma tem. A política de negação recusa qualquer mudança em um sink da pasta a todos, exceto o grupo de emergência, a conta de administrador da inicialização e o agente de serviço do Privileged Access Manager. A política de IAM da pasta, que guarda a configuração de auditoria, tem as mesmas exceções e uma quarta, a identidade que configura as concessões; essa identidade só age a partir de código revisado, e a condição sobre o seu acesso exige que uma mudança modifique pelo menos uma concessão e só dos papéis que os direitos dão, então uma chamada que muda apenas a configuração de auditoria é recusada. Uma chamada que muda ao mesmo tempo uma concessão permitida e a configuração de auditoria ainda passa: na pasta, uma regra do Grafana avisa quando uma configuração de auditoria muda, e na organização não há sink. O sink deixa de fora as entradas de teste do VPC Service Controls, que registram o que um perímetro teria recusado e não uma recusa; o log próprio de cada projeto as guarda. Os eventos de auditoria do GitLab chegam ao bucket por dois destinos de transmissão, o controle e o receptor de auditoria, e cada um escreve todos os eventos; o GitLab não reenvia um evento, então um evento criado enquanto os dois estão inacessíveis falta no bucket, e se o seu tipo é um dos que o GitLab só transmite ele não é registrado em lugar nenhum.
Status: aplicado
Fonte: landing-zone roots/audit/main.tf, roots/organisation/deny.tf, roots/wif/grants.tf, docs/adr/0007-pam-companion-condition.md; operations roots/grafana/detections.tf; control-plane docs/adr/0032-a-gate-that-cannot-be-reached.md (pendência 7), gate/infra/audit-receiver.tf

A retenção do bucket de auditoria está bloqueada.

Mecanismo: Uma política de retenção guarda cada objeto por 365 dias, e nenhum pode ser apagado ou sobrescrito antes disso. A política está bloqueada desde 2026-10-01, o que o Google torna irreversível: ninguém, nem um administrador com uma concessão, pode encurtá-la ou removê-la, e o projeto de auditoria não pode ser apagado enquanto o bucket tiver objetos.
Status: aplicado
Fonte: landing-zone roots/audit/main.tf, roots/audit/terraform.tfvars, docs/bootstrap-log.md

Os dados não podem sair dos projetos da plataforma pelas APIs do Google, nem com credenciais válidas.

Mecanismo: Três perímetros do VPC Service Controls, de produção, não produção e auditoria, são aplicados como especificações em modo de teste: uma possível violação é registrada, e nada é bloqueado. Aplicá-los é uma variável. As leituras diárias da raiz da organização que um perímetro recusaria vêm de dentro do perímetro de produção, do runner de confiança na VPC da rede de produção, porque a lista de serviços alcançáveis a partir dessa VPC não os inclui; não são chamadas de fora.
Status: projetado
Fonte: landing-zone roots/perimeters/

Um uso suspeito gera um alerta: uma tentativa de criar uma chave, uma recusa da política de negação, uma concessão, uma identidade usada fora do seu pipeline.

Mecanismo: Um segundo sink, estreito, na pasta envia só estas entradas para o Loki: uma tentativa de criar uma chave, uma recusa de uma política de negação ou da organização, um token recusado, uma mudança nos sinks, nas políticas de negação ou na configuração de auditoria da pasta, uma concessão, e os eventos de auditoria do GitLab. Regras no Grafana acionam a plataforma com urgência pelos cinco primeiros e abrem um ticket por uma concessão ou uma rajada de mudanças no GitLab. Um evento na própria organização, como uma concessão no nível da organização, fica fora dos sinks da pasta; a notificação ao aprovador é o seu único registro além do log de auditoria. Os eventos do GitLab chegam pelo controle, então os criados enquanto ele não pode ser alcançado nunca chegam, e nenhuma regra os vê.
Status: aplicado
Fonte: landing-zone roots/audit/main.tf, docs/adr/0027-the-audit-detections-alert-in-grafana.md; operations roots/grafana/detections.tf

O desvio é informado.

Mecanismo: O job de desvio do componente tf-apply planeja cada raiz no agendamento diário do repositório, e o componente drift-report, como a identidade de auditoria, mantém uma issue com o rótulo audit::drift para cada raiz com desvio, a reescreve e a fecha quando o plan volta a ficar vazio.
Status: aplicado
Fonte: control-plane templates/tf-apply/, templates/drift-report/

O trabalho de um agente de código fica rotulado.

Mecanismo: As instruções para um agente de código e o skill airframe-platform pedem um trailer Generated-by em cada commit e o rótulo agent no merge request, e a configuração do GitLab da plataforma define o rótulo. Nenhum job ou regra verifica nenhum dos dois, então eles registram o que um agente de código ou seu usuário declara.
Status: convenção
Fonte: golden-path template/; platform-skills skills/

Uma auditoria consegue distinguir o trabalho de um agente de código do de uma pessoa, e medir sua parte.

Mecanismo: É para isso que o trailer e o rótulo foram projetados; como nada os verifica, hoje eles não podem provar isso.
Status: projetado
Fonte: landing-zone docs/architecture.md 9.7

Cada produto tem seus painéis e regras de alerta a partir da sua entrada.

Mecanismo: A raiz de Grafana do operations, que roda quando o catálogo muda, cria a pasta de cada produto, seus painéis de serviço e de SLO e suas regras de alerta básicas, com limites tirados do slo da entrada; as regras selecionam produção pelo rótulo env, e uma série que falta não é um alerta.
Status: aplicado
Fonte: operations roots/grafana/pack.tf, alerts.tf

Um alerta chega à equipe do produto, e hoje isso significa o mantenedor.

Mecanismo: Cada regra é roteada pelo rótulo da equipe para o ponto de contato da equipe, que manda e-mail aos membros da equipe com conta no Grafana, e um alerta urgente se repete a cada quatro horas até ser resolvido. O Grafana Cloud só aceita os endereços dos seus próprios membros, e hoje esses membros são as contas próprias do mantenedor, então os alertas de cada equipe, e os da plataforma, chegam ao mantenedor.
Status: aplicado
Fonte: operations roots/grafana/alerts.tf, members.tf

Uma aplicação não precisa de configuração e não tem nenhuma credencial do Grafana.

Mecanismo: A saída Ready da fábrica de projetos traz o endereço do gateway da edição do produto, e o módulo de Cloud Run do golden path o injeta em cada serviço. Os traces e as métricas chegam ao gateway OTLP com o token de identidade do serviço; os logs chegam ao gateway de logs pelo sink do projeto e por um buffer do Pub/Sub. Os gateways têm o token só de escrita da edição, a única credencial do Grafana desse lado.
Status: aplicado
Fonte: operations roots/telemetry/; golden-path modules/cloud-run-service/main.tf

Cada sinal diz de qual edição veio.

Mecanismo: O gateway OTLP mantém o env de um sinal só quando ele é válido para a sua própria edição e troca um valor ausente ou alheio por unknown; o gateway de logs mantém um env válido e, se não houver, dá à linha o do seu perímetro, então só as entradas de auditoria ficam em unknown. Os dois marcam a edição como perimeter. O módulo de Cloud Run do golden path dá aos traces e às métricas de um serviço seu nome de serviço, seu domínio e seu ambiente, e o agente da plataforma rotula as métricas de recursos do Cloud de cada projeto de produto faturado com o caminho do produto e sua jornada e domínio.
Status: aplicado
Fonte: operations roots/telemetry/config/

Os sinais de uma aplicação, as métricas de recursos do agente da plataforma e as séries das tarefas agendadas da plataforma trazem o ambiente de onde vieram.

Mecanismo: O gateway OTLP dá a um recurso sem env o valor de deployment.environment.name e, se faltar, o de deployment.environment, o atributo que o módulo de Cloud Run do golden path define a partir do deploy (prod, np, sandbox ou eph-<n>); um ponto de dados mantém o seu próprio env válido, e um valor que não é válido para a edição vira unknown. O agente da plataforma rotula com env as séries de cada projeto: platform para os projetos da plataforma, a edição para os de um produto, e na não produção o nome do serviço de Cloud Run o reduz a sandbox ou eph-<n>. O gateway de logs dá a uma linha sem um env válido o do seu perímetro, reduzido da mesma forma; as linhas de um projeto da plataforma são platform, e as entradas de auditoria mantêm unknown. As próprias tarefas agendadas da plataforma (os relatórios de custos, de entrega e de cobertura e a verificação diária do Policy Analyzer) declaram deployment.environment=platform no seu recurso, então as suas séries trazem env platform; o relatório de custos guarda o ambiente do projeto a que um custo pertence em um rótulo à parte, project_env (seção 7 dos contratos). As séries do relatório de drift ainda chegam como unknown até a próxima versão da plataforma, porque cada repositório executa o componente drift-report da sua versão. O pipeline aplica a raiz de telemetria a partir da main de operations, e o seu job telemetry:test gera as configurações reais e as executa no Alloy fixado sempre que mudam, e falha em vez de ser pulado quando o binário falta.
Status: aplicado
Fonte: operations commit 872681a: roots/telemetry/config/otlp.alloy.tftpl, logs.alloy.tftpl, agent.alloy.tftpl, roots/telemetry/agent.tf, tests/telemetry_test.py, .gitlab-ci.yml, jobs/delivery_report.py, jobs/coverage-report.sh, jobs/cost_report.py; control-plane templates/drift-report/template.yml; landing-zone .gitlab-ci.yml, docs/contracts.md 7; golden-path modules/airframe-context/main.tf, modules/cloud-run-service/main.tf

Os sinais de uma aplicação trazem a sua equipe e a sua criticidade.

Mecanismo: O design dá a cada sinal os rótulos do catálogo, entre eles a equipe e a criticidade. Hoje eles não trazem nenhum rótulo assim: os traces e as métricas de um serviço têm service.name, service.namespace, que é o seu domínio, e deployment.environment, e o gateway de logs mantém o projeto, o serviço, o tipo de recurso, o nome do log e a severidade de uma linha. Só algumas séries da própria plataforma trazem uma equipe, como as dos relatórios de entregas e de cobertura.
Status: projetado
Fonte: landing-zone docs/guides/observability.md (Labels); golden-path modules/cloud-run-service/main.tf; operations roots/telemetry/config/logs.alloy.tftpl

Um alerta chama uma pessoa de plantão, com uma escala e uma cadeia de escalonamento.

Mecanismo: A ferramenta de plantão e incidentes do Grafana teria as duas para cada equipe, a partir do catálogo. Hoje um alerta é um e-mail.
Status: projetado
Fonte: landing-zone docs/architecture.md 13.5

Uma queda do controle é notada sem esperar os pipelines ficarem vermelhos.

Mecanismo: Uma verificação HTTP do Synthetic Monitoring do Grafana Cloud, airframe-gate, consulta https://gate.projectairframe.dev/health a cada 60 segundos a partir de duas sondas. Uma regra do grupo airframe-platform avisa o ponto de contato da plataforma quando mais de uma sonda falha por dois minutos, ou quando a verificação não informa nada. A verificação cobre só o controle; nenhum outro hostname tem uma. Hoje um aviso é um e-mail para o mantenedor.
Status: aplicado
Fonte: operations roots/grafana/synthetic.tf, alerts.tf, docs/adr/0012-the-gate-uptime-check-in-synthetic-monitoring.md

A base de alertas cobre cada falha que o design nomeia.

Mecanismo: O Cloud Run no seu máximo de instâncias, os reinícios ou a falta de memória, uma verificação de contrato bloqueada na main, e as verificações de disponibilidade pelo hostname de produção de cada produto estão projetados; a raiz de Grafana ainda não cria essas regras. A verificação de disponibilidade do controle, acima, é a única construída.
Status: projetado
Fonte: landing-zone docs/architecture.md 13.4, 13.6; operations roots/grafana/pack.tf

Um agente de operações investiga um alerta, e um agente de auditoria procura desperdício e órfãos.

Mecanismo: O primeiro agiria dentro do que o agentic_ops da entrada permite; o segundo olharia a organização inteira, e encontraria uma prévia sem registro ou uma destruição que falhou. Nenhum dos dois existe hoje.
Status: projetado
Fonte: landing-zone docs/architecture.md 14.3

Documentação

Um skill diz o que as verificações da plataforma fazem.

Mecanismo: Os jobs skills:policy, skills:validate, skills:catalog e skills:references do pipeline do platform-skills verificam os exemplos de cada skill contra o pacote de políticas no commit do control-plane que os skills fixam, o terraform validate e o lint do catálogo, e verificam os caminhos que um skill nomeia; o GitLab só integra uma mudança quando eles passam. O release:check do control-plane exige que essa fixação seja a da versão da plataforma. Se um agente de código carrega um skill depende do agente e do seu usuário.
Status: aplicado
Fonte: platform-skills .gitlab-ci.yml; control-plane .gitlab-ci.yml (release:check)

Cada skill traz exemplos que as verificações devem aceitar ou recusar.

Mecanismo: O README do platform-skills diz que cada skill vem com seus testes e que um skill sem testes não é integrado, e quatro dos cinco skills trazem exemplos que devem passar e falhar. O skill de visão geral, airframe-platform, não traz nenhum: seu único teste, tests/references, verifica que os caminhos que ele nomeia existem. Nada recusa um skill sem exemplos.
Status: convenção
Fonte: platform-skills README.md, skills/airframe-platform/

Cada produto publica sua própria parte do mapa, e só a sua.

Mecanismo: O job validate:fragment do componente catalog-publish constrói o fragmento no merge request sem nenhuma credencial; na main protegida, release:catalog o publica com a identidade que o repositório já tem. A identidade de apply de produção de um produto só pode escrever sob o prefixo do seu produto. Os quatro repositórios da plataforma compartilham uma identidade, platform-docs@, cuja permissão cobre todo o prefixo da plataforma, então nada impede um deles de escrever a parte de outro.
Status: aplicado
Fonte: control-plane templates/catalog-publish/template.yml, roots/executor/variables.tf

O mapa se reconstrói sozinho a partir dos últimos fragmentos.

Mecanismo: O agregador, um job do Cloud Run, roda quando uma identidade que publica o pede depois de uma publicação, e a cada hora por agendamento. Ele lê a lista de produtos do catálogo, pula um fragmento quebrado deixando os motivos no registro da execução e guarda as três últimas versões.
Status: aplicado
Fonte: operations eventcatalog/, roots/eventcatalog/

Um agente de código pode consultar o mapa pelo servidor MCP do catálogo.

Mecanismo: O servidor está projetado; o índice legível por máquina que ele leria é publicado hoje junto de cada build.
Status: projetado
Fonte: landing-zone docs/guides/architecture-catalog.md

Os documentos da plataforma coincidem com o seu código.

Mecanismo: Uma mudança traz seus documentos no mesmo merge request e a revisão sustenta isso; nenhum job compara os dois. Diferenças conhecidas hoje: o guia de segurança põe o Binary Authorization em cada projeto; o guia de observabilidade dá a cada equipe uma escala de plantão; o ADR-0016 diz que a destruição de uma prévia remove seu estado, que o executor mantém; e os contratos contam o tempo de vida de uma prévia a partir do seu último push, o executor a partir do seu último apply.
Status: convenção
Fonte: landing-zone docs/guides/security.md, docs/guides/identity.md, docs/guides/observability.md, docs/contracts.md 8; control-plane docs/adr/0016-the-preview-lifecycle-through-the-executor.md, executor/scripts/preview.sh

Onde fica

No repositório landing-zone:

No repositório control-plane:

docs/policy-pack.md: cada regra, com seu nível