repo.work.create_intake FLEX-IN-0001

correlation_id: 6ecb3fb9-f866-4c24-ad03-ba9e15915442
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

@@ -5,15 +5,23 @@
 > 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 as currently stated is `gate-house/INTENT.md` § "Where Gate House Sits";
-> it is ruled to become a `net-kingdom/canon/standards/` standard, not yet written.
+> 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 Engine — and the only policy decision point in NetKingdom.** The largest adaptation of the review. (1) **Rename to `access-engine`** — ruled, with sequence: reframe this INTENT first, rename second as a governed migration, since the rename touches `FLEX-WP` prefix ownership, State Hub identifiers, ops-warden's tables, zone-engine's binding boundary text, and secrets-engine integrations. `auth-engine` was rejected because key-cape owns authentication and `auth-` keeps the ambiguity. (2) **Drop the "control plane" self-description** — that is Staff vocabulary for an Engine-layer repository. (3) **Split policy authoring from policy evaluation**: authoring, governing, and versioning policy is Staff work (gate-house); evaluating it deterministically and in-path is this repository's, and stays exclusively so. This is the constructive resolution of the `FLEX-WP-0017` overlap — gate-house designs the approval contract, access-engine validates approvals at decision time. (4) Consume gate-house's **authority context** (principal / actor / runtime identity / mandate / operating mode) as input claims. (5) Record the demarcation: **ops-warden and ops-mason own access lanes; access-engine owns access rules.**
+> **This repository is Engine — and the only policy decision point in NetKingdom.**
+> Reframed on 2026-08-28 per `gate-house/decisions/decisions.md` GH-DEC-2026-001:
+> "control plane" dropped as Staff vocabulary, the layer and the exclusive
+> decision-point role stated, policy authoring separated from policy evaluation,
+> gate-house's authority context adopted as input claims, and the access
+> lane/rule demarcation recorded.
 >
-> *This note records what should change. The body below is not yet adapted.*
+> *Reframe applied. One item remains: the ruled rename to `access-engine`, which
+> is a separate governed migration — it touches `FLEX-WP` prefix ownership, State
+> Hub identifiers, ops-warden's routing tables, zone-engine's binding boundary
+> text, and secrets-engine integrations — and is not authorized by GH-DEC-2026-001.*
 
 > This file captures **why this repository exists**, the **direction it is
 > moving toward**, and the **kind of system it is meant to become**.
@@ -22,10 +30,19 @@
 
 ## Intent
 
-Flex-auth is a policy-as-code authorization registry and control plane for
-organizations that want to grow from simple access rules into enterprise-grade
-authorization without giving up clear ownership, local development ergonomics,
-or inspectable policy decisions.
+Flex-auth is a policy-as-code authorization registry and **decision engine**
+for organizations that want to grow from simple access rules into
+enterprise-grade authorization without giving up clear ownership, local
+development ergonomics, or inspectable policy decisions.
+
+It is an **Engine** in the NetKingdom security layer model
+(`net-kingdom/canon/standards/security-layer-model_v0.1.md`): a deterministic
+API for a modeled concept, where the same authoritative input state yields the
+same result. It is deliberately not described as a control plane — that is
+Staff-layer vocabulary, and flex-auth is not Staff.
+
+Within NetKingdom it is **the only policy decision point** (standard §6). No
+other repository, in any layer, may render or cache an authorization decision.
 
 It is the **authorization layer** in the path from verified identity to
 protected resources:
@@ -71,24 +88,55 @@ authenticated; flex-auth decides what that actor is allowed to do.
 - The canonical identity claim contract and required claims.
 - Coarse roles, scopes, and assurance claims.
 
-### Flex-Auth Owns Authorization
+### Flex-Auth Owns the Decision
 
+- **Evaluation — exclusively.** Rendering the decision, in-path, deterministically.
 - Protected-system registration.
 - Resource namespaces and resource hierarchy.
 - Canonical action vocabulary.
-- Policy-as-code packages, tests, versions, and rollout.
+- The policy-as-code mechanism: package format, tests, versions, and rollout.
 - Mapping enterprise groups, app roles, scopes, tenants, and assurance claims
   into resource-specific authorization.
 - Relationship facts and inherited access.
 - PDP adapter coordination.
 - Decision logging, explanations, and audit export.
 
+### Gate House Owns the Doctrine the Decision Serves
+
+Authoring and governing security doctrine is Staff work. `gate-house` owns the
+invariants policy must satisfy, the authority ceilings, the assistant and
+autonomous operating modes, and the **authority context** — principal, actor,
+runtime identity, tenant, mandate, operating mode — which flex-auth consumes as
+input claims alongside verified identity claims.
+
+The division is between *authoring the rules of the game* and *rendering a
+result*: gate-house designs the approval contract and the invariants; flex-auth
+validates approvals and renders decisions at request time. Neither can do the
+other's half. Policy **content** for a given protected system remains authored
+by that system's owner, within flex-auth's mechanism and gate-house's doctrine.
+
+Gate House holds no runtime position and never renders a decision. A
+deterministic authority boundary inside a non-deterministic layer would violate
+the invariant the estate is built on.
+
 ### Protected Systems Own Enforcement
 
 Applications remain policy enforcement points. They extract resource
 metadata, call flex-auth for decisions, enforce allow/deny/redact results,
 and emit local diagnostics. They do not own central policy administration.
 
+### Access Lanes Are Not Access Rules
+
+The estate uses "access" for two different things, and the demarcation is
+normative (standard §8):
+
+- **ops-warden and ops-mason own access lanes** — how a worker reaches a host:
+  routes, tunnels, SSH certificates, credential lanes.
+- **flex-auth owns access rules** — whether an actor may act at all.
+
+A lane delivers someone to the door. This repository decides whether the door
+opens. Neither substitutes for the other, and neither owns the other's word.
+
 ## Design Principles
 
 - Policy is code: versioned, reviewed, tested, and explainable.

intakes/intakes.md

@@ -0,0 +1,34 @@
+# Intake records
+
+## FLEX-IN-0001 — Assent requested: Engine framing, access-engine rename, and the authoring/evaluation split
+
+```yaml
+id: FLEX-IN-0001
+kind: intake
+title: 'Assent requested: Engine framing, access-engine rename, and the authoring/evaluation
+  split'
+status: open
+origin: cross-repo
+origin_ref: gate-house GH-DEC-2026-001
+priority: high
+owner: flex-auth
+requested_by: gate-house
+standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
+description: 'gate-house asks flex-auth to assent to three items ratified in GH-DEC-2026-001,
+  following the estate precedent that a boundary is drawn on review by the other side
+  rather than asserted — as flex-auth itself did to zone-engine. (1) flex-auth is
+  Engine-layer and is NetKingdom’s only policy decision point; the INTENT reframe
+  is already applied (commit fe46122) and can be revised or reverted if wrong. (2)
+  The ruled rename flex-auth -> access-engine, NOT yet authorized to execute: it is
+  a separate governed migration touching FLEX-WP prefix ownership, State Hub identifiers,
+  ops-warden routing tables, zone-engine boundary text, and secrets-engine integrations.
+  auth-engine was rejected because key-cape owns authentication. (3) The split: flex-auth
+  owns evaluation exclusively plus the policy-as-code mechanism; gate-house owns doctrine,
+  invariants, authority ceilings, operating modes, and the authority context consumed
+  as input claims; policy content stays with the protected system owner. This resolves
+  the FLEX-WP-0017 overlap — gate-house designs the approval contract, flex-auth validates
+  approvals at decision time. Assent, revision, or rejection all acceptable; the standard
+  stays proposed until this is answered.'
+created: '2026-08-28T19:30:03.602578Z'
+updated: '2026-08-28T19:30:03.602578Z'
+```