diff --git a/app/protokoll_parsers/bw.py b/app/protokoll_parsers/bw.py
index 4733646..51a7322 100644
--- a/app/protokoll_parsers/bw.py
+++ b/app/protokoll_parsers/bw.py
@@ -51,6 +51,30 @@ Stichprobe-Analyse von `17_0050.pdf` (618 KB, ~617k Zeichen):
 - Fuer namentliche Abstimmungen (3/Sitzung) ist eigene Logik noetig
   (separate Tabelle im PDF).
 
+## **WICHTIG — Datenmodell-Inkompatibilitaet**
+
+Vertiefte Probe (Sitzung 17_0050):
+- Anchor-Phrase ``Damit ist Artikel 1 einstimmig zugestimmt`` (3x)
+- ``Damit ist Artikel 2 mehrheitlich zugestimmt`` (1x)
+- Aber **keine direkten** ``Damit ist Drucksache X angenommen``-Anchors
+
+**BW stimmt pro Gesetzentwurf-Artikel ab**, nicht pro Drucksache. Das
+ist eine andere Datenmodellierung als NRW (Drucksache → Vote) und
+BUND (Beschlussempfehlung → Vote). Ein BW-Parser muesste:
+
+1. Pro Gesetzentwurf alle Artikel-Anchors sammeln
+2. Aggregat bilden: Gesetzentwurf X = wenn alle Artikel angenommen
+3. Drucksache aus dem zugehoerigen Gesetzentwurf-Header oben rueckwaerts
+   suchen (nicht trivial — der Bezug ist mehrere Seiten zurueck)
+
+Alternative-Modellierung: Schema ``plenum_vote_results`` um optionalen
+``artikel``-Spalten-Pfad erweitern, um pro-Artikel-Records zu speichern.
+
+**Empfehlung fuer Implementer:** vor Parser-Start mit Maintainer
+abstimmen, ob BW-Datenmodell ggf. eigenen Tabellen-Anbau noetig macht
+oder eine BW-spezifische Aggregations-Heuristik (alle Artikel zugestimmt
+→ Gesetzentwurf-DS=angenommen) genuegt.
+
 ## Bezug
 
 - Architektur: ADR 0009 (Plenarprotokoll-Parser-Registry)