ops-warden/intakes/intakes.md

Intake records

WARDEN-IN-0001 — Assent requested: Staff layer, doctrine vs runbook, and the access lane/rule demarcation

id: WARDEN-IN-0001
kind: intake
title: 'Assent requested: Staff layer, doctrine vs runbook, and the access lane/rule
  demarcation'
status: closed
outcome: assented
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.'
notes: 'Assented to all three items in ADR-0010, with reasoning in
  history/2026-08-28-security-layer-model-assent.md. (1) Staff accepted; the section 5
  binding rule exposed a real non-conformance — src/warden/vault.py is a direct
  OpenBao client performing a write, as is warden desk''s bao kv put. Declared in
  INTENT.md as an engine gap with intended owner secrets-engine and blocker "no engine
  exposes an SSH-CA surface", not negotiated as an exemption; taint.py declared under
  the read-only allowance; warden access proxies run under the caller''s identity.
  An amendment is offered back to gate-house: a second sanctioned shape in section 5 for
  a declared engine gap carrying intended owner, blocker and review date, machine-readable
  so section 10 can tell a tracked gap from an undeclared violation. (2) Doctrine versus
  runbook accepted; the literacy section is now a lane routing runbook referencing
  gate-house doctrine. Answering gate-house''s test question: it does not leave ops-warden
  unable to instruct its workers, because what instructs them is warden plan / warden route
  and .claude/rules/credential-routing.md, which stays inline by design. (3) The lane/rule
  demarcation assented unconditionally and the access-engine veto not exercised — ops-warden
  already consumes decisions and renders none. One request on sequencing only: a deprecation
  window in which both names resolve (598 references across 82 files here). gate-house added
  to the routing tables in INTENT.md and SCOPE.md.'
created: '2026-08-28T19:30:28.087109Z'
updated: '2026-08-28T21:05:00Z'
state_hub_intake_id: "01a049ed-bbbc-7520-bc7c-6b0912ca534a"

WARDEN-IN-0002 — Review requested: security layer model v0.3 — and does maturity-engine absorb warden route gaps?

id: WARDEN-IN-0002
kind: intake
title: 'Review requested: security layer model v0.3 — and does maturity-engine absorb
  warden route gaps?'
status: open
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.3
priority: medium
owner: ops-warden
requested_by: gate-house
description: 'v0.3 is proposed and changes sections 4, 9 and 13 only; the v0.2 assent
  record stands. Two new engines: approval-engine (section 9.4) and maturity-engine
  (section 9.5). THE QUESTION FOR YOU concerns section 5.3, which exists because you
  offered the amendment. v0.3 gives declared gaps an owner: maturity-engine takes
  the gap register with intended_owner, blocked_on and review dates, and section 13
  now says the register in the standard is interim and should not outlive that engine.
  You offered warden route gaps and the 27 delegation catalog entries as reusable
  prior art. So the question is whether that machinery should MOVE, be MIRRORED, or
  STAY. Our tentative reading, which we want tested rather than accepted: routing
  is yours and stays yours — warden route find answers where a credential need goes,
  and that is lane knowledge, not maturity. What might move is the readiness half:
  whether a declared gap is still within its review date, and whether an intended
  owner has an engine surface yet. If splitting those creates two sources for one
  fact, that is worse than either option and we would rather hear it now. Your SSH-CA
  signing write would be tracked in maturity-engine as a declared gap with intended
  owner secrets-engine and a review date — that is reporting your own non-conformance
  to an engine, so we would rather you assent to it than discover it. Also note approval-engine
  (section 9.4): it owns the approval object, not the approval workflow, so ops-warden
  lanes needing approval consume a claim rather than implementing one. Assent, revision,
  or rejection acceptable.'
created: '2026-08-28T20:40:24.957468Z'
updated: '2026-08-28T20:40:24.957468Z'
state_hub_intake_id: "01a04d97-94cd-7b49-8019-a91c7fce8adb"