diff --git a/modules/rust/PLAN.md b/modules/rust/PLAN.md
index 05ab84a..3d06a8d 100644
--- a/modules/rust/PLAN.md
+++ b/modules/rust/PLAN.md
@@ -5075,6 +5075,18 @@ users and fake linked Steam ids stood in for players.
   tally, and a tally holds only people who were on that server, so Carbon already has their record.
   It does reach an admin grant (phase 7) to somebody who has never joined a Carbon server. That grant
   lands at the first audit sync after they join, as a group membership does (§12.2 rule 4).
+
+  **Corrected 2026-10-30 (account deletion walk, W3), Carbon 2.0.262.** Carbon no longer answers
+  *"user not found"*. For a Steam id it has no record for, `GetUserData` returns one shared,
+  static blank record, and `GrantUserPermission` and `AddUserGroup` write into it. The grant
+  still read back `notLanded`, because `GetPermissionUsers` lists only real records. The
+  membership read back as a success, because `UserHasGroup` reads the same blank record. Either
+  way the write was then held by **every** Steam id Carbon had no record for, until a restart.
+  On the rig, three random never-seen ids each held `autodoors.use` after one admin grant. The
+  bridge now checks `permission.UserExists` on Carbon before either write. A never-seen player's
+  grant is reported `notLanded`, and their membership `pending`, without touching the store.
+  Both land at the first audit sync after the player joins, as this bullet and §12.2 rule 4
+  already said. Oxide creates a real record and is unchanged.
 - **A directory the panel's `files/write` creates is not writable by the game.** Kits failed to
   initialise with *access denied* on `player_data.json`, in the `oxide/data/Kits/` directory the
   test-kit upload had created. Making the directory writable fixed it. Phase 18's egg and anybody
diff --git a/website/ACCOUNT_DELETION.md b/website/ACCOUNT_DELETION.md
index fe838d7..29e443c 100644
--- a/website/ACCOUNT_DELETION.md
+++ b/website/ACCOUNT_DELETION.md
@@ -431,17 +431,21 @@ Asked while building core (§6 step 2), the same day:
    codes and the game logins came from a probe and a small socket client kept outside the repos.
    The deletion paths themselves were the real ones.
 
-   **Found, not fixed:**
-   - **W1 (Module-Rust).** `edge` holds an empty file named `Promise.reject(dup)`, committed by
-     step 3's PR (#70). It is a stray from a tool, not code.
-   - **W2 (Module-uo).** *Still linked on the shard* says "tried 1 time, and tried again when the
-     bridge reconnects" about a retry that has not happened yet.
+   **Found, then fixed (org lead, 2026-10-30):**
+   - **W1 (Module-Rust).** `edge` held an empty file named `Promise.reject(dup)`, committed by
+     step 3's PR (#70). It is a stray from a tool, not code. Removed in Module-Rust#71.
+   - **W2 (Module-uo).** *Still linked on the shard* said "tried 1 time, and tried again when the
+     bridge reconnects" about a retry that has not happened yet. It now says "It tries again
+     when the bridge reconnects." Module-uo#48.
    - **W3 (Rust bridge, not deletion).** On Carbon, a group membership for a Steam id the server
-     has never seen was reported as applied, but `c.show group` listed no users, and later
-     syncs found nothing to correct. A grant to the same id was reported as not landed and
-     landed on the next push.
+     had never seen was reported as applied, but `c.show group` listed no users. The cause was
+     worse than the symptom: Carbon writes such a grant or membership into one shared blank
+     record, which every never-seen id then holds until a restart ([`rust/PLAN.md`
+     §29.8](../modules/rust/PLAN.md)). The org lead chose to hold these until the player joins.
+     Rust-Plugins#47 checks for a record on Carbon before writing, and reports `notLanded` or
+     `pending` instead. It was proven on the rig before and after the change.
    - **Observed, unchanged:** `user.self_delete` names the id only, as §4.1 says, so the
-     activity log alone cannot tell staff which account deleted itself. The auth slow-down covers the delete route,
-     so a third call from one address took about 4 s.
+     activity log alone cannot tell staff which account deleted itself. The auth slow-down
+     covers the delete route, so a third call from one address took about 4 s.
 7. Then `USER_SAFETY.md` (report, block and hide, now 1.21.0), then `android/PLAN.md` M8's
    cutover.