Platform Design Knowledge Graph

Foundations

• 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.

Decisions

• application-teams-own-the-cost — Every subscription an application provisions bills to that application's own invoice section.
• azure-native-services-only — A service can be adopted only if it is reachable through Azure Resource Manager.
• azure-policy-allowed-resources — Every resource type is denied until the platform has validated its security controls, telemetry, and integration pattern.
• azure-policy-custom-definition — Every Deny or DeployIfNotExists gap with no built-in policy requires a custom definition.
• azure-policy-hard-deny — Security controls are enforced through deny policies.
• azure-policy-naming-convention — Azure Policy assignment names are prefixed by effect — [deny|config|allowed] — followed by the requirement name.
• azure-policy-reference — Policy exemptions resolve assignment IDs from a platform-generated reference.
• deployment-branch-gated-promotion — No platform change reaches production without passing through the test environment first.
• deployment-config-in-repo — Every GitHub variable the platform uses is defined in the repo, never created ad hoc.
• deployment-declarative-lifecycle — Within a deployment stack, what is not declared in code is deleted on the next deployment.
• deployment-end-to-end — Each platform capability deploys through its own pipeline — no capability triggers another's deployment.
• deployment-logic-reusable-workflow — Deployment logic lives in reusable workflows — each environment controls only when and with what inputs.
• graph — A link exists only where the source is incomplete without the target — the note names the dependency.
• job-function-scoped-roles — Access is granted by job function, not by resource type — new resource types never require a new role.
• knowledge — Each decision record states one constraint plainly.
• landing-zone-action-group — Alerts route through the landing zone's action group — never hardcoded to a person.
• landing-zone-allowed-public-ip — Data-plane operations from outside Azure must use the platform-trusted public IP.
• landing-zone-automation — Automation runs inside each landing zone's own subscription.
• landing-zone-diagnostic-settings — Diagnostic settings are defined by the platform — a landing zone never declares its own.
• landing-zone-getting-started — No application repo is created without deployable pipelines and modules from the template.
• landing-zone-github-runners — Every landing zone has its own private GitHub runners provisioned inside the landing zone VNet.
• landing-zone-identity — Each landing zone has a single managed identity — shared across all its workflows, jobs, and service integrations.
• landing-zone-ipam — VNet address spaces are allocated by querying live Azure, not by maintaining an assignment registry.
• landing-zone-lifecycle — Landing zone provisioning draws from a subscription bank, returning the subscription to it when the landing zone is sunset.
• landing-zone-monitoring — No landing zone shares a Log Analytics workspace with another.
• landing-zone-ownership — The platform owns exactly what the landing zone template declares — nothing more.
• landing-zone-platform-members — Joining the platform establishes the Entra ID group, billing scope, and GitHub repo.
• landing-zone-repo — Each application has its own GitHub repository — the single control and deployment plane for all its landing zones.
• landing-zone-resource-group — Platform-managed landing zone resources live in a single dedicated resource group, separate from application resources.
• landing-zone-tags — Tag values on every landing zone must be sourced from the platform member profile.
• landing-zone-template — Each landing zone has its own parameter file and dedicated trigger workflow.
• landing-zone-vnet — Each landing zone has its own isolated VNet with no connectivity to other landing zones or on-premises networks.
• platform-break-glass — Break-glass is used only when automation cannot execute the change.
• platform-exemptions-automation — Platform automation Docker images are hosted outside the landing zones.
• platform-identity-azure — The platform uses an app registration rather than a managed identity.
• platform-identity-claude — Agentic GitHub workflows authenticate via a Claude Pro OAuth token.
• platform-identity-github — All platform and landing zone workflows authenticate to GitHub using a single, shared GitHub App identity.
• platform-identity-graph — Landing zone identities receive granular Microsoft Graph read permissions — never broad directory access.
• platform-test-environment — Every platform capability exists in the test environment exactly as it does in production.
• self-service-policy-exemptions-defender-for-cloud — Defender for Cloud recommendations with no free remediation path must be pre-exempted by the platform.
• self-service-policy-exemptions — Application teams can exempt themselves from any policy assignment via Pull Request.
• single-region — All landing zones deploy to a single region — the platform owns the region decision.