repo.work.create_intake WARDEN-IN-0001

correlation_id: 65d40cdd-5894-440e-9c95-c6bcfe259b66
reason: Request assent for GH-DEC-2026-001 boundaries
source: repo-manager

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9

INTENT.md

@@ -1,5 +1,20 @@
 # 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

@@ -0,0 +1,35 @@
+# 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'
+```