repo.work.resolve_decision GH-DEC-2026-001

correlation_id: 18f20bc4-d273-4697-9bd0-c2e43536cd36
reason: Ratify the 2026-08-28 layer model rulings
source: repo-manager

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9

decisions/decisions.md

@@ -7,7 +7,7 @@ id: GH-DEC-2026-001
 kind: decision
 title: NetKingdom security layer model, the gate-house re-cut, and the access-engine
   reframing
-status: open
+status: resolved
 owner: Bernd Worsch
 repo: gate-house
 standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
@@ -26,5 +26,136 @@ affects:
 - net-kingdom
 - zone-engine
 created: '2026-08-28T19:15:15.607849Z'
-updated: '2026-08-28T19:15:15.607849Z'
+updated: '2026-08-28T19:16:01.456127Z'
+rationale: 'Approved in session on 2026-08-28. The three rulings were taken interactively:
+  Staff as the layer name, net-kingdom canon as the model''s home, and access-engine
+  as the rename target with the lane/rule demarcation accepted as its cost. Approval
+  covers the doctrine and documents only; the flex-auth rename remains a separate
+  governed migration, and the standard stays proposed pending assent from flex-auth,
+  kings-guard, and ops-warden.'
+decided_by: Bernd Worsch
+decided_at: '2026-08-28T19:16:01.456127Z'
 ```
+
+## Context
+
+The security estate acquired overlapping claims to the same responsibility, and
+the overlap was invisible in each repository's own documents. `gate-house` was
+seeded as a deterministic authority plane — a policy decision point with an
+`/authorize` API, grant storage, and a revocation service — while `flex-auth`
+already described itself as the authorization control plane and was actively
+delivering `FLEX-WP-0017`, an approval contract binding approvals to action,
+actor, target, and validity window. Neither repository's INTENT named the other.
+`zone-engine` had already been ruled against on the same question.
+
+Full review and evidence: `history/2026-08-28-security-layer-model-and-gate-house-recut.md`.
+
+## Decision requested
+
+Ratify three linked rulings. They are one decision because the second does not
+hold without the first, and the third is the first applied to the repository
+that was already right.
+
+### Ruling 1 — Adopt the NetKingdom security layer model
+
+The estate is layered **Taxonomy → Tooling → Engines → Staff**, distinguished by
+determinism and by the kind of artifact each layer produces. The top layer is
+named **Staff** — the general-staff sense of plans and doctrine without
+execution — not "Helpers", which undersold a layer holding architecture,
+controlling, and change.
+
+The model is published as `net-kingdom/canon/standards/security-layer-model_v0.1.md`,
+owned by gate-house, status `proposed`. It belongs in net-kingdom canon rather
+than info-tech-canon because it is NetKingdom-flavored security architecture,
+not general semantic contract.
+
+It carries two normative rules:
+
+- **Staff never touches Tooling directly. It acts only through Engine APIs.**
+- **`access-engine` is the only policy decision point**, generalizing to the
+  whole estate the ruling first drawn in `zone-engine/INTENT.md` §5.
+
+### Ruling 2 — Re-cut gate-house as the doctrine council
+
+Gate House is Staff: the council where NetKingdom's security and defence
+doctrine is established, documented, taught, and supervised. It holds no
+runtime position.
+
+The decisive argument is gate-house's own: **a decision point inside gate-house
+would place the deterministic authority boundary inside the non-deterministic
+management layer, violating INV-02 — the first invariant the repository exists
+to defend.** The repository would have been the clearest available
+counterexample to the canon it hosts.
+
+Boundary: *the mandate and the operating mode are gate-house's; the decision is
+access-engine's; the credential is secrets-engine's; the perimeter is
+ops-mason's and ops-warden's.*
+
+gate-house keeps what no other repository owns — the operating modes, the
+principal/actor/runtime triple, mandates and authority ceilings, the change
+dynamics envelope, the MCP doctrine, the posture asymmetry, the assurance
+specifications, and the curriculum. It gives up `/authorize`, policy evaluation,
+policy engine selection, grant storage, and revocation.
+
+### Ruling 3 — Reframe flex-auth as an Engine and rename it access-engine
+
+`flex-auth` is Engine-layer and remains the only policy decision point. It is
+renamed **`access-engine`**. `auth-engine` was rejected: key-cape owns
+authentication, and `auth-` preserves the ambiguity the rename exists to remove.
+`permission-engine` was rejected as ageing badly against a future `role-engine`.
+
+The name's one cost is that "access" is already spoken for operationally by
+ops-warden and ops-mason. It is paid by a demarcation, now normative in §8 of
+the standard: **ops-warden and ops-mason own access lanes — how a worker reaches
+a host; access-engine owns access rules — whether they may.**
+
+Sequence is binding: **reframe the INTENT first, rename second**, as a governed
+migration. The rename touches `FLEX-WP` prefix ownership, State Hub identifiers,
+ops-warden's routing tables, zone-engine's binding boundary text, and
+secrets-engine integrations.
+
+The reframing also splits a responsibility flex-auth currently holds whole:
+**authoring and governing policy is Staff work (gate-house); evaluating it
+deterministically and in-path is access-engine's, exclusively.** This is the
+constructive resolution of the `FLEX-WP-0017` overlap — gate-house designs the
+approval contract, access-engine validates approvals at decision time.
+
+## What approval authorizes
+
+- Publication of the layer model as a proposed net-kingdom standard.
+- The gate-house INTENT re-cut, already applied at `7f13f72`.
+- The layering review notes placed at the top of twelve estate INTENT files.
+- Starting the flex-auth INTENT reframe.
+- Retiring the gate-house artifacts that describe an engine: ADR-003 (policy
+  engine selection), milestones M0, M3, and M4, and `GH-WP-0001-T04`
+  (`/authorize` skeleton). `GH-WP-0001` is rewritten against the re-cut before
+  it is promoted to active.
+
+## What approval does not authorize
+
+- The `flex-auth` → `access-engine` rename itself. That is a separate governed
+  migration with its own record, and it must not begin before the INTENT
+  reframe lands.
+- Any change to `zone-engine`'s 2026-08-23 disposition.
+- Promoting the standard from `proposed` to `accepted`.
+- Any change to another repository's workplans. Work structure stays with the
+  repository doing the work.
+
+## Assent still required
+
+Two adaptations move vocabulary away from repositories that currently use it,
+and follow the estate's precedent that a boundary is drawn on review by the
+other side rather than asserted — as flex-auth did to zone-engine:
+
+1. **flex-auth** — Engine framing, the rename, and the authoring/evaluation split.
+2. **kings-guard** and **ops-warden** — releasing "control plane" and the
+   security curriculum respectively to the layers that own them.
+
+## Reversal
+
+The rulings are documents; nothing executable depends on them yet, and no code
+exists in gate-house. Reversal is reverting the INTENT and standard commits.
+The falsifiers that should trigger reconsideration are in
+`gate-house/INTENT.md` § "What Would Make This Repository Wrong" — principally
+gate-house becoming a paper generator whose conformance loop never turns, or
+the estate declining to adopt the authority vocabulary.