no-fixed-cost — Every platform component is free; if it can't be, it must be consumption-based — never a flat cost.
no-human-touch — BigBang initializes the platform. After that, code is the only path to production — proof it can always be rebuilt from scratch.
no-platform-ops — The platform grows more self-sufficient, landing zones take on more ownership, and the platform team becomes less and less necessary.
no-unapproved-resources — The allowed list starts empty. A resource type joins the platform only after its security controls, telemetry, and integration patterns are in place — once it is, app teams can use it freely within the boundaries Azure Policy guarantees.
Constitutive rules
allowed-resources — An Azure resource counts as approved in Gazelle when the allowed-resources list names it.
codebase — A codebase counts as the source of truth for Gazelle when BigBang establishes it.
constitution — A JSON file counts as Gazelle's constitution when the knowledge graph holds it.
gazelle — An Azure tenant counts as Gazelle when BigBang builds it and Gazelle says what it is.
guardrail — A policy name counts as a guardrail in Gazelle when the platform assigns it.
landing-zone — An Azure subscription counts as a landing zone when the oases register names it.
monitored — An Azure resource counts as monitored in Gazelle when Azure Policy names it.
oases — A management group counts as oases when the platform establishes it.
platform-azure-identity — An Entra ID app registration counts as the platform Azure identity when Gazelle names it in configuration files.
platform-github-identity — A GitHub App counts as the platform GitHub identity when Gazelle names it in configuration files.
platform-member — A product team counts as a platform member in Gazelle when the member register names it.
platform-test-environment — A management group counts as the platform-test-environment when Gazelle names it in configuration files.
platform — A management group counts as the platform when Gazelle names it.
secure-network — An Azure resource counts as secure-network in Gazelle when Azure Policy denies its public network access.
single-region — An Azure region counts as Gazelle's single region when Azure Policy names it.
single-tenant — An Azure resource counts as single-tenant in Gazelle when Azure Policy names it.
strong-authentication — An Azure resource counts as strong-authentication in Gazelle when Azure Policy names it.
strong-transport — An Azure resource counts as strong-transport in Gazelle when Azure Policy names it.
azure-policy-custom-definition — A guardrail gap must be closed by a custom Azure Policy definition when no built-in policy can enforce the institutional fact.
diagnostic-settings-parameter-contract — The main diagnostic initiative must define shared defaults; parameter files may override only policy-specific values.
job-function-scoped-roles — A role must be scoped to a job function and assigned to the application's Entra ID group, never to an individual or a resource type.
landing-zone-action-group — Alerts must route through the landing zone's action group, addressed from the platform member profile rather than to a person.
landing-zone-allowed-public-ip — Data-plane access from outside Azure must originate from the platform-trusted public IP.
landing-zone-automation — Automation jobs must run inside the landing zone's own subscription.
landing-zone-getting-started — An application repo must be seeded with deployable pipelines and modules from the template at creation.
landing-zone-github-runners — Every landing zone must have its own private GitHub runners provisioned inside its VNet.
landing-zone-identity — A landing zone must have a single managed identity, shared across all its workflows, jobs, and service integrations.
landing-zone-monitoring — A landing zone must not share a Log Analytics Workspace with another landing zone.
landing-zone-repo — Every landing zone must be deployed and configured from its application's repository.
landing-zone-resource-group — Resources the landing zone template declares must live in a single dedicated resource group.
landing-zone-tags — Tag values on a landing zone must be sourced from the platform member profile.
landing-zone-template — Each landing zone must have its own parameter file and its own trigger workflow.
oases-ipam — VNet address spaces must be allocated by querying live Azure, not by reading an assignment registry.
oases-lifecycle — A landing zone must draw its subscription from the Subscription Bank, and must return it there when sunset rather than cancelling it.
oases-placement — The platform must not restrict landing zone placement to the production environment.
platform-break-glass — Break-glass must be used only where automation cannot execute the change.
destroy-landing-zone — A landing zone must be decommissioned through lz-flow-destroy-landing-zone, which returns its subscription to the bank.
knowledge-candidate — An observation that does not fit as a rule, a link, or a violation must be recorded as a knowledge-candidate issue rather than forced into the graph.
register-platform-member — An application must be registered through requestNew-Platform-Members before any landing zone is provisioned for it.
update-knowledge-base — A knowledge graph entry must be drafted and presented before any file is written, and must reach main through a pull request.
update-landing-zone — A landing zone must be reshaped by editing its parameter file and merging a pull request, which redeploys the stack.