Afirmaciones y mecanismos

Esta página enumera cada afirmación que hace Airframe sobre su seguridad, su costo y sus registros, con el mecanismo que respalda cada una y un estado honesto. Una afirmación vale lo que vale aquello que la hace cumplir, así que cada fila dice si algo rechaza hoy una infracción, si la afirmación depende de que las personas sigan una regla, o si está diseñada y todavía no construida. La página de límites de confianza explica cómo encajan las piezas.

Cómo leer una fila

Cada fila tiene una afirmación, su mecanismo, un estado y una fuente: el repositorio y los archivos donde vive el mecanismo. El estado es una de tres palabras:

Aplicado: un mecanismo rechaza la infracción. Para una afirmación de que la plataforma proporciona algo, como un panel, significa que el propio código de la plataforma lo proporciona siempre, sin que nadie lo elija.
Convención: está escrito y se enseña, pero nada rechaza un cambio que lo ignore.
Diseñado: especificado en el diseño o los registros de la plataforma, y no construido.

Los ejemplos vienen de una organización de demostración, cuyos proyectos están bajo una carpeta en Google Cloud. Hoy una sola persona opera la plataforma. Donde una fila nombra a una segunda persona, como quien aprueba, esa persona es la segunda cuenta del mantenedor: el mecanismo se aplica, pero la separación entre dos personas todavía no es real.

Cada afirmación de las páginas “por qué” aparece aquí con el mismo mecanismo, y también cada brecha que enumeran las propias revisiones y registros de la plataforma.

Identidades y acceso

Ninguna cuenta de uso diario de una persona tiene un rol permanente que pueda cambiar la infraestructura de producción.

Mecanismo: La raíz de carpetas y las fábricas de proyectos les dan a las personas roles de lectura y de lectura de registros, y la única escritura que tiene un equipo es agregar una versión de sus secretos de producción, nunca leer uno. Los roles administrativos llegan a las personas solo por concesiones de Privileged Access Manager. Un trabajo diario de Policy Analyzer falla, y alerta, si esa única cuenta de administrador tiene en el nodo de la organización algún rol que no sea Organization Administrator, o si cualquier otra persona o grupo tiene allí un rol permanente.
Estado: aplicado
Fuente: landing-zone roots/folders/main.tf, roots/project-factory/, .gitlab-ci.yml (audit:policy-analyzer)

Solo un trabajo del propio repositorio del producto, en una rama o etiqueta protegida, en el entorno correcto, puede obtener su identidad de apply.

Mecanismo: La fábrica de proyectos vincula cada identidad de apply a un valor que combina la ruta del repositorio, el entorno y si la ref está protegida, solo con el valor protegido. El proveedor de identidades rechaza cualquier token de fuera del grupo projectairframe en GitLab.
Estado: aplicado
Fuente: landing-zone roots/wif/main.tf, roots/project-factory/

Nada de lo que se ejecuta antes de un merge puede cambiar producción.

Mecanismo: El ejecutor puede usar la identidad de plan de cada producto, que lee y no cambia nada, y cada identidad de apply de no producción, y ninguna identidad de apply de producción. El pipeline propio de un merge request no recibe ninguna identidad.
Estado: aplicado
Fuente: landing-zone roots/project-factory/ (los permisos del ejecutor)

No se puede crear ni subir ninguna clave de cuenta de servicio bajo la carpeta de la organización de demostración.

Mecanismo: Las políticas de la organización en la carpeta desactivan la creación y la subida de claves para todo principal, y la política de denegación bloquea la creación de claves para todos menos el grupo de emergencia, la cuenta de administrador del arranque y el agente de servicio de Privileged Access Manager. El paquete de políticas también rechaza una clave declarada en Terraform.
Estado: aplicado
Fuente: landing-zone roots/organisation/policies.tf, deny.tf; control-plane policy/airframe/iam.rego

El acceso administrativo de un mantenedor es temporal, y lo aprueba otro miembro del grupo de la plataforma.

Mecanismo: Los derechos de Privileged Access Manager que dan roles administrativos duran como máximo dos horas y necesitan la aprobación de otro miembro del grupo de la plataforma; quien pide nunca aprueba su propia solicitud. Hoy ese miembro es la segunda cuenta del mantenedor.
Estado: aplicado
Fuente: landing-zone roots/pam/main.tf

El proyecto de no producción de un producto facturado tiene una concesión de nivel 1, para leer sus registros y su estado durante una hora.

Mecanismo: El único derecho de nivel 1, de una hora y sin aprobador, está en el proyecto de no producción de la plataforma, lk-runtime-np. Ninguna fábrica de proyectos crea uno para un producto todavía.
Estado: diseñado
Fuente: landing-zone roots/pam/variables.tf, docs/guides/identity.md

El propio Google Cloud rechaza los roles owner y editor en cualquier lugar bajo la carpeta, incluso fuera de un pipeline.

Mecanismo: Una restricción personalizada de la política de la organización, aplicada en la carpeta desde el 2026-10-01, rechaza una concesión de cualquiera de los dos roles por cualquier camino, la consola incluida. Admite dos casos: un proyecto todavía en la ventana de arranque de su fábrica, y el propio agente de servicio de las API de Google, al que Google le da editor cuando se activan las API de un proyecto. Las fábricas de proyectos además quitan el rol owner que Google les da en cada proyecto que crean. El paquete de políticas también rechaza los dos roles en cada cambio de Terraform (Políticas, más abajo).
Estado: aplicado
Fuente: landing-zone roots/organisation/constraints.tf, terraform.tfvars, docs/adr/0026-the-floor-enforced-and-the-audit-record-locked.md

La política de denegación también protege la política de cortafuegos y Binary Authorization.

Mecanismo: La arquitectura 9.3 incluye las dos entre los permisos de la política de denegación. La política de denegación construida cubre la creación de claves, los cambios en las políticas de la organización, los cambios en el IAM de la carpeta y el sink de registros de la carpeta, y ninguna de las dos.
Estado: diseñado
Fuente: landing-zone docs/architecture.md 9.3, roots/organisation/deny.tf

Cada hostname de producto está detrás del inicio de sesión único.

Mecanismo: Identity-Aware Proxy está activo en cada servicio que atiende a usuarios, para el grupo de usuarios del producto: el módulo de Cloud Run del golden path lo activa en cada backend de producto, y el paquete de políticas rechaza un ingreso abierto, o un backend de producto, sin él. La verificación de invocador de Cloud Run sigue activa, con el agente de servicio de IAP como único invocador de un servicio del borde, así que se rechaza una llamada que rodee IAP. La compuerta de aprobación y este sitio web son las excepciones públicas de la plataforma. Una ruta que una entrada declara pública, con ingreso externo, está diseñada: nada la construye todavía.
Estado: aplicado
Fuente: control-plane policy/airframe/cloud_run.rego; golden-path modules/cloud-run-service/main.tf; landing-zone docs/contracts.md 8

Las aplicaciones verifican el encabezado firmado que envía IAP, y la dirección predeterminada de un servicio está apagada.

