gate-house/decisions/decisions.md

# Decision records

## GH-DEC-2026-001 — NetKingdom security layer model, the gate-house re-cut, and the access-engine reframing

```yaml
id: GH-DEC-2026-001
kind: decision
title: NetKingdom security layer model, the gate-house re-cut, and the access-engine
  reframing
status: resolved
owner: Bernd Worsch
repo: gate-house
standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
source_note: history/2026-08-28-security-layer-model-and-gate-house-recut.md
requested_dispositions:
- approved
- revised
- rejected
affects:
- gate-house
- flex-auth
- ops-warden
- ops-mason
- kings-guard
- whitehat-security
- net-kingdom
- zone-engine
created: '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'
state_hub_decision_id: "2d6509d0-ffd2-4209-89ab-bf68a4945ada"
```

## 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.