repo.work.create_intake KEY-IN-0001

correlation_id: 699a27b1-b998-4e47-801a-3cb1efe093de
reason: Request own-voice layer declaration under §11
source: repo-manager

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9

INTENT.md

@@ -1,5 +1,20 @@
 # 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.
+>
+> The layer rule that binds every repository: **Staff never touches tooling
+> directly. It acts only through engine APIs.**
+>
+> **This repository is Tooling — deterministic infrastructure and state.** State the layer: key-cape packages the third-party identity tooling (authelia, lldap, privacy-idea) behind a versioned IAM profile. It owns authentication and identity claims only. Because "auth" is ambiguous across the estate, this INTENT should say explicitly that key-cape is **not** an authorization decision point — that is access-engine's, and it stays the only one.
+>
+> *This note records what should change. The body below is not yet adapted.*
+
 ## Purpose
 
 This repository exists to provide a **lightweight, profile-conformant identity and access management (IAM) system**.

intakes/intakes.md

@@ -0,0 +1,38 @@
+# Intake records
+
+## KEY-IN-0001 — Declaration requested: state this repository's layer in INTENT.md (security layer model §11)
+
+```yaml
+id: KEY-IN-0001
+kind: intake
+title: 'Declaration requested: state this repository''s layer in INTENT.md (security
+  layer model §11)'
+status: open
+origin: cross-repo
+origin_ref: net-kingdom security-layer-model_v0.4 §11
+priority: low
+owner: key-cape
+requested_by: gate-house
+proposed_layer: Tooling
+description: 'A conformance sweep on 2026-08-28 found this repository has no layer
+  declaration of its own. It carries a layering review note gate-house wrote into
+  the top of its INTENT.md on 2026-08-24, and that note names a layer — but the words
+  are gate-house''s, sitting above a line admitting the body is unadapted. Section
+  11 has since been amended to say so explicitly: a layer stated about a repository
+  by another repository is not a declaration; only the repository''s own file, in
+  its own voice, conforms. Seven of fifteen estate-authored repositories have declared;
+  this is one of the eight that have not, and the standard does not claim adoption
+  on the basis of notes gate-house wrote. REQUESTED: state the layer in INTENT.md
+  in your own voice, or contest it. PROPOSED LAYER: Tooling. Packaged identity tooling
+  (authelia, lldap, privacy-idea) behind a versioned IAM profile; authentication only.
+  Worth stating explicitly that key-cape is not an authorization decision point, since
+  ''auth'' is ambiguous across the estate and access-engine owns the decision. Note
+  also that the components key-cape packages are not catalogued individually — if
+  you think they should be, say so. Contesting is a real option and costs nothing
+  — the three repositories that reviewed this model each returned a correction, two
+  of which changed the standard. If the proposed layer is wrong for what this repository
+  actually does, that is more useful to us than a label added to close a checkbox.
+  Standard: net-kingdom/canon/standards/security-layer-model_v0.4.md.'
+created: '2026-08-28T21:01:53.604723Z'
+updated: '2026-08-28T21:01:53.604723Z'
+```