Policy As Config

Policy As Config

Policy hardcoded in code is invisible (you can't grep a behavior) and expensive to change (a code edit + deploy). Policy as config is auditable (a data field), grep-able, and changeable without touching code. This is the compliance counterpart to infrastructure-as-code.

What counts as policy

• Consent — the mechanism (opt-in checkbox on /check) and what consented data is used for.
• Data flow — where consented samples go (data/data-ingest/inbox), what source they're tagged as (data-ingest source: model-gateway-health-checks).
• Allowlists / denylists — which sites, which providers, which endpoints.
• Retention — how long data is kept.
• Feature gates — which features are on for which sites/tenants.

The shape

Encode policy in the fleet/service registry config, alongside the entity it governs:

{
  "id": "model-gateway",
  "domain": "model-gateway.example.com",
  "dataConsent": "Opt-in checkbox on /check; consented samples → data/data-ingest/inbox (data-ingest source: model-gateway-health-checks)"
}

One field encodes: the mechanism (opt-in checkbox), the location (/check), the flow (→ data/data-ingest/inbox), and the source tag. A compliance reviewer reads one field and knows the whole consent story for that site.

Why config, not code

• Auditable. A reviewer greps dataConsent across the registry and sees every site's consent model in one pass. A code-based consent model requires reading every route handler.
• Changeable without a code edit. Tightening consent from "opt-in" to "opt-in + explicit confirmation" is a config change, not a code change + deploy.
• Visible to automation. The fleet SDK reads the config; a drift detector can flag sites missing a dataConsent field.
• Stable surface. Code changes; policy fields stay named and grep-able across versions.

When to keep policy in code

• The policy is enforced by code semantics that can't be expressed as data (a complex multi-step auth flow).
• The policy is truly one-off for a single code path.
• The policy changes so often that config would lag code anyway.

Most policy is none of these — it's a rule that belongs in config.

Anti-patterns

• Consent buried in a route handler. "We do consent in the /check page" — invisible to anyone not reading that handler.
• Data flow implied by code. Samples land in data/data-ingest/inbox because a script writes there, but nothing says that's the intended flow. A config field makes intent explicit.
• Policy fields without the flow. "dataConsent": "opt-in" — opt-in for what? The field must encode the mechanism AND the flow.
• Config that duplicates code instead of governing it. Policy in config that the code ignores is worse than no config — it lies.

Pair with

• metadata-align — the fleet/service registry is the surface where policy-as-config lives; keep it aligned.
• agent-guardrails — allowlists are policy-as-config applied to agents.
• readiness-report — a missing dataConsent field on a new site is a "needs your input" item (compliance sign-off).