diff --git a/04-ISSUES/169-a-machine-shares-its-files-and-the-mesh-does-not-know/00-report.md b/04-ISSUES/169-a-machine-shares-its-files-and-the-mesh-does-not-know/00-report.md
index 60c28ba..f19d679 100644
--- a/04-ISSUES/169-a-machine-shares-its-files-and-the-mesh-does-not-know/00-report.md
+++ b/04-ISSUES/169-a-machine-shares-its-files-and-the-mesh-does-not-know/00-report.md
@@ -82,6 +82,30 @@ the catalogue beside the modules (a seat definition registered like a manifest),
 saying which seats it implements. This is the first role with an obvious second implementation,
 which is what makes it the exemplar for that mechanism.
 
+## The consumer's half: the machine mounts it (2026-09-30, third round)
+
+A binding tells a consumer *where* the share is; it does not put the files on its machine. A
+consumer on another node needs the export **mounted by the host, at a directory the consumer
+declares, before its container starts**, and unmounted when the requirement goes. That is a host
+action, not something a container reads from a file.
+
+**Not a client module.** A node-wide `nfs-client` with a list of mounts in its settings is fstab
+with a manifest around it: consumers would stop requiring `nfs-share` and couple on a path again,
+unassigning a consumer would leave its mount behind, and a person is back in the loop deciding
+which machine mounts what — the thing the binding removes.
+
+**A mount is a resource of the consuming module.** The vocabulary (directory, file, package,
+container, service, process, network, archive, user, access) has no `mount`. It can be assembled
+today — a `package` (nfs-utils), a `file` writing a systemd `.mount` unit with
+`What=${bound:nfs-share:at}:${bound:nfs-share:path}` and `Where=${dir:library}`, a `service`
+enabling it after the overlay is up — but the honest form is a **`mount` resource kind**: the host
+mounts from the binding, refuses a mountpoint the module did not declare (ADR 0091's three ways a
+path can be), and unmounts on undeclare. The nfs and samba modules are then the *server* side only.
+
+**Identity crosses the wire.** `sec=sys` NFS trusts the client's uid, so a consumer must run as the
+library's owner on the server (ace: `media`, 1001:2000) — hq 153's `${access:<id>:uid}` proposal
+extended to a mount, `${mount:<id>:uid}`, read from the mounted tree.
+
 ## Open questions for the decision
 
 - Whether an NFS export over the overlay is an `internal` reach of the same endpoint or a second