diff --git a/adr/0012-organisationseinheiten-gruppen-konfigurationsvererbung.md b/adr/0012-organisationseinheiten-gruppen-konfigurationsvererbung.md
index 371d6f5..ceee648 100644
--- a/adr/0012-organisationseinheiten-gruppen-konfigurationsvererbung.md
+++ b/adr/0012-organisationseinheiten-gruppen-konfigurationsvererbung.md
@@ -12,7 +12,7 @@ In der Diskussion kristallisierten sich zwei fachlich unterschiedliche Gruppieru
 1. **Organisatorische Verortung** (z. B. „Gebäude A" → „Klasse 5a"): jedes Gerät gehört zu genau einem Ort, Orte können ineinander verschachtelt sein, und Konfiguration soll von einem allgemeineren zu einem spezifischeren Ort vererbt werden können — klassische OU-Semantik.
 2. **Querschnitts-Zuordnung** (z. B. „Lehrer", „Schulleitung"): ein Gerät (bzw. dessen Nutzer:in) kann mehreren solcher Zuordnungen gleichzeitig angehören, die Zuordnungen selbst sind nicht hierarchisch.
 
-Beide Bedürfnisse mit einem einzigen, verschachtelbaren Gruppen-Konzept mit Mehrfachmitgliedschaft abzudecken, hätte bedeutet, dass die "zutreffenden Gruppen" eines Geräts keine einzelne Vorfahrenkette mehr sind, sondern die Vereinigung mehrerer, unabhängiger Vorfahrenpfade — mit entsprechend unklarer Konfliktauflösung selbst für den einfachen, hierarchischen Fall. Die beiden Bedürfnisse wurden deshalb bewusst als zwei getrennte Konzepte modelliert.
+Beide Bedürfnisse mit einem einzigen, verschachtelbaren Gruppen-Konzept mit Mehrfachmitgliedschaft abzudecken, hätte bedeutet, dass die „zutreffenden Gruppen" eines Geräts keine einzelne Vorfahrenkette mehr sind, sondern die Vereinigung mehrerer, unabhängiger Vorfahrenpfade — mit entsprechend unklarer Konfliktauflösung selbst für den einfachen, hierarchischen Fall. Die beiden Bedürfnisse wurden deshalb bewusst als zwei getrennte Konzepte modelliert.
 
 ## Entscheidung
 
@@ -22,7 +22,7 @@ Jede Organisation besitzt automatisch eine geschützte Standard-OE **„Neue Ger
 
 Organisationseinheiten sind Self-Service durch die Kund:in selbst verwaltbar (Kundenportal, `/struktur`) — anders als bei Bereitstellungsvorlagen (installationszeitlich, technisch) ist die OE-Struktur eine rein organisatorische Entscheidung, die die Kund:in selbst am besten kennt.
 
-**Gruppen** sind dagegen bewusst flach (keine Verschachtelung) — ein Gerät kann **mehreren Gruppen gleichzeitig** angehören. Gruppen sind in dieser ersten Ausbaustufe nur intern verwaltbar (`/admin/kunden/{id}`), nicht Self-Service: bei der aktuellen, kleinen Kundenzahl sind die Bedürfnisse dem Betreiber bekannt genug, um sie direkt zu pflegen; künftige, heterogenere Kundschaft (KMUs) wird das wahrscheinlich einmal brauchen. Backend-seitig ist die Gruppen-API identisch zur OE-API aufgebaut (gleiche Endpunkt-Struktur für Merkmal-Overrides), sodass Self-Service später ohne Datenmodell-Umbau nachgezogen werden kann — nur die Kundenportal-Routen fehlen dafür noch.
+**Gruppen** sind dagegen bewusst flach (keine Verschachtelung) — ein Gerät kann **mehreren Gruppen gleichzeitig** angehören. Gruppen waren in dieser ersten Ausbaustufe zunächst nur intern verwaltbar (`/admin/kunden/{id}`), nicht Self-Service (siehe Nachtrag unten, noch am selben Tag revidiert): bei der aktuellen, kleinen Kundenzahl sind die Bedürfnisse dem Betreiber bekannt genug, um sie direkt zu pflegen; künftige, heterogenere Kundschaft (KMUs) wird das wahrscheinlich einmal brauchen. Backend-seitig ist die Gruppen-API identisch zur OE-API aufgebaut (gleiche Endpunkt-Struktur für Merkmal-Overrides), sodass Self-Service später ohne Datenmodell-Umbau nachgezogen werden kann — nur die Kundenportal-Routen fehlten dafür noch.
 
 **Konfigurationsvererbung:** Sowohl OEs als auch Gruppen können — wie ein Gerät selbst über `device_merkmale` (ADR-0010) — einzelne katalogfähige Merkmale explizit auf `aktiv` oder `inaktiv` setzen (`oe_merkmale`, `gruppen_merkmale`; jeweils sparsam, nur bei tatsächlich abweichender Meinung eine Zeile). Die Auflösungsreihenfolge für ein Gerät ist: