Reframe INTENT as an Engine and the sole decision point

Per gate-house GH-DEC-2026-001 and net-kingdom canon
security-layer-model_v0.1. The rename to access-engine is NOT part of this
change; it remains a separate governed migration.

- Drop the "control plane" self-description: that is Staff-layer vocabulary,
  and flex-auth is an Engine — a deterministic API where the same
  authoritative input state yields the same result.
- State the exclusive role: flex-auth is the only policy decision point in
  NetKingdom. No other repository, in any layer, renders or caches a decision.
- Split authoring from evaluation. flex-auth owns evaluation exclusively plus
  the policy-as-code mechanism; gate-house owns the doctrine, invariants,
  authority ceilings, operating modes, and the authority context consumed as
  input claims; policy content stays with the protected system's owner.
- Record the access lane/rule demarcation: ops-warden and ops-mason own lanes
  (how a worker reaches a host), flex-auth owns rules (whether they may).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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";
+> The model is `net-kingdom/canon/standards/security-layer-model_v0.1.md` (proposed),
-> it is ruled to become a `net-kingdom/canon/standards/` standard, not yet written.
+> 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
+Flex-auth is a policy-as-code authorization registry and **decision engine**
-organizations that want to grow from simple access rules into enterprise-grade
+for organizations that want to grow from simple access rules into
-authorization without giving up clear ownership, local development ergonomics,
+enterprise-grade authorization without giving up clear ownership, local
-or inspectable policy decisions.
+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.