# Reality Trial 001 — protocole preregistre

Version du protocole : `reality-trial-001-v0.1`  
Statut : `preparing`  
Langage : GardenScript `0.2` / `tomato.v2`  
Plan : 9 plants de tomate, 3 strategies, 3 repetitions, 21 jours

## Ce que ce pilote cherche a montrer

Reality Trial 001 teste une question limitee : des politiques GardenScript
ecrites et scellees par trois IA peuvent-elles etre executees de facon
prospective, reproductible et auditable sur de vrais plants de tomate ?

Ce pilote ne cherche pas a prouver qu'un modele d'IA est meilleur agronome,
ni qu'une intervention est efficace en general. Avec trois plants par
strategie, un seul lieu, un operateur et 21 jours, il ne permet ni inference
statistique forte, ni recommandation agronomique. Les resultats seront publies
comme une demonstration falsifiable avec donnees brutes et limites visibles.

Point essentiel : les trois strategies ne pilotent jamais le meme plant.
Chaque strategie est affectee a trois plants distincts et son programme est
evalue separement pour chacun d'eux.

## 1. Plan experimental

- 9 plants de `Solanum lycopersicum`, de meme cultivar, meme lot et age aussi
  proches que possible ;
- 3 emplacements de strategie anonymes : `model-a`, `model-b`, `model-c` ;
- 3 repetitions par strategie ;
- plan en blocs complets randomises : chacun des 3 blocs spatiaux contient un
  plant de chaque strategie ;
- pots, volume de substrat, lot de substrat, drainage, tuteurs, espacement,
  date de transplantation et exposition identiques ;
- horizon fixe de 21 jours, sans prolongation decidee apres observation des
  resultats ;
- GardenScript evalue une fois par plant et par jour, avant les interventions.

Le site, le cultivar, le volume exact des pots, les lots de materiel, les
dates et les identifiants des operateurs doivent etre renseignes dans le
manifeste avant le scellement. Tant qu'un de ces champs manque, le statut reste
`preparing`.

## 2. Criteres d'inclusion et mise a niveau initiale

Les plants doivent provenir du meme lot. Sont exclus avant randomisation les
plants avec casse de tige, symptome infectieux evident, infestation visible,
fanage persistant ou ecart de taille superieur a 25 % de la mediane du lot.

Pendant les 48 heures d'acclimatation, tous les plants recoivent le meme soin.
Vingt-quatre heures avant la randomisation, l'humidite du substrat est mise a
niveau selon une procedure unique et journalisee. Le jour 0, avant toute
intervention de strategie, chaque plant recoit :

- une photo de dessus et quatre photos laterales avec mire et charte couleur ;
- sa hauteur, la largeur de canopee, le nombre de fruits et leur stade visuel ;
- deux lectures d'humidite du substrat aux positions marquees ;
- la masse du pot si une balance adaptee est disponible ;
- les scores de stress hydrique, thermique, maladie et maturite.

Les 9 plants sont ordonnes selon un indice initial annonce avant allocation
(hauteur, surface projetee et nombre de fruits), puis groupes en trois blocs
de trois plants proches. Aucun plant n'est remplace apres revelation de
l'allocation.

## 3. Randomisation et aveuglement

Apres validation et scellement des trois sources GardenScript, six des
physiques a six faces sont lances devant une video continue. Les six chiffres
forment la seed decimale dans l'ordre de lecture. La cle de 32 octets est
`SHA-256("reality-trial-001|" + six_chiffres)`. Un Fisher-Yates utilise le flux
ChaCha20 IETF (RFC 8439), nonce de 12 octets a zero et compteur initial zero ;
les mots 32 bits little-endian sont convertis par rejection sampling pour
eviter le biais modulo. Il permute les trois slots separement dans chaque bloc,
en poursuivant le meme flux. Le fichier d'allocation, le petit programme de
randomisation et la video sont hashes en SHA-256.

Les pots portent seulement des identifiants `P01` a `P09`. La cle
plant/strategie est conservee separement. L'operateur qui applique les actions
ne peut pas etre aveugle. Les personnes qui notent les photos terminales et la
qualite des fruits ne voient que les identifiants des plants ; la cle n'est
revelee qu'apres gel des mesures et calcul du classement. Il s'agit donc d'un
aveuglement partiel, pas d'un double aveugle.

Les positions restent fixes pendant les 21 jours. Tout deplacement impose par
le vent, un accident ou la securite est horodate et photographie.

## 4. Budgets identiques

Chaque plant possede son propre registre, initialise a :