Mecanismo: La revisión del 2026-09-25 registró las dos como las capas siguientes después de la verificación de invocador. Hoy solo la verificación de invocador impide que alguien rodee IAP: el módulo de Cloud Run del golden path la mantiene activa (invoker_iam_disabled = false), y el paquete de políticas solo advierte cuando un servicio del borde la apaga.
Estado: diseñado
Fuente: landing-zone docs/reviews/2026-09-25-implementation-review.md (F06); control-plane policy/airframe/cloud_run.rego

Cada vista previa tiene su propio hostname, detrás del inicio de sesión único, y ninguna otra entrada.

Mecanismo: El certificado y el registro comodín del dominio cubren cada hostname de vista previa, así que no se emite nada por vista previa. El módulo preview-substrate del golden path le da a cada producto un enrutador en su proyecto de no producción, detrás de IAP para el grupo de usuarios del producto; el enrutador lee el número del merge request en el hostname, y cada servicio de vista previa nombra al enrutador como su único invocador.
Estado: aplicado
Fuente: golden-path modules/preview-substrate/

Un nombre eliminado nunca se reutiliza.

Mecanismo: El catálogo guarda una lápida por cada nombre retirado, y su lint rechaza cualquier otro producto con ese nombre en el dominio. Una identidad está vinculada a la ruta del repositorio, así que un repositorio nuevo no puede heredar el acceso de uno viejo.
Estado: aplicado
Fuente: catalog scripts/lint.mjs, retired-names/

Control de cambios

El pipeline de un merge request no tiene ninguna credencial de la nube.

Mecanismo: Se ejecuta en el runner sin confianza, fuera de los perímetros, en una red sin ruta hacia los rangos de la plataforma; sus trabajos no pueden llegar al servidor de metadatos, y ninguna vinculación de identidad acepta una rama sin protección.
Estado: aplicado
Fuente: control-plane roots/runner-untrusted/, docs/adr/0007-an-untrusted-runner-of-our-own.md; landing-zone roots/wif/main.tf

Solo los responsables actuales pueden aprobar.

Mecanismo: La compuerta de aprobación lee el modelo de responsables desde la rama main protegida del catálogo, nunca desde el cambio que juzga, no cuenta ninguna aprobación del autor ni de quien hizo un commit, y vincula su propia aprobación al commit que revisó; una política de aprobación hace de esa aprobación una condición para el merge.
Estado: aplicado
Fuente: control-plane gate/src/core/ownership.ts; security-policies .gitlab/security-policies/policy.yml

Solo la aprobación de una persona con nombre permite el merge de un cambio, nunca la de su autor.

Mecanismo: La política de aprobación enumera a sus aprobadores por nombre, las personas activas del catálogo con una cuenta de GitLab, y excluye al autor y a quienes hicieron commits. Un agente de código con su propia cuenta no está en ninguna lista; uno que actúa con la cuenta o el token de una persona es esa persona para GitLab, y nada distingue a los dos. La cuenta de servicio de la compuerta es la única aprobadora de otra política y no puede dar la aprobación de la persona. Hoy cada aprobador con nombre es una de las cuentas propias del mantenedor.
Estado: aplicado
Fuente: security-policies .gitlab/security-policies/policy.yml

Cada archivo del catálogo se revisa antes del merge.

Mecanismo: El componente validate de control-plane ejecuta el lint del catálogo, validate:catalog, en cada merge request y en main: cada archivo contra su JSON Schema, el padre de cada nivel presente, cada líder y cada miembro de un equipo una persona que no se ha ido, y el líder de cada equipo uno de sus miembros con el rol de líder de equipo. Cada hallazgo nombra su archivo. El proyecto del catálogo permite el merge de un merge request solo cuando su pipeline terminó con éxito, así que un hallazgo detiene el merge; en main, un lint fallido detiene la cadena de reconciliadores antes de que empiece.
Estado: aplicado
Fuente: control-plane templates/validate/template.yml (validate:catalog), roots/gitlab/projects.tf; catalog scripts/lint.mjs, schema/, .gitlab-ci.yml

Solo los responsables actuales pueden aprobar un cambio al catálogo.

Mecanismo: La compuerta de aprobación lee las reglas de responsables, los equipos y las personas de la rama main protegida del catálogo, nunca del cambio que evalúa, y cuenta solo a personas activas con una cuenta de GitLab, nunca al autor ni a los autores de sus commits. La política required ownership gate en security-policies hace de la aprobación de la compuerta una condición para el merge en el catálogo, como en cada otro repositorio que la compuerta protege.
Estado: aplicado
Fuente: 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

Un merge al catálogo llega a los lectores sin que nadie ejecute un comando.

Mecanismo: El pipeline del catálogo en su rama main protegida dispara por turno los pipelines de landing-zone, operations y control-plane, y luego otra vez el de landing-zone, cada uno esperando al anterior; una falla detiene los que siguen. En ellos, el componente tf-apply ejecuta solo las raíces que declaran reads_catalog, contra la rama main del catálogo, cada una con su propia identidad de pipeline.
Estado: aplicado
Fuente: 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 lector deriva las membresías y las aprobaciones solo de personas activas.

Mecanismo: La raíz de grupos sincroniza membresías solo para personas activas; las raíces de GitLab dan membresías y derechos de merge solo a personas activas con un nombre de usuario de GitLab, y les dan acceso a los repositorios de la plataforma y a security-policies a través de un solo grupo, projectairframe/contributors, así que una salida saca a la persona de todos ellos en la siguiente ejecución de la cadena; la raíz de Grafana agrega solo a personas activas con un nombre de usuario de Grafana; la compuerta de aprobación cuenta solo a personas activas. El lint rechaza a una persona que se fue en cualquier equipo o lista de líderes, así que el merge request que marca a alguien como departed también lo saca de cada equipo y cada lista de líderes.
Estado: aplicado
Fuente: 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

Los aprobadores con nombre de la política de aprobación siguen al catálogo.

Mecanismo: El trabajo policy:approvers compara la lista con las personas activas del catálogo con una cuenta de GitLab. En security-policies se ejecuta en cada merge request y en main, y un fallo se ve en el merge request. En control-plane se ejecuta después de cada merge al catálogo, donde una persona que hay que agregar o quitar solo genera una advertencia, así que la cadena del catálogo sigue, y cada día, donde falla y policy:approvers:report mantiene un issue con el cambio exacto que hay que hacer. Un rol, un grupo o un id entre los aprobadores, o cualquier aprobador que no sea la cuenta de la compuerta en la regla de la propia compuerta, hace fallar todas las ejecuciones. Mientras la lista no se pone al día, una persona que todavía no figura en ella no puede aprobar, y una persona que se fue y sigue en ella no llega a ningún repositorio de la plataforma, porque las personas llegan a ellos solo a través del grupo projectairframe/contributors, cuyos miembros salen del catálogo. Lo que sostiene la lista es la aprobación de cada cambio en security-policies por una persona con nombre, nunca su autor.
Estado: convención
Fuente: 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

La aprobación de la compuerta se exige en todos los repositorios menos uno.

Mecanismo: La política de la compuerta de responsables cubre los repositorios que la compuerta exige, hoy todos menos security-policies, que guarda las reglas de aprobación. Un repositorio nuevo se suma con dos merge requests, uno en control-plane y otro en security-policies; mientras tanto, solo necesita la aprobación de una persona con nombre.
Estado: aplicado
Fuente: security-policies .gitlab/security-policies/policy.yml; control-plane gate/

