flex-auth/decisions/decisions.md

Decision records

FLEX-DEC-2026-001 — Assent to GH-DEC-2026-001: Engine framing, access-engine rename, authoring/evaluation split

id: FLEX-DEC-2026-001
kind: decision
title: 'Assent to GH-DEC-2026-001: Engine framing, access-engine rename, authoring/evaluation
  split'
status: resolved
origin: cross-repo
origin_ref: gate-house GH-DEC-2026-001
standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
intake_ref: FLEX-IN-0001
owner: flex-auth
affects:
- flex-auth
- gate-house
- net-kingdom
- ops-warden
- secrets-engine
- zone-engine
requested_dispositions:
- assent
- revise
- reject
created: '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'
state_hub_decision_id: "c990e442-77c2-4556-a40b-61f65eded10b"

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.

FLEX-DEC-2026-002 — Review of security layer model v0.4: assent with findings, one rule contested

id: FLEX-DEC-2026-002
kind: decision
title: 'Review of security layer model v0.4: assent with findings, one rule contested'
status: open
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.4
standard: net-kingdom/canon/standards/security-layer-model_v0.4.md
intake_ref: FLEX-IN-0002
owner: flex-auth
affects:
- flex-auth
- gate-house
- net-kingdom
- ops-warden
- approval-engine
- maturity-engine
requested_dispositions:
- assent
- revise
- reject
created: '2026-08-29T00:41:21.171665Z'
updated: '2026-08-29T00:41:21.171665Z'