diff --git a/docs/DESIGN_PREVISION_PV.md b/docs/DESIGN_PREVISION_PV.md
index f0dc5b6..aa84160 100644
--- a/docs/DESIGN_PREVISION_PV.md
+++ b/docs/DESIGN_PREVISION_PV.md
@@ -1319,3 +1319,37 @@ Le `performanceRatio` à **1,00** est bien visible, et bien borné : 13,4 kWh un
 septembre sur 2 kWc est **le haut de la fourchette**, pas au-delà. Il rend la prévision
 optimiste de l'ordre de 10 à 20 % — exactement ce qui avait été annoncé en le fixant, et il
 **s'ajoute** au plafond du §3 sans jamais l'expliquer.
+
+
+---
+
+## 28. Décisions du 2026-10-12
+
+*Consignées telles que rendues (brief 1 du lot « protocole 1.1 »), à la suite du rapport du lot 0.
+Rien de ce qui précède n'est réécrit ; aucune n'est implémentée à ce jour — ce sont des décisions,
+pas un état du code.*
+
+1. **Les paramètres physiques PAR CHAMP vivent sur le Thing plan openmeteo** — coefficient de
+   température, NOCT — à côté de `tilt`, `azimuth`, `kwp` et `performanceRatio`. **C'est openmeteo
+   qui applique la correction de température.** Une seule source de vérité pour l'orientation et
+   la physique d'un champ : le doublon « Thing plan + store `ems` » relevé au lot 0 §1b est écarté.
+2. **Le plafond AC est un paramètre DE SITE, côté `ems`**, appliqué **après la somme des plans**.
+   L'écrêtage onduleur porte sur ce que l'onduleur reçoit de tous ses champs, pas sur chacun : il
+   ne peut donc pas vivre sur un plan.
+3. **openmeteo publie EN PLUS le GTI brut et `temperature_2m` horaire**, pour l'**enregistrement**
+   — de quoi refaire ou contrôler la conversion plus tard sans dépendre de ce qu'elle a produit.
+4. **Pas horaire conservé.** Le **15 min viendra avec les prix day-ahead**, sans changement de
+   contrat : la grille est lue (`step`, §14.3), jamais supposée.
+5. **§5 maintenu : aucune correction apprise dans le GPL.** `conversion` ∈ `physics` | `fallback` ;
+   le plugin GPL n'émet jamais `hybrid`. Un optimiseur qui corrige la prévision le déclare de son
+   côté (`OPTIMIZER_PROTOCOL.md` §6, `diagnostics.inputsUsed.pv`).
+6. **§11 maintenu : la prévision n'entre dans aucune décision sans un lot dédié**, avec sa propre
+   décision écrite. Les décisions 1 à 4 améliorent la courbe ; elles ne la branchent sur rien.
+
+> **Ce que ces décisions déplacent, et qui n'est pas encore fait** : la correction de température
+> et la publication du GTI brut / `temperature_2m` sont du travail **openmeteo** (dépôt
+> `etm-powersync-plugins`) et un changement de forme du transport. **Si** `v` est incrémenté — la
+> règle proposée au lot 0 §4 est de l'incrémenter à tout changement de forme —
+> `ForecastStore::depuisTransport()` **refusera** la charge utile (`VERSION_x`) tant que ce dépôt
+> n'aura pas appris à la lire : l'ordre de livraison est alors imposé, le lecteur avant ou en même
+> temps que le producteur. Le plafond AC de site est du travail **`ems`**.