diff --git a/FABRIC-2.md b/FABRIC-2.md
index be8484f..e3ee1e7 100644
--- a/FABRIC-2.md
+++ b/FABRIC-2.md
@@ -241,12 +241,29 @@ and recorded.
 - [ ] **§17.4 — the framebuffer utility's internal heat/decay dynamics are undesigned.**
   Explicitly "Open, deferred": not a Stadium patron, but what physics (if any) governs it
   internally was never designed. Not blocking anything.
-- [ ] **§23.4 #2 — cell-size validation against a real message shape.** "Check that a typical
+- [x] **§23.4 #2 — cell-size validation against a real message shape.** "Check that a typical
   message still fits in one cell" was never done — item 3.1's own done-note confirmed no
   message-patron struct existed yet at the time. This is now checkable: item 4.2 built
   Hermes's actual message/channel structures on the Stadium, so the 32-byte inline payload
   can finally be validated against something real instead of a hypothetical.
 
+  > **SETTLED 2026-08-13, but not as originally framed.** Read Hermes v1's real message
+  > struct (`capsules/hermes/init.4th`, blocks 4100/4105/4143, item 4.2): `MSG-CELLS` is 9
+  > cells — `TYPE, FROM, TO, PADDR, PLEN, STADIUM-CELL, SEQ, CH, ORIG-TYPE` — at 8 bytes/cell
+  > (`cell_t` is `int64_t`/`long`, `include/vm.h:71-75`), i.e. **72 bytes**, already over
+  > §23.3's whole proposed 64-byte cell before any payload. And the payload itself is
+  > **not inline at all**: `MSG-SEND` (`:208-213`) takes a caller-supplied `paddr plen` —
+  > wherever the caller already put the bytes (a string literal via `S"`, a block buffer) —
+  > and stores only the pointer and length in the struct. There is no fixed-size inline
+  > payload field to check a message against. So §23.4 #2's literal question ("does a
+  > typical message fit in the 32-byte inline payload") is **moot, not answered**: the
+  > shipped design didn't adopt §23.3's speculative 64-byte-cell/32-byte-inline-payload
+  > scheme for messages at all, it used a larger fixed control block plus out-of-line
+  > pointer/length indirection instead. Closing as settled-by-divergence — the real
+  > implementation went a different direction than the design question assumed, which is
+  > itself the answer; §23.3's cell-size numbers were never made load-bearing for Hermes
+  > messages and nothing here depends on reconciling them.
+
 ---
 
 ## E. Documentation debt