Declare Engine/PIP and open TEN-WP-0011 for v0.7 conformance

The security layer model is accepted at v0.7. INTENT.md now declares
Engine / PIP in this repository's own voice (TEN-DEC-2026-001), SCOPE.md
is brought current with shipped APIs, and the intent/scope/implementation
review is history/2026-08-29-security-layer-intent-scope-review.md.

TEN-IN-0003 is absorbed by the declaration. Approvals stay with
approval-engine. TEN-IN-0001 and TEN-IN-0002 promote into TEN-WP-0011.

Assistant: grok
Assistant-Session: 01a04cea-e5e8-7081-a0fc-808ebbc35fa9

decisions/decisions.md

@@ -0,0 +1,75 @@
+# Decision records
+
+## TEN-DEC-2026-001 — Declare Engine / PIP; contest approval lifecycle here
+
+```yaml
+id: TEN-DEC-2026-001
+kind: decision
+title: "Declare Engine / PIP; contest approval lifecycle here"
+status: resolved
+disposition: approved
+origin: cross-repo
+origin_ref: TEN-IN-0003
+standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
+companion: net-kingdom/SECURITY-COMPANION.md
+owner: tenant-engine
+affects:
+  - tenant-engine
+  - gate-house
+  - net-kingdom
+  - access-engine
+  - approval-engine
+created: "2026-08-29"
+updated: "2026-08-29"
+decided_by: tenant-engine (reviewing side)
+decided_at: "2026-08-29"
+```
+
+## Context
+
+gate-house asked this repository, via `TEN-IN-0003`, to declare its layer in
+`INTENT.md` in its own voice, or contest it. Proposed layer: Engine —
+tenant-as-an-entity facts. The existing boundary contract was to hold
+unchanged. One live question: the reserved guardrail/quota policy was
+briefly considered as a home for organizational approval lifecycle before
+`approval-engine` was seeded; if approvals belong nearer tenant governance,
+now is the time to say.
+
+The NetKingdom Security Layer Model was accepted at v0.7 on 2026-08-29. The
+working companion is `net-kingdom/SECURITY-COMPANION.md` v0.2. Statute §4
+already catalogues this repository as Engine / PIP. Statute §11 says a layer
+stated *about* a repository is not a declaration; only this file, in this
+repository's voice, conforms. The previous `INTENT.md` carried a gate-house
+review note naming Engine above a line that admitted the body was unadapted.
+
+## Decision
+
+1. **Declare Engine, role PIP.** Same authoritative tenant state yields the
+   same result. This repository supplies tenant-as-an-entity facts as claims
+   a decision consumes. It does not render or cache an authorization
+   decision. `access-engine` (`flex-auth` until the governed rename) remains
+   the only PDP. The declaration lives in `INTENT.md` frontmatter
+   (`layer: Engine`, `role: PIP`) and in the body's own-voice note.
+2. **Contest placing approval lifecycle here.** A guardrail is a safety
+   ceiling — a PIP fact. An approval is a durable object owned by
+   `approval-engine` (statute §4, §9.4) and consumed as a claim by
+   `access-engine`. Tenant governance will not mint, store, or evaluate
+   approvals. If a tenant mutation should require one, the write stays
+   PEP-shaped: this engine mutates only after `access-engine` has allowed
+   it, and that decision may rest on an `approval-engine` claim.
+3. **Name the write path PEP-shaped without becoming a PDP.** Protected
+   side effects (create, grant, revoke, plan, lifecycle, grouping,
+   guardrail mutations) proceed only with a decision record or a recorded
+   fail-closed unreachable-engine stance. That stance is already the
+   shipped default; publishing it and persisting decision ids is
+   implementation, recorded as `TEN-WP-0011`, not a change of layer.
+
+## Consequences
+
+- `TEN-IN-0003` is closed, absorbed by this decision.
+- Implementation gaps against v0.7 are not hidden by the declaration.
+  They are `TEN-WP-0011`.
+- A boundary-contract amendment in `net-kingdom` is requested from that
+  workplan: guardrails are no longer reserved, and "not a policy
+  enforcement point" must be restated so it cannot be read as denying the
+  PEP *shape* of our writes.