diff --git a/04-ISSUES/021-a-provider-is-announced-at-a-name-its-port-is-not-bound-to/00-report.md b/04-ISSUES/021-a-provider-is-announced-at-a-name-its-port-is-not-bound-to/00-report.md
index f14bdce..96eb7c7 100644
--- a/04-ISSUES/021-a-provider-is-announced-at-a-name-its-port-is-not-bound-to/00-report.md
+++ b/04-ISSUES/021-a-provider-is-announced-at-a-name-its-port-is-not-bound-to/00-report.md
@@ -49,6 +49,16 @@ consumers (the ordinary small-mesh case) is exactly where it bites.
 It also blocks anything that must *reach* a routed/served name from inside the mesh, not just
 application traffic — see the internal-CA validation dependency noted in the connectivity design.
 
+## Narrowing
+
+The loopback bind appears tied to **mesh-assigned** host ports, not to publishing as such. A
+container that declares a bare port (`"5432"`) — which the mesh assigns a host port for — is bound
+to `127.0.0.1:<assigned>`. A container that declares an explicit host mapping (`"17672:15672"`) is
+bound to `0.0.0.0:17672` and is reachable at the node's private-network address. So the defect is
+in the path that assigns and binds a host port for a bare declaration, not in the general publish
+step — which is also why a route to an explicitly-mapped port works while a database on an assigned
+port does not.
+
 ## Open questions
 
 - Should a `from: mesh` provision publish on the node's private-network address specifically, on