diff --git a/FABRIC-3.md b/FABRIC-3.md
index 1d39510..023e190 100644
--- a/FABRIC-3.md
+++ b/FABRIC-3.md
@@ -3635,9 +3635,27 @@ retarget, quota grant, etc.) — those are finer-grained checks built elsewhere.
 - **Escape hatch, mechanism confirmed reused**: the only way to temporarily exceed that
   creator-ceiling is "some kind of temporary Zuse power" — **confirmed reuse of the existing,
   already-built-and-measured `ACL-TTL` mechanism** (`acl_ttl` field on `DictEntry`), not a new
-  parallel temporary-grant mechanism. **Explicitly still undecided: the trigger/path for *how*
-  a session actually reaches that elevated state** — only the underlying TTL mechanism itself
-  is settled as reused, not the invocation flow.
+  parallel temporary-grant mechanism.
+- **Mechanism grounded, checked directly against `capsules/ACL.4th`**: the existing `ACL-TTL`
+  machinery is a recheck-cadence cache, not itself a grant mechanism — the real C-exposed
+  primitives are `ACL-ALLOW!`/`ACL-TTL!` (`ACL-RECHECK` recomputes TTL from execution heat and
+  sets `allow`). Reusing it for elevation means Zuse-triggered code calls these same
+  primitives directly, setting `allow=1` with a TTL that counts down to expiry.
+- **Trigger, decided 2026-09-02: live message-based request, kept deliberately simple.**
+  Three options were weighed — message-based request/grant, a live-console `sudo`-style
+  command, and a pre-signed capability ticket decoupling grant-time from use-time — user
+  picked the first: "live request, keep it simple for now." Rides the H.7 messaging protocol:
+  the requesting session posts a request (working name `ELEVATE-REQUEST`) on `common` or a
+  private topic with Zuse, Zuse's session responds grant/`NACK`, and the
+  `ACL-ALLOW!`/`ACL-TTL!` write happens on receipt. Fits the standing "nothing is done until
+  it's real Hermes messages" completion criterion (D.1). The other two options are explicitly
+  deferred, not rejected — "keep it simple for now" scopes this decision to the live-request
+  path only.
+- **Eligibility gate on top of the trigger, user-proposed**: "maybe zuse keeps a list of users
+  that can be granted zuse caps?" — confirmed as a gating layer, not a replacement for the
+  trigger. Zuse checks this list (presumably keyed by `owner_pubkey`, matching H.4's
+  single-owner VM-card shape) before honoring any elevation request. Exact list
+  representation/storage not yet designed.
 
 ### H.6 — Block card
 
@@ -3687,9 +3705,13 @@ Explicitly open items surfaced during this capture pass, none decided yet:
    `acl_ttl`/`acl_allow`/`acl_mode`/`acl_pinned` `DictEntry` fields fold into the stack-of-
    cards model, beyond the one confirmed reuse (`ACL-TTL` as the word card's escape hatch,
    H.5).
-4. **Temporary-elevation invocation path (H.5).** The `ACL-TTL` mechanism itself is confirmed
-   reused; *how* a session actually reaches that elevated state (who/what invokes it, under
-   what condition, what Zuse has to do) is explicitly undecided.
+4. **CLOSED 2026-09-02 — temporary-elevation invocation path (H.5).** Trigger decided: a live
+   message-based request (`ELEVATE-REQUEST` on `common` or a private topic, Zuse's session
+   grants/`NACK`s, write happens on receipt via `ACL-ALLOW!`/`ACL-TTL!`), gated by a
+   Zuse-held eligibility list keyed by `owner_pubkey`. Still open underneath this closure: the
+   eligibility list's exact representation/storage, and the two explicitly-deferred (not
+   rejected) alternate triggers — live-console `sudo`-style grant, and pre-signed capability
+   tickets.
 5. **`BMAPFMT` code change (H.6).** Field design was finished in the §F.4 pass but the actual
    code edit to `blk_meta_t` was never made — a real, concrete implementation gap, not just an
    open question.