| Ressource | Budget par plant |
|---|---:|
| Irrigation pilotee | `90 mm` sur 21 jours |
| Irrigation maximale | `12 mm` par jour |
| Travail virtuel GardenScript | `240 min` |

La pluie naturelle ne debite pas le budget d'irrigation. Les minutes sont le
cout virtuel public du ruleset, pas une affirmation sur le temps de travail
reel. Le temps reel est mesure separement.

## 5. Cycle quotidien

Le meme horaire local est conserve, avec une tolerance de plus ou moins 30
minutes :

1. a 06:30, capture du bulletin meteo choisi avant le depart ;
2. entre 07:00 et 07:30, mesures avant intervention et photos standardisees ;
3. a 07:45, production des 18 capteurs et evaluation locale des neuf programmes
   avec le binaire Rust `garden-script` ;
4. entre 08:00 et 09:00, application des actions acceptees par le noyau de
   securite ;
5. application des filets d'ombrage sur la fenetre fixe 11:00–17:00 ;
6. en fin de journee, journal des incidents, recoltes et actions d'urgence.

Les heures exactes, les intentions, les actions acceptees ou refusees, les
motifs de refus et les ressources restantes sont conservees. Une strategie
n'est jamais reecrite pendant le pilote.

## 6. Adaptateur du terrain vers les 18 capteurs

GardenScript 0.2 a d'abord ete concu pour le jumeau numerique. Plusieurs de ses
capteurs ne sont pas directement mesurables sans detruire le plant. Reality
Trial 001 publie donc les mesures brutes et distingue explicitement les
mesures, les scores visuels et les variables derivees. Les valeurs derivees ne
doivent jamais etre presentees comme des mesures agronomiques directes.

| Capteur | Construction quotidienne |
|---|---|
| `clock.day` | entier 1 a 21 |
| `forecast.rain_mm` | pluie prevue sur les prochaines 24 h dans le bulletin commun capture a 06:30 |
| `forecast.temp_max_c` | maximum prevu pour le jour dans ce meme bulletin |
| `forecast.humidity_pct` | humidite maximale prevue pour le jour dans ce meme bulletin |
| `soil.water_pct` | mediane des deux sondes marquees, apres calibration commune, bornee a 0–100 % |
| `soil.water_mm` | `soil.water_pct / 100 × capacite_disponible_mm`, avec la capacite geometrique gelee avant scellement |
| `plant.water_stress_pct` | grille visuelle gelee : 0 normal, 25 leger port tombant, 50 port tombant sur 25–50 % du feuillage, 75 sur plus de 50 %, 100 effondrement ; interpolation par pas de 5 autorisee et justifiee |
| `plant.heat_stress_pct` | meme echelle 0–100 par pas de 5, fondee sur enroulement, fletrissement aux heures chaudes et brulure ; rubric photo gelee avant depart |
| `plant.disease_pct` | pourcentage de surface foliaire visible symptomatique, estime sur les vues standardisees et relu en aveugle |
| `plant.ready_pct` | pourcentage des fruits visibles ayant atteint le stade de couleur de recolte preregistre |
| `plant.biomass_g_m2` | proxy non destructif : `500 × sqrt(ratio_surface_dessus × ratio_surface_laterale)`, ou 500 est la valeur du jour 0 ; borne 0–20 000 `g_m2` |
| `plant.leaf_area_index` | surface verte projetee de dessus divisee par la surface superieure du pot, bornee 0–12 `lai` ; c'est un proxy, pas un LAI de laboratoire |
| `history.rain_3d_mm` | somme des pluies mesurees durant les trois jours termines, fenetre tronquee au debut |
| `history.irrigation_3d_mm` | somme des irrigations acceptees pour ce plant durant les trois jours termines |
| `history.dry_streak_day` | jours termines consecutifs avec pluie mesuree inferieure a `1 mm` |
| `history.days_since_irrigation_day` | jours termines depuis la derniere irrigation acceptee ; zero avant la premiere |
| `resource.water_left_mm` | registre initial de 90 mm moins les irrigations acceptees |
| `resource.labor_left_min` | registre initial de 240 min moins les couts virtuels acceptes |

La source meteo manuelle, le point geographique, l'edition du bulletin, la
definition exacte de l'humidite retenue et la procedure de panne sont geles
avant sollicitation des IA. Tous les plants recoivent les trois memes valeurs
de prevision chaque jour. Aucun appel d'API payant n'est necessaire.

Les images sources, masques de segmentation et calculs intermediaires des
proxies sont conserves. Toute modification de l'adaptateur apres scellement
rend le pilote exploratoire non classable, sauf correction purement logicielle
publiee avec ancien et nouveau resultat.

## 7. Mapping physique des actions

