diff --git a/decisions/decisions.md b/decisions/decisions.md index fa2ae2c..7b7a020 100644 --- a/decisions/decisions.md +++ b/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.