# Decision records

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

```yaml
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

```yaml
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'
```