Align INTENT and SCOPE to security layer model v0.7; plan conformance work

The standard was accepted at v0.7 on 2026-08-29. Four of flex-auth's review
findings are in the accepted text: 9.3's two-owner split, 6.4.2 scoped to the
decision's own binding with our canonical request digest as its mechanical test,
9.7.2 split by role, and 17 moving the decision-record schema to access-engine.

INTENT.md
- Machine-readable layer declaration in frontmatter (layer: Engine, role: PDP),
  which section 11 requires and we did not have. audit-core noted our
  declaration was legible only by following the decision trail.
- PDP failure semantics stated: our outage is consumer residue, not input
  degradation; fail-open is not expressible by a PDP at all.
- Four owned obligations added: the decision-record schema as our contract, the
  request digest as the published replay test, a lifetime on every allow, and
  visibility deadlines per input class.
- A Layer Conformance section stating the state honestly: conforming with one
  declared gap, no Tooling client, not PEP-shaped.
- Vocabulary correction: earlier text dropped "control plane" as Staff
  vocabulary. Section 8 binds it to the Engine layer, which is why kings-guard
  was asked to release it. The term is ours; we prefer "decision engine" for
  precision, not boundary.

SCOPE.md
- Layer and role in the one-liner; the four obligations In Scope; five
  boundaries established in review but never written down Out of Scope.
- Three capability blocks marked planned for workplans completed in May are now
  current; two blocks added.
- Superseded ADR-0006 citation corrected to ADR-0009, which retires the global
  flag outright rather than deferring it.

history/2026-08-29-layer-model-v0.7-alignment-review.md checks each obligation
against the code and finds six gaps. FLEX-WP-0019 closes them, with T02 before
T04 because a visibility deadline for registry-borne facts is unfalsifiable
until provenance can identify the snapshot a decision read.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012sgN4GH5ZYT8pJVkCR6dcP

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014348@bnt-lap001
Assistant-Session: a993abda-65a0-4ea8-8ccd-0fcd78c92ac0

INTENT.md

@@ -1,45 +1,53 @@
+---
+# NetKingdom security layer declaration (security-layer-model_v0.7 §11).
+# Machine-readable because §11 requires it: prose cannot distinguish a
+# declaration from a transcribed review. Reference form: ops-warden layer.yaml.
+layer: Engine
+role: PDP
+framework: netkingdom-security-layer-model
+standard_version: "0.7"
+declared_by: decisions/decisions.md FLEX-DEC-2026-001, FLEX-DEC-2026-002, FLEX-DEC-2026-003
+declared_at: "2026-08-29"
+pep_stance: null            # not PEP-shaped: flex-auth renders decisions, it causes no protected side effect
+tooling_contacts: []        # §5 binds Staff; flex-auth holds no Tooling client
+---
+
 # Flex-Auth Intent
 
-> **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.
+> **Layer declaration.** flex-auth is **Engine / PDP** under the NetKingdom
+> Security Layer Model (`net-kingdom/canon/standards/security-layer-model_v0.7.md`,
+> accepted 2026-08-29). It is **the only policy decision point in NetKingdom**
+> (§6): no other repository, in any layer, renders or caches an authorization
+> decision. The frontmatter above is the machine-readable form §11 requires; this
+> paragraph is the declaration in flex-auth's own voice.
 >
-> The layer rule that binds every repository: **Staff never touches tooling
-> directly. It acts only through engine APIs.**
+> The layer rule that binds every repository: **Staff never touches Tooling
+> directly. It acts only through Engine APIs.** flex-auth is one of those APIs.
 >
-> **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.
+> **What PDP means here, and what it does not.** As the estate's only PDP,
+> flex-auth's outage is *consumer residue*, not input degradation (§9.3): when
+> flex-auth is unreachable there is no evaluator in the path, so what happens
+> next is the consumer's declared stance and never flex-auth's to express.
+> Fail-open is not expressible by a PDP at all. When flex-auth is reachable but
+> cannot reach its own inputs, the fallback is flex-auth's, deterministic, and
+> fails to reduced authority. The PIP engines — user, tenant, zone, approval,
+> maturity — supply facts flex-auth consumes as claims; `audit-core` records;
+> `secrets-engine` holds credential lifecycle downstream of a decision.
 >
-> *Reframe applied. **Assent given on 2026-08-28** — `decisions/decisions.md`
-> FLEX-DEC-2026-001, answering intake `FLEX-IN-0001`: flex-auth assents to the Engine
-> framing, to `access-engine` as the ruled name, and to the authoring/evaluation
-> split. One item remains: the rename itself, 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. flex-auth adds two conditions on it
-> (FLEX-DEC-2026-001 item 2): repository identity and runtime identity rename in
+> flex-auth reached this position by review rather than assertion, and holds
+> three records: `FLEX-DEC-2026-001` (Engine framing, the `access-engine` name,
+> the authoring/evaluation split), `FLEX-DEC-2026-002` (§9.3 contested and
+> upheld), and `FLEX-DEC-2026-003` (v0.6 review; §6.4.2, §9.7.2 and §17 as
+> adopted in v0.7).
+>
+> *One item remains open: the ruled rename to `access-engine`. It is a separate
+> governed migration — it touches `FLEX-WP` prefix ownership, State Hub
+> identifiers, ops-warden's routing tables, zone-engine's boundary text, and
+> secrets-engine integrations — and carries two conditions from
+> `FLEX-DEC-2026-001`: repository identity and runtime identity rename in
 > separate revertible steps, repository first, because the enforcing ops-warden
 > pin binds tokens to the protected-system name; and `FLEX-WP` prefix ownership
 > stays with the repository.*
