diff --git a/specs/spec_loadmodel.md b/specs/spec_loadmodel.md
index 25963b4..ccdf8ed 100644
--- a/specs/spec_loadmodel.md
+++ b/specs/spec_loadmodel.md
@@ -879,6 +879,50 @@ motif faux envoie diagnostiquer le mauvais problème, avec l'autorité d'une exp
 > elle est en aval de la coupure, elle n'est pas la coupure. Sans cette précédence, deux charges
 > successives auraient produit deux points de rupture concurrents dans le même cycle.
 
+**LM-1012 — On PUBLIE ce qui ne se dérive pas ; on DÉRIVE ce qui se dérive.** *(Ligne tracée par
+l'agent app le 2026-08-30. Elle vaut bien au-delà du §10, et elle explique après coup plusieurs
+refus qu'on avait pris un par un.)*
+
+La légitimité d'une valeur **dérivée** ne dépend pas de son utilité, mais de **l'endroit où elle
+vit** :
+
+- **dérivée, locale, jamais transportée** → légitime, et **précisément parce qu'**elle est
+  dérivable : chaque lecteur la recalcule, elle ne peut pas mentir.
+- **dérivée et PUBLIÉE** → illégitime, **pour la même raison** : elle devient une seconde source
+  de vérité pour un fait qui en a déjà une, et les deux divergeront.
+
+C'est ce qui distingue un `"mixed"` calculé côté client — parfaitement légitime, il se relit à
+chaque affichage — d'un `"mixed"` publié par le moteur, qui serait une valeur à maintenir en
+accord avec une ventilation qui, elle, fait foi.
+
+> **Elle couvre, après coup, trois refus déjà pris séparément** : l'**index d'ordre de service**
+> (dérivable d'un tri sur `(niveau, priority)`), le **`"mixed"` de `funding`** (dérivable de
+> `counts`), et le **`stagesW`** publié — qui, lui, est publié *parce que* la table de paliers
+> n'est PAS dérivable côté client, la combinatoire vivant dans l'adaptateur.
+>
+> **Et son symétrique** : `rankOrigin` est publié parce qu'il **ne se dérive pas** — rien dans un
+> rang ne dit qui l'a posé.
+
+**LM-1013 — `grid` l'emporte dès qu'un seul watt est acheté.** *(Règle posée par l'agent app le
+2026-08-30, retenue telle quelle : c'est une RÈGLE, pas une approximation, et la nuance décide.)*
+
+Le financement d'un niveau vaut `"grid"` **dès qu'une part, si petite soit-elle, est achetée au
+réseau** ; `"surplus"` seulement si la totalité vient du surplus.
+
+**Pourquoi ce n'est pas « une approximation qu'on assume »** : tant qu'on la décrit ainsi,
+quelqu'un voudra un jour la rendre *exacte* — part dominante, seuil de majorité. Sur un niveau à
+900 W de surplus et 480 W de réseau, un tel libellé **basculerait d'un cycle à l'autre au gré des
+proportions**, sans qu'aucune décision n'ait changé. La règle « un watt acheté suffit » est
+**déterministe, indépendante des proportions**, alignée sur le fait actionnable — *de l'argent
+a-t-il été dépensé ?* — et elle vaudra **sans décision nouvelle** pour le plancher éco du §10.
+
+> **Et il n'y aura pas de troisième valeur `"mixed"`.** L'argument est celui de l'app, et il est
+> décisif : **tout client qui teste `funding == "grid"` a une branche par défaut, et cette
+> branche est « surplus »**. Une valeur inconnue y tomberait **sans erreur**, et rangerait au
+> soleil un niveau dont une part est achetée — c'est la panne de l'omission, avec un champ
+> présent en plus pour faire croire le contraire. Le client qui veut la nuance la **dérive** de
+> `counts` (LM-1012).
+
 **LM-1007 — Compatibilité descendante, et elle est gratuite.** Une charge qui ne déclare
 **aucun** besoin éco ne participe qu'à la passe 2 — soit exactement le comportement
 d'aujourd'hui. Le modèle à deux niveaux **dégrade proprement** vers le modèle actuel, ce qui