From 4d913c52fd0c5b69c2372d352a3e7df1c51549b7 Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 28 Aug 2026 20:04:57 +0200 Subject: [PATCH] Record layer-model rulings: Staff, net-kingdom canon, access-engine MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Name the top layer Staff rather than Helpers, throughout. Place the layer model in net-kingdom canon rather than info-tech-canon — it is NetKingdom security architecture, not general semantic contract. Record flex-auth's reframing as an Engine with access-engine as the working rename target, and note the one cost: "access" is already spoken for operationally by ops-warden and ops-mason, so adopting it requires demarcating access lanes from access rules in both INTENTs. Co-Authored-By: Claude Opus 5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9 --- ...curity-layer-model-and-gate-house-recut.md | 68 ++++++++++++------- 1 file changed, 44 insertions(+), 24 deletions(-) diff --git a/history/2026-08-28-security-layer-model-and-gate-house-recut.md b/history/2026-08-28-security-layer-model-and-gate-house-recut.md index 908df43..43730a6 100644 --- a/history/2026-08-28-security-layer-model-and-gate-house-recut.md +++ b/history/2026-08-28-security-layer-model-and-gate-house-recut.md @@ -33,12 +33,12 @@ No code exists in gate-house. The re-cut costs nothing but documents. | **Aspects / taxonomy** | cross-cutting language | terms, semantic contracts | info-tech-canon | | **Tooling** | deterministic infrastructure; consistent, performant, scalable state | data structures, persistence | authelia, lldap, privacy-idea → packaged as key-cape; OpenBao | | **Engines** | deterministic APIs for a modeled concept | interfaces, contracts | user-engine, tenant-engine, zone-engine, secrets-engine, flex-auth, role (future) | -| **Helpers** | interactive, non-deterministic; management, operations, change, innovation, controlling | specifications, decisions, workplans, tasks | gate-house, ops-mason, ops-warden, kings-guard, whitehat-security | +| **Staff** | interactive, non-deterministic; management, operations, change, innovation, controlling | specifications, decisions, workplans, tasks | gate-house, ops-mason, ops-warden, kings-guard, whitehat-security | The layer boundary is defined by what a layer *produces* and how deterministic it is, not by technical tier. Engines model a concept and expose it deterministically; new concepts get new engines as they become relevant. -Helpers work through agentic capability — assistants and autonomous agents — +Staff repos work through agentic capability — assistants and autonomous agents — and their output is specification and decision, not state. ## 3. Why the model is load-bearing: it is self-similar to the Canon @@ -47,7 +47,7 @@ Read by determinism, the layers reproduce the three planes of the Active Secrets Management Canon: ```text -Helpers interactive, non-deterministic ≈ Cognitive Plane +Staff interactive, non-deterministic ≈ Cognitive Plane Engines deterministic APIs ≈ Authority Plane Tooling deterministic state ≈ Execution Plane Taxonomy cross-cutting language @@ -70,19 +70,19 @@ hosts. This is not a turf dispute with `flex-auth`; it is internal incoherence. A taxonomy that only labels decays. The model carries one falsifiable rule: -> **Helpers never touch tooling directly. They act only through engine APIs.** +> **Staff never touches tooling directly. It acts only through engine APIs.** This is the architectural form of "no privilege from cognition". It is why -kings-guard — agentic, therefore a Helper — may contain a threat only by +kings-guard — agentic, therefore Staff — may contain a threat only by calling an engine, never by reaching into OpenBao itself; and why an autonomous -coding agent gets no shortcut. It is greppable: a Helper repo holding a direct +coding agent gets no shortcut. It is greppable: a Staff repo holding a direct database or OpenBao client is violating the model. ## 5. Findings from the INTENT review **5.1 gate-house already contradicts itself.** `README.md` line 7 — *"Think of Gate House as observability for vault managed secrets based on sound governance -policy best practices"* — is a Helpers-layer sentence, and the only one in the +policy best practices"* — is a Staff-layer sentence, and the only one in the repository. Everything after it describes a runtime decision point. **5.2 Direct collision with flex-auth.** `flex-auth/INTENT.md` carries a @@ -148,7 +148,7 @@ engine selection, grant storage, and the revocation service. **7.1 Policy authoring vs policy evaluation.** flex-auth today claims both *"policy-as-code packages, tests, versions, and rollout"* and the evaluation itself. Under the model these are different layers: authoring and governing -policy is Helpers work; evaluating it deterministically and in-path is Engine +policy is Staff work; evaluating it deterministically and in-path is Engine work. This resolves the `FLEX-WP-0017` overlap constructively — designing the approval contract (what must bind to an approval, what an authority ceiling means) is gate-house; validating an approval at decision time is the engine's. @@ -175,23 +175,43 @@ owner. is briefed" is defensible — but only if `INTENT.md` says so in the first paragraph, or every reader re-derives the PDP misreading. -## 9. Open questions, not decided here +## 9. Rulings taken, and what remains open -1. **Layer name.** "Helpers" is the working term; it undersells a layer holding - architecture, doctrine, controlling, and change. "Staff" — the general-staff - sense of plans and doctrine without execution — was proposed and fits the - kingdom metaphor. Undecided. -2. **flex-auth reframing.** Renaming to an `*-engine` form is agreed in - principle to make its layer and role legible. The specific name is open: - `auth-` is ambiguous between authentication and authorization, and key-cape - owns authentication, so `auth-engine` preserves the confusion the rename - should remove. `authz-engine` and `access-engine` were the alternatives - raised. **Sequence: reframe the INTENT first, rename second** — the rename - touches `FLEX-WP` prefix ownership, State Hub identifiers, ops-warden's - tables, zone-engine's binding boundary text, and secrets-engine - integrations, so it is a governed migration, not a `git mv`. -3. Whether the layer model itself is written into net-kingdom canon or - info-tech-canon. +Taken on 2026-08-28, to be written up as the decision record in §11.2: + +1. **The layer is named Staff.** "Helpers" was the working term and undersold a + layer holding architecture, doctrine, controlling, and change. Staff carries + the general-staff sense — plans, doctrine, and orders, without execution — + and sits in the kingdom metaphor beside guard, warden, and mason. Applied + throughout this note. +2. **The layer model is NetKingdom canon, not info-tech-canon.** It is + NetKingdom-flavored security architecture, not general semantic contract, so + it belongs in `net-kingdom/canon/standards/` alongside + `security-zones_v0.1`, `credential-management_v0.2`, `tenancy-posture_v0.1`, + and the `*-boundary-contract_v0.1` family. info-tech-canon keeps the + cross-cutting terminology role and does not carry the model. +3. **flex-auth is reframed as an Engine and renamed.** `access-engine` is the + working proposal. Sequence is unchanged: reframe the INTENT first, rename + second, as a governed migration — the rename touches `FLEX-WP` prefix + ownership, State Hub identifiers, ops-warden's tables, zone-engine's binding + boundary text, and secrets-engine integrations. + +Open: + +- **The rename target.** `access-engine` reads naturally and avoids the + authentication/authorization ambiguity that rules out `auth-engine` while + key-cape owns authentication. Its cost is that "access" is already spoken for + operationally: ops-warden is the *"operational access steward"* owning + *"operational SSH access guidance"* and `wiki/AccessManagementDirective.md`, + and ops-mason's one-liner is to maintain *"access routes, credentials, tokens, + and policies"*. In current NetKingdom usage "access" denotes the operational + lane by which a worker reaches a host — Staff territory — rather than the + decision about whether they may. Adopting `access-engine` therefore requires + demarcating the word in both INTENTs: **ops-warden and ops-mason own access + lanes; access-engine owns access rules.** `permission-engine` avoids the + collision but ages badly against a future `role-engine`, since roles grant + permissions and the two would overlap; `access-engine` sits cleanly above + roles. `authz-engine` is precise but insider shorthand. ## 10. Consequences for existing gate-house artifacts