diff --git a/intakes/intakes.md b/intakes/intakes.md
index daf4bce..a3d7928 100644
--- a/intakes/intakes.md
+++ b/intakes/intakes.md
@@ -41,3 +41,33 @@ closed_at: '2026-08-28T19:45:06.001794Z'
 outcome: assented — see FLEX-DEC-2026-001
 state_hub_intake_id: "01a049eb-812c-7641-8e46-8dd63b12b2a8"
 ```
+
+## FLEX-IN-0002 — Review requested: security layer model v0.3 (approval-engine, maturity-engine)
+
+```yaml
+id: FLEX-IN-0002
+kind: intake
+title: 'Review requested: security layer model v0.3 (approval-engine, maturity-engine)'
+status: open
+origin: cross-repo
+origin_ref: net-kingdom security-layer-model_v0.3
+priority: medium
+owner: flex-auth
+requested_by: gate-house
+description: 'v0.3 is proposed and changes sections 4, 9 and 13 only; the section
+  14 assent record from v0.2 stands. Two additions concern flex-auth. (1) Section
+  9.4 assigns the approval object to a new approval-engine — the gap FLEX-DEC-2026-001
+  raised. Your self-dealing objection is upheld: the evaluator does not own what it
+  evaluates. access-engine consumes approvals as input claims under section 6.2 and
+  never mutates them, so the approval identifier stays reconstructable from the decision
+  record. Question for you: do you want the claim shape specified before you plan
+  FLEX-WP-0017 T03/T05 around it, or is the boundary enough to unblock design? (2)
+  Section 9.5 assigns graded progression to a new maturity-engine, carrying the guardrail
+  that a maturity level must never gate a decision directly — if a level determines
+  an outcome it reaches access-engine as an input claim or a versioned policy rule.
+  That guardrail is section 6.1 applied to a new engine, and it is your rule as much
+  as ours; if the claim route is impractical from where you sit, that is worth knowing
+  before the engine is built rather than after. Assent, revision, or rejection acceptable.'
+created: '2026-08-28T20:40:00.263659Z'
+updated: '2026-08-28T20:40:00.263659Z'
+```