diff --git a/11-Features.md b/11-Features.md
index 0af209c..a4c9483 100644
--- a/11-Features.md
+++ b/11-Features.md
@@ -3144,13 +3144,51 @@ blocked.
 
 **The gotcha: no meaningful boundary exists inside one uid.** Environment scrubbing, worktrees and
 config rewrites reduce **accidents**, and that is worth having. They do not contain a member that
-chooses to look. A real boundary needs a different OS user (`memberHerdrSocket`, above) or OS-level
+chooses to look. A real boundary needs a different OS user (`memberHerdrSocket`, above — but see
+the next entry: fleetd cannot verify that one for you) or OS-level
 confinement such as a container or VM — a different execution model, not a longer name list. Even a
 different user does not protect argv, and does not protect shared git objects where `worktreeGroup`
 grants access to them.
 
 Open work, ranked, is on #184.
 
+## fleetd states the member trust model at startup
+
+**What.** Every boot, `fleetd` logs one INFO line saying what kind of boundary members run inside.
+The line changes with `memberHerdrSocket`. With the key unset:
+
+```
+member trust model: members run as the same OS user as fleetd, not in a sandbox. A member can
+read any file this user can read, including SSH keys and credential stores, whatever
+memberCredentials says. To add a real boundary, route members to a second herdr under a
+different OS user with memberHerdrSocket.
+```
+
+With the key set, it says instead that members are routed to a separate herdr, and that **fleetd
+cannot see that herdr's uid**, so the operator must confirm it runs as a different OS user before
+treating it as a boundary.
+
+**The knob.** None. It always logs, at INFO, from `Fleetd.reportMemberTrustModel`, right after the
+startup secret report. Find it with:
+
+```bash
+grep 'member trust model' fleetd/fleetd.out | tail -1
+```
+
+**Why it exists.** The entry above documents the honest boundary, but a wiki page only reaches
+someone who goes looking. `memberCredentials` reads like a security control, so an operator who
+never opens this page reasonably assumes it contains a member. It does not. Putting the trust model
+in the boot log means the claim arrives unprompted, in the same place the operator already checks
+`startup secret` lines, on a machine where the config is whatever it is.
+
+**The gotcha: this line is honest about the uid, and one older WARN is not.**
+`HerdrPeerLauncher.warnUnknownMemberEnvironment` still says a configured `memberHerdrSocket` means
+"member panes run under a different OS user". fleetd cannot see the uid at the other end of a unix
+socket — it infers that from the key being set. The direction that costs something is a second
+herdr running as the **same** user: members then inherit fleetd's environment, and the credential
+gap the WARN reports as UNKNOWN is in fact exactly the count it just told you to disregard. A known
+exposure reported as an unknown one. Tracked as item 5 on #184.
+
 ## `leadSeats` reports the seat the lead itself holds
 
 **What.** For a `subscription: true` profile, `fleet_list`'s row carries a `leadSeats` field when the