diff --git a/docs/RELEVE_ECS306.md b/docs/RELEVE_ECS306.md
index ec1a462..d600504 100644
--- a/docs/RELEVE_ECS306.md
+++ b/docs/RELEVE_ECS306.md
@@ -165,9 +165,23 @@ Traces brutes :
 → `−198`. Côté verrou expiré : `3201 − 3000 = +201`, sonde éteinte donc aucun
 recrédit → `+201`, au-dessus de son palier de 100 W.
 
-**La prédiction du §2 est confirmée sur le fond** : sans ECS-306, 500 W sont
-consommés de plus que comptés, et la charge suivante s'allume sur un résidu qui
-n'existe pas.
+### Ce qui est démontré, et ce qui ne l'est pas
+
+**Démontré, directement** : au même budget, honorer le verrou ou l'ignorer change
+le résidu de 500 W et **fait basculer la charge de rang 3**. C'est la moitié
+*comptable* de l'affaire, et elle est observée sans ambiguïté.
+
+**NON démontré directement** : l'écart entre consommé et compté. Dans le cycle à
+verrou expiré, le routeur applique **réellement** 3000 W — il n'y a donc aucun
+écart dans ce cycle-là. L'autre moitié — le routeur qui écrête à 3500 W pendant
+que le scheduler ne compte que 3000 — est observée dans le **premier** cycle, pas
+dans le second.
+
+Le résultat tient donc par **composition de deux moitiés observées, chacune dans
+un cycle différent du même binaire**. C'est solide, mais ce n'est pas une
+observation directe du défaut complet. **Un `+etm2` réellement installé reste le
+seul moyen de voir les deux moitiés dans le même cycle** — c'est ce qui reste à
+faire, et c'est pourquoi l'expérience naturelle ne le remplace pas.
 
 **La prédiction secondaire est confirmée aussi** : la PAC de rang 2 est restée en
 état 4 sur les deux cycles. Sans la charge sonde, ce relevé aurait conclu « aucun
diff --git a/specs/spec_ecs.md b/specs/spec_ecs.md
index bd7f9ef..3732c66 100644
--- a/specs/spec_ecs.md
+++ b/specs/spec_ecs.md
@@ -499,6 +499,15 @@ ensemble) d'un étage en défaut (un seul chute).
 surplus (`AGENTS.md` règle 8, pas de boucle de feedback). Elle sert au diagnostic
 et au recrédit anti-clignotement déjà en place.
 
+> **Piège de mise en service, indépendant de toute configuration.** Le compteur
+> d'une charge NE DOIT JAMAIS être désigné comme **rootmeter** dans nymea. Aucun
+> champ de `LoadConfig` n'est en cause : il suffit d'une désignation dans
+> l'interface. L'arbitre lit le rootmeter par `internalRootMeter()`
+> (`energyarbitrator.cpp:229`) et en tire `meter.importW`/`exportW` — la
+> consommation de la charge entrerait donc **dans le bilan de surplus lui-même**,
+> et le budget serait faussé pour toutes les charges. Le compteur d'une charge est
+> un instrument de diagnostic ; le rootmeter mesure le point de livraison.
+
 ---
 
 ## §8 — Thermique