diff --git a/docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md b/docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md
index 8ab68d2..e40306a 100644
--- a/docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md
+++ b/docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md
@@ -92,3 +92,61 @@ eine dauerhaft zu pflegende Fork-Anpassung mit Rust/wasm-Build gegenüber. Die A
 Tastaturgeräusche als hinnehmbar erklären und stattdessen Push-to-Talk bzw. bewusstes
 Stummschalten dokumentieren — ist billiger und sollte bewusst verworfen werden, nicht
 übersehen.
+
+## Prototyp gebaut und getestet 2026-08-15
+
+Wegwerf-Aufbau außerhalb des Forks (`deepfilternet3-noise-filter` v1.3.0 + `livekit-client`,
+lokale Testseite, Assets **selbst ausgeliefert**). Ziel war, die drei ungeklärten Punkte der
+Spezifikation durch Messung zu ersetzen.
+
+### Ergebnis: es funktioniert — und zwar besser als nötig
+
+**Höreindruck sorb:** *„die Tastatur ist weg, Stimme klingt natürlich"* — bei **35 %**
+Dämpfung.
+
+Das ist der wichtigste Einzelbefund, und er entscheidet die Reglerfrage:
+
+- **Der Dry/Wet-Mix der Spezifikation entfällt ersatzlos.** Das Paket bietet
+  `setSuppressionLevel()`, und die wasm-Signatur trägt `atten_lim` — DeepFilterNet begrenzt
+  die Dämpfung **nativ**. Die Prämisse der Spec („neuronale Netze kennen nur An/Aus") ist
+  widerlegt. Damit entfallen zugleich der fehlende Delay-Node und das Phasenproblem —
+  es gibt gar keinen zweiten Signalpfad mehr, der phasenversetzt zurückgemischt werden müsste.
+- **35 % statt 100 % als Vorgabe.** Die Spec setzt „standardmäßig 100 % Filter-Aktivität";
+  gemessen reicht gut ein Drittel für „Tastatur weg **und** Stimme natürlich". Weniger
+  Dämpfung heißt weniger Artefaktrisiko — der Standardwert sollte bei ~35 % liegen, nicht am
+  Anschlag.
+
+### Gemessen (ersetzt die Schätzungen der Spec)
+
+| Größe | Wert | Bemerkung |
+|---|---|---|
+| Download je Client | **23,27 MB** | 15,66 MB `df_bg.wasm` + 7,61 MB Modell — Spec-Schätzung („15–25 MB") bestätigt, oberer Rand |
+| Vergleich RNNoise | 2,0–4,6 MB | rund ein Zehntel (`@jitsi/rnnoise-wasm`, `@shiguredo/rnnoise-wasm`) |
+| Lizenz Paket | Apache-2.0 **oder** MIT | wie behauptet; Modellgewichte kommen aus dem DeepFilterNet-Projekt |
+
+### ⚠️ Befund, der die Paketwahl bestimmt: fremdes CDN
+
+`deepfilternet3-noise-filter` lädt Modell und wasm zur Laufzeit von **`cdn.mezon.ai`**. Für
+eine selbstgehostete Plattform ist das nicht hinnehmbar: jeder Teilnehmer meldet bei jedem
+Call-Start seine IP an einen Dritten, und die Verfügbarkeit des Calls hinge an fremder
+Infrastruktur.
+
+**Entschärft:** `assetConfig.cdnUrl` ist konfigurierbar. Der Prototyp liefert die Assets
+bereits **lokal** aus — der CDN-freie Betrieb ist damit nachgewiesen, nicht nur angenommen.
+Für eine Integration hieße das: die 23 MB gehören mit ausgeliefert (Image/Ingress), nicht
+nachgeladen.
+
+### Ebenfalls korrigiert gegenüber der Spec
+
+Die `getUserMedia`-Constraints, die im finalen Spec-Code fehlten, sind im Prototyp gesetzt:
+`noiseSuppression: false` (sonst arbeiten Browser-Filter und Modell gegeneinander),
+`echoCancellation: true`.
+
+### Weiterhin offen — und entscheidungsrelevant
+
+1. **CPU-Last** (Jitter mit/ohne Filter) noch nicht abgelesen.
+2. **Telefon.** Die eigentliche Härteprobe: 23 MB Download und DFN3-Inferenz auf einem
+   Mittelklasse-Gerät. Fällt das durch, braucht es einen Pfad (RNNoise als leichte Variante,
+   oder Filter auf Mobilgeräten aus).
+3. **Fork-Wartung** bleibt der ungemessene Posten — die Anpassung muss jeden Upstream-Rebase
+   überleben.