diff --git a/INTENT.md b/INTENT.md
index b3cff8e..b2519df 100644
--- a/INTENT.md
+++ b/INTENT.md
@@ -1,7 +1,63 @@
+---
+# NetKingdom security layer declaration (§11), in key-cape's own voice.
+#
+# This frontmatter is the declaration. The prose sentence under "# INTENT"
+# is not: §11 says prose cannot distinguish a declaration from a transcribed
+# review. The §4 catalog row, gate-house (GH-WP-0004-T08) and access-engine
+# (FLEX-WP-0030, B2) all name key-cape Tooling; none of that is a declaration,
+# and this value was worked out against §3 from key-cape's own character.
+#
+# Form per GH-DEC-2026-017: INTENT.md governs, no layer.yaml sidecar, no
+# standard version in any key or value (A12, reach per GH-DEC-2026-020).
+layer: Tooling
+role: —
+repository: key-cape
+declared_by: INTENT.md
+declared_at: "2026-09-21"
+ruling: GH-DEC-2026-017
+# Why Tooling. key-cape is deterministic identity infrastructure: it packages
+# Authelia, LLDAP and privacyIDEA and keeps the authentication state they hold
+# (directory entries, second factors, sessions, client registrations, signing
+# keys), and its own server issues tokens under the IAM profile. It does not
+# model the user or tenant as an authoritative concept (user-engine and
+# tenant-engine do), and it renders no authorization decision (access-engine
+# does, §6). Agreement with §4: yes.
+#
+# Stated tension, not a disagreement: key-cape's token endpoint is an estate-
+# authored deterministic API whose claims access-engine consumes as facts,
+# which is how §3.3 describes a PIP, and authentication enforcement (MFA,
+# PKCE, exact redirect URIs) sits here although §3.3 places enforcement
+# boundaries in Engines. key-cape reads this as Tooling behaviour today and
+# does not claim Engine permissions; any move would go through §10.
+tooling_contacts:
+  - target: authelia, lldap, privacyidea
+    shape: packaged-backend
+    rationale: >-
+      Implementation dependencies inside key-cape's own tooling boundary, not
+      separately owned estate capabilities.
+  - target: kubernetes-secret (secretRef)
+    shape: delivered-reference
+    rationale: >-
+      Confidential client secrets arrive as env secretRefs from a separate
+      Secret delivered by the platform owner; key-cape holds no OpenBao client
+      and never carries secret values in config.
+# §11 non-Tooling clients, recorded so the check is total.
+non_tooling_clients:
+  - target: state-hub
+    layer: not-catalogued
+    rationale: Work records, workplans and progress events only.
+# Boundary with access-engine, stated from this side. key-cape establishes
+# authentication and issues verified identity claims under the IAM profile;
+# it owns login, MFA, PKCE, token issuance and lifecycle. access-engine
+# consumes those claims as normative input and decides what the actor may do.
+# key-cape relies on access-engine for no validation of a claim beyond
+# standard token verification (signature, issuer, audience, expiry); a role or
+# scope claim is an input to a decision, never the decision.
+---
 # INTENT
 
-KeyCape declares its layer as **Tooling** under the NetKingdom security layer
-model v0.4. It provides deterministic authentication and identity claims through
+KeyCape's layer is **Tooling** under the NetKingdom security layer model; the
+machine-readable declaration is the frontmatter above, and this sentence is not. It provides deterministic authentication and identity claims through
 the versioned IAM profile, packaging Authelia, LLDAP, and privacyIDEA.
 Authorization decisions belong to access-engine; KeyCape is not an authorization
 decision point. Issuing a role or scope claim does not decide access to a resource.