diff --git a/specs/spec_loadmodel.md b/specs/spec_loadmodel.md
index 04e0928..e10201d 100644
--- a/specs/spec_loadmodel.md
+++ b/specs/spec_loadmodel.md
@@ -1369,6 +1369,38 @@ doit pas devenir un geste d'arbitrage.** Renuméroter pour « faire de la place
 l'ordre de service de charges auxquelles personne n'a touché — et le ferait sans qu'aucune
 décision d'exploitation ait été prise.
 
+**LM-1209-d — Le rang est un ordre TOTAL ; les domaines ne le partitionnent pas.** *(Point
+ouvert soulevé par l'agent app, tranché le 2026-08-29.)*
+
+L'insertion en queue entrelace les domaines — `ecs, ev, ev, heating, ev`. Faut-il que
+l'insertion respecte la **contiguïté** d'un domaine, ou que le regroupement automatique côté
+client cesse d'être automatique ? **La seconde.**
+
+**La contiguïté n'a jamais été un invariant, et rien dans le moteur n'en a besoin** : le
+waterfall trie sur le **rang seul**, et `domain` est une métadonnée d'intention que l'arbitre ne
+lit pas (LM-1101 · §3). La contiguïté est une convention d'**affichage**, inventée par le client.
+
+**Et l'exiger du moteur serait CONTRADICTOIRE avec la raison même de LM-1209**, pas seulement
+avec sa condition « aucun autre rang ne bouge ». Insérer une charge `heating` en respectant la
+contiguïté obligerait à décaler toutes les charges `ev` situées après — c'est-à-dire **une
+détection qui réordonne une installation qu'un humain a classée**, exactement ce que LM-1209
+interdit. On ne peut pas invoquer LM-1209 pour la queue et l'enfreindre pour le regroupement.
+
+> **Le même raisonnement s'applique au CLIENT, et c'est le vrai point.** Un regroupement par
+> domaine appliqué **à l'enregistrement** est aussi une machine qui réordonne ce qu'un humain a
+> décidé — au pire moment, et sans que personne l'ait demandé. Il défait l'entrelacement
+> délibéré (« l'ECS après la borne 1 mais avant la borne 2 » est un arbitrage légitime, et le
+> §10 en produira d'autres), et il remonterait au rang 3 une borne que le moteur vient de ranger
+> en queue.
+>
+> **Grouper à l'AFFICHAGE : oui. Grouper à l'ÉCRITURE : non.** Si le regroupement a de la
+> valeur, il doit être un **geste explicite** de l'installateur — visible, réversible —, jamais
+> une normalisation au moment de sauver.
+>
+> **Conséquence sur la note d'entrelacement** : elle ne doit pas s'énoncer comme un
+> avertissement. Une liste entrelacée n'a rien d'incohérent ; l'annoncer comme un défaut pousse
+> à « réparer » un ordre que personne n'a cassé. Au plus une **proposition**.
+
 **LM-1209-c — Une entrée créée d'office DOIT se dire.** Une charge qui prend une place dans
 l'ordre de service sans que rien ne le signale est un **changement d'arbitrage silencieux**. Le
 journal l'annonce déjà ; cela ne suffit pas — l'app ne lit pas le journal, et c'est elle qui