From 78749be45e2ea57755737ce13f72b634a31b7975 Mon Sep 17 00:00:00 2001
From: yahya <19204398+thep2p@users.noreply.github.com>
Date: Tue, 28 Jul 2026 12:42:08 -0700
Subject: [PATCH 1/2] [improve][docs] Clarify SetLinkOp side flip

---
 docs/protocol/concurrent-insert.md | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/docs/protocol/concurrent-insert.md b/docs/protocol/concurrent-insert.md
index 73694f9..7d6db5b 100644
--- a/docs/protocol/concurrent-insert.md
+++ b/docs/protocol/concurrent-insert.md
@@ -162,8 +162,11 @@ not a correctness requirement: `search_by_id`'s existing candidate-collection lo
    end of Stage 1. This is expected, not a bug — see Section 5.3, healed by Algorithm 8.
 
 8. Each `GetLinkOp` is handled via `change_neighbor`/`try_link` (Section 4); the terminal accepting
-   node replies `SetLinkOp{ nonce, side, level: 0, linked: Some(accepting_node's Identity) }` directly
-   to `u`. `u` applies each reply to its own table via the same `try_link` primitive (Section 4) — there
+   node replies `SetLinkOp{ nonce, side: opposite(request.side), level: 0, linked:
+   Some(accepting_node's Identity) }` directly to `u`. `side` is receiver-owned (Section 2), so the
+   reply names the slot in `u`'s **own** table — the mirror of the slot `u` was just installed into —
+   hence the explicit flip, identical to the `opposite(side)` Section 6.2 writes for repair
+   corrections. `u` applies each reply to its own table via the same `try_link` primitive (Section 4) — there
    is exactly one code path in this design that ever writes a lookup-table entry, whether the write is
    `u` installing its own neighbor, a peer installing `u`, or a repair correction (Section 6).
 
@@ -238,7 +241,9 @@ if v.neighbor[side][level] exists AND v.neighbor[side][level].key `cmp` u.key:
     forward the link-request to v.neighbor[side][level]
 else:
     v.neighbor[side][level] = u
-    reply to u confirming the link (SetLinkOp{ side, level, linked: v's identity })
+    reply to u confirming the link (SetLinkOp{ side: opposite(side), level, linked: v's identity })
+        # side is receiver-owned (Section 2): the reply names u's own slot, the mirror of the
+        # slot u was installed into here — same flip Section 6.2 writes for repair corrections
 ```
 
 The request moves monotonically toward `u`'s true position and self-corrects around concurrent

From f0932a0e205904bff07e3d1ae776f6a74eebe9b8 Mon Sep 17 00:00:00 2001
From: yahya <19204398+thep2p@users.noreply.github.com>
Date: Tue, 28 Jul 2026 15:42:37 -0700
Subject: [PATCH 2/2] [cleanup][docs] Use opposite(side) notation

---
 docs/protocol/concurrent-insert.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/protocol/concurrent-insert.md b/docs/protocol/concurrent-insert.md
index 7d6db5b..51d559e 100644
--- a/docs/protocol/concurrent-insert.md
+++ b/docs/protocol/concurrent-insert.md
@@ -162,8 +162,8 @@ not a correctness requirement: `search_by_id`'s existing candidate-collection lo
    end of Stage 1. This is expected, not a bug — see Section 5.3, healed by Algorithm 8.
 
 8. Each `GetLinkOp` is handled via `change_neighbor`/`try_link` (Section 4); the terminal accepting
-   node replies `SetLinkOp{ nonce, side: opposite(request.side), level: 0, linked:
-   Some(accepting_node's Identity) }` directly to `u`. `side` is receiver-owned (Section 2), so the
+   node replies `SetLinkOp{ nonce, side: opposite(side), level: 0, linked: Some(accepting_node's
+   Identity) }` directly to `u`. `side` is receiver-owned (Section 2), so the
    reply names the slot in `u`'s **own** table — the mirror of the slot `u` was just installed into —
    hence the explicit flip, identical to the `opposite(side)` Section 6.2 writes for repair
    corrections. `u` applies each reply to its own table via the same `try_link` primitive (Section 4) — there