repo.work.resolve_decision FLEX-DEC-0001

correlation_id: e556f743-da76-4cc4-a441-f1f1fba981bd
reason: rmgr CLI
source: repo-manager

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014348@bnt-lap001
Assistant-Session: a993abda-65a0-4ea8-8ccd-0fcd78c92ac0

decisions/decisions.md

@@ -7,7 +7,7 @@ id: FLEX-DEC-0001
 kind: decision
 title: 'Assent to GH-DEC-2026-001: Engine framing, access-engine rename, authoring/evaluation
   split'
-status: open
+status: resolved
 origin: cross-repo
 origin_ref: gate-house GH-DEC-2026-001
 standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
@@ -25,5 +25,147 @@ requested_dispositions:
 - revise
 - reject
 created: '2026-08-28T19:43:38.443788Z'
-updated: '2026-08-28T19:43:38.443788Z'
+updated: '2026-08-28T19:44:29.505314Z'
+rationale: 'Assent to all three items of GH-DEC-2026-001. Item 1: flex-auth is Engine-layer
+  and the sole decision point; the INTENT reframe at fe46122 stands. flex-auth accepts
+  one conformance debt of its own — DecisionProvenance carries no registry snapshot
+  digest, so a decision turning on registry content is not replayable from its own
+  provenance (standard section 6). Item 2: access-engine is the right name; execution
+  is a separate governed migration, conditioned on renaming repository identity and
+  runtime identity in separate revertible steps (the enforcing ops-warden pin binds
+  tokens to the protected-system name flex-auth, and a single-step rename would 401
+  every warden sign) and on FLEX-WP prefix ownership staying with the repository.
+  Item 3: the authoring/evaluation split is accepted; gate-house authority ceilings
+  must reach the decision as input claims or as rules in the versioned policy package
+  so their application is reconstructable from the decision record — the same section
+  6 test flex-auth applied to zone-engine and now to itself. FLEX-WP-0017-T03/T05
+  stay wait: the design half is re-routed to gate-house, the durable storage half
+  remains unowned and is raised as an engine gap.'
+decided_by: flex-auth (reviewing side)
+decided_at: '2026-08-28T19:44:29.505314Z'
 ```
+
+## Context
+
+`gate-house` asked flex-auth, via `FLEX-IN-0001`, to assent to the three items
+ratified in `GH-DEC-2026-001`. The request follows the estate precedent that a
+boundary is drawn on review by the other side rather than asserted — the
+precedent flex-auth itself set when it reviewed a `zone-engine` draft and ruled
+that flex-auth is the policy decision point and stays the only one.
+
+This record is flex-auth's answer. It is written from the reviewing side: the
+questions asked were not "is this flattering to flex-auth" but "does this hold
+against what flex-auth actually is, and does flex-auth actually conform".
+
+## Disposition
+
+**Assent to all three items, with one accepted conformance debt and two
+conditions on the rename.** Nothing here revises or rejects any part of
+`GH-DEC-2026-001`.
+
+### Item 1 — Engine framing and the sole decision point: assent
+
+flex-auth is Engine-layer under §3.3 and §4 of the standard. The defining
+property holds: the same authoritative input state yields the same result. The
+INTENT reframe is applied at `fe46122` and is correct as written — "control
+plane" is dropped as Staff vocabulary, and the exclusive decision-point role of
+§6 is stated.
+
+The generalization in §6 is the ruling flex-auth drew against `zone-engine`,
+applied to the estate. flex-auth cannot consistently hold that boundary against
+another repository and decline it as a general rule.
+
+**Accepted conformance debt — registry provenance.** §6 states that compiled
+data determining an outcome is still deciding, and that provenance must remain
+reconstructable from the engine's decision. flex-auth does not fully satisfy
+this today. `DecisionProvenance` (`pkg/api/canonical.go`) carries the evaluator,
+mode, policy package, policy version, and a directory ETag — but no digest of
+the registry snapshot that supplied resource, subject, and relationship facts.
+A decision that turned on registry content therefore cannot be replayed from
+its own provenance.
+
+flex-auth accepts this as its own gap rather than claiming conformance it does
+not have. It is the same argument flex-auth made to `zone-engine` — zone
+*membership* compiles into the registry snapshot, per-zone *stance* belongs in
+the versioned policy package, precisely because registry content is absent from
+decision provenance. The clean fix is to make registry content provenanced, and
+a workplan will carry it. Until it lands, the flex-auth position that
+outcome-determining content belongs in the versioned policy package stands
+unchanged, and stands for gate-house's inputs on the same terms (item 3).
+
+### Item 2 — The `flex-auth` → `access-engine` rename: assent to the name, not yet to execution
+
+`access-engine` is the right name. The rejection of `auth-engine` is correct —
+`key-cape` owns authentication, and `auth-` preserves exactly the ambiguity the
+rename exists to remove. The §8 lane/rule demarcation is an acceptable cost and
+flex-auth adopts it: `ops-warden` and `ops-mason` own access lanes, flex-auth
+owns access rules.
+
+flex-auth agrees the rename is a separate governed migration and does not treat
+`GH-DEC-2026-001` as authorizing it. Two conditions, from the consumer side
+rather than the documentary side:
+
+1. **Repository identity and runtime identity must be renamed in separate,
+   independently revertible steps, repository first.** The name `flex-auth` is
+   not only a repo slug: it is a deployed service, an in-cluster DNS name, a
+   chart and image name, and — since `FLEX-WP-0016` moved the ops-warden pin to
+   `callerAuth.mode: enforce` — a protected-system identifier that inbound
+   tokens are bound to. A single-step rename would make every `warden sign` a
+   401, including the certificate the `ops-bridge` tunnels depend on. This is
+   the same dependency shape that caused `ops-warden`'s `ADR-0006` to defer
+   `policy.enabled` permanently.
+2. **`FLEX-WP` prefix ownership stays with the repository across the rename.**
+   Existing `FLEX-WP-0001..0018` identifiers are referenced by State Hub
+   records, by consumer repositories, and by decision provenance in shipped
+   audit records. They are not renamed retroactively; whether new work takes a
+   new prefix is a question for the migration record, not for this assent.
+
+The migration also touches State Hub identifiers, `ops-warden`'s routing
+tables, `zone-engine`'s boundary text, and `secrets-engine` integrations, as
+`GH-DEC-2026-001` states. flex-auth will not begin any of it under this record.
+
+### Item 3 — The authoring/evaluation split: assent, with the §6 test applied symmetrically
+
+The split is correct and flex-auth gives up the authoring half willingly:
+gate-house owns the doctrine, the invariants, the authority ceilings, the
+operating modes, and the authority context; flex-auth owns evaluation
+exclusively plus the policy-as-code mechanism; policy *content* stays with the
+protected system's owner.
+
+flex-auth draws one boundary back, which is the §6 test applied to gate-house's
+inputs on the same terms flex-auth applies it to `zone-engine` and to itself:
+
+> An authority ceiling that determines an outcome must reach the decision as
+> either an input claim on the request or a rule in the versioned policy
+> package — and its application must be reconstructable from the decision
+> record. A ceiling that resolves an outcome before evaluation runs has decided
+> early, and gate-house is Staff, where §6 forbids a decision point.
+
+Concretely: gate-house authors the ceiling; flex-auth renders it. The principal
+/actor/runtime triple, the mandate, and the operating mode arrive as input
+claims and appear in the decision binding. Where a ceiling constrains an
+outcome, it is expressed in the versioned policy package so that the policy
+version in provenance identifies the ceiling that applied. This is not a
+restriction on gate-house's authorship; it is what keeps the authorship
+auditable at decision time.
+
+**Effect on `FLEX-WP-0017`.** The split resolves the overlap and re-routes the
+design half of the blocked work: gate-house designs the approval contract,
+flex-auth validates approvals at decision time. It does not unblock
+`FLEX-WP-0017-T03` — the durable approval object, authenticated approval
+entries, and atomic supersession still need an owner for *storage and
+lifecycle*, which is neither gate-house's (Staff holds no state another layer
+depends on at runtime, §3.4) nor flex-auth's (flex-auth does not own the
+organizational approval lifecycle). T03 and T05 stay `wait`, with the design
+half now addressed to gate-house. That unowned half is flagged to gate-house as
+an engine gap under §5, not solved locally.
+
+## Consequences
+
+- The standard's §11 blocker "flex-auth reframed as an Engine … not yet
+  assented" is answered for flex-auth. `kings-guard` and `ops-warden` assent
+  remains outstanding and is not flex-auth's to give.
+- `INTENT.md` records the assent and the registry-provenance debt.
+- A workplan will carry the registry snapshot digest into `DecisionProvenance`.
+- The rename is not started, and must not start before a migration record
+  exists that satisfies the two conditions above.