Declare Engine/PIP and open USER-WP-0024 for layer conformance

Adopt security-layer-model v0.7 in INTENT.md in this repository's own
voice, restate SCOPE.md from that declaration, and record the
scope-versus-implementation assessment. USER-IN-0001 is answered;
runtime follow-through is USER-WP-0024.

Assistant: grok
Assistant-Session: 01a04cea-f0d6-7ab3-9ffd-881eb6bea6cb

INTENT.md

@@ -1,24 +1,94 @@
-# INTENT
+---
+layer: Engine
+role: PIP
+standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
+companion: net-kingdom/SECURITY-COMPANION.md
+declared: "2026-08-29"
+---
 
-> **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 Engine — deterministic API for a modeled concept.** Add the layer label. The existing boundary contract (`net-kingdom/canon/standards/user-engine-boundary-contract_v0.1.md`) holds unchanged. Worth making explicit that user-engine supplies subject context as input to the authorization decision and never renders one.
->
-> *This note records what should change. The body below is not yet adapted.*
+# INTENT
 
 > 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 current implementation.
 
+## Layer
+
+**Engine, role PIP.** This is user-engine's own declaration under the
+NetKingdom Security Layer Model
+([`SECURITY-COMPANION.md`](../net-kingdom/SECURITY-COMPANION.md) v0.2;
+statute [`security-layer-model_v0.7.md`](../net-kingdom/canon/standards/security-layer-model_v0.7.md),
+accepted 2026-08-29). A layer stated about this repository by another
+repository is not a declaration; this one is.
+
+The same authoritative user-domain inputs yield the same result. That
+determinism is the test. user-engine is not Staff: it is not a judgment
+surface. It is not Tooling: it does not package identity infrastructure or
+hold runtime secrets. It is not the PDP: `access-engine` (`flex-auth` until
+the governed rename) is the only decision point in the estate.
+
+The catalog row we accept: **users, accounts, memberships.** The existing
+boundary contract
+(`net-kingdom/canon/standards/user-engine-boundary-contract_v0.1.md`) holds
+unchanged. What the model adds, and what this file now states in our own
+voice:
+
+- we **supply subject context as claims** a decision consumes;
+- we **never render, cache, or compile an authorization decision**;
+- a new engine is a PIP unless the statute is amended, and we stay one.
+
+**PEP-shaped, same layer.** Protected mutations in this service — account
+lifecycle, memberships, invitations, registration orchestration, hat
+selection, catalog and profile writes — proceed only after a decision from
+`access-engine`, or under a published unreachable-engine stance whose
+application is recorded in place of a decision. Being PEP-shaped does not
+move the repository out of Engine/PIP. The stance map belongs at a path
+named in the machine-readable layer declaration, registered in statute
+§13.1; shipping fail-closed in an adapter is not publication.
+
+**Not contested.** Engine/PIP is the right assignment. What we raise back
+is that §4 catalogues us as Engine/PIP and does not mark the PEP shape
+that our protected mutations already have. That is a register finding,
+not a layer dispute.
+
+### Binding rules this repository keeps
+
+1. **One decision point.** `access-engine` renders authorization decisions.
+   user-engine asks, enforces, and records. Access-control facts, hats,
+   memberships, and projections are inputs and read models, never a local
+   allow.
+2. **Compiled data that determines an outcome is still deciding.** A
+   registry, cache, or access-profile schema that resolved a result before
+   the engine ran would be an early decision. Provenance of anything we
+   export as claims must remain reconstructable from the decision record
+   that consumed it.
+3. **Doctrine arrives as a claim.** Nothing we hold — membership, hat,
+   assurance forwarded from IAM, tenant capability roles — becomes
+   authority except by reaching `access-engine` as a request claim or a
+   versioned policy rule.
+4. **Adaptive systems may only tighten.** user-engine does not manufacture
+   authority, and it does not assume the estate can contain anything
+   automatically. Actuation is unowned and held at zero.
+5. **Every allow has a lifetime.** A decision we enforce is used within
+   its stated binding and lifetime, not as a standing grant.
+6. **Evidence proves alteration and truncation, not omission at source.**
+   Local audit and the durable outbox prove the records they hold. They
+   do not prove that an event never sent did not happen. Completeness is
+   not claimed.
+7. **Agents working this repository are Staff principals**, not a second
+   layer. No standing credential, tool use only as a conduit or an Engine
+   API, memory is not a state plane, every action reconstructable as the
+   caller's. How to get a credential or a lane is `ops-warden`'s, not
+   this file's.
+
+**Tooling.** §5 binds Staff. This Engine owns the persistence of the
+concept it models (the user-domain store). It consumes verified IAM
+Profile claims from `key-cape` / Keycloak / `local-identity`, and runtime
+secret *references* injected by Railiance. It holds no OpenBao client and
+no Keycloak admin client. A `SecretProvider` port exists so an engine
+surface can replace environment injection when `secrets-engine` exposes
+one; until then that capability is at zero here, not taken locally.
+
 ## Purpose
 
 `user-engine` exists to provide a reusable, headless user-domain and
@@ -27,6 +97,11 @@ preference, membership, identity-context, and application-specific user
 attribute management without coupling those concerns to a particular identity
 provider, authorization engine, security stack, or user interface.
 
+As a PIP it is the estate's source of user-domain facts that authorization
+and consuming applications may take as claims: who the subject is in a
+domain context, which account and memberships apply, which profile
+material may be projected, and which identity-context mappings hold.
+
 ## Primary Utility
 
 The project provides a canonical user layer that can start small in a
@@ -45,13 +120,16 @@ It manages:
 - profile projections for consuming applications;
 - lifecycle and profile-change events.
 
+Those records are the PIP surface. They are not a policy package.
+
 ## Strategic Direction
 
 `user-engine` is intended to become the NetKingdom identity-domain integration
-layer: a headless service that exposes canonical identity, user, account,
+layer: a headless Engine that exposes canonical identity, user, account,
 membership, tenant, team, profile, lifecycle, and evidence-facing concepts to
-applications without requiring those applications to know the technical IAM,
-security, authorization, audit, or secret-management implementation details.
+applications, and that supplies those facts as claims to `access-engine`,
+without requiring those applications to know the technical IAM, security,
+authorization, audit, or secret-management implementation details.
 
 NetKingdom infrastructure remains the source of truth for authentication,
 credential assurance, token issuance, policy decisions, security controls,
@@ -70,6 +148,9 @@ applications and agents to answer:
   claims-enrichment contexts;
 - which lifecycle, access-review, evidence, or integration gaps need attention.
 
+It should never answer whether an actor may act. That answer is
+`access-engine`'s, including when the resource is a user-engine record.
+
 ## Strategic Role
 
 `user-engine` separates user-domain management from authentication,
@@ -85,6 +166,11 @@ identity-context mappings. It should reference, map to, or consume adjacent
 canon entities when their source of truth belongs to NetKingdom infrastructure,
 security, access-control, governance, or organization systems.
 
+Hats, realms, services, assets, and access profiles stay user-domain facts
+and claim templates. They exist so `access-engine` and consuming runtimes
+can see the same subject context; they do not become a second decision
+point by compilation or by local evaluation.
+
 ## Intended Users
 
 - application developers adding user/account functionality to a service;
@@ -96,7 +182,9 @@ security, access-control, governance, or organization systems.
   context;
 - domain services that need identity-canon aligned user, actor, principal,
   subject, tenant, team, membership, and evidence references without depending
-  on technical IAM implementation details.
+  on technical IAM implementation details;
+- `access-engine`, as a PIP consumer of subject, membership, and
+  access-control facts.
 
 ## Product Boundaries
 
@@ -107,15 +195,19 @@ It does not aim to be:
 - a full identity provider;
 - a password, passkey, session, or MFA system;
 - a fine-grained authorization engine;
-- the policy decision point for protected resources;
+- the policy decision point for protected resources, including its own;
 - the owner of NetKingdom security controls or runtime secrets;
 - the full organization, HR, or directory authority;
 - a directory server;
-- a UI application.
+- a UI application;
+- an observer of production security events;
+- an actuation surface for containment, step-up, or authority reduction.
 
 It provides the user-domain and identity-domain APIs, mapping records, catalog
-metadata, projections, events, evidence references, and audit records that those
-surrounding systems can consume.
+metadata, projections, events, evidence references, and local audit records
+that those surrounding systems can consume. Platform audit custody stays
+with `audit-core`. Optional UI in this repository is a surface over the
+same APIs, not a product identity.
 
 ## Design Principles
 
@@ -124,14 +216,17 @@ surrounding systems can consume.
 - standalone-friendly;
 - enterprise-integratable;
 - identity-provider agnostic;
-- authorization-engine agnostic;
+- authorization-engine agnostic — and never a substitute for one;
 - NetKingdom-integrated without hiding source-of-truth boundaries;
 - canon-aligned through explicit entity and relationship mappings;
 - catalog-driven customization;
 - explicit ownership, visibility, mutability, and sensitivity of attributes;
 - layered profiles instead of one global metadata blob;
 - deterministic and inspectable effective profile resolution;
-- evidence and lifecycle awareness for identity-domain changes;
+- evidence and lifecycle awareness for identity-domain changes, bounded by
+  what an archive can actually prove;
+- fail closed on unreachable `access-engine` for protected mutations, with
+  that stance published rather than implied by adapter code;
 - concrete user-domain focus with a possible future extraction path toward a
   generic profile engine.
 
@@ -147,3 +242,9 @@ intent: applications should be able to consume user, account, identity-link,
 actor, principal, subject, tenant, team, membership, profile, lifecycle, and
 evidence context through stable APIs and mappings without taking a direct
 dependency on the technical IAM, authorization, security, or audit substrate.
+
+It succeeds as a PIP when `access-engine` can consume those facts as claims
+and reconstruct their application from the decision record, and as a
+PEP-shaped engine when every protected mutation it performs is bound to a
+decision or to a recorded stance, with a lifetime, and without a second
+decision point hiding in a cache, a hat, or a local adapter.