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

SCOPE.md

@@ -2,8 +2,10 @@
 
 ## One-liner
 
-flex-auth is a policy-as-code authorization registry and control plane for
-NetKingdom-aligned systems.
+flex-auth is a policy-as-code authorization registry and decision engine for
+NetKingdom-aligned systems. Under the NetKingdom Security Layer Model
+(`security-layer-model_v0.7`, accepted 2026-08-29) it is **Engine / PDP** — the
+estate's only policy decision point.
 
 ## Core Idea
 
@@ -33,6 +35,14 @@ can be coordinated behind a stable flex-auth API.
 - Markitect as the first concrete protected-system consumer.
 - Delegated PDP and directory adapter boundaries after the standalone core is
   stable.
+- The **decision-record schema**, published as flex-auth's own contract
+  (`security-layer-model_v0.7` §17).
+- The **canonical request digest** as the published replay test for consumers
+  (§6.4.2).
+- **Decision lifetimes** on every allow, and **revocation visibility deadlines
+  stated per input class** (§9.7).
+- **Registry-snapshot provenance**, so a decision that turned on registry
+  content is replayable from its own record (§6.1, §9.7.2).
 
 ## Out of Scope
 
@@ -46,6 +56,18 @@ can be coordinated behind a stable flex-auth API.
   model.
 - Forcing a single PDP backend or directory provider.
 - Hiding policy behavior behind opaque administrative toggles.
+- Expressing fail-open. When flex-auth is unreachable there is no evaluator in
+  the path; the residue is the consumer's declared stance (§9.3).
+- Owning enforcement. A PEP's obligations under §6.4 are the consumer's,
+  including its published stance map.
+- Owning the approval object, its storage, or its lifecycle — that is
+  `approval-engine`'s (§9.4). flex-auth validates approvals as input claims and
+  never mutates them.
+- Owning evidence of authentication or assurance. flex-auth consumes assurance
+  claims and never redefines them; it owns evidence of the decision
+  (`FLEX-DEC-2026-002`, recorded as declined in §13).
+- Authoring security doctrine. gate-house owns invariants, authority ceilings,
+  operating modes, and the authority context flex-auth consumes as claims.
 
 ## Relevant When
 
@@ -105,13 +127,19 @@ ops-warden adopted a calling identity (`WARDEN-WP-0031`): anonymous `/v1/check`
 is 401, a token bound to another protected system is 403.
 
 Production `policy.enabled` is **deliberately off, and is not coming back as a
-boolean.** ops-warden's `ADR-0006` (2026-08-19) defers it permanently:
+boolean.** ops-warden's `ADR-0009` (2026-08-22, superseding `ADR-0006`) settles it:
 `policy.enabled` is one repo-wide flag, and with `fail_closed: true` it makes
 flex-auth a hard dependency of every `warden sign` — including the SSH
 certificates the ops-bridge tunnels depend on, one of which carries the policy
-call itself. Enforcement is being rescoped to *security zones* (`zone-engine`
-`ZONE-WP-0001`, consumer side `WARDEN-WP-0032`). flex-auth reviewed that model as
-the PDP on 2026-08-19 and holds one boundary: zone **membership** compiles into
+call itself. `ADR-0009` retires `policy.enabled` and the global `policy.fail_closed`
+outright and replaces them with a total per-zone stance map in the consumer PEP
+(`ops-warden/pep-stance.yaml`): open for `z0`-`z2` and `unknown`, closed for
+`z3-critical`. That map is the reference shape for `security-layer-model_v0.7`
+§6.4 obligation 3, and it is the estate's only published one — §13.1's register
+has one row, which the standard records as itself the finding.
+
+flex-auth reviewed the zone model as the PDP on 2026-08-19 and holds one
+boundary: zone **membership** compiles into
 the registry snapshot flex-auth already consumes (no schema change needed), while
 per-zone **stance** belongs in the versioned policy package, because registry
 content is absent from decision provenance. **Fail-open is not expressible by a
@@ -119,6 +147,16 @@ PDP at all** and stays a consumer-side setting. The enforcing pins stay
 enforcing regardless — an enforcing pin with no enforcing consumer still turns
 the anonymous path into a 401 rather than a decision.
 
+**Layer position (2026-08-29).** The NetKingdom Security Layer Model was
+accepted at v0.7. flex-auth is **Engine / PDP**, declared machine-readably in
+`INTENT.md` frontmatter per §11. Four of flex-auth's review findings were adopted
+into the standard: §9.3's two-owner split for degraded mode, §6.4.2 scoped to the
+decision's own binding with the canonical request digest as its mechanical test
+and negative caching ruled explicitly, §9.7.2 split by role, and §17 moving the
+decision-record schema to flex-auth. Conformance state is **conforming with one
+declared gap** — the registry-snapshot digest in decision provenance, which §9.7.2
+promotes to a conformance prerequisite. `FLEX-WP-0019` carries the work.
+
 State Hub integration is present through:
 
 - `.custodian-brief.md`
@@ -212,20 +250,34 @@ description: Repo intent, boundaries, research, workplan map, and State Hub agen
 ```capability
 type: workplan
 title: Standalone policy core plan
-status: planned
+status: current
 description: Workplan for schemas, local registry, policy packages, check APIs, list/explain, decision log, CLI/service skeleton, tests, and examples.
 ```
 
 ```capability
 type: workplan
 title: Markitect consumer integration plan
-status: planned
+status: current
 description: Workplan for Markitect resource namespace, manifest import, action vocabulary, check fixtures, contract tests, and integration flow.
 ```
 
 ```capability
 type: workplan
 title: Delegated adapter plan
-status: planned
+status: current
 description: Workplan for Topaz evaluation, relationship PDP adapters, rule PDP adapters, Keycloak AuthZ path, directory resolvers, and operations docs.
 ```
+
+```capability
+type: contract
+title: Decision-record contract
+status: current
+description: Published decision-record schema, canonical request digest as the replay test for consumers, and decision provenance — flex-auth's own contract under security-layer-model v0.7 section 17.
+```
+
+```capability
+type: orientation
+title: Layer declaration
+status: current
+description: Machine-readable Engine/PDP declaration in INTENT.md frontmatter with conformance state and the one declared gap, per security-layer-model v0.7 section 11.
+```