Apply gate-house's section 11 rulings: four-token validator, emission guarantee, resource.system.

GH-DEC-2026-017: the validator admitted {Staff, Engine, Tooling}, built from
section 4's catalog rows, and rejected Taxonomy, which section 3.1 defines.
railiance-master was conforming; the validator was the divergent artifact.
Now four tokens, ASCII case folded, section 4's spelling canonical, INTENT.md
governing while form disagreements are still reported, and every run states
its scope (section 11 binds section 4; volunteers are not non-conformances).
Also fixes the survey silently dropping audit-core's layer.yaml by decoding
peers into flex-auth's own struct.

GH-DEC-2026-018: flex-auth is a section 4 source of evidence. G2 closes as a
question and reopens as a dated gap (review 2026-10-19). cadence.yaml
publishes the per-event-class inventory: deny, redact, not_applicable and
audit_only rare load-bearing (heartbeat and reconciliation, rate forbidden);
allow volume load-bearing (expected-rate and reconciliation). INTENT.md
declares source_of_evidence and names it; tests assert both. Delivery is
FLEX-WP-0031.

FLEX-DEC-2026-015: resource.system follows the runtime, not the repository,
answering ops-warden's WARDEN-IN-0003.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703

decisions/decisions.md

@@ -1833,3 +1833,61 @@ to finish before a repository-coordinate rename, and they must not be
 cancelled or rewritten by it. Live Forge apply (`T06`) still needs the exact
 human confirmation string and a fresh zero-blocker preflight of the commit
 being renamed.
+
+---
+
+## FLEX-DEC-2026-015 — `resource.system` follows the runtime, never the repository
+
+**Date:** 2026-09-21
+**Status:** accepted
+**Workplan:** `FLEX-WP-0030-T08`; bears on `FLEX-WP-0020`
+**Asked by:** `ops-warden`, `WARDEN-IN-0003`
+
+**Question.** `ops-warden` sends a lane's `owner_repo` verbatim as
+`resource.system` (and as `context.owner_repo`) on every `/v1/check`. Exactly one
+lane, `flex-auth-policy-check`, names `flex-auth` as `owner_repo`. Should
+`resource.system` follow the repository coordinate at rename, or the runtime?
+
+**Ruling.** It follows the **runtime**, and flips only when the runtime name
+flips — which `FLEX-DEC-2026-013` says it does not, at this rename.
+
+`resource.system` is **policy vocabulary**, not a coordinate. It is the key the
+PDP matches on in two places, and both fail closed on an unknown value:
+
+- the caller-binding table (`ADR-0004`, `internal/callerauth`) binds each
+  `resource.system` to exactly one authenticated workload principal; an unknown
+  system is rejected;
+- policy packages select on it, so a value no package names produces
+  `not_applicable`, which a consumer treats as deny.
+
+`FLEX-DEC-2026-013`'s retain table already keeps "policy/API vocabulary" as
+`flex-auth`. So flipping `owner_repo` at the repository rename would rename a
+policy resource under cover of a coordinate change. It would not fail at the
+edit; it would fail at the check, in production, as a denial nobody decided.
+`ops-warden`'s instinct — hold `owner_repo`, add `access-engine` to
+`need_keywords` so routing resolves under both names — is the right one and is
+confirmed.
+
+**When it does change, the order is fixed: PDP first, consumers second.** A
+later runtime rebrand (the post-soak workplan `FLEX-DEC-2026-013` anticipates)
+MUST first ship a binding and package that accept both values, then let each
+consumer flip on its own schedule, then retire the old value. A consumer that
+flips before the PDP accepts the new value is a fail-closed outage; a PDP that
+drops the old value before consumers flip is the same outage from the other
+side. Neither is a repository-rename step.
+
+**Observation, not a ruling on `ops-warden`'s catalog.** `owner_repo` is doing
+two jobs — repository coordinate and policy resource — and this question arose
+only because they share a field. Separating them (for example a
+`policy_system` field defaulting to today's value) would make the next rename a
+coordinate-only change by construction. That is `ops-warden`'s schema and its
+call; flex-auth only states that the PDP matches on the resource, not on the
+repository.
+
+**Also answers `WARDEN-WP-0039-T03`'s framing.** The credential proxy's admitted
+policy binding reads the same field from the delegated-read side. This ruling
+applies there identically: the repository rename answers nothing about it.
+
+**Reversal condition.** Reverses only by a runtime-rename decision that
+supersedes `FLEX-DEC-2026-013`'s retain row for policy vocabulary — and that
+decision inherits the PDP-first order above.