diff --git a/docs/adr/030-briefwechsel-removal-unidirectional-search.md b/docs/adr/030-briefwechsel-removal-unidirectional-search.md
new file mode 100644
index 00000000..7362ac05
--- /dev/null
+++ b/docs/adr/030-briefwechsel-removal-unidirectional-search.md
@@ -0,0 +1,54 @@
+# ADR-030 — Removing Briefwechsel trades bidirectional correspondence for a unidirectional search filter
+
+**Date:** 2026-06-02
+**Status:** Accepted
+**Issue:** #716 (remove the Briefwechsel view; retarget its links to document search)
+**Milestone:** —
+
+---
+
+## Context
+
+The standalone **Briefwechsel** view (`/briefwechsel`) was a bilateral letter timeline
+between two `Person`s. It was not in the main navigation; its only inbound product link
+was the "Häufige Korrespondenten" card on a person's detail page. It was backed by a
+dedicated endpoint (`GET /api/documents/conversation`) and two repository queries
+(`findConversation`, `findSinglePersonCorrespondence`) that nothing else used.
+
+The view's data source, `findConversation`, was **bidirectional**: it returned letters
+where `(sender = A AND receiver = B) OR (sender = B AND receiver = A)` — i.e. the
+exchange in both directions. We removed the view entirely (frontend and backend) and
+retargeted the one inbound link into the existing **document search**
+(`/documents?senderId=A&receiverId=B`).
+
+Document search composes its `senderId`/`receiverId` filters with AND
+(`sender.id = A` **AND** `receivers contains B`), so the retargeted link shows **only the
+A→B direction**. The reverse direction (B's replies to A) is no longer surfaced by
+clicking a correspondent.
+
+## Decision
+
+**Accept the behaviour change: the retargeted card link is unidirectional (A→B only).**
+The reverse direction is intentionally dropped rather than preserved with a redirect
+shim or a new bidirectional search filter.
+
+- The card link sets both params (`senderId=A&receiverId=B`); the destination is the
+  consistent, already-tested document search rather than a separate dedicated view.
+- The "×N" badge on each correspondent chip remains **bilateral** — it counts shared
+  letters in both directions as a relationship-strength signal — so the badge may exceed
+  the unidirectional search result count. This is surfaced in the badge's title, not
+  recomputed.
+
+## Consequences
+
+- **Regression:** a reader can no longer reach B→A replies in one click from the
+  correspondents card. They must run a second search with sender/receiver swapped.
+- The bilateral query code (`findConversation`, `findSinglePersonCorrespondence`, the
+  `/api/documents/conversation` endpoint, and the `getConversationFiltered` service
+  method) is fully removed — no dormant dead code.
+- No data migration and no schema change: only query/endpoint code was removed; the
+  `documents`, `persons` and join tables are untouched. The `hasSender`/`hasReceiver`
+  specifications stay — document search still uses them.
+- **Future enhancement (out of scope here):** a bidirectional "between these two people,
+  either direction" document-search filter would restore the dropped direction without
+  reviving the standalone view. If built, it supersedes the unidirectional link.