Expansion · 02 of 03 · Governance
Where the policy lives
Architects and security teams own the rules. The platform team owns the code that enforces them. The developer owns a short request, and never has to read either.
Where the policy lives
Three rows. Who writes the policy: Enterprise Architecture (standards and approved patterns) and Security (controls and data classification) hand their standards, in words, to the platform team, which turns both into code in git. Policy as code lives in three places. The XRD schema decides what you can ask for; built in Hangar today: enums and patterns for runtime, architecture and region, and CEL rules across fields, such as RabbitMQ attach mode needing a broker. The Composition decides what you always get; built today: gates and safe defaults, like the live dev cluster check and no Delete on repositories; a proposal, drawn dashed: tags, roles and encryption on every cloud resource. Admission and CI, drawn as a fence, decide what nobody gets; built today: a Kyverno admission policy so a test mounts only its own secret, and airframe-validate in CI keeping release-owned keys where they belong. A developer writes kind LambdaFunction with a few fields in plain words, Airframe applies all three on create and on every change, and the result is a service that already complies, with the paperwork done.
WHO WRITES THE POLICY POLICY AS CODE WHAT A DEVELOPER DOES Enterprise Architecture standards · approved patterns Security controls · data classification Platform team turns both into code, in git STANDARDS, IN WORDS The XRD schema what you can ask for Enums and patterns runtime · architecture · region CEL rules across fields attach mode needs a broker The Composition what you always get Gates and safe defaults dev cluster check · no repo Delete Tags, roles, encryption proposal · every cloud resource Admission and CI what nobody gets Kyverno admission policy a test mounts only its own secret airframe-validate in CI release-owned keys stay put kind: LambdaFunction a few fields, in plain words Airframe applies all three on create and on every change A service that already complies the paperwork is done The policy is written once, by the people who own it, and enforced on every request. LEGEND Owns the standard Where it lives Built in Hangar Proposal A fence Hands over
The schema is the first policy. A region that is not on the list is not a value the API will take, so it never reaches a review.
The Composition adds what every service gets whether anyone asked or not. Nobody remembers the tags, because nobody has to.
Admission policies and CI checks are the fence for anything that slips around the API. They fail loudly, with a rule id a person or an agent can read.