coulomb/gate-house
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Record layer-model rulings: Staff, net-kingdom canon, access-engine

Browse source 
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 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
This commit is contained in:
tegwick 2026-08-28 20:04:57 +02:00
parent 9f7df24c73
commit 4d913c52fd
1 changed files with 44 additions and 24 deletions
Download patch file Download diff file Expand all files Collapse all files

68
history/2026-08-28-security-layer-model-and-gate-house-recut.md
View file

@ -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