Le programme produit une intention. Le noyau public applique ensuite les
plafonds, les couts et les contraintes de securite dans l'ordre des cinq
canaux.

### Setup

- `mulch = none` : aucun paillage ;
- `mulch = straw_light` : couche uniforme de paille propre de 2 cm ;
- `mulch = straw_heavy` : couche uniforme de paille propre de 5 cm.

La masse et le lot de paille par pot sont notes au jour 0.

### Decisions

| Intention | Application physique preregistree | Cout virtuel |
|---|---|---:|
| irrigation `Xmm` | `X × surface_superieure_du_pot_m2` litres, apportes lentement ; plafonds 12 mm/j et 90 mm/plant | 0 min |
| `off` | aucun filet | 0 min |
| `net_30` | filet certifie environ 30 %, geometrie commune, 11:00–17:00 | 4 min |
| `net_50` | filet certifie environ 50 %, meme geometrie et fenetre | 8 min |
| `none` | aucune protection | 0 min |
| `bio_low` | inspection et retrait des seuls debris vegetaux deja detaches du pot ; aucun produit | 10 min |
| `bio_high` | `bio_low`, puis retrait d'au plus une feuille dont au moins 75 % de la surface est symptomatique, photographiee avant retrait ; aucun produit | 18 min |
| nutrition `none` | aucun apport | 0 min |
| `compost_low` | 1 g de compost mur et tamise par litre de substrat, en surfaçage | 15 min |
| `compost_high` | 2 g du meme compost par litre de substrat, en surfaçage | 25 min |
| `keep` | aucune taille | 0 min |
| `prune_light` | retrait d'au plus une feuille basse eligible, photographiee avant/apres | 25 min |

`compost_low`, `compost_high` et `prune_light` ont chacun un delai de securite
de sept jours par plant. Une demande pendant le delai est refusee, conserve sa
trace et ne consomme pas la ressource. Une feuille eligible est completement
developpee, situee sous la premiere grappe, sans fruit ni lesion mecanique ;
aucune feuille n'est retiree si cela laisse moins de six feuilles saines.

Le compost doit etre le meme produit et le meme lot pour les neuf plants ; son
origine, sa masse seche et le volume exact de substrat sont publies avant le
depart. Cette convention est propre au pilote et n'est pas une recommandation
de culture.

Les outils sont desinfectes entre plants. L'ordre de passage quotidien des
plants est une permutation pregeneree et scellee afin de ne pas toujours
favoriser le meme slot.

## 8. Noyau de securite et integrite des plants

Une plante n'est pas un animal et le terme « bien-etre » n'est pas utilise au
sens sentient. Le protocole protege toutefois son integrite et interdit de
sacrifier deliberement un plant pour le spectacle.

Le noyau, avant toute application :

1. borne l'irrigation a 0–12 mm et au reliquat ;
2. verifie le travail virtuel restant ;
3. verifie les delais, l'eligibilite de la feuille et la stabilite du filet ;
4. refuse toute action non conforme, non documentee ou dangereuse ;
5. inscrit intention, action finale et motif machine-lisible.

