Declare the layer per GH-DEC-2026-012; close T02

Gate House ruled all three questions within a day, attributing the speed to the
request being filed before the architecture with candidate answers and their
costs.

R1 PEP-shaped, confirmed as proposed. The ruling settles the shape; the layer
stays ours to declare, so layer.yaml is written in this repository's voice
rather than transcribed from the reply.

R2 yes to a presentation claim, no second catalog row, under three limits now
declared in layer.yaml and tested. Limit 2 — the claim must never be an input to
the decision it presents for — is load-bearing: our self-dealing argument was
accepted because it holds, not despite it. Limit 3 drives architecture, since
here the actor being audited and the evidence source are the same component.

R3 (b) with the authority rule: binding digest authoritative for what the
request is, view_hash only for what was shown, neither substitutable, and a
disagreement between them is a finding against the presenting surface rather
than a fact about the request. Linkage is co-reference; nesting was refused
because it reproduces the GH-DEC-2026-008 hash cycle.

Built to v0.8 obligation 3 rather than migrating later: axis enumerated, unknown
resolves to fail_closed, absent distinguishable from unknown in the record, and
published-equals-shipped asserted by test rather than claimed. Every stance is
fail_closed, which is a conclusion not a shortcut — ops-warden can justify
fail_open on a continuity argument that does not exist here.

GH-DEC-2026-010 inherited as a declared gap in four documents: a decision cannot
today be proven to have come from access-engine. The decision path must not be
described as validated while FLEX-WP-0024 is open.

46 tests pass. T05 and T07 unblocked.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568

INTENT.md

@@ -7,7 +7,7 @@ date: "2026-09-09"
 domain: infotech
 topic_slug: netkingdom
 layer: surface
-role: pep-shaped          # PROVISIONAL — see "Layer Placement", INFD-WP-0001-T02
+role: pep-shaped          # confirmed by GH-DEC-2026-012; see layer.yaml
 standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
 companion: net-kingdom/SECURITY-COMPANION.md
 ---
@@ -184,21 +184,69 @@ not failure** — a memo sent back for improvement is the surface working.
     presented view plus explicit highlight acknowledgment — never keystroke
     analytics, dwell timers, or attention theater.
 
-## Layer Placement — Provisional
+## Layer Placement — Ruled
 
-Under security layer model v0.7 this repository is **not** an Engine. It is
-browser-facing and it causes a protected side effect on the far side of a
-decision, which is the shape statute §6.4 and companion §5 call **PEP-shaped**.
-`approval-engine`'s own INTENT names this expectation: *"Callers that do are
-PEP-shaped and owe companion §5 / statute §6.4."*
+**PEP-shaped**, confirmed by `GH-DEC-2026-012` (answering `INFD-IN-0001`).
+Not an Engine: this repository holds no state another layer reads at runtime for
+a verdict, and renders no decision. Companion §5 is owed and statute §6.4
+applies in full. The declaration is `layer.yaml`, in this repository's own voice
+— a layer someone else states about you is not a declaration.
 
-This is declared **provisional** because the catalog row does not exist yet and
-inventing one is the drift §17 exists to prevent. `INFD-WP-0001-T02` takes the
-question to `gate-house` and writes `layer.yaml` from the answer, not from this
-paragraph. The framing this repository will argue: informed-decision is a
-**presentation and binding surface** — a PEP for the acts it fronts, and a PIP
-for exactly one fact, *what was presented*, which it supplies as a claim and
-never evaluates.
+The ruling also confirmed that emitting a **presentation claim** does not
+require a second catalog row: PEP and PIP are shapes a repository has, and §4
+records the layers it occupies. That permission carries three limits, and they
+are the substance of it rather than caveats on it:
+
+1. **The claim carries presentation and nothing else.** It must never carry,
+   restate, summarise or imply the decision, the verdict, or whether the act was
+   permitted. A consumer learns from it only what was *shown*, never what was
+   *decided*.
+2. **The claim must not be an input to the decision it presents for.** A policy
+   reading `view_hash` to decide whether an act is permitted would let the
+   presenting surface contribute to its own authorization.
+3. **The evidence copy reaches `audit-core` independently of this repository.**
+   The claim endpoint and the evidence path are different things and neither
+   substitutes for the other.
+
+Limit 2 is load-bearing. `GH-DEC-2026-012` accepted this repository's argument
+that a renderer attesting its own rendering is not the self-dealing that kept
+the approval object out of `access-engine` — *but only because that limit
+holds*. Without it, the two collapse into the same failure.
+
+Limit 3 is the one that most shapes the architecture: audit evidence is
+protected from the actor being audited, and here the actor and the source are
+the same component.
+
+### `view_hash` and the binding digest
+
+Ruled as option (b): they are **distinct attestations with an authority rule**.
+
+- `approval-engine`'s binding digest is authoritative for **what the request
+  is**.
+- `view_hash` is authoritative for **what was shown**, and nothing else.
+- Neither may be substituted for the other.
+- **A disagreement between them is a finding against the presenting surface,
+  never a fact about the request.**
+
+They link by **co-reference**, not nesting: the presentation record carries the
+approval or binding identifier explicitly, and both attestations are read
+against that one reference. This repository must never recompute or restate
+`approval-engine`'s binding digest in its own vocabulary — it references the
+digest that layer computed and recorded.
+
+Nesting was refused for a reason worth carrying: it reproduces the hash cycle
+that made `GH-DEC-2026-008` unimplementable, where a claim had to name the
+digest of a request that would come to contain it, and a fail-closed consumer
+obeying it would deny permanently.
+
+### An inherited gap, stated rather than glossed
+
+`GH-DEC-2026-010` requires a decision be **attributable** to `access-engine`.
+No consumer can satisfy that today: the decision envelope is unsigned, a
+declared §13 gap tracked as `FLEX-WP-0024`. This repository's record can show
+that a decision was obtained and what it said; it cannot yet show that
+`access-engine` said it. The decision path must not be described as validated
+while that is open.
 
 ## What Would Make This Repository Wrong