diff --git a/decisions/drafts/GH-DEC-2026-023-frictionless-decision-intake.md b/decisions/drafts/GH-DEC-2026-023-frictionless-decision-intake.md
new file mode 100644
index 0000000..d9fc7cd
--- /dev/null
+++ b/decisions/drafts/GH-DEC-2026-023-frictionless-decision-intake.md
@@ -0,0 +1,142 @@
+## GH-DEC-2026-023 — Posing a decision needs no human act; attribute admission may replace exact-record admission, on conditions
+
+**Draft, status `proposed`. Not registered in State Hub.** The metadata below is
+fenced as `text` on purpose: a `yaml` block carrying a `GH-DEC-` id is
+registered as a hub decision by the consistency sync (C-32), and this record
+is not ruled yet. When the founder rules, move it into `decisions/decisions.md`
+with the usual `yaml` block and let the sync register it.
+
+```text
+id: GH-DEC-2026-023
+kind: decision
+title: Posing a decision needs no human act; attribute admission may replace
+  exact-record admission for decision memos, on conditions
+status: proposed
+owner: Bernd Worsch
+repo: gate-house
+standard: net-kingdom/canon/standards/security-layer-model_v0.8.md
+source_note: informed-decision docs/specs/FrictionlessDecisionIntake.md (INFD-WP-0005,
+  T09); hub message 6ab42744 (2026-10-03); CUST-WP-0075 close-down checklist row 2
+requested_dispositions: [approved, revised, rejected]
+affects: [gate-house, informed-decision, access-engine, approval-engine, state-hub,
+  railiance-platform, audit-core]
+created: '2026-10-03'
+```
+
+## Question
+
+`informed-decision` asked whether any doctrine requires a human or operator act
+when a decision is *posed*, as opposed to when it is *bound*. Today an
+operator-edited exact-record list in `access-engine`
+(`informed-decision.compact-sitting` v1–v6) admits each memo. The spec proposes
+admission by attributes, with the human still seeing exactly what is bound.
+
+## Ruling 1 — No doctrine requires a human or operator act at posing time
+
+- **The human requirement attaches to the bind, not to the request.**
+  `GH-DEC-2026-016` §1–§2 puts it on the approval object and makes the bind
+  "the cheap moment" for refusal. Nothing in it, in statute §6.4 or §9.4, or in
+  the ASM canon requires a human to put a question in front of a human.
+- **Posing is proposing.** "Cognition proposes. Authority disposes." An agent
+  drafting a memo and a create-only client drafting an approval is the shape
+  the canon asks for, not an exception to it. A draft approval carries no
+  authority until a human binds it.
+- **The exact-record list was a build artifact, not doctrine.** No gate-house
+  record required it. Of its two jobs (spec §5.1), (a), that the human sees
+  exactly what is bound, *is* doctrine (`GH-DEC-2026-012` R3). (b), operator
+  gating of posing, is not.
+- **The `human_control` declaration made at issue is a requester property, not
+  a human act.** `GH-DEC-2026-016` §3 requires it to be declared at issue, and
+  the intake declares it on every create.
+
+## Ruling 2 — Accepted, on conditions that hold now (build mode included)
+
+C1. **Never accept the approval fact from the PDP allow** (statute §6.4
+obligation 5, last sentence). The live approval-engine read and the identity
+compare of approval id and binding digest against the memo pin (spec §5.1,
+§5.4) are the validation of the approval. The PDP allow is eligibility only.
+The spec must say this as a rule. Today it reads only as a description of
+current code.
+
+C2. **`view_hash` never enters the PDP context** (`GH-DEC-2026-012` R2 limit 2,
+R3). Spec §5.2 omits it. Make the omission normative. The binding digest in
+context is the one read from approval-engine, never recomputed from the memo's
+own vocabulary (R3 co-reference, obligation 5 identity-not-translation).
+
+C3. **`human_control: true` on every intake-created approval, with no memo
+class able to turn it off** (`GH-DEC-2026-016` §3). The PDP rule keeps
+`approval_human_control == true` as a deny condition. The human principal stays
+directory-asserted (`authentication-derived`), never registration-supplied
+(`GH-DEC-2026-016` §5).
+
+C4. **A submitter can be stopped without its cooperation, at runtime**
+(ASM-S09, INV-07). Removing a submitter from `deploy/intake-submitters.json`
+must refuse its next pose without an access-engine image build. A refusal at
+the surface is deny-side and cannot manufacture authority (§8), so this is not
+a second decision point.
+
+C5. **No submitter admits itself** (ASM-G05). Changes to the submitter and
+class lists, in `informed-decision` and in the generated `access-engine` set,
+are reviewed commits made by someone other than the submitter they admit.
+
+C6. **Asserted provenance stays visibly asserted** (ASM-M04). While State Hub
+is the submitter for workstation agents (R2), `intake_submitter = state-hub`
+proves only that the hub forwarded the memo. Anything that can reach the
+hub's loopback API can pose. The review UI shows `drafted_by` as asserted, and
+no record or rationale may describe it as authenticated origin.
+
+## Findings carried into the close-down register
+
+F1. **R3 is the material relaxation.** In build mode the PDP decides on
+approval and intake facts asserted by the PEP that benefits from the allow.
+This is tolerable only because of C1, and because approval-engine refuses a
+non-human bind regardless. Re-arm: access-engine verifies the approval-engine
+approval-claim (`GH-DEC-2026-005`, `GET /v1/approvals/{id}/claim`) and a signed
+intake receipt itself, and the PEP carries ids only. The `GH-DEC-2026-010`
+attribution gap (the PEP cannot yet prove the allow came from access-engine)
+is unchanged by this design and stays declared.
+
+F2. **Human attention becomes the control, and it can be flooded.** With
+posing ungated, the scarce resource is the founder's attention. A habituated
+reviewer turns a human-in-the-loop control into the theatre `GH-DEC-2026-016`
+§1 forbids. Build mode: a per-submitter volume cap SHOULD exist. Close-down:
+it MUST, with a budget per submitter (ASM-G04) and the overview showing
+volume per submitter.
+
+F3. **Notifications are an unauthenticated channel** (R8). A hub writer can
+send the founder a message that looks like a memo notification and links
+elsewhere. Close-down: the signed-in overview is the authoritative entry point,
+and notifications carry ids, not links the reviewer must trust.
+
+## What must be re-armed at production close-down
+
+R1–R8 of the spec §9, as written, plus:
+
+- R2 re-arm also covers C6: the forwarded submitter carries the authenticated
+  drafting agent identity, and `drafted_by` becomes authenticated or is
+  dropped.
+- R3 re-arm as F1, including retirement of PEP-carried approval attributes.
+- R5 re-arm also covers C5: the signed regeneration path names a reviewer
+  other than the admitted submitter.
+- New: the per-submitter volume budget (F2) becomes MUST.
+- New: the exact-record branch (`compact-sitting` v1–v6) is removed once its
+  memos are terminal, not left as a permanent second path.
+
+## Never relaxed
+
+The spec's own list stands: humans bind, fresh MFA on answer, one question per
+memo, no approve-all, no secret values, audit-core evidence. Also C1–C3 above.
+
+## What this does not rule
+
+Which acts require human approval at all. That stays open
+(`GH-DEC-2026-016` §5). This record says posing needs no human act. It does not
+say which memo classes must exist. Nor does it rule approval-engine's
+`Idempotency-Key` or `requested_via` (spec §4); those are the owner's.
+
+## Reversal condition
+
+Ruling 1 reverses if a memo reaches a reviewer whose approval binding the live
+read did not confirm. That would mean job (a) of the exact-record list was
+lost, and an operator gate returns until it is restored. Ruling 2's acceptance
+of R3 lapses at production close-down whether or not F1 has landed.
diff --git a/workplans/GH-WP-0004-section-11-layer-declarations.md b/workplans/GH-WP-0004-section-11-layer-declarations.md
index 9f11c56..6b569ae 100644
--- a/workplans/GH-WP-0004-section-11-layer-declarations.md
+++ b/workplans/GH-WP-0004-section-11-layer-declarations.md
@@ -123,11 +123,17 @@ and A12 r3 (operator-authorized; recorded under T09), changes no files, and conf
 `INFD-IN-0007` and the §4 row coupling stay open with no deadline. Nothing the task waits
 for was delivered; the wait stays on `informed-decision` resolving `INFD-IN-0007`.
 
+2026-10-03 (CUST-WP-0075, second check): `informed-decision`'s 2026-10-03 message (`6ab42744`,
+INFD-WP-0005 doctrine check on frictionless decision intake) is about memo admission, not
+`INFD-IN-0007` or the §4 row. It was answered separately (reply `4a290496`; draft
+`decisions/drafts/GH-DEC-2026-023-frictionless-decision-intake.md`). No other
+`informed-decision` message delivers the gate. The wait stands.
+
 ```task
 id: GH-WP-0004-T06
 status: wait
 blocked_on: message-from:informed-decision
-blocking_reason: "informed-decision answered yes; its section-4 row is coupled to INFD-IN-0007, still open with no deadline (reply 2026-09-27)."
+blocking_reason: "informed-decision answered yes; its section-4 row is coupled to INFD-IN-0007, still open with no deadline (reply 2026-09-27; rechecked 2026-10-03)."
 priority: medium
 state_hub_task_id: "62ac1f55-d3fc-59bd-84a5-8baec5de6bac"
 ```