# Cible — répartition nirs4all ↔ dag-ml ↔ dag-ml-data

> **Directive maintainer (2026-06-23, renforcée) :** dag-ml doit fournir **TOUTES** les
> fonctionnalités génériques de nirs4all **nativement en Rust/C-ABI** — y compris l'**agrégation
> CV** (par-fold + ensembles `avg`/`w_avg` + refit `final`), le **scoring/metrics**, la
> **sélection**, et la **persistance prédictions/scores**. Parité **exacte et native** (ne PAS
> ré-implémenter l'agrégation côté host Python). État final : **nirs4all entièrement
> cross-language ; seuls les operators/controllers restent par-langage.** Persistance
> prédictions/scores : pas de nouveau projet → **étendre le prediction-cache dag-ml en store
> prédictions+scores** (`NATIVE_PERSISTENCE_LAYER_REPORT.md`).
>
> **Objectif réel :** un **squelette nirs4all cross-language** = `dag-ml` + `nirs4all-io` +
> `nirs4all-methods`, identique dans **tous les langages** ; chaque langage ajoute ses
> controllers/operators. **Le langage target possède ses binaires de modèles** (format natif) ;
> **dag-ml sauve tout le reste** (orchestration, prédictions, scores, agrégation, lineage) →
> reproductible cross-language. Les modèles **nirs4all-methods** = même binaire partout (C-ABI)
> → reproductibilité totale. **nirs4all = "nirs4all-core + controllers Python"** ; Python =
> vaisseau amiral (SHAP, controllers ML/DL, Studio) ; « torch depuis R » ≡ « torch depuis Python ».


> **État *final* visé** du chantier core→dag-ml. À la fin : `nirs4all` ne garde que ce qui
> **calcule sur des spectres** (opérateurs/contrôleurs/modèles) + la **matérialisation des
> données** + HPO + explainabilité + l'**API/UX** ; `dag-ml` devient **tout l'orchestrateur** ;
> `dag-ml-data` porte les **contrats de données**. Synthèse — pas un inventaire exhaustif.

## Qui possède quoi

| Capacité | nirs4all (Python natif) | dag-ml | dag-ml-data |
|---|:---:|:---:|:---:|
| Opérateurs preprocessing (SNV, MSC, SavGol, Detrend, OSC/EPO/CARS…) | ✓ code numérique | — | — |
| Modèles (PLS*, sklearn, PyTorch/TF/JAX) — `fit`/`predict` | ✓ | — | — |
| Contrôleurs (host controllers `fit`/`transform`/`predict`) | ✓ parlent le protocole host dag-ml | invoque (NodeTask) | — |
| Splitters (KennardStone, SPXY, KFold, ShuffleSplit…) | ✓ calcule les indices | orchestre les folds | contrat `FoldSet` |
| **Matérialisation données** (X/y, identité `sample_id`, multi-source) | ✓ `SpectroDataset` + resolver | **jamais les matrices** (identity-keyed) | schémas/axes/représentations/envelope |
| Lecture fichiers (~58 formats) | ✓ nirs4all-io / nirs4all-formats | — | — |
| Hyperparamétrisation (`finetune_params`/Optuna) | ✓ exécute la recherche | génère+sélectionne les variantes (`_or_`/`_grid_`…) | — |
| Explainabilité (SHAP) | ✓ calcule les valeurs | orchestre la phase EXPLAIN + lineage | — |
| Compile / Plan / Scheduling | — | ✓ | — |
| CV · OOF (join par `sample_id`) · anti-fuite | — | ✓ | contrat fold/relations |
| Sélection de modèle · fingerprints | — | ✓ | — |
| Replay · lineage · provenance (RO-Crate/PROV/OpenLineage) | — | ✓ | — |
| Façade API (`run`/`predict`/`explain`/`retrain`/`session`/`generate`) | ✓ fine, délègue | moteur | — |
| Workspace (SQLite+Parquet) · bundles `.n4a` | ✓ contrat utilisateur/UX | alimenté par bundles+lineage dag-ml | — |
| Visualisation · charts · analyzers | ✓ | — | — |

## En trois phrases

- **nirs4all** = la lib de **numérique NIRS** : opérateurs + modèles + contrôleurs, **+ matérialisation
  des données**, + HPO, + explainabilité, + API/UX/workspace. *Tout ce qui touche des spectres.*
- **dag-ml** = le **moteur d'orchestration** : `compile→plan→fit_cv→select→refit→predict→explain`,
  OOF/anti-fuite, variantes, fingerprints, replay/lineage. *Tout ce qui coordonne — sans jamais voir une matrice.*
- **dag-ml-data** = les **contrats de données** sample-aligned : schémas, représentations, envelope,
  `FoldSet`, vtable host-provider.

## La frontière qui décide tout (vérifiée empiriquement)

Le cœur dag-ml **ne voit jamais X/y** : les données circulent par `sample_id`, et c'est nirs4all qui
les résout en vraies lignes `SpectroDataset` (le `MaterializationResolver`, livré en 2b-i). C'est
pourquoi **la matérialisation des données reste irréductiblement Python** — ce n'est pas *seulement*
les opérateurs qui restent côté nirs4all. Tout le reste de la coordination part vers dag-ml.

> Nuance HPO/sélection : la *recherche* d'hyperparamètres (entraîner/évaluer chaque candidat) reste
> Python (Optuna), mais la *génération déterministe des variantes* et la *sélection finale* (avec
> fingerprints + anti-fuite) sont des responsabilités dag-ml. La ligne exacte se fige à l'étape HPO.