diff --git a/docs/superpowers/specs/2026-05-15-user-uid-split-design.md b/docs/superpowers/specs/2026-05-15-user-uid-split-design.md
index 2e150ba..b19d1dd 100644
--- a/docs/superpowers/specs/2026-05-15-user-uid-split-design.md
+++ b/docs/superpowers/specs/2026-05-15-user-uid-split-design.md
@@ -37,6 +37,24 @@ The question never got a structured answer because each plan
 inherited "we have 2 users" as a constraint, not as a design choice.
 This doc fixes that.
 
+## Note: these are system units, not user units
+
+Both `left4me-server@.service` and `left4me-web.service` are
+**system units** at `/usr/local/lib/systemd/system/`, started by
+PID 1, that drop to the unprivileged uid via `User=left4me`
+`Group=left4me` after their `+`-prefixed ExecStartPre runs as root.
+They are **not** user units (no `systemctl --user`, no per-user
+systemd instance, no lingering required).
+
+This makes the user-split refactor much simpler than it would be
+otherwise. Changing `User=`/`Group=` in the unit is a literal
+one-line edit per unit. None of the typical user-unit friction
+applies — no lingering setup, no `pam_systemd` dependency, no
+"how does the user instance get bootstrapped on boot," no socket
+activation gymnastics. The privileged ExecStartPre/ExecStopPost
+steps continue to run as root via the `+` prefix regardless of
+what `User=` is set to.
+
 ## Current state (2 users)
 
 User → what runs as it: