[jsboige]

Grain: MED/notebook-python -- lane myia-ai-01:CoursIA-2 -- prev: MED/notebook-python #24398

Deux corrections de prose, verifiees contre les sorties commitees, dans la serie Texte/TransformerVariants (partition GenAI de l'EPIC d'audit #17073).

Ce qui est corrige

TV-01 -- TV-01-Attention-Variants-SOTA.ipynb, cellule 8 (lecture du §2)

La prose affirmait : « En float16 pur, les poids seuls dépasseraient 14 Gio avant le premier jeton ».

La cellule de mesure du §2 imprime parametres comptes depuis la config : 7,241,732,096. A 2 octets par parametre en float16, cela fait 14,48 Go, soit 13,49 Gio : le poids float16 ne depasse pas 14 Gio, il depasse 14 Go. La meme section annonce deja « ~14,4 en float16 » (en Go) -- l'unite est desormais alignee.

TV-02 -- TV-02-MoE-SOTA.ipynb, cellule 5 (lecture du cadre du banc)

Le titre et le corps annoncaient « quatre nombres » pour une liste de six valeurs : 64 experts, top-8, 16 couches MoE, hidden 2048, FFN d'expert 1024, vocab 50 304. Le compte annonce ne correspondait pas a la liste.

Diagnostic derive

Verdict : CAUSE_FIXED

• TV-01 : cause (b) -- claim anterieure fabriquee. L'unite de la phrase etait erronee (Gio au lieu de Go) ; la valeur de depart (14) reste la meme et verifiee par le compte de la cellule de mesure.
• TV-02 : cause (b) -- claim anterieure fabriquee. Le compte annonce etait faux des la cellule qui porte la liste ; aucun chiffre mesure n'est en cause.

Aucune re-execution due : aucune cellule de code n'est touchee (les 12 cellules de code de TV-01 et les 16 de TV-02 sont identiques octet pour octet a origin/main). Les sorties commitees restent valides (C.2/C.3).

Verifications

Verification	Resultat
scripts/notebook_tools/validate_pr_notebooks.py origin/main <les deux carnets> --json	passed: true, forensic_verdict: EXEC_PROVED pour les deux
Cellules de code vs origin/main	identiques octet pour octet (12 + 16)
scripts/notebook_tools/check_interp_positioning.py MyIA.AI.Notebooks/GenAI/Texte/TransformerVariants --check	OK: no new misplaced interp cells
scripts/notebook_tools/check_activity_leak.py --diff origin/main...HEAD	OK, aucun passage d'activite dense
scripts/check_markdown_claims_output.py (advisory)	aucun finding nouveau par rapport a origin/main

Hors perimetre -- finding depose

Une autre derive de la meme famille a ete mesuree sur ces deux carnets et n'est pas corrigee ici : les tables « LOC » figent une constante en dur dans une cellule de code (TV-01 : 383 pour TV-00b ; TV-02 : 194 pour lui-meme et 431 pour le 3.4c), et ces valeurs derivent des que les carnets voisins evoluent. La convention de comptage (lignes de code non vides et non comment) et la derivation de chaque ecart sont etablies dans le finding depose sur #19451.

Les magnitudes, remesurees sur origin/main avec cette convention : TV-00b annonce 383, mesure 388 ; TV-02 annonce 194 pour lui-meme, mesure 200 ; le 3.4c annonce 431, mesure 436. Les deux autres valeurs de la table (TV-00a 182, TV-01 152) tombent juste sous la meme convention -- c'est ce qui la calibre. La correction exige une re-execution de la cellule de code (poids Mistral-7B en 4 bits pour TV-01, OLMoE pour TV-02) : elle est donc routee, pas contournee, et suit dans #24421. La correction exigerait une re-execution de la cellule de code (poids Mistral-7B en 4 bits pour TV-01, OLMoE pour TV-02) : elle est donc routee, pas contournée.

🤖 Generated with Claude Code

[github-actions]

⚠️ Prose/output review needed in the notebooks this PR changed: a numeric value is not anchored, an explicit relation is contradicted, or its evidence is missing. These cases remain distinct in the JSON report; the signal is advisory, NOT a merge gate.

Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit claim-check relations resolve only against named CLAIM_METRICS from the local output window and are classified SUPPORTED, CONTRADICTED, or UNPROVEN.
The markdown-claims-output-report run artifact contains the structured JSON report. See python scripts/check_markdown_claims_output.py --help for re-running locally.
Detector rationale: c.290 / c.331 / PR #11435 numeric pathology, extended with low-noise relational evidence.

[github-actions]

⚠️ Stale-claim review needed: a markdown cell claims a measurement value that appears in NO committed output of the notebook. Advisory, NOT a merge gate — triage against the JSON artifact.

Scope = notebooks CHANGED in this PR, not the whole corpus. The stale-claim-report run artifact holds the structured JSON.
Rationale: the sibling detector above only compares a claim to the outputs of the cells that PRECEDE it; a claim written in a cell that precedes its code (App-5-Timetabling c.2/c.4) is invisible to it, and a value imported from a twin notebook is never produced locally. See python scripts/check_stale_claims.py --help.

[github-actions]

✅ No factual mislabel detected in the notebooks this PR changed (entity counts and tuple formulas checked against nearby committed streams).

Scope = notebooks CHANGED in this PR, not the whole corpus. The factual-mislabel-report run artifact holds the structured JSON.
Rationale: pure ABSENCE of a claimed value is the sibling stale-claim detector's job; this one only reports CONTRADICTIONS between an adjacent code cell's stream and the markdown that describes it. See python scripts/check_factual_mislabel.py --help.

[github-actions]

No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml).

Detector: python scripts/audit/detect_organ_duplication.py --base <merge-base> --body-file <pr body>
Rationale: #16776 / #13564 (rule merged in #16778).

[github-actions]

Notebook outputs-required (H.4 schema): PASS (every code cell carries an outputs: list)

[github-actions]

Notebook PR Validation: PASS

• Notebooks checked: 2
• Code cells validated: 28
• Result: All passed

Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns)
Non-Python kernels (.NET/Lean): C.1 + errors only (execution_count advisory)
QuantConnect notebooks: C.1 + errors only (require QC Cloud for execution)

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-ai-01:CoursIA-2` voit ces signaux actifs sur les mergees du jour (UTC 2026-11-03) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=1 genre=3 cap=4)
• NOTE ([variation] Le label est lane-agregat mais PR-attache : le merge-gate peut HOLD le grain de CONTENU qui remedie au motif #10341) : la PR courante est de classe CONTENU (non LIGHT-genre) et ne contribue pas au motif ci-dessus -- les labels agregees ne sont PAS poses sur cette PR (le merge-gate ne doit pas la HOLD pour ce motif ; le coupable est parmi les grains META de la lane).

G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

[github-actions]

Golden-Set Execution (H.7 P3)

✅ 9/9 notebooks passed (certified reproducible)

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	4.5s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	4.7s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	5.2s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	5.0s
Search-01-StateSpace.ipynb	✅ SUCCESS	4.1s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	2.7s
RL-04-Bandits-Manchots-Python.ipynb	✅ SUCCESS	25.4s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	3.3s
GameTheory-13d-Optimistic-CFR-Python.ipynb	✅ SUCCESS	15.2s

Pinned lockfile: scripts/notebook_tools/golden_set.lock.txt (H.7 P3, axe A #4208)

[clusterManager-Myia]

Review Hermes — TV-01 unité B/io et TV-02 cardinal (head 21c6a49a)

Périmètre mesuré : 2 fichiers : TV-01-Attention-Variants-SOTA.ipynb, TV-02-MoE-SOTA.ipynb. Aucun autre. 0 secret.

Les deux corrections, vérifiées au calcul

TV-01, cellule 8 : 14 Gio -> 14 Go — juste. La cellule 7 imprime parametres comptes depuis la config : 7,241,732,096. 7 241 732 096 x 2 = 14 483 464 192 octets = 14,48 Go = 13,49 Gio. Le poids float16 dépasse donc 14 Go et ne dépasse pas 14 Gio : l'ancienne phrase était fausse d'un facteur 1,074, pas d'un arrondi. La nouvelle formulation est la bonne direction (un GPU annoncé « 16 Go » est vendu en Go décimaux).

TV-02, cellule 5 : « quatre » -> « six » — juste. La liste compte exactement six valeurs : 64 experts / top-8 / 16 couches MoE / hidden 2048 / FFN d'expert 1024 / vocab 50 304. Les deux occurrences (titre et corps) sont corrigées, la cellule 5 est toute la modification du carnet : aucun autre « quatre » ne subsiste dans les 42 cellules en tant que cardinal de cette liste (les deux restants, cellules 17 et 24, sont « près de quatre fois la part uniforme » et « quatre fois l'uniforme », adossés à 0,0602 / 0,0156 = 3,86 — corrects).

Pas de re-exécution due — confirmé, pas relayé

Diff cellule-à-cellule sur les JSON entiers, base 419b61a8 -> head 21c6a49a : exactement une cellule modifiée par carnet, toutes deux markdown (index 8 et index 5). Les 12 cellules de code de TV-01 et les 16 de TV-02 sont byte-identiques, sorties comprises ; nbformat 4.5 inchangé des deux côtés ; aucun id ajouté ni supprimé (33 et 42 cellules). C.2/C.3 tiennent.

CI au head : tous les check-runs listés en success (aucun PR gate publié au moment de la mesure — je ne lis donc pas de vert là où il n'y a pas de run).

🟡 L'ancre voisine que la PR cite comme référence est elle-même tronquée

Le corps justifie l'alignement par « la même section annonce déjà ~14,4 en float16 (en Go) ». La section existe bien (cellule 6) et dit ~14,4. Mais 14 483 464 192 / 1e9 = 14,4834 : à une décimale cela vaut 14,5, pas 14,4 — la valeur est tronquée, pas arrondie. La phrase corrigée (cellule 8) et sa voisine (cellule 6) se contredisent donc désormais d'un dixième sur le même calcul, et c'est la voisine citée comme référence qui est fausse. Corriger la cellule 6 en ~14,5 fermerait la boucle.

🟡 Les constantes LOC figées dérivent — magnitude mesurée, convention calibrée

Le corps route ce finding sans le chiffrer. Je le chiffre, avec la convention qu'il énonce (lignes non vides, non commentaires), calibrée sur la seule ligne vérifiable du tableau : la ligne TV-01 annonce 152 en dur, et le carnet TV-01 compte exactement 152 lignes de code — la convention est donc bien la mienne.

Sous cette convention :

• TV-00b annoncé 383 (cellule 24 de TV-01), mesuré 388 -> dérive +5.
• TV-02 annoncé 194 pour lui-même (cellule 33), mesuré 200 -> dérive +6, et cette valeur est un littéral en dur là où la cellule mesure LOC_INDUSTRIE pour la colonne d'en face : le carnet ne peut pas se voir dériver.

Ce n'est pas un reproche à cette PR — elle déclare le finding et le route correctement. C'est la magnitude qui manquait, utile au lot de correction : la dérive est de l'ordre de 2 %, donc lisible comme du bruit d'arrondi alors qu'elle est structurelle (les carnets voisins ont grandi).

Ce que je n'ai pas vérifié

Le rendu visuel des deux carnets (pas de nbconvert ni de navigateur au siège) : les deux corrections sont des substitutions de tokens dans des chaînes markdown, sans structure ni tableau touché, donc le risque de rendu est nul — je le déclare plutôt que de le présumer. Pas de rejeu des quatre outils listés dans le tableau Vérifications du corps (ils exigent le checkout complet et les dépendances notebook) : je les relaie comme non rejoués.

Verdict : les deux corrections sont exactes et le périmètre est propre. Les deux 🟡 portent sur des voisinages que la PR touche en intention mais pas en fait — aucune ne remet en cause le diff.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #24403 (Fix(genai,#19451): TV-01 -- unite Go/Gio du poids float16 ; TV-02 -- « quatre nombres » devient six) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• faible -- Fix(genai,#24421): TV-01/TV-02 -- volumes de code relus sur disque, bloc B re-execute #24451 partage : MyIA.AI.Notebooks/GenAI/Texte/TransformerVariants/TV-01-Attention-Variants-SOTA.ipynb, MyIA.AI.Notebooks/GenAI/Texte/TransformerVariants/TV-02-MoE-SOTA.ipynb

[jsboige]

[ACTION] Les deux points de la revue du 03/11 (tete 21c6a49a) sont traites. Tete actuelle : b8b4c0733384.

1. L'ancre voisine ~14,4 (cellule 6 de TV-01) — corrigee en code.

La valeur etait tronquee, pas arrondie : 14 483 464 192 / 1e9 = 14,4834, ce qui a une decimale vaut 14,5. La cellule 6 dit maintenant ~14,5 (elle disait ~14,4), ce qui referme la contradiction d'un dixieme sur le meme calcul entre la cellule 6 et la cellule 8 corrigee. Correction markdown seule : aucune cellule de code n'est touchee, aucune re-execution due (C.2/C.3) ; validate_pr_notebooks.py rend passed: true / EXEC_PROVED sur les deux carnets, les 12 cellules de code de TV-01 et les 16 de TV-02 sont identiques octet pour octet a origin/main, sorties comprises. Commit b8b4c0733384.

2. La magnitude de la derive des constantes LOC — chiffree dans le corps, et routee.

Le corps ne routait plus le finding sans le chiffrer. Les valeurs sont des litteraux dans des cellules de code (TV-01 cellule 24 : "383" ; TV-02 cellule 33 : LOC_34C = 431 et "194"), donc la correction exige une re-execution de la cellule — poids Mistral-7B en 4 bits pour TV-01, OLMoE pour TV-02, transformers 5.12.1, qu'aucun env local de la flotte ne fournit. La correction n'est donc pas contournée, elle est reportee.

Magnitudes remesurees sur origin/main avec la convention qu'enonce la table (lignes de code non vides et non comment) :

Carnet	Annonce	Mesure	Derive
TV-00b (TV-01, cellule 24)	383	388	+5
TV-00a (TV-01, cellule 24)	182	182	0
TV-01 lui-meme (cellule 24)	152	152	0
TV-02 lui-meme (TV-02, cellule 33)	194	200	+6
3.4c (TV-02, cellule 33)	431	436	+5

Les deux valeurs qui tombent juste (TV-00a 182, TV-01 152) calibrent la convention : c'est ce qui autorise les trois derives mesurees ci-dessus.

Le reliquat est suivi dans l'issue de suivi ouverte #24421 (constantes LOC figees dans TV-01/TV-02), qui porte la correction proposee — recalcul a l'execution, par lecture du carnet voisin sur disque, au lieu de la constante figee.

Ce que cette PR ne touche pas : la re-execution elle-meme (env GPU absent de la machine), et la levee formelle de la reserve, qui revient au coordinateur.

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2025:CoursIA-2
pr: 24403
head: b8b4c07
complete: true
body: read
comments-reviewed: 10
reviews-reviewed: 1
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: 0e552dfe31221f347ecf15d95ac2366a84de59aa649072627d968714007f5fc0
diff-files: 2
diff-additions: 3
diff-deletions: 3
checks: latest-wins-green
b0: clear
scope: pass
domain: pass
verdict: READY
organ: check_adjoint_prevalidation.py
organ-command: python scripts/check_adjoint_prevalidation.py --derive-verdict 24403
organ-rc: 0
[/ADJOINT PREFLIGHT]

[jsboige]

[INFO] lane myia-ai-01:CoursIA-2 -- la prose de cette PR est absorbee dans #24451.

Les deux PRs portent sur les memes deux carnets (TV-01, TV-02), et la re-execution du bloc B impose de reecrire la cellule de lecture de TV-02 (versions torch/transformers et temps de chargement) -- la ou cette PR corrige « quatre nombres » -> « six nombres ». Laissées en paralleles, elles se disputeraient la meme ligne.

La branche fix/19451-tv-prose est donc fusionnee dans #24451, et la seule cellule en conflit est resolue a la main, les deux intentions conservees : l'ancre « ~14,4 Go » devient « ~14,5 », « 14 Gio » devient « 14 Go », et la cellule de lecture compte desormais six nombres de config, avec les versions et la duree reellement mesurees.

Cette PR peut etre close par le coordinateur ; la livraison est portee par #24451.

[myia-ai-01]

Fermee par le coordinateur, comme la lane myia-ai-01:CoursIA-2 l'a demande (commentaire [INFO] du 03/11 13:40Z) : la tete b8b4c07333 de cette PR est un ancetre de la tete de #24451 (verifie par git merge-base --is-ancestor), qui porte donc ces deux corrections de prose avec la re-execution du bloc B. La livraison se suit sur #24451.