diff --git a/03-DESIGN/01-to-be/25-the-bus-on-nats.md b/03-DESIGN/01-to-be/25-the-bus-on-nats.md
index 4100103..1052976 100644
--- a/03-DESIGN/01-to-be/25-the-bus-on-nats.md
+++ b/03-DESIGN/01-to-be/25-the-bus-on-nats.md
@@ -97,7 +97,14 @@ exactly the current declaration and nothing older. That is the wire-level answer
 *is* the order, and a node that sees sequence n refuses n−1 by construction.
 
 **A reply-to travelling through a JetStream stream is carried in the payload, never in the
-transport `Reply` field.** Revision, first review: core NATS request/reply sets the requester's
+transport `Reply` field.** *Verified against a running server, 2026-09-27*: a caller published
+asking for a reply to `_INBOX.LCr3M83q…`, and the consumer saw a `Reply` field of
+`$JS.ACK.PROBE.probe_consumer.1.1.1…`. The address is replaced, not merely at risk — so the
+payload-borne reply subject below is necessary rather than defensive, and the check is a test
+rather than a note, because a future server that stopped doing this would leave enrolment
+working and the reason for the field quietly becoming folklore.
+
+Revision, first review: core NATS request/reply sets the requester's
 ephemeral inbox as the message's `Reply` field, and a plain responder answers it directly — but a
 message a JetStream consumer delivers has already had that field claimed for the consumer's own
 ack address (`$JS.ACK.<stream>.<consumer>...`), so by the time the controller (§3's CONTROL