INTENT.md

@@ -1,20 +1,5 @@
 # INTENT
 
-> **NetKingdom layering review — 2026-08-28.** This repository's role was reviewed
-> against the NetKingdom IT-security layer model: **Taxonomy → Tooling → Engines →
-> Staff**, layered by determinism and by the kind of artifact each layer produces.
-> Findings and the argument behind them:
-> `gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md`.
-> The model is `net-kingdom/canon/standards/security-layer-model_v0.1.md` (proposed),
-> ratified by `gate-house/decisions/decisions.md` GH-DEC-2026-001.
->
-> The layer rule that binds every repository: **Staff never touches tooling
-> directly. It acts only through engine APIs.**
->
-> **This repository is Staff — interactive, non-deterministic; operational stewardship.** Add the layer label and the Staff invariant. Two substantive changes. (1) The **"NetKingdom Security Literacy"** section is evidence that the security curriculum had no owner; it now has one. Doctrine and curriculum move to gate-house, and this section becomes lane-specific runbooks that reference gate-house doctrine rather than restating it. The boundary is **doctrine versus runbook**. (2) The literacy and routing tables should add gate-house — currently every plane is listed and gate-house appears nowhere — routing doctrine and authority-model questions there, while continuing to route policy decisions to access-engine. Record the lane/rule demarcation as in ops-mason.
->
-> *This note records what should change. The body below is not yet adapted.*
-
 > This file captures **why this repository exists**, the **direction it is
 > moving toward**, and the **kind of system it is meant to become**.
 > It is intentionally **aspirational and stable**, not a description of

intakes/intakes.md

@@ -1,35 +0,0 @@
-# Intake records
-
-## WARDEN-IN-0001 — Assent requested: Staff layer, doctrine vs runbook, and the access lane/rule demarcation
-
-```yaml
-id: WARDEN-IN-0001
-kind: intake
-title: 'Assent requested: Staff layer, doctrine vs runbook, and the access lane/rule
-  demarcation'
-status: open
-origin: cross-repo
-origin_ref: gate-house GH-DEC-2026-001
-priority: medium
-owner: ops-warden
-requested_by: gate-house
-standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
-description: 'gate-house asks ops-warden to assent to three boundary items. (1) ops-warden
-  is Staff, bound by the rule that Staff acts only through Engine APIs and never touches
-  Tooling directly (standard section 5). (2) Doctrine versus runbook: the NetKingdom
-  Security Literacy section in ops-warden INTENT is evidence the security curriculum
-  had no owner; it now has one in gate-house. Proposal is that doctrine and curriculum
-  move to gate-house and that section becomes lane-specific runbooks referencing gate-house
-  doctrine rather than restating it. ops-warden keeps the lanes it stewards and everything
-  operational about them. (3) The access lane/rule demarcation, normative in standard
-  section 8: ops-warden and ops-mason own access lanes — how a worker reaches a host;
-  access-engine owns access rules — whether they may. This demarcation is the condition
-  attached to renaming flex-auth to access-engine, so ops-warden effectively holds
-  a veto on that name. Also requested: add gate-house to the Security Literacy and
-  routing tables — currently every plane is listed and gate-house appears nowhere
-  — routing doctrine and authority-model questions there while continuing to route
-  policy decisions to access-engine. If moving the curriculum out leaves ops-warden
-  unable to instruct its own workers, say so; the boundary is wrong if it does.'
-created: '2026-08-28T19:30:28.087109Z'
-updated: '2026-08-28T19:30:28.087109Z'
-```