diff --git a/specs/spec_loadmodel.md b/specs/spec_loadmodel.md
index baa2228..4cd9b1c 100644
--- a/specs/spec_loadmodel.md
+++ b/specs/spec_loadmodel.md
@@ -1286,6 +1286,70 @@ consommation de la borne plutôt que de la sous-estimer.
 > dangereux que le défaut est crédible. La question « cette borne a-t-elle été préparée ? » doit
 > être POSABLE, pas déduite d'une valeur.
 
+**LM-1209 — L'auto-provisionnement REMPLIT UN TROU, il ne décide pas.** *(Décision Patrick,
+2026-08-28. La règle est générale : elle porte sur toute création d'entrée par le moteur, pas
+sur les seules bornes.)*
+
+Une charge détectée par le moteur reçoit une entrée de configuration parce que **sans entrée
+elle serait arbitrée sans rang réglable** — c'est le trou que l'auto-provisionnement referme. Il
+ne s'ensuit rien sur sa PLACE : **le rang est un choix de l'installateur**, et une détection ne
+réordonne pas ce qu'un humain a décidé.
+
+**Donc : insertion en QUEUE, jamais en tête.** Une borne détectée un mois après la mise en
+service passerait sinon devant l'ECS que quelqu'un a réglé exprès — l'ancienneté d'un réglage
+n'est pas une raison de le défaire, et la nouveauté d'une détection n'est pas une raison de la
+servir en premier.
+
+> **Cela ne contredit PAS l'ordre par défaut « le VE d'abord »**, et c'est la distinction qui
+> manquait à la question : ce défaut-là décrit une **mise en service initiale**, où personne n'a
+> encore rien classé. Un **ajout ultérieur** est une situation différente — il existe un
+> classement, et il fait autorité. Deux moments, deux règles, et les confondre revient à laisser
+> le matériel réordonner l'installation.
+
+**Ce que « en queue » veut dire exactement : `1 + max(rangs existants)`.** Formulé d'abord comme
+« en queue de son DOMAINE », il faut le préciser, parce que les domaines ne sont pas des blocs
+contigus : rien n'empêche `ev` d'occuper les rangs 2 et 3 pendant qu'`ecs` tient 1 et 4. Insérer
+« juste après le dernier `ev` » exigerait alors de pousser l'ECS du rang 4 — ce que LM-1209-b
+interdit.
+
+> **Et la queue de LISTE est ici plus fidèle au principe que la queue de domaine**, ce qui règle
+> la tension au lieu de l'arbitrer : `max(domaine) ≤ max(liste)` toujours, donc la queue de liste
+> est **toujours au moins aussi reculée**. Quand le domaine occupe déjà la fin de la liste — le
+> cas ordinaire d'un domaine qui ne grandit que par détection — les deux coïncident. Quand ils
+> divergent, la queue de liste place la nouvelle charge **derrière tout le monde** au lieu de
+> l'intercaler devant une charge classée : c'est exactement « remplir un trou sans décider ».
+
+**LM-1209-a — L'égalité de rang doit être IMPOSSIBLE, et le contrat doit la garantir plutôt que
+la supposer.**
+
+`1 + max` produit un rang libre par construction, y compris sur une configuration héritée qui
+contiendrait déjà des doublons. Mais la garantie ne peut pas reposer sur le seul chemin
+d'insertion : une écriture cliente doit être **refusée** si elle pose deux charges au même rang.
+
+> ⚠️ **Ce que l'égalité coûte n'est PAS l'indéterminisme** — cette lecture est périmée depuis
+> 3g-2, et s'y fier ferait chercher le défaut au mauvais endroit. Le waterfall trie sur le
+> couple **`(rang, identifiant)`** (`rulebasedscheduler.cpp`), un ordre **total et reproductible**
+> ajouté précisément parce que deux bornes à égalité rendaient irreproductible laquelle
+> démarrait. Trois charges au rang 1 sont donc servies dans un ordre **stable** — mais **arbitraire
+> et non réglable** : il obéit à des identifiants, c'est-à-dire à personne. C'est cela que
+> l'unicité corrige, et c'est une exigence de gouvernabilité, pas de déterminisme.
+
+**LM-1209-b — Insérer ne renumérote personne.** Aucun autre rang ne bouge. C'est le pendant
+exact de la suppression côté app, qui laisse les rangs en place : **un geste de configuration ne
+doit pas devenir un geste d'arbitrage.** Renuméroter pour « faire de la place » modifierait
+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-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
+montre le classement. La charge utile doit porter de quoi distinguer **« ce rang est un défaut »**
+de **« ce rang est un choix »**.
+
+C'est la même exigence que C2 de LM-1009 et que LM-1106 : **le régime se publie, il ne se déduit
+pas.** Un client ne peut pas deviner qu'un rang n'a jamais été choisi — rien dans le nombre ne le
+dit. *(Forme du champ : voir la note de contrat, à figer avant écriture.)*
+
 **LM-1207 — Ne PAS ajouter de `priority` à `ChargingInfo`.** Ce serait un **second système de
 priorité**, et il serait immédiatement insuffisant : il ne saurait pas exprimer
 **« VE1 > ECS > VE2 »**, puisqu'il ne classerait que les bornes entre elles. Deux classements