diff --git a/docs/DESIGN_PREVISION_PV.md b/docs/DESIGN_PREVISION_PV.md
index 01d0083..f9853fb 100644
--- a/docs/DESIGN_PREVISION_PV.md
+++ b/docs/DESIGN_PREVISION_PV.md
@@ -1003,3 +1003,62 @@ douter de l'installation, l'autre fait croire au chiffre qui la fait douter.
 
 Écrit dans la description de `GetPvForecast`, pas seulement ici : c'est un client qui construira
 l'écran, et c'est le contrat qu'il lira.
+
+
+---
+
+## 22. La somme vérifiée — et ce qu'elle rend visible (2026-09-09, 08:08)
+
+Un second plan a été créé sur le site. **Le chemin de sommation a donc été exercé pour la
+première fois**, et il l'a été sur la machine :
+
+```
+08:08:00  [Prévision] 2 plans sommés — 48 créneaux
+08:08:00  RÉVISION 484220d7 — 48 créneaux, âge 2026-09-09T03:00:00Z
+08:09:00  courbe inchangée — fraîcheur mise à jour
+
+  7eb8a7d4  vu 08:02:00  revu 08:07:00  48 créneaux  20,0 kWh   ← un plan
+  484220d7  vu 08:08:00  revu 08:09:00  48 créneaux  36,0 kWh   ← deux plans sommés
+```
+
+`20,0 + 16,0 = 36,0 kWh`, au dixième. Puis déduplication au cycle suivant.
+
+### 22.1 Ma garde était juste, et son coût était plus grand que je ne le pensais
+
+L'hypothèse « les plans d'un site partagent un instant » était **fausse** : `due()` portait un
+jitter aléatoire par plan, si bien que deux plans divergeaient en quelques minutes. Ma garde
+« ne sommer que des plans du même run » aurait donc **bloqué la somme** à chaque publication de
+run — `issuedAt` venant d'un domaine à 3 h, cela fait **huit fenêtres par jour, jusqu'à une heure
+chacune**. Pas un cas rare : un cas régulier.
+
+Corrigé chez le producteur (`+etm14`) : le site pilote la prévision horaire de tous ses plans dans
+la même passe, et c'est désormais **au contrat**. L'hypothèse est vraie **par construction, pas
+par chance**.
+
+> **Et ma garde reste utile après le correctif** — elle devient l'**instrument qui l'observe**.
+> Si la boucle naturelle ne tenait pas, le journal dirait « plans de runs différents — on attend
+> la prochaine passe ». Une garde qui vérifie la promesse sur laquelle elle repose vaut mieux
+> qu'une garde qu'on retire parce que la promesse a été faite.
+
+### 22.2 CE QUE LA SOMME REND VISIBLE : une CONFIGURATION qui ressemble à une révision
+
+Le passage de 20,0 à 36,0 kWh est enregistré comme une **révision**. Il n'en est pas une : **la
+prévision n'a pas changé, l'installation a changé.**
+
+C'est le point du §8.5, annoncé au premier jour et devenu réel :
+
+> *« L'historique doit retenir SOUS QUEL PLAN une prévision a été convertie — sinon un recâblage
+> rend toute la série antérieure incomparable sans que rien ne le dise. »*
+
+**Conséquence pour la comparaison prévu/réalisé** : comparer les 20 kWh d'avant 08:08 à une
+production postérieure comparerait **deux installations différentes**. Rien dans la table ne
+permet aujourd'hui de le voir — la révision est là, sa **cause** ne l'est pas.
+
+**Proposition, non implémentée** : une colonne portant l'**ensemble des plans** (leur nombre, ou
+l'empreinte de leurs identifiants) à côté de la courbe. Elle ne change pas la clé — le contenu
+suffit à identifier la révision — mais elle rend la **cause** lisible, et permet d'écarter d'une
+comparaison les révisions qui n'en sont pas.
+
+**Pas fait maintenant, et délibérément** : ce serait un schéma v3 une heure après la v2, sur un
+mécanisme qui n'a qu'une matinée d'observation. Mêler deux inconnues. À reprendre quand les runs
+se seront succédé.