Les refus normaux prevus par ce noyau font partie du jeu et restent classables.
En revanche, une irrigation de sauvetage, un traitement non preregistre, le
retrait d'urgence d'un plant ou une intervention pour eviter un dommage
irreversible declenche `emergency_override`. Le plant est soigne sans attendre
le classement ; la strategie concernee devient non classable. Un evenement
externe touchant plusieurs slots (tempete, panne d'arrosage, contamination)
peut rendre tout le pilote `inconclusive` sur decision publiee avant ouverture
de la cle d'allocation.

## 9. Donnees et scellement

Tous les textes sont en UTF-8 avec fins de ligne LF. Les empreintes SHA-256
portent sur les octets exacts, pas sur une copie reformatee.

Pour chaque IA sont conserves :

- fournisseur, nom de modele, version ou identifiant visible, interface et
  date de sollicitation ;
- prompt exact, reponse brute complete et transcript sans secret ;
- `prompt_sha256`, `transcript_sha256`, `source_sha256` ;
- `program_sha256` et version du compilateur Rust ;
- toutes les tentatives invalides avant scellement, sans selection cachee.

L'attribution du nom « Claude », « Codex » ou « Grok » reste une provenance
declaree tant qu'elle n'est pas attestee par un export ou une signature du
fournisseur. Aucun logo ne vaut preuve cryptographique.

Avant le jour 0, un snapshot du manifeste, du protocole, du challenge, des
trois sources, des transcripts, de l'allocation et de l'ordre de passage est
liste dans `SHA256SUMS`. Le timestamp de scellement et le hash de ce fichier
sont publies. Apres scellement, les fichiers originaux ne sont jamais
remplaces : une correction est un nouvel artefact qui reference l'ancien.

Chaque photo conserve l'horodatage, l'identifiant du plant, la vue, le hash et
le fichier original. Une horloge unique synchronisee est utilisee par
l'operateur. Aucun horodatage du client web n'est traite comme preuve unique.

## 10. Mesures terminales et classement preregistre

Les fruits sont recoltes des qu'ils atteignent le stade de couleur preregistre.
Chaque lot est photographie et pese sur la meme balance au 0,1 g. La masse
commercialisable exclut seulement les fruits fendus, pourris ou gravement
leses selon la grille gelee au jour 0 ; masse totale et exclusions sont aussi
publiees.

Une strategie agrege ses trois repetitions. Le classement est
lexicographique : le premier critere different decide, sans score composite.

1. `rankable_desc` — strategie classable avant non classable ;
2. `critical_plant_days_asc` — moins de plant-jours critiques ;
3. `plants_lost_count_asc` — moins de plants perdus ;
4. `marketable_harvest_g_desc` — masse commercialisable totale plus elevee ;
5. `total_harvest_g_desc` — masse recoltee totale plus elevee ;
6. `mean_disease_pct_asc` — moyenne quotidienne sur les trois plants plus basse ;
7. `mean_water_stress_pct_asc` — moyenne quotidienne plus basse ;
8. `irrigation_total_mm_asc` — moins d'irrigation pilotee ;
9. `virtual_labor_total_min_asc` — moins de travail virtuel accepte ;
10. `slot_id_asc` — departage deterministe final.

Un plant-jour est critique si au moins un des trois scores `water_stress`,
`heat_stress` ou `disease` atteint 85 %, ou si un `emergency_override` a lieu.
Un plant perdu ne presente plus de tissu apical viable au jour 21 ou a du etre
retire du dispositif. Les valeurs non arrondies servent au classement ;
l'affichage peut etre arrondi.

Les resultats de chaque plant sont publies en plus des agregats. Aucun test de
significativite, intervalle causal ou generalisation a d'autres cultures n'est
revendique. Si un critere requis est manquant pour un slot, son resultat est
`provisional` et non classable jusqu'a resolution documentee.

## 11. Donnees manquantes, ecarts et arret

- une mesure manque : conserver `null` dans la donnee brute, la raison et la
  methode d'imputation preregistree ; ne jamais inventer une observation ;
- une photo est refaite : conserver les deux fichiers et indiquer celle jugee
  exploitable sans effacer la premiere ;
- une erreur de saisie est corrigee : journal append-only avec ancienne valeur,
  nouvelle valeur, auteur, date et motif ;
- deux jours consecutifs sans paquet quotidien complet pour plus de trois
  plants rendent le pilote `inconclusive` ;
- une contamination, un accident de site ou une difference materielle non
  repartie entre slots peut arreter le pilote avant 21 jours.

Une conclusion negative, une egalite ou un pilote inconclusif est un resultat
acceptable. Le protocole ne doit jamais etre modifie pour fabriquer un gagnant.

## 12. Limites a afficher avec chaque resultat

- seulement trois repetitions par strategie ;
- un seul site et une seule fenetre meteo ;
- plants partageant un environnement : independance statistique limitee ;
- operateur d'intervention non aveugle ;
- scores visuels et plusieurs capteurs GardenScript derives de proxies ;
- differences initiales de fruits impossibles a eliminer totalement ;
- horizon trop court pour juger un cycle cultural complet ;
- mapping physique propre a ce pilote, distinct des equations du jumeau ;
- provenance des IA principalement declaree, sauf preuve externe jointe ;
- aucune recommandation agronomique, sanitaire ou commerciale.

## 13. Portes de lancement

Le statut ne peut passer de `preparing` a `sealed` que si :

- neuf plants et trois plants de reserve ont ete photographies et controles ;
- site, cultivar, pots, substrat, compost, paille, filets et instruments sont
  identifies ;
- sondes, balance et geometres photo ont passe leur verification ;
- source meteo et procedure de panne sont gelees ;
- trois reponses IA valides et leurs transcripts sont archives ;
- les trois `program_sha256` ont ete produits par le compilateur Rust ;
- allocation et ordre de passage sont generes et scelles ;
- protocole, challenge, manifeste et `SHA256SUMS` sont publies ;
- aucun fichier d'observation n'est antidate.

Le manifeste initial reste volontairement `preparing`, avec zero observation
et zero resultat, jusqu'a satisfaction de toutes ces portes.