Un cambio todavía puede integrarse cuando la compuerta funciona pero no puede aprobarlo.

Mecanismo: Un merge request en security-policies, aprobado por una persona con nombre que no lo escribió, saca al repositorio bloqueado del alcance de la política de la compuerta, y un segundo lo vuelve a poner. Esto se ensayó: la regla dejó un repositorio de producto 11 segundos después del primer merge y volvió 35 segundos después de la reversión.
Estado: aplicado
Fuente: control-plane docs/security-policies.md; security-policies .gitlab/security-policies/policy.yml

Un cambio en un repositorio de la plataforma todavía puede integrarse cuando no se puede llegar a la compuerta.

Mecanismo: security-policies está fuera de la política de ejecución de pipelines de todo el grupo, así que sus propios pipelines no llevan gate:integrity y sus merge requests no esperan a la compuerta. Un merge request ahí, aprobado por una persona con nombre que no lo escribió, saca un repositorio del alcance de la política required ownership gate y lo agrega a las exclusiones de esa política de ejecución; ese repositorio entonces integra solo con la aprobación de alguien que no es el autor, y un merge request inverso devuelve las dos. Durante la ventana el ejecutor no planifica, no construye ni promueve nada para él. El ensayo del 2026-10-02 sacó un repositorio de la plataforma y lo devolvió con la compuerta en funcionamiento: la regla salió en 10 segundos y volvió 16 segundos después del merge inverso. Luego dejó la compuerta inalcanzable durante dos minutos: un pipeline de otro repositorio falló de forma cerrada 10 segundos después de empezar, y el pipeline de security-policies pasó. El repositorio de un producto no puede integrar así, porque su merge también espera la verificación de estado Airframe cost, que solo fija la compuerta; no está decidido si un cambio urgente de un producto espera a la compuerta o tiene una salida por esa verificación. Lo que se pierde en una caída: GitLab no vuelve a enviar un evento de auditoría que la compuerta no pudo recibir. El 2026-10-02, 34 de los 35 pipelines del grupo que fallaron entre las 09:00 y las 15:30 UTC tienen su evento de fallo en el registro de la compuerta; el que no lo tiene falló durante la caída. Desde esa tarde un segundo destino de transmisión envía cada evento al receptor de auditoría, un servicio de Cloud Run aparte que ejecuta la imagen de la compuerta con solo la ruta de auditoría, así que el bucket de auditoría bloqueado pierde un evento solo cuando ninguno de los dos está disponible; las detecciones leen solo la copia de la compuerta, así que una caída de la compuerta sigue ocultándoles sus eventos.
Estado: aplicado
Fuente: security-policies .gitlab/security-policies/policy.yml; control-plane docs/adr/0032-a-gate-that-cannot-be-reached.md (pendientes 5 y 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

Una caída de la compuerta se atiende con un procedimiento escrito, empezando por recuperar la propia compuerta.

Mecanismo: El ADR-0032 de control-plane fija dos etapas. Primero se recupera la compuerta en Google Cloud, porque no puede volver a desplegarse por su propio pipeline mientras está caída: con una concesión de nivel 2 de Privileged Access Manager que aprueba otro miembro del grupo de plataforma, el tráfico de Cloud Run vuelve a la última revisión que funcionó, unos 22 segundos en cada sentido en el ensayo. Solo si eso no restableció la compuerta en 30 minutos, y un cambio no puede esperar, un repositorio sale de los dos controles de la compuerta, por dos horas como máximo, como arriba. Las aprobaciones están aplicadas: Privileged Access Manager rechaza que quien pide apruebe su propia solicitud, y la política de aprobación rechaza la del autor. El orden, los 30 minutos y el issue que lleva la cronología están escritos y ensayados, y nada rechaza un merge request de emergencia que se los salte.
Estado: convención
Fuente: 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

Una ventana de emergencia para un repositorio termina a las dos horas.

Mecanismo: Nada la cierra: terminar la ventana es el merge request inverso de una persona. Quien verifica el límite es el pipeline programado de control-plane, que se ejecuta una vez al día, así que un exceso se ve en la ejecución del día siguiente. breakglass:check compara el archivo de políticas de security-policies con el estado normal, avisa mientras una diferencia tiene menos de dos horas y falla después, con los repositorios nombrados, y breakglass:report mantiene abierto un issue con la etiqueta audit::misconfiguration hasta que las políticas coinciden otra vez.
Estado: convención
Fuente: control-plane cli/breakglass_bound.py, .gitlab-ci.yml (breakglass:check, breakglass:report), docs/adr/0032-a-gate-that-cannot-be-reached.md

Ninguna variable de proyecto, de grupo o de pipeline puede apuntar el trabajo de integridad de la compuerta a otro lugar ni vaciarlo.

Mecanismo: El trabajo se ejecuta donde la política de todo el grupo lo inyecta: en cada repositorio menos security-policies y uno sacado para una ventana de emergencia. Define él mismo la dirección de la compuerta, y una dirección vacía falla de forma cerrada, como una compuerta inalcanzable. Las dos políticas de ejecución de pipelines no permiten anular variables, así que ninguna variable de proyecto, de grupo, de instancia ni de pipeline llega a los trabajos que inyectan. Hasta el 2026-10-02 el trabajo leía su dirección de una variable de grupo y registraba un pase cuando estaba vacía; ese respaldo ya no existe.
Estado: aplicado
Fuente: security-policies templates/airframe.yml, .gitlab/security-policies/policy.yml; control-plane docs/adr/0032-a-gate-that-cannot-be-reached.md

Un producto se crea sin que nadie ejecute un comando.

Mecanismo: El pipeline del catálogo inicia la cadena de raíces de Terraform después del merge, y cada raíz se aplica con una identidad de pipeline que solo un trabajo de su propio repositorio, en una ref protegida de su entorno, puede obtener.
Estado: aplicado
Fuente: catalog .gitlab-ci.yml; landing-zone roots/wif/

Solo un cambio aprobado recibe una vista previa, y nunca con la identidad de producción.

Mecanismo: La compuerta de aprobación inicia la ejecución de vista previa del ejecutor solo cuando aprueba el merge request de un producto, y no para un producto en retiro; la ejecución aplica la raíz infra/eph del producto con la identidad de apply de no producción, después de que el paquete de políticas revisó el plan. Alguien que solo puede abrir merge requests no puede inflar la factura.
Estado: aplicado
Fuente: control-plane executor/scripts/preview.sh, docs/adr/0016-the-preview-lifecycle-through-the-executor.md

El merge request muestra cuánto avanzó el producto.

Mecanismo: Después del merge, el trabajo de progreso del catálogo sigue la cadena, y la compuerta de aprobación mantiene una nota en el merge request integrado hasta que el producto responde en su hostname, falla un trabajo o pasan tres horas.
Estado: aplicado
Fuente: control-plane templates/progress/, gate/src/adapters/gitlab-progress.ts

Retirar un producto requiere dos aprobaciones además de la del autor.

Mecanismo: La regla de ciclo de vida de la compuerta pide dos aprobadores distintos, ninguno de ellos el autor: uno del equipo del producto y otro de los líderes del dominio o del equipo de la plataforma. El trabajo de ciclo de vida del catálogo exige la etiqueta lifecycle y los estados en orden. Hoy los dos pueden ser cuentas propias del mantenedor.
Estado: aplicado
Fuente: control-plane gate/src/core/ownership.ts; catalog scripts/lifecycle-check.mjs

El Terraform de un producto no puede leer las credenciales del pipeline.

Mecanismo: Antes de cualquier plan, el ejecutor rechaza en la raíz de un producto toda función de plantilla y toda lectura de archivo que no sea un archivo que el commit trae o uno de un módulo fijado, y ejecuta el Terraform del producto como un usuario aparte, con un entorno limpio y un solo token. Esa segunda capa está probada en el pipeline y todavía no se ejerció con el plan real de un producto.
Estado: aplicado
Fuente: control-plane executor/scripts/security.py, executor/scripts/worker.py, docs/adr/0028-a-products-terraform-runs-as-a-worker-with-one-token.md

Un producto no puede reclamar el nombre de host, el backend ni la identidad de otro producto en la red compartida.

Mecanismo: La raíz de red toma el dueño y la edición de cada publicación del nombre del objeto, compara con ellos cada afirmación que contiene, y rechaza por separado una publicación inválida o disputada: el nombre de host y el backend de una ruta, y la identidad de un alcance o de un objeto de salida, deben ser del dueño. Conservar la última configuración válida está pendiente.
Estado: aplicado
Fuente: landing-zone docs/adr/0024-the-edge-publications-are-checked-against-their-owner.md, docs/reviews/2026-09-26-implementation-review.md (R02)

La dirección de un alcance pertenece a un servicio de su propio dueño.

Mecanismo: La raíz de red solo verifica que la dirección de un alcance esté en el rango de acceso a servicios privados de la red de la edición, no que sea la base de datos o la caché del propio dueño. Así, un producto puede abrir el camino de su propia identidad hacia la dirección de la base de datos o la caché de otro producto en ese rango, detrás de la autenticación propia de ese servicio. Una verificación del dueño de la dirección está pendiente.
Estado: diseñado
Fuente: landing-zone docs/adr/0024-the-edge-publications-are-checked-against-their-owner.md, docs/reviews/2026-09-26-implementation-review.md (R02)

Una aprobación es un inicio de sesión nuevo, no una sesión.

Mecanismo: El diseño exige volver a autenticarse en cada aprobación. Está desactivado, un apartamiento registrado del diseño: mientras no esté activo, una aprobación dada con la sesión o el token de una persona cuenta como de esa persona.
Estado: diseñado
Fuente: landing-zone docs/adaptations.md (fila 32); security-policies .gitlab/security-policies/policy.yml

Un producto de criticidad 1 se publica con verificación, un período de observación y un canario.

Mecanismo: Las criticidades 2 y 3 siguen el orden diseñado. La criticidad 1 toma el orden de la criticidad 2, porque el componente de despliegue de las etapas posteriores no está construido; la organización de demostración no tiene ningún producto de criticidad 1.
Estado: diseñado
Fuente: landing-zone docs/adaptations.md (fila 48)

Un producto repartido en varios repositorios, cada uno desplegando su parte.

Mecanismo: El catálogo acepta los repositorios de una entrada y los contratos nombran su estado, sus identidades y sus hostnames, pero nada los lee todavía, y la decisión de diseño sigue siendo una propuesta.
Estado: diseñado
Fuente: landing-zone docs/adr/0017-multi-repository-products-and-adoption-by-moving-the-group.md

Políticas

Las pruebas del paquete de políticas se ejecutan con cada cambio en él.

Mecanismo: El trabajo policy:test de control-plane ejecuta las pruebas unitarias de Conftest y los casos que deben pasar y fallar en cada merge request que cambia el paquete, y GitLab solo integra un merge request cuyo pipeline termina bien.
Estado: aplicado
Fuente: control-plane .gitlab-ci.yml (policy:test), policy/airframe/

Cada regla trae un caso que debe aceptar y otro que debe rechazar.

Mecanismo: Las convenciones de trabajo y la documentación del paquete piden los dos. La revisión lo sostiene; ningún trabajo verifica que una regla nueva traiga sus pruebas.
Estado: convención
Fuente: control-plane docs/policy-pack.md

El repositorio de un producto no puede saltarse la validación.

Mecanismo: La política de ejecución de pipelines de producto inyecta los componentes validate y build-test en cada pipeline de los repositorios de los grupos de recorrido, y GitLab no deja que el archivo propio de ningún proyecto quite o reemplace un trabajo inyectado.
Estado: aplicado
Fuente: security-policies .gitlab/security-policies/policy.yml, templates/product.yml

El archivo de pipeline de un producto incluye solo los componentes de la plataforma, y ninguno de sus propios trabajos despliega.

Mecanismo: Las reglas de pipeline del paquete rechazan una inclusión que no sea uno de los ocho componentes con nombre de control-plane, un trabajo que declara un entorno y un trabajo que dispara otro pipeline; la validación inyectada las ejecuta sobre el archivo del producto.
Estado: aplicado
Fuente: control-plane policy/airframe/pipeline.rego, docs/adr/0026-a-product-job-never-deploys.md

Una regla que rechaza detiene el cambio.

Mecanismo: Un rechazo hace fallar el trabajo de validación inyectado, y GitLab integra el merge request de un producto solo cuando su pipeline termina bien. En main, policy:<root> ejecuta el paquete sobre el plan, y el apply necesita que pase. Las reglas de costo se ejecutan en el ejecutor y deciden la verificación de estado Airframe cost.
Estado: aplicado
Fuente: control-plane templates/validate/template.yml, templates/tf-apply/template.yml

Una advertencia necesita la aprobación de la plataforma y una fila en el registro de excepciones.

Mecanismo: Hoy una advertencia aparece en el registro del trabajo y no detiene nada: Conftest se ejecuta sin fallar por advertencias, aunque la documentación del paquete y algunos mensajes dicen que hace falta una aprobación.
Estado: diseñado
Fuente: control-plane docs/policy-pack.md, templates/validate/template.yml

Una regla nueva de rechazo pasa una versión de la plataforma como advertencia, y después rechaza.

Mecanismo: Las convenciones de trabajo lo piden, y nada convierte una advertencia en rechazo. Varias reglas marcadas como advertencias por una versión, como las reglas de la base de datos sidecar, la verificación de invocador del borde y las inclusiones obligatorias del archivo de un producto, siguen siendo advertencias en la versión 2026.10.01-1.
Estado: convención
Fuente: control-plane policy/airframe/cloud_run.rego, pipeline.rego, docs/policy-pack.md

Los recursos propios se permiten, con una advertencia.

Mecanismo: El paquete advierte sobre cada recurso administrado que la raíz de un producto declara fuera de un módulo, y pide una razón en el merge request; una advertencia no hace fallar nada. Sus reglas de rechazo se aplican a todo recurso, propio o no, y los tipos que son de la plataforma, como redes, proyectos y perímetros, se rechazan en la raíz de un producto.
Estado: aplicado
Fuente: control-plane policy/airframe/naming.rego, platform_owned.rego

Ningún cambio de Terraform da el rol owner o editor, ni nada al público.

Mecanismo: Las reglas de IAM del paquete rechazan owner y editor en cualquier forma, y cualquier permiso a allUsers o allAuthenticatedUsers, en el código y en el plan.
Estado: aplicado
Fuente: control-plane policy/airframe/iam.rego

Cada recurso etiquetado lleva el conjunto completo de etiquetas de la plataforma.

Mecanismo: La regla de etiquetas rechaza un recurso al que le falte cualquiera de las seis que nombran los contratos, en el código y en el plan.
Estado: aplicado
Fuente: control-plane policy/airframe/naming.rego; landing-zone docs/contracts.md 7

Cada recurso lleva las etiquetas de la plataforma, incluso uno que no declara ninguna.

Mecanismo: Los contratos piden etiquetas en cada proyecto y recurso. La regla de etiquetas revisa las etiquetas que un recurso declara, así que un recurso sin ningún atributo de etiquetas la pasa.
Estado: diseñado
Fuente: landing-zone docs/contracts.md 7; control-plane policy/airframe/naming.rego

La laptop ejecuta la validación del merge request.

Mecanismo: airframe validate ejecuta los comandos de formato, terraform validate y paquete de políticas del componente validate, sin backend y sin credenciales; OpenTofu y tflint se ejecutan solo donde están instalados. Ejecutarlo es una convención, y el merge request ejecuta las verificaciones de todos modos. Lee el paquete del clon de control-plane desde el que se instaló, no de la versión de la plataforma del producto, y no ejecuta el lint del catálogo, la compuerta, las pruebas de la aplicación, el plan ni su precio; donde están Infracost y su clave, muestra una estimación a partir del código.
Estado: convención
Fuente: control-plane cli/airframe-validate.sh

`airframe validate` ejecuta las pruebas de módulos, el lint de las especificaciones de API y la verificación de compatibilidad de API.

Mecanismo: Las convenciones de trabajo del espacio de trabajo enumeran las tres; el script no ejecuta ninguna.
Estado: diseñado
Fuente: control-plane cli/airframe-validate.sh

Cadena de suministro

Su propio Dockerfile se construye sobre una imagen base de la plataforma.

Mecanismo: Las reglas de Dockerfile del paquete rechazan un FROM o un COPY --from fuera de las imágenes base de la plataforma, uno sin fijar y uno calculado a partir de un argumento de compilación, en los Dockerfiles que enumera .airframe/images.yaml. Desde la versión 2026.10.01-1, la validación inyectada las ejecuta en cada merge request que cambia un Dockerfile enumerado llamado Dockerfile, Dockerfile.*, *.Dockerfile o *.dockerfile, y airframe validate las ejecuta en la máquina local. El constructor de confianza construye y atesta exactamente esa lista.
Estado: aplicado
Fuente: control-plane policy/airframe/dockerfile.rego, templates/validate/template.yml

Un merge request que cambia solo un Dockerfile enumerado se juzga, sea cual sea su nombre.

Mecanismo: Un Dockerfile enumerado con otro nombre, como Containerfile, se juzga solo cuando el merge request también cambia otro archivo que la validación vigila.
Estado: diseñado
Fuente: control-plane templates/validate/template.yml, docs/adr/0014-approved-base-images-built-in-project-and-checked-on-every-from.md

Cada stack se construye y se prueba cuando cambia su parte de la plantilla.

Mecanismo: El pipeline de golden-path vuelve a generar los tres ejemplos y exige que coincidan con los guardados cada vez que cambia la plantilla, y construye y prueba el ejemplo de un stack cuando cambian los archivos de ese stack. El catálogo de demostración tiene un producto activo en cada stack.
Estado: aplicado
Fuente: golden-path .gitlab-ci.yml (template:render, template:test)

Un stack que la plantilla no ofrece se construye sobre una imagen base de la plataforma, sin las pruebas de la plataforma.

Mecanismo: Las reglas de imagen base se aplican a cada Dockerfile enumerado. Los trabajos inyectados de compilación y pruebas conocen solo los tres stacks de la plantilla, así que otro stack no ejecuta ninguno y no pasa el umbral de cobertura hasta que su entrada baje quality.minimum_coverage.
Estado: aplicado
Fuente: control-plane templates/build-test/template.yml

Un servicio de producto desplegado con el golden path ejecuta solo una imagen que la plataforma construyó y promovió.

Mecanismo: El módulo de Cloud Run del golden path adhiere cada servicio a la política de Binary Authorization de su proyecto, que en el proyecto de producción de un producto facturado se aplica y exige las atestaciones de compilación y de promoción; la raíz trusted-builder deja firmar solo a la identidad que firma las compilaciones y al promotor de artefactos.
Estado: aplicado
Fuente: golden-path modules/service-project/main.tf, modules/cloud-run-service/main.tf; control-plane roots/trusted-builder/

Binary Authorization rige para cada servicio de Cloud Run, como parte de la base.

Mecanismo: La arquitectura 9.3 la cuenta entre los controles que se sostienen si se elude un pipeline. Lo construido es una adhesión por servicio, escrita solo para productos facturados: ninguna política de la organización exige que un servicio se adhiera, un servicio de Cloud Run propio pasa el paquete con una advertencia, y la puerta de enlace de telemetría de la plataforma se ejecuta sin ella.
Estado: diseñado
Fuente: landing-zone docs/architecture.md 9.3, roots/organisation/policies.tf; golden-path modules/cloud-run-service/main.tf

Cada imagen se analiza en busca de vulnerabilidades conocidas en la compilación de confianza.

Mecanismo: El constructor de confianza ejecuta grype sobre cada imagen que construye, con una base de datos de vulnerabilidades que la plataforma prepara una vez al día y que solo usa si tiene como máximo 48 horas y coincide con su suma de verificación; si no, grype descarga la base de datos del proveedor para esa compilación. El análisis y la lista de materiales de software de la imagen se guardan junto al digest de la imagen como evidencia, con constancia de qué base de datos se usó, y los hallazgos llegan al informe de vulnerabilidades de GitLab en la promoción. Un hallazgo avisa: no bloquea un despliegue.
Estado: aplicado
Fuente: 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

La atestación de compilación se firma aparte de la compilación.

Mecanismo: El constructor de confianza construye y analiza; build-attestor@, que solo el ejecutor puede suplantar, firma la atestación de compilación después de que el ejecutor comparó la compilación con el registro propio de Cloud Build. La promoción a producción agrega una segunda atestación.
Estado: aplicado
Fuente: control-plane roots/trusted-builder/main.tf, docs/adr/0029-the-build-attestation-is-signed-apart-from-the-build.md

Cada imagen se vuelve a analizar, aparte de la compilación.

Mecanismo: El análisis del constructor se ejecuta dentro de la compilación, y su resultado llega al informe de vulnerabilidades de GitLab en la promoción. Un análisis independiente de cada digest fuera de la compilación figura como pendiente.
Estado: diseñado
Fuente: landing-zone docs/reviews/2026-09-26-implementation-review.md (R03)

Una versión de la plataforma revocada no ejecuta ningún pipeline nuevo.

Mecanismo: El trabajo de integridad de la compuerta, que la política de ejecución de pipelines del grupo inyecta en cada pipeline, lee las versiones permitidas en la rama main de control-plane y hace fallar un pipeline que incluye una revocada; el ejecutor hace la misma verificación antes de que una ejecución de merge request o de versión tenga las credenciales de un producto.
Estado: aplicado
Fuente: control-plane gate/src/core/releases.ts, executor/scripts/release_check.py, releases/permitted.yaml

Una versión de la plataforma es un conjunto fijo de commits, verificados juntos.

Mecanismo: Una versión es un manifiesto del commit de cada parte, que no cambia una vez integrado, verificado en esos commits antes de permitirse; un componente obtiene su paquete de políticas en su propio commit y nombra cada imagen por digest. Un archivo de pipeline que incluye un componente por rama o etiqueta recibe una advertencia, no un rechazo.
Estado: aplicado
Fuente: 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

Costo

Un cambio por encima del presupuesto no puede integrarse.

Mecanismo: La compuerta de aprobación define la verificación de estado Airframe cost de cada merge request de producto a partir de los planes con precio del ejecutor de cada raíz en su último commit: falla cuando el total de las raíces o cualquier raíz supera el monthly_budget de la entrada, o cuando una raíz no tiene precio. La regla del proyecto del producto exige que las verificaciones de estado pasen. Un plan en main también se detiene ante un rechazo registrado. Las vistas previas y los recursos por uso quedan fuera de la cifra.
Estado: aplicado
Fuente: control-plane gate/src/adapters/gitlab-status-checks.ts, executor/scripts/cost.sh, docs/adr/0025-the-merge-waits-for-the-cost-verdict.md

Subir un presupuesto requiere a un líder del dominio.

Mecanismo: La regla de responsables de la compuerta exige la aprobación de un líder del dominio para un cambio del catálogo que sube monthly_budget; donde los líderes del dominio no tienen cuenta de GitLab, como en la demostración, el equipo de la plataforma los reemplaza.
Estado: aplicado
Fuente: control-plane gate/src/core/ownership.ts

Cada producto tiene un panel de costo frente a su presupuesto.

Mecanismo: La raíz de Grafana de operations, que se ejecuta cuando cambia el catálogo, crea un panel de costo en la carpeta de cada producto: el mes en curso y la proyección frente a monthly_budget, naranja al 80 por ciento y rojo al 100, desde la exportación de facturación a través del trabajo diario cost:report.
Estado: aplicado
Fuente: operations roots/grafana/pack.tf, roots/cost/

Los presupuestos de Google Cloud siguen la misma cifra.

Mecanismo: La fábrica de proyectos del dominio crea un presupuesto en cada proyecto de producto facturado a partir de monthly_budget, 70 por ciento para producción y 30 para no producción, con alertas al 80 y al 100 por ciento. Ningún producto de demostración está facturado hoy, así que ninguno tiene todavía los presupuestos de sus proyectos.
Estado: aplicado
Fuente: landing-zone roots/project-factory/

Una alerta de presupuesto llega al equipo del producto.

Mecanismo: Cuando un producto está facturado, las alertas de sus presupuestos van por correo a los administradores y usuarios de la cuenta de facturación, lo predeterminado de Google, no al equipo.
Estado: diseñado
Fuente: landing-zone roots/project-factory/

Un aumento de costo de más de USD 10 o del 25 por ciento al mes necesita la aprobación de la plataforma.

Mecanismo: Hoy ese aumento es una advertencia en la nota de la raíz en el merge request y no detiene nada.
Estado: diseñado
Fuente: control-plane policy/airframe/cost.rego

Una vista previa se destruye cuando termina su merge request.

Mecanismo: La compuerta de aprobación se entera del merge o del cierre por el webhook de GitLab e inicia la ejecución de destrucción del ejecutor, que verifica por sí misma el estado del merge request. El registro de cada vista previa tiene un bloqueo, así que un apply y una destrucción nunca se ejecutan a la vez, y un merge request reabierto empieza una nueva generación, así que una destrucción tardía no puede quitar la vista previa nueva.
Estado: aplicado
Fuente: control-plane executor/scripts/preview.sh, executor/scripts/preview_record.py

Una vista previa vencida u olvidada se recoge.

Mecanismo: preview:collect, en el pipeline programado diario de control-plane, enumera las vistas previas que según los registros del ejecutor siguen activas y destruye las integradas, las cerradas y las que pasaron preview_ttl_hours (72 por defecto, como máximo 168, contadas desde el último apply), con una nota en cada merge request.
Estado: aplicado
Fuente: control-plane executor/scripts/preview.sh

Una vista previa casi no cuesta nada mientras está inactiva, y nunca bloquea un merge.

Mecanismo: El enrutador y los servicios de la vista previa escalan a cero, la base de datos sidecar predeterminada vive en la propia revisión del servicio, y el módulo de Cloud Run del golden path ejecuta el servicio de una vista previa con una instancia como máximo. El ejecutor pone precio al plan de cada vista previa y lo muestra en su nota, y la verificación de costo que retiene un merge deja fuera las vistas previas.
Estado: aplicado
Fuente: golden-path modules/preview-substrate/, modules/cloud-run-service/; control-plane executor/scripts/preview.sh

Auditoría y observabilidad

Cada concesión, y cada cambio hecho con ella, queda registrado.

Mecanismo: Privileged Access Manager guarda cada concesión con quien la pidió, la justificación, quien la aprobó y su motivo, y el registro de auditoría de Google Cloud guarda cada cambio; los registros de Data Access en la carpeta también guardan las lecturas de Secret Manager, Cloud SQL, Cloud Storage, IAM y Cloud KMS.
Estado: aplicado
Fuente: landing-zone roots/pam/, roots/audit/main.tf

Cada uso de una concesión tiene una fila en el registro del arranque.

Mecanismo: La fila nombra la concesión, quién la pidió y quién la aprobó, la raíz y el commit aplicados, y el plan vacío posterior. Está escrito y se enseña; nada rechaza una concesión sin fila.
Estado: convención
Fuente: landing-zone docs/bootstrap-log.md

Cada registro de auditoría de Google Cloud llega a un solo bucket, y ningún pipeline puede desviarlo.

Mecanismo: Un sink agregado en la carpeta envía los registros de auditoría de cada proyecto, y los eventos de auditoría de GitLab a través de la compuerta y el receptor de auditoría, a un bucket en lk-audit cifrado con una clave que tiene la plataforma. La política de denegación rechaza cualquier cambio en un sink de la carpeta a todos menos el grupo de emergencia, la cuenta de administrador del arranque y el agente de servicio de Privileged Access Manager. La política de IAM de la carpeta, que guarda la configuración de auditoría, tiene las mismas excepciones y una cuarta, la identidad que configura las concesiones; esa identidad actúa solo desde código revisado, y la condición sobre su acceso exige que un cambio modifique al menos una concesión y solo de los roles que dan los derechos, así que una llamada que cambia únicamente la configuración de auditoría se rechaza. Una llamada que cambia a la vez una concesión permitida y la configuración de auditoría todavía pasa: en la carpeta, una regla de Grafana avisa cuando cambia una configuración de auditoría, y en la organización no hay sink. El sink deja fuera las entradas de prueba de VPC Service Controls, que registran lo que un perímetro habría rechazado y no un rechazo; el registro propio de cada proyecto las conserva. Los eventos de auditoría de GitLab llegan al bucket por dos destinos de transmisión, la compuerta y el receptor de auditoría, y cada uno escribe todos los eventos; GitLab no vuelve a enviar un evento, así que un evento creado mientras ninguno de los dos está disponible falta en el bucket, y si su tipo es de los que GitLab solo transmite no se registra en ningún lugar.
Estado: aplicado
Fuente: 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 (pendiente 7), gate/infra/audit-receiver.tf

La retención del bucket de auditoría está bloqueada.

Mecanismo: Una política de retención guarda cada objeto durante 365 días, y ninguno se puede borrar ni sobrescribir antes. La política está bloqueada desde el 2026-10-01, lo que Google hace irreversible: nadie, ni un administrador con una concesión, puede acortarla ni quitarla, y el proyecto de auditoría no se puede borrar mientras el bucket tenga objetos.
Estado: aplicado
Fuente: landing-zone roots/audit/main.tf, roots/audit/terraform.tfvars, docs/bootstrap-log.md

Los datos no pueden salir de los proyectos de la plataforma por las API de Google, ni siquiera con credenciales válidas.

Mecanismo: Tres perímetros de VPC Service Controls, de producción, no producción y auditoría, se aplican como especificaciones en modo de prueba: una posible infracción se registra, y no se bloquea nada. Aplicarlos es una variable. Las lecturas diarias de la raíz de la organización que un perímetro rechazaría vienen de dentro del perímetro de producción, del runner de confianza en la VPC de la red de producción, porque la lista de servicios alcanzables desde esa VPC no los incluye; no son llamadas desde fuera.
Estado: diseñado
Fuente: landing-zone roots/perimeters/

Un uso sospechoso genera una alerta: un intento de crear una clave, un rechazo de la política de denegación, una concesión, una identidad usada fuera de su pipeline.

Mecanismo: Un segundo sink, estrecho, en la carpeta envía solo estas entradas a Loki: un intento de crear una clave, un rechazo de una política de denegación o de la organización, un token rechazado, un cambio en los sinks, las políticas de denegación o la configuración de auditoría de la carpeta, una concesión, y los eventos de auditoría de GitLab. Reglas en Grafana avisan con urgencia a la plataforma por los cinco primeros y abren un ticket por una concesión o una ráfaga de cambios en GitLab. Un evento en la propia organización, como una concesión a nivel de organización, queda fuera de los sinks de la carpeta; la notificación al aprobador es su único registro además del registro de auditoría. Los eventos de GitLab llegan a través de la compuerta, así que los creados mientras no se puede llegar a ella nunca llegan, y ninguna regla los ve.
Estado: aplicado
Fuente: landing-zone roots/audit/main.tf, docs/adr/0027-the-audit-detections-alert-in-grafana.md; operations roots/grafana/detections.tf

La deriva se informa.

Mecanismo: El trabajo de deriva del componente tf-apply planifica cada raíz con la programación diaria del repositorio, y el componente drift-report, como la identidad de auditoría, mantiene un issue con la etiqueta audit::drift por cada raíz con deriva, lo reescribe y lo cierra cuando el plan vuelve a estar vacío.
Estado: aplicado
Fuente: control-plane templates/tf-apply/, templates/drift-report/

El trabajo de un agente de código queda etiquetado.

Mecanismo: Las instrucciones para un agente de código y el skill airframe-platform piden un trailer Generated-by en cada commit y la etiqueta agent en el merge request, y la configuración de GitLab de la plataforma define la etiqueta. Ningún trabajo ni regla verifica ninguno de los dos, así que registran lo que declara un agente de código o su usuario.
Estado: convención
Fuente: golden-path template/; platform-skills skills/

Una auditoría puede distinguir el trabajo de un agente de código del de una persona, y medir su parte.

Mecanismo: Para eso están diseñados el trailer y la etiqueta; como nada los verifica, hoy no pueden demostrarlo.
Estado: diseñado
Fuente: landing-zone docs/architecture.md 9.7

Cada producto tiene sus paneles y reglas de alerta a partir de su entrada.

Mecanismo: La raíz de Grafana de operations, que se ejecuta cuando cambia el catálogo, crea la carpeta de cada producto, sus paneles de servicio y de SLO y sus reglas de alerta básicas, con umbrales tomados del slo de la entrada; las reglas seleccionan producción por la etiqueta env, y una serie que falta no es una alerta.
Estado: aplicado
Fuente: operations roots/grafana/pack.tf, alerts.tf

Una alerta llega al equipo del producto, y hoy eso significa al mantenedor.

Mecanismo: Cada regla se enruta por la etiqueta del equipo hacia el punto de contacto del equipo, que envía correo a los miembros del equipo con cuenta de Grafana, y un aviso urgente se repite cada cuatro horas hasta que se resuelve. Grafana Cloud acepta solo las direcciones de sus propios miembros, y hoy esos miembros son las cuentas propias del mantenedor, así que las alertas de cada equipo, y las de la plataforma, le llegan al mantenedor.
Estado: aplicado
Fuente: operations roots/grafana/alerts.tf, members.tf

Una aplicación no necesita configuración y no tiene ninguna credencial de Grafana.

Mecanismo: La salida Ready de la fábrica de proyectos trae la dirección de la puerta de enlace de la edición del producto, y el módulo de Cloud Run del golden path la inyecta en cada servicio. Las trazas y las métricas llegan a la puerta de enlace OTLP con el token de identidad del servicio; los registros llegan a la puerta de enlace de registros por el sink del proyecto y un buffer de Pub/Sub. Las puertas de enlace tienen el token de solo escritura de la edición, la única credencial de Grafana de ese lado.
Estado: aplicado
Fuente: operations roots/telemetry/; golden-path modules/cloud-run-service/main.tf

Cada señal dice de qué edición vino.

Mecanismo: La puerta de enlace OTLP conserva el env de una señal solo cuando es válido para su propia edición y reemplaza un valor faltante o ajeno por unknown; la puerta de enlace de registros conserva un env válido y, si no, le da a la línea el de su perímetro, así que solo las entradas de auditoría quedan en unknown. Las dos marcan la edición como perimeter. El módulo de Cloud Run del golden path les da a las trazas y las métricas de un servicio su nombre de servicio, su dominio y su entorno, y el agente de la plataforma etiqueta las métricas de recursos de Cloud de cada proyecto de producto facturado con la ruta del producto y su recorrido y dominio.
Estado: aplicado
Fuente: operations roots/telemetry/config/

Las señales de una aplicación, las métricas de recursos del agente de la plataforma y las series de las tareas programadas de la plataforma llevan el entorno del que vinieron.

Mecanismo: La puerta de enlace OTLP le da a un recurso sin env el valor de deployment.environment.name y, si falta, el de deployment.environment, el atributo que el módulo de Cloud Run del golden path fija a partir del despliegue (prod, np, sandbox o eph-<n>); un punto de datos conserva su propio env válido, y un valor que no es válido para la edición pasa a unknown. El agente de la plataforma etiqueta con env las series de cada proyecto: platform para los proyectos de la plataforma, la edición para los de un producto, y en no producción el nombre del servicio de Cloud Run lo reduce a sandbox o eph-<n>. La puerta de enlace de registros le da a una línea sin un env válido el de su perímetro, reducido de la misma manera; las líneas de un proyecto de la plataforma son platform, y las entradas de auditoría conservan unknown. Las propias tareas programadas de la plataforma (los informes de costos, de entrega y de cobertura y la comprobación diaria de Policy Analyzer) declaran deployment.environment=platform en su recurso, así que sus series llevan env platform; el informe de costos guarda el entorno del proyecto al que pertenece un costo en una etiqueta aparte, project_env (sección 7 de los contratos). Las series del informe de deriva siguen llegando como unknown hasta la próxima versión de la plataforma, porque cada repositorio ejecuta el componente drift-report de su versión. El pipeline aplica la raíz de telemetría desde la rama main de operations, y su trabajo telemetry:test genera las configuraciones reales y las ejecuta en el Alloy fijado cada vez que cambian, y falla en lugar de omitirse cuando falta el binario.
Estado: aplicado
Fuente: 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

Las señales de una aplicación llevan su equipo y su criticidad.

Mecanismo: El diseño le da a cada señal las etiquetas del catálogo, entre ellas el equipo y la criticidad. Hoy no llevan ninguna etiqueta así: las trazas y las métricas de un servicio tienen service.name, service.namespace, que es su dominio, y deployment.environment, y la puerta de enlace de registros conserva el proyecto, el servicio, el tipo de recurso, el nombre del registro y la severidad de una línea. Solo algunas series de la propia plataforma llevan un equipo, como las de los informes de entregas y de cobertura.
Estado: diseñado
Fuente: landing-zone docs/guides/observability.md (Labels); golden-path modules/cloud-run-service/main.tf; operations roots/telemetry/config/logs.alloy.tftpl

Una alerta avisa a una persona de guardia, con una programación y una cadena de escalamiento.

Mecanismo: La herramienta de guardias e incidentes de Grafana tendría las dos para cada equipo, a partir del catálogo. Hoy una alerta es un correo.
Estado: diseñado
Fuente: landing-zone docs/architecture.md 13.5

Una caída de la compuerta se nota sin esperar a los pipelines en rojo.

Mecanismo: Una verificación HTTP de Synthetic Monitoring de Grafana Cloud, airframe-gate, consulta https://gate.projectairframe.dev/health cada 60 segundos desde dos sondas. Una regla del grupo airframe-platform avisa al punto de contacto de la plataforma cuando más de una sonda falla durante dos minutos, o cuando la verificación no informa nada. La verificación cubre solo la compuerta; ningún otro hostname tiene una. Hoy un aviso es un correo al mantenedor.
Estado: aplicado
Fuente: operations roots/grafana/synthetic.tf, alerts.tf, docs/adr/0012-the-gate-uptime-check-in-synthetic-monitoring.md

La base de alertas cubre cada falla que nombra el diseño.

Mecanismo: Cloud Run en su máximo de instancias, los reinicios o la falta de memoria, una verificación de contrato bloqueada en main, y las verificaciones de disponibilidad a través del hostname de producción de cada producto están diseñadas; la raíz de Grafana todavía no crea esas reglas. La verificación de disponibilidad de la compuerta, arriba, es la única construida.
Estado: diseñado
Fuente: landing-zone docs/architecture.md 13.4, 13.6; operations roots/grafana/pack.tf

Un agente de operaciones investiga una alerta, y un agente de auditoría busca desperdicio y huérfanos.

Mecanismo: El primero actuaría dentro de lo que permite el agentic_ops de la entrada; el segundo miraría toda la organización, y encontraría una vista previa sin registro o una destrucción fallida. Ninguno existe hoy.
Estado: diseñado
Fuente: landing-zone docs/architecture.md 14.3

Documentación

Un skill dice lo que hacen las verificaciones de la plataforma.

Mecanismo: Los trabajos skills:policy, skills:validate, skills:catalog y skills:references del pipeline de platform-skills verifican los ejemplos de cada skill contra el paquete de políticas en el commit de control-plane que fijan los skills, terraform validate y el lint del catálogo, y verifican las rutas que nombra un skill; GitLab integra un cambio solo cuando pasan. El release:check de control-plane exige que esa fijación sea la de la versión de la plataforma. Si un agente de código carga un skill depende del agente y de su usuario.
Estado: aplicado
Fuente: platform-skills .gitlab-ci.yml; control-plane .gitlab-ci.yml (release:check)

Cada skill trae ejemplos que las verificaciones deben aceptar o rechazar.

Mecanismo: El README de platform-skills dice que cada skill viene con sus pruebas y que un skill sin pruebas no se integra, y cuatro de los cinco skills traen ejemplos que deben pasar y fallar. El skill de visión general, airframe-platform, no trae ninguno: su única prueba, tests/references, verifica que existan las rutas que nombra. Nada rechaza un skill sin ejemplos.
Estado: convención
Fuente: platform-skills README.md, skills/airframe-platform/

Cada producto publica su propia parte del mapa, y solo la suya.

Mecanismo: El trabajo validate:fragment del componente catalog-publish construye el fragmento en el merge request sin ninguna credencial; en la rama main protegida, release:catalog lo publica con la identidad que el repositorio ya tiene. La identidad de apply de producción de un producto puede escribir solo bajo el prefijo de su producto. Los cuatro repositorios de la plataforma comparten una identidad, platform-docs@, cuyo permiso cubre todo el prefijo de la plataforma, así que nada impide que uno escriba la parte de otro.
Estado: aplicado
Fuente: control-plane templates/catalog-publish/template.yml, roots/executor/variables.tf

El mapa se reconstruye solo a partir de los últimos fragmentos.

Mecanismo: El agregador, un trabajo de Cloud Run, se ejecuta cuando una identidad que publica lo pide después de una publicación, y cada hora según una programación. Lee la lista de productos del catálogo, omite un fragmento roto dejando sus motivos en el registro de la ejecución y guarda las tres últimas versiones.
Estado: aplicado
Fuente: operations eventcatalog/, roots/eventcatalog/

Un agente de código puede consultar el mapa con el servidor MCP del catálogo.

Mecanismo: El servidor está diseñado; el índice legible por máquina que leería se publica hoy junto a cada compilación.
Estado: diseñado
Fuente: landing-zone docs/guides/architecture-catalog.md

Los documentos de la plataforma coinciden con su código.

Mecanismo: Un cambio lleva sus documentos en el mismo merge request y la revisión lo sostiene; ningún trabajo compara los dos. Diferencias conocidas hoy: la guía de seguridad pone Binary Authorization en cada proyecto; la guía de observabilidad le da a cada equipo una programación de guardias; el ADR-0016 dice que la destrucción de una vista previa quita su estado, que el ejecutor conserva; y los contratos cuentan el tiempo de vida de una vista previa desde su último push, el ejecutor desde su último apply.
Estado: convención
Fuente: 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

Dónde está

En el repositorio landing-zone:

En el repositorio control-plane:

docs/policy-pack.md: cada regla, con su nivel