GloriousFlywheel ARC Additive Policy Governance 2026-04-15

GloriousFlywheel ARC Additive Policy Governance 2026-04-15

Snapshot date: 2026-04-15

Purpose

Define where additive ARC runner-set policy belongs now that the repo has a separate baseline policy file, a repo-owned additive file, and an org-specific CI override path.

This note is intentionally narrow. It does not decide the full Linux builder contract. It only classifies who should own extra ARC runner-set policy in the current #169 transition.

Companion notes:

Current Repo Facts

Direct inspection on 2026-04-15 shows:

  • .github/workflows/deploy-arc-runners.yml now applies ARC policy in three layers:
    1. tofu/stacks/arc-runners/dev-policy.tfvars
    2. tofu/stacks/arc-runners/dev-extra-runner-sets.tfvars when present
    3. optional TOFU_EXTRA_POLICY_TFVARS secret
  • dev-policy.tfvars is now the committed baseline dev ARC policy surface
  • dev-extra-runner-sets.tfvars is now the committed additive runner-set surface
  • TOFU_EXTRA_POLICY_TFVARS is now the explicit org-specific CI-side additive or overriding surface
  • terraform.tfvars.example is the local operator example surface, not the repo’s product-policy baseline

Policy Ownership Layers

1. Repo-Owned Baseline Policy

Use tofu/stacks/arc-runners/dev-policy.tfvars for:

  • the minimum intended dev ARC environment
  • runner classes that GloriousFlywheel expects to exist for its own primary validation path
  • shared sizing and toggle choices that are part of the product’s default ARC behavior

Do not use it for:

  • cluster access
  • backend credentials
  • installation-specific extra runner sets

2. Repo-Owned Additive Policy

Use tofu/stacks/arc-runners/dev-extra-runner-sets.tfvars for:

  • named canary workloads that GloriousFlywheel intentionally supports as part of its product and validation story
  • additive runner sets that should stay reviewable in the repo because they exercise an important builder or ARC lifecycle path
  • non-secret cross-repo policy that should travel with the reset and milestone work

This layer should stay small. It is not the place for every custom runner set an installation may want.

3. Local Installation Policy

Use local {env}.tfvars files under tofu/stacks/arc-runners/ for:

  • installation-specific runner sets that an operator wants to keep in their own local deployment surface
  • persistent local or downstream environment policy that is not part of GloriousFlywheel’s shared product baseline

This is the right place for extra runner sets when the local operator flow, not the compatibility workflow, is the primary deployment path.

4. Org-Specific CI Additive Policy

Use TOFU_EXTRA_POLICY_TFVARS for:

  • organization-specific or installation-specific extra runner sets injected through the compatibility workflow
  • short-lived experiments
  • capacity overrides or labels that are not part of the repo’s shared product story
  • policy that should not be committed into the GloriousFlywheel repo

This should not become a hidden replacement for baseline repo truth.

Decision Rules

Put an additive runner set in the repo-owned layer only if most of these are true:

  • it is already named in the reset, milestone, or builder-contract planning surface
  • it acts as a platform canary or validation target, not just a tenant custom workload
  • it is non-secret and reviewable as product policy
  • it is stable enough that keeping it in git improves clarity more than it adds churn
  • removing it would weaken GloriousFlywheel’s own evidence for a supported runner or builder path

Keep an additive runner set out of the repo-owned layer if most of these are true:

  • it exists for one org, one user, or one installation only
  • it is experimental or short-lived
  • it encodes capacity or label choices that are operationally local rather than product-defining
  • it does not appear in the repo’s canary, builder, or milestone story

Current Classification

linux-xr-docker

Current decision:

  • keep linux-xr-docker in dev-extra-runner-sets.tfvars

Reasoning:

  • the reset notes already name linux-xr as a concrete Linux builder consumer and canary workload
  • the additive runner set is non-secret and product-shaped
  • it exercises an ARC path that matters to the builder-contract work in #171
  • keeping it repo-owned makes the current canary surface visible while the broader Linux builder contract is still being defined

Future org-specific extras

Default decision:

  • keep them out of dev-extra-runner-sets.tfvars
  • place them in local {env}.tfvars or TOFU_EXTRA_POLICY_TFVARS unless they later become named product canaries

Operator Guidance

When adding extra ARC runner sets:

  1. Decide whether the runner set is product-owned or installation-owned.
  2. If it is product-owned and canary-worthy, discuss it in the milestone and builder-contract surfaces first.
  3. If it is installation-owned, keep it in local {env}.tfvars or TOFU_EXTRA_POLICY_TFVARS.
  4. Do not silently grow dev-extra-runner-sets.tfvars into a catch-all custom policy bucket.

Exit Condition

  • primary ARC docs explain the baseline, repo-owned additive, and org-specific policy layers explicitly
  • linux-xr-docker has an explicit ownership reason instead of looking like an arbitrary example
  • operators are no longer told to put every extra runner set in one unqualified extra_runner_sets bucket

GloriousFlywheel