# 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'
```