diff --git a/11-Features.md b/11-Features.md
index 91842c5..e3e624d 100644
--- a/11-Features.md
+++ b/11-Features.md
@@ -2334,13 +2334,17 @@ so, because no route exists for reading another daemon's mail.
 
 **On.** Nothing to configure beyond the `coordinator:` block that lead-to-lead messaging already
 needs. Pass your own `selfId` — `fleet_list` reports it as `coordinator.selfId` — as `fleet_poll`'s
-`coordId`. `fleet_list` also now reports `heldCount` and `heldDurable` beside `held[]`.
+`coordId`. `fleet_list` also now reports `heldCount` and `heldDurable` beside `held[]`. `heldDurable` is
+**derived** from the queue's declared durability and the consume ack mode, not written as a
+constant, so it can actually report `false` if either changes (fleetd #440). It is one boolean
+over two inputs, so a `false` does not say which of the two moved.
 
 **Why.** A lead could see *that* it had peer mail but not read it. `fleet_list`'s `held[]` carries
 only an 80-character preview, on purpose, so a constantly-called roster scan never dumps a
 coordination body. `fleet_poll{target}` drained the wrong store — a worker's reply inbox, not the
-coordinator mailbox — and returned an empty list with no error. The only other route, `fleet_ack`,
-would have destroyed the message before anyone read it. So the full body was reachable in principle
+coordinator mailbox — and returned an empty list with no error. The only other route, `fleet_ack`, looked
+destructive but is not: it never touches the coordination channel at all, and reports
+`acknowledged <msgId>` anyway (fleetd #437). So the full body was reachable in principle
 and unreachable in practice, and the busiest leads were the ones most affected: delivery into a
 lead's pane is status-gated, so a lead that never goes idle never drains its own mailbox.