->
-> **Known non-conformance — registry provenance.** Standard §6 holds that
-> compiled data determining an outcome is still deciding, and that provenance
-> must stay reconstructable from the decision. `DecisionProvenance` carries the
-> evaluator, mode, policy package, policy version, and directory ETag, but no
-> digest of the registry snapshot. A decision that turned on registry content
-> cannot be replayed from its own provenance. flex-auth accepts this as its own
-> gap rather than claiming conformance; until it is closed, outcome-determining
-> content belongs in the versioned policy package, not the registry — for
-> zone-engine's zone stance, for gate-house's authority ceilings, and for
-> everyone else on the same terms.
 
 > This file captures **why this repository exists**, the **direction it is
 > moving toward**, and the **kind of system it is meant to become**.
@@ -53,14 +61,24 @@ 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
+It is an **Engine**, role **PDP**, in the NetKingdom security layer model
+(`net-kingdom/canon/standards/security-layer-model_v0.7.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.
+same result.
 
 Within NetKingdom it is **the only policy decision point** (standard §6). No
 other repository, in any layer, may render or cache an authorization decision.
+Engine typing (§3.3) makes the corollary explicit: a new engine is a PIP unless
+the standard is amended, so *"we need an engine for X"* can never become *"X now
+decides"*.
+
+A note on vocabulary, corrected here. Earlier versions of this file dropped
+"control plane" on the grounds that it was Staff-layer vocabulary. That reason
+was wrong on the standard's own terms — §8 binds **control plane to the Engine
+layer**, which is why kings-guard was asked to release it. The term is
+flex-auth's to use. This file prefers **decision engine** anyway, because it
+names what flex-auth does rather than where it sits, but the preference is
+style, not a boundary.
 
 It is the **authorization layer** in the path from verified identity to
 protected resources:
@@ -118,6 +136,19 @@ authenticated; flex-auth decides what that actor is allowed to do.
 - Relationship facts and inherited access.
 - PDP adapter coordination.
 - Decision logging, explanations, and audit export.
+- **The decision-record schema**, published as flex-auth's own contract
+  (§17). A decision record is the PDP's output artifact — the one thing in the
+  estate only flex-auth produces — so §2 keeps its schema here rather than in
+  Taxonomy. flex-auth argued this against its own interest and took the work on.
+- **The canonical request digest** over normalized subject, action, resource,
+  and context. It is the mechanical test for §6.4.2: a consumer may replay a
+  verdict iff the digest matches and the decision's lifetime holds.
+- **A stated lifetime on every allow** (§9.7.1) — a TTL, or a binding to a
+  session or obligation that ends. An allow with no stated end is a standing
+  grant.
+- **A revocation visibility deadline per input class** (§9.7.2) — approval-claim
+  freshness, registry snapshot cadence, policy package activation, directory
+  ETag. A single number at a PDP is either a fiction or the worst case.
 
 ### Gate House Owns the Doctrine the Decision Serves
 
@@ -237,12 +268,12 @@ adopting their models as its own:
 - a local directory plus policy-evaluation engine for self-contained
   delegated setups
 
-Flex-auth remains the stable control plane even when the backend changes.
+Flex-auth remains the stable decision point even when the backend changes.
 
 ## Consumer Patterns
 
 Two consumer shapes drive flex-auth, and the first one to ship deliberately
-is not a document pipeline — proving the control plane stays generic.
+is not a document pipeline — proving the decision engine stays generic.
 
 **First shipped consumer — an action gate (ops-warden SSH signing).** A
 protected system asks flex-auth a single "may this actor perform this action
@@ -273,6 +304,30 @@ Together these shape flex-auth around real authorization needs — both
 point-in-time action gates and result-filtering pipelines — without making the
 policy service consumer-specific.
 
+## Layer Conformance
+
+flex-auth's conformance state under §11 is **conforming with one declared gap**.
+It holds no Tooling client, so the §5 shapes do not apply to it, and it is not
+PEP-shaped, so it owes no stance map under §6.4.
+
+**The declared gap — registry-snapshot digest in decision provenance (§13).**
+`DecisionProvenance` carries the evaluator, mode, policy package, policy version,
+directory ETag, and decision time, but no digest of the registry snapshot that
+supplied resource, subject, and relationship facts. A decision that turned on
+registry content cannot be replayed from its own provenance.
+
+v0.7 §9.7.2 promotes this from housekeeping to a **conformance prerequisite**,
+on flex-auth's own argument: a stated visibility deadline for a fact carried by
+a registry snapshot is unfalsifiable while provenance holds no snapshot digest,
+because nobody can determine afterwards which snapshot a decision read. The
+deadline and the digest are one gap seen from two sides.
+
+Until it closes, one rule holds and flex-auth applies it to everyone equally,
+including itself: **outcome-determining content belongs in the versioned policy
+package, not in registry content** — for zone stance, for gate-house's authority
+ceilings, for maturity levels, and for flex-auth's own facts. Registry content
+carries membership and identity; the policy package carries effect.
+
 ## Non-Goals
 
 - Flex-auth is not an identity provider.