Carte des capacités : ce que Kshana fait, fait partiellement et ne fait pas

Kshana est un moteur de preuves de performance et de résilience PNT (positionnement, navigation et synchronisation temporelle), et non une boîte à outils complète de systèmes spatiaux. Il met en avant la synchronisation temporelle et le holdover, son domaine le mieux validé (voir POSITIONING.md). Cette page est la carte honnête du périmètre : pour chaque domaine de capacité qu'un évaluateur d'achat ou de recherche pourrait contrôler, elle indique l'état, ce qui existe réellement dans le code, ce qui manque et où cela se situe dans la feuille de route. L'état est l'un des suivants :

complet : mis en œuvre de bout en bout et validé à un niveau indiqué dans la ligne ;
partiel : un modèle réel mais limité (périmètre explicitement borné ci-dessous) ;
aucun : non modélisé (hors périmètre aujourd'hui).

Ces trois valeurs sont les seules que prend la colonne d'état. Elles notent la maturité de la capacité, qui est un axe différent de la note VALIDATED / MODELLED / PARTNER de VERIFICATION-MATRIX.md : celle-ci note la provenance des preuves, ligne par ligne, et est contrôlée par machine à partir de src/verification.rs.

Rien ici n'est ambitieux : « partiel » ne signifie jamais « presque terminé », cela signifie « autant et pas plus ». Voir aussi VALIDATION.md, INTEGRITY.md, QUANTUM-MODELS.md et le registre de clôture des surévaluations CLAIMS-VS-REALITY.md (chaque surévaluation historique, la façon dont elle a été résolue, et une garde d'intégration continue (CI) qui la maintient résolue).

PNT de base (là où Kshana joue réellement)#

Capacité	État	Ce qui existe	Ce qui manque	Feuille de route
Détermination d'orbite et propagation	partiel	SGP4/SDP4 sans dépendance (SGP4 : Simplified General Perturbations 4 ; SDP4 : Simplified Deep-space Perturbations 4), validé à 4,12 mm par rapport aux 666 vecteurs AIAA (American Institute of Aeronautics and Astronautics) 2006-6753 (position et vitesse, cette dernière à 1 mm/s) ; képlérien analytique + J2 séculaire ; vitesse inertielle exposée et présentée de bout en bout par le scénario `ephemeris` exécutable (`src/ephemeris.rs`, accessible depuis CLI/Python/WASM/MCP (CLI : interface en ligne de commande ; WASM : WebAssembly ; MCP : Model Context Protocol)) : à chaque pas, il émet l'état TEME (true equator, mean equinox) et GCRS (Geocentric Celestial Reference System) (position + vitesse), la position ITRF/ECEF (ITRF : International Terrestrial Reference Frame ; ECEF : Earth-centred, Earth-fixed), la trace au sol du point subsatellite WGS-84 (WGS : World Geodetic System) (lat/lon/alt), et l'azimut/élévation/distance de la station + la vitesse radiale/Doppler (la vitesse radiale de distance concorde avec la vraie dérivée de position, sans bruit de JD (JD : date julienne), à 6e-9 m/s), et par l'export d'éphéméride OEM (Orbit Ephemeris Message) du CCSDS (Consultative Committee for Space Data Systems) qui porte la vitesse (`--export-oem`). Un propagateur numérique (de Cowell) (`src/propagator.rs`) intègre un modèle de forces de gravité zonale configurable, le champ zonal terrestre complet jusqu'au degré 6 (`forces::zonal_accel`, les `J2..J6` publiés d'EGM-96 (EGM : Earth Gravitational Model)), avec un choix de pilote adaptatif, soit doublement de pas RK4 (Runge–Kutta d'ordre quatre), soit la paire imbriquée Dormand–Prince RK5(4) (`integrate_dopri` / `propagate_dopri`, une estimation d'erreur imbriquée à 7 évaluations, moins coûteuse, qui franchit la même barrière de Kepler et concorde avec le chemin RK4 à <1 m sur une orbite J2..J6), calé sur une vérité analytique plus forte qu'une comparaison numérique entre outils : l'orbite non perturbée reproduit la solution képlérienne exacte à variables universelles à mieux que le mètre sur 24 h (une barrière plus serrée que le « par rapport à la référence < 10 m » de l'étape), l'énergie et le moment cinétique se conservent à ~1e-9 en relatif, la régression nodale due à J2 concorde avec le taux séculaire en forme fermée de la théorie au premier ordre, l'accélération zonale est vérifiée comme étant le gradient exact de son propre potentiel (et se réduit à la forme fermée J2 validée sur les 666 vecteurs), et `solve_kepler_checked` renvoie `Err` plutôt qu'une réponse fausse lorsque Newton ne converge pas (par exemple près du périgée, e = 0,999). La gravité de troisième corps (Soleil et Lune) pilotée par l'époque est câblée dans l'intégrateur variable dans le temps (`ForceModel::third_body` / `accel_at`, avec les éphémérides de basse précision du Soleil et de la Lune de Montenbruck & Gill de `src/ephem.rs` : aucun noyau DE/SPK (DE : Development Ephemeris ; SPK : noyau d'éphéméride planétaire) n'est nécessaire) : chaque évaluation du second membre (RHS) échantillonne les positions des perturbateurs à l'époque avancée `epoch_jd_tt + t/86400`, de sorte que le Soleil et la Lune se déplacent sur leurs orbites pendant l'intégration. La perturbation est vérifiée comme le gradient exact de son potentiel perturbateur, s'annule au géocentre et a les ordres de grandeur LEO (orbite terrestre basse) des manuels (~5e-7 m/s² pour le Soleil, ~1.1e-6 m/s² pour la Lune) ; l'éphéméride du Soleil atteint des repères J2000 dérivés à la main (distance au périhélie, déclinaison de solstice ~−23°, mouvement ~1°/jour) et celle de la Lune son enveloppe périgée/apogée, sa distance moyenne de ~384 400 km, sa borne d'inclinaison ≤ 5,3° et son retour de direction au mois sidéral ; et le câblage de l'intégration est prouvé exact au bit près (le terme du second membre égale `third_body_accel` à la position échantillonnée à t = 0 et t = 1 jour), un décalage d'époque d'un quart d'année donnant une trajectoire différente. La pression de rayonnement solaire (SRP) emprunte le même second membre piloté par l'époque (`forces::srp_accel` / `ForceModel::solar_radiation`) : le modèle boulet de canon `ν·P☉·cᵣ·(A/m)·(AU/d)²·d̂` avec un facteur d'éclipse ombre + pénombre `forces::conical_shadow` (ν lisse ∈ [0 1], vérifié comme s'atténuant à travers une pénombre monotone qui s'étend au-delà du cylindre d'ombre), vérifié par rapport à la pression de manuel à 1 UA (UA : unité astronomique) (≈ 4.54e-6 N/m²), l'ordre de grandeur LEO de ~1.36e-7 m/s² qui éloigne du Soleil, la décroissance en inverse du carré (doubler la distance au Soleil la divise par quatre), une accélération exactement nulle dans le cylindre d'ombre, et un déplacement propagé qui varie ~linéairement avec A/m. La traînée atmosphérique est le premier terme dépendant de la vitesse (`forces::drag_accel` / `ForceModel::drag` + le nouveau second membre `accel_rv` / avec passage de la vitesse) : traînée quadratique `−½·ρ(h)·(C_D·A/m)·\|v_rel\|·v_rel` par rapport à l'atmosphère en corotation `v_rel = v − ωₑ ẑ × r`, avec `ρ` la `forces::atmospheric_density` exponentielle par morceaux de Vallado, vérifiée par l'ancrage au niveau de la mer de 1,225 kg/m³, une décroissance LEO strictement monotone avec une hauteur d'échelle physique de ~58 km, l'ordre de grandeur de traînée de ~2e-6 m/s² qui s'oppose à la vitesse relative, et la signature de dissipation (une orbite à 300 km perd de l'énergie spécifique de façon monotone et son demi-grand axe décroît de ~km/jour de façon bornée, alors que l'orbite dans le vide conserve l'énergie). La correction relativiste post-newtonienne (de Schwarzschild) est le second terme dépendant de la vitesse (`forces::relativistic_accel` / `ForceModel::relativity`) : la forme `β = γ = 1` de l'IERS (International Earth Rotation and Reference Systems Service) `a = (μ/c²r³)·{[4μ/r − v²]·r + 4(r·v)·v}`, le principal moteur de l'avance relativiste du périgée, vérifiée par rapport à sa valeur circulaire en forme fermée `3μ²/(c²r³)·r̂` (radiale, vers l'extérieur), son rapport LEO de manuel `≈1.9e-9` au problème à deux corps, la forme à vitesse radiale simplifiée à la main, et la signature conservative (elle perturbe l'orbite mais maintient le demi-grand axe à moins d'un mètre/jour, l'opposé structurel de la traînée). Le terme d'entraînement des référentiels de Lense–Thirring (`forces::lense_thirring_accel` / `ForceModel::lense_thirring`, IERS 2010 §10) est la correction gravitomagnétique au-delà de Schwarzschild : facultatif, inférieur de ~1 à 2 ordres de grandeur à celui-ci en LEO, vérifié comme s'annulant sans rotation de la Terre et comme restant sous l'ordre de grandeur de Schwarzschild. La détermination d'orbite (OD, `src/orbit_determination.rs`) referme la boucle des observations vers un état : un correcteur par lots de Gauss–Newton (`src/batch_ls.rs`) amène un `[r, v]` candidat sur le meilleur ajustement des distances de stations au sol propagées sur l'arc (sub-métrique / mm·s⁻¹ à partir de distances sans bruit ; ~2 m avec un résidu après ajustement au plancher de bruit de 5 m, la signature d'un ajustement des moindres carrés cohérent), avec une variante récursive séquentielle sur le filtre de Kalman sans parfum	Le modèle de forces de Cowell par défaut ne porte que le champ zonal : le champ tesséral EGM2008 (Earth Gravitational Model 2008) de haut degré (`src/gravity_sh.rs`, degré/ordre 70, avec un chargeur `from_gfc` pour les fichiers ICGEM (International Centre for Global Earth Models)) n'est composé que dans le moteur d'ajustement d'éphéméride précise (`src/precise_od.rs` ; voir `AGENCY-ORBIT-VALIDATION.md`) ; la densité de traînée est l'exponentielle par morceaux statique de Vallado (indépendante de l'activité solaire), et non NRLMSISE-00 (le modèle d'atmosphère Naval Research Laboratory Mass Spectrometer and Incoherent Scatter Radar Extended ; la clause de densité thermosphérique < 5 %) ; la SRP est le modèle boulet de canon avec une ombre géométrique conique ombre + pénombre (sans assombrissement centre-bord solaire, sans ombre d'une Terre aplatie, sans forme ni attitude du satellite) ; la relativité couvre les termes de Schwarzschild et de Lense–Thirring (entraînement des référentiels), tous deux facultatifs, mais sans réglage des paramètres PPN (PPN : post-newtonien paramétré) ; le troisième corps et la SRP utilisent les éphémérides de basse précision (~0,005° pour le Soleil, ~0,3° pour la Lune), et non la précision d'un noyau DE/SPK. Les niveaux conservatifs du modèle de forces (deux corps → J2–J6 → Soleil/Lune → SRP) sont VALIDATED par rapport à Orekit 12,2 (pire écart de 0,08 m sur 24 h, `tests/numerical_cowell_propagator_reference.rs`), et la détermination d'orbite par lots/séquentielle est VALIDATED par rapport aux estimateurs d'Orekit 12,2 (`tests/batch_sequential_orbit_determination_reference.rs`) ; le niveau de traînée et la fidélité absolue des entrées d'éphéméride et de densité restent MODELLED ; il n'y a pas de contrôle croisé avec GMAT (General Mission Analysis Tool)	gravité tesséral dans le modèle de Cowell par défaut + traînée NRLMSISE-00 + assombrissement centre-bord solaire + éphéméride de niveau DE + validation croisée GMAT + mesures de vitesse radiale/angles de la détermination d'orbite et STM analytique (matrice de transition d'état) : P2+
Systèmes de temps	partiel	`src/timescales.rs` : API de date julienne (civil↔JD, MJD (date julienne modifiée)), UTC↔TAI (UTC : temps universel coordonné ; TAI : temps atomique international) via la table complète des secondes intercalaires de l'IERS (10→37 s, 1972→2017), TAI→TT (TT : temps terrestre), UT1 (temps universel 1, temps de rotation de la Terre) via DUT1 (le temps de rotation de la Terre moins le temps universel coordonné), et l'angle de rotation de la Terre IAU-2000 (IAU : Union astronomique internationale) (ERA, vérifié bit à bit par rapport au vecteur SOFA (Standards of Fundamental Astronomy) `eraEra00`). L'approximation DUT1≈0 du chemin SGP4 est explicitement documentée au site d'appel `gstime` (une erreur de GMST (temps sidéral moyen de Greenwich) ≤ ~13″, bien à l'intérieur de l'erreur propre du modèle SGP4), et le scénario `ephemeris` accepte des réglages explicites `dut1_s`/`xp_arcsec`/`yp_arcsec` ou une vraie série IERS `finals2000A` intégrée (`eop_finals2000a` / `kshana --eop <file>`, interpolée par le même `EopSeries` que celui qu'utilise `precise_od`), de sorte que la trace au sol est réduite à travers le vrai UT1 et le vrai mouvement du pôle de l'IERS, et pas seulement les scalaires nominaux	Les chemins en orbite terrestre utilisent encore une JD à un seul `f64` (résolution de ~50 µs vers 2020 : c'est ce plancher, et non l'algorithme, qui limite un contrôle croisé par différences finies) ; une JD en deux parties existe (`timescales::TwoPartJd`, utilisée par les chemins radiométriques, CCSDS-TDM, simulateur de segment sol et système solaire, et `src/jd2.rs` `Jd2`) et est propagée à travers SGP4 (`Sgp4::propagate_at(Jd2)`), la prédiction de passages, la géométrie et les conceptions Walker (validée par rapport à SOFA, `tests/jd2_sofa_time_oracle.rs`), et à travers la rotation de la Terre sur le chemin orbital (`jd2::gmst82`, `cio::gcrs_to_itrs_matrix_jd2`, `orbit::Propagator::position_in_frame_jd2`, le `two_part_jd` facultatif du scénario d'éphéméride ; VALIDATED par rapport à ERFA, `tests/jd2_earth_rotation_erfa_oracle.rs`), avec des conversions sans perte entre `Jd2` et `TwoPartJd` ; les chemins en orbite terrestre par défaut conservent la date à un seul `f64` sauf si `two_part_jd` est défini, et l'époque du modèle de forces de Cowell reste volontairement à un seul `f64` (son erreur analytique Soleil/Lune écrase un arrondi de 40 µs) ; l'UTC à seconde élastique d'avant 1972 (1960–1971) est modélisé sur le chemin en deux parties (`jd2`, `timescales::tai_minus_utc_on_date`, VALIDATED par rapport à ERFA, `tests/jd2_pre1972_sofa_oracle.rs`) mais `timescales::tai_minus_utc` à un seul `f64` plafonne encore à 10 s avant 1972 ; un prédicteur d'orientation de la Terre par moindres carrés + autorégressif (`src/eop_ls_ar.rs`, comparé au Bulletin A de l'IERS comme un résultat) peut désormais prolonger une série EOP au-delà de sa dernière ligne (`EopSeries::with_ls_ar_prediction`, facultatif ; `tests/eop_prediction_beyond_table.rs`), de sorte que les arguments de référentiel au-delà de la table suivent la prévision au lieu de plafonner ; la série par défaut plafonne toujours et aucune clé de scénario n'active encore la prédiction	fait (fondation) ; JD en deux parties à travers la rotation de la Terre sur le chemin orbital : fait (facultatif dans le scénario d'éphéméride) ; prédiction EOP au-delà de la table : fait (bibliothèque, facultatif) ; UTC d'avant 1972 sur le chemin en deux parties : fait
Référentiels	complet	`src/frames.rs` : TEME↔ECEF fondé sur le GMST, géodésique WGS-84↔ECEF (exact + inverse itératif, à la précision machine à toutes les altitudes), et un observateur de station au sol géodésique (azimut/élévation/distance) ; précession IAU 2006 (`src/precession.rs` : les angles de Fukushima–Williams `(γ̄, φ̄, ψ̄, ε̄_A)` + la matrice de biais-précession GCRS↔moyen de la date) ; nutation IAU 2000A/2000B + chaîne complète TEME→GCRS (`src/nutation.rs` : la série IAU 2000A complète, 678 termes luni-solaires + 687 termes planétaires, `nutation_iau2000a` / `nutation_matrix_2000a`, table générée par machine à partir de la référence `nut00a` d'ERFA (Essential Routines for Fundamental Astronomy) par `tools/gen_nut00a.py`, à côté de la série 2000B à 77 termes, des arguments de Delaunay, de la matrice de nutation SOFA `iauNumat`, de l'équation des équinoxes, et de `teme_to_gcrs(r, v, jd_tt)` via TEME→TOD→MOD→GCRS (vrai de la date, moyen de la date) ; les deux séries sont vérifiées bit à bit par rapport aux vecteurs de référence SOFA/ERFA `nut00a`/`nut00b`, Δψ/Δε à 1e-13 rad) ; mouvement du pôle de l'IERS PEF→ITRF (pseudo-fixe terrestre vers terrestre) (`teme_to_itrf` / `polar_motion_matrix`, SOFA `iauPom00`, `x_p`/`y_p` fournis par l'appelant, un effet de plusieurs dizaines de mètres au rayon orbital) ; réduction IAU 2006/2000A fondée sur le CIO (CIO : Celestial Intermediate Origin) (`src/cio.rs` : la chaîne GCRS↔CIRS↔ITRS sans équinoxe (CIRS : Celestial Intermediate Reference System ; ITRS : International Terrestrial Reference System), avec le CIP (Celestial Intermediate Pole) `X,Y` issu de la matrice NPB (nutation-précession-biais) 2006/2000A, la série du localisateur du CIO `s` à 66 termes, `gcrs_to_cirs_matrix`, l'angle de rotation de la Terre, et le `gcrs_to_itrs_matrix` complet, vérifiée bit à bit par rapport aux vecteurs SOFA `eraXys06a`/`eraC2ixys`/`eraEra00`). Les transformations de bout en bout sont désormais calées sur un exemple détaillé publié faisant autorité, et pas seulement sur l'autocohérence : par rapport à l'état Vallado AIAA 2006-6753 (2004-04-06, avec ses EOP (paramètres d'orientation de la Terre) de l'IERS ; `tests/frame_reference_vectors.rs`), TEME→PEF concorde à 0,1 mm, TEME→ITRF à 0,6 mm, le GCRS→ITRS complet par le CIO à 4 mm, et ECEF→géodésique reproduit latitude/longitude/altitude de l'exemple 3-3 de Vallado jusqu'au dernier chiffre publié. Toute la chaîne est accessible à l'utilisateur via le scénario `ephemeris` (position ITRF/ECEF + trace au sol du point subsatellite WGS-84 à chaque pas)	La chaîne TEME→GCRS par défaut utilise 2000B (~1 mas, sous sa propre simplification de rotation du référentiel de vitesse) ; le chemin à < 0,1 mas, de la 2000A complète, est disponible via `nutation_matrix_2000a`, et la réduction rigoureuse par le CIO (X, Y, s) est disponible via `src/cio.rs`. Le chemin TEME historique utilise le GMST IAU-1982 (convention SGP4). Le contrôle croisé numérique indépendant ANISE/SPICE (ANISE : Attitude, Navigation, Instrument, Spacecraft, Ephemeris, une boîte à outils de géométrie planétaire en Rust pur ; SPICE : Spacecraft, Planet, Instrument, C-matrix, Events) est livré (`xval/anise-frames/` : `gcrs_to_itrs_matrix` par rapport au GCRF→ITRF93 d'ANISE (GCRF : Geocentric Celestial Reference Frame ; ITRF93 : International Terrestrial Reference Frame 1993) sur huit époques de 2020 à 2023, ≤ 0,86 m au sol, ≤ 3,6 m en orbite GNSS (système mondial de navigation par satellite)) ; c'est un crate autonome en dehors des portes d'intégration continue par défaut. `precession_matrix` et `teme_to_gcrs_matrix` sont aussi contrôlés directement par rapport à ERFA à 40 époques de 1950 à 2100, et la chaîne CIO accepte les décalages du pôle céleste dX, dY de l'IERS (`cio::gcrs_to_cirs_matrix_with_offsets` ; `tests/frames_erfa_vector_oracle.rs`) ; les chemins par défaut négligent encore dX, dY. La matrice de vérification note cette ligne VALIDATED (vecteurs SOFA/ERFA + Vallado)	TEME↔ECEF + géodésique : fait (vérifié par Vallado) ; TEME→GCRS inertiel : fait (2000B + 2000A complet) ; ITRF avec mouvement du pôle : fait (vérifié par Vallado) ; GCRS→ITRS par le CIO : fait (vérifié par Vallado)
Synchronisation temporelle et fréquence	partiel	Horloge de Kalman à deux états à Q de van Loan exacte (NIST (National Institute of Standards and Technology) SP (Special Publication) 1065) avec une mise à jour de covariance stabilisée de Joseph (semi-définie positive sous des rapports Q/R extrêmes, vérifiée par Cholesky en CI) et un moniteur de santé de cohérence du filtre (`src/filter_health.rs`) : une évaluation Monte-Carlo NIS/NEES (NIS : innovation normalisée au carré ; NEES : erreur d'estimation normalisée au carré) par rapport à des bandes de confiance du χ², présentée sous `filter_health` dans le JSON (JavaScript Object Notation) du résultat et dans une carte verte/ambre du bac à sable, avec un test de balayage de désaccord Q/R prouvant que le moniteur bascule sur inconsistent lorsque le réglage est faux (Bar-Shalom §5,4) ; estimateurs ADEV (écart-type d'Allan), MDEV (écart-type d'Allan modifié), TDEV (écart de temps), HDEV (écart d'Hadamard) à recouvrement + intervalles de confiance fondés sur le χ² avec des degrés de liberté effectifs propres à chaque type de bruit (formes fermées du tableau 5 de NIST SP 1065 pour WPM/FPM/WFM/FFM/RWFM (WPM : modulation de phase blanche ; FPM : modulation de phase en scintillation ; WFM : modulation de fréquence blanche ; FFM : modulation de fréquence en scintillation ; RWFM : modulation de fréquence à marche aléatoire), l'ensemble qu'utilise Stable32 ; la courbe ADEV exportée identifie le type de loi de puissance de l'enregistrement à partir de sa pente MDEV et joint une bande à 95 % par τ, `src/allan.rs`), validés numériquement par rapport aux écarts de référence de Stable32 pour le jeu de données canonique NBS14 à 1e-4 près (`tests/allan_reference.rs`) et l'edf recoupé par un ensemble Monte-Carlo de FM (modulation de fréquence) blanche ; mesure de mérite de holdover honnêtement bornée par la grille ; ensembles d'horloges ; modèle de transfert de temps bidirectionnel avec annulation du retard réciproque + un plancher de retard différentiel non réciproque à marche aléatoire de FM (`src/timetransfer.rs`, signature d'Allan rapportée) ; un calculateur de holdover d'horloge en environnement sans GNSS (`src/holdover.rs`) exposant la croissance de l'erreur en roue libre de van Loan en forme fermée `σ_x²(t) = q_wf·t + q_rw·t³/3 + q_drift·t⁵/20` sous forme d'une inversion holdover jusqu'au seuil orientée utilisateur (combien de temps une horloge dérive librement avant que son erreur de temps ne dépasse le budget), avec des classes représentatives d'horloges quantiques (réseau optique/ion piégé/ion mercure) : modélisé, non validé en externe : recoupé avec la récurrence de covariance multi-pas `clock_state`, et indiqué honnêtement que, pour une horloge très stable, le holdover jusqu'à un seuil serré est *gouverné par le plancher de bruit rouge à long tau supposé, et non par l'ADEV cité* (utilisez des planchers mesurés pour obtenir un nombre défendable). Un niveau de protection temporel conditionnel (`src/tpl.rs`) s'appuie sur la même mécanique de holdover pour le cas du leurrage : une borne sur l'erreur de temps non détectée étant donné un contrôle croisé indépendant, soit un plancher de moniteur à k σ plus la variance de van Loan en roue libre sur la latence de détection plus un délai d'alarme CUSUM (somme cumulée), étalonnée sur un vrai leurrage enregistré (JammerTest 2024, Zenodo 15911589) et reproductible via `cargo run --example tpl_jammertest`. Composition modélisée, conditionnelle à la détection : il n'existe aucune borne inconditionnelle finie (une rampe assez lente échappe à un moniteur unique assisté par l'horloge). L'erreur maximale d'intervalle de temps (MTIE) et le TDEV sont VALIDATED par rapport à `allantools` (`tests/mtie_reference.rs`, `tests/mdev_tdev_reference.rs`), et l'inversion de la variance en roue libre du holdover est VALIDATED par rapport à SciPy (`tests/gnss_denied_clock_holdover_reference.rs`) ; le type `telecom-timing` les applique aux gabarits ITU-T (Union internationale des télécommunications, secteur de la normalisation des télécommunications) G.8272 / G.8272.1 / G.8273.2 / G.8271.1, voir `TELECOM-TIMING.md`	edf complet par l'algorithme de Greenhall (les formes fermées simples sont bornées en biais mais plus grossières que le BasicSum exact), et identification de mélanges de plusieurs bruits	edf exact + identification de bruits mélangés : P2
Traitement GNSS / PNT	partiel	Une simulation de pseudodistances dans le domaine des mesures (type `gnss-sim`, `src/gnss_sim.rs`) : pour chaque satellite visible, elle synthétise `ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath` et le Doppler L1, avec l'ionosphère monofréquence de Klobuchar (IS-GPS-200 (IS : spécification d'interface ; GPS : Global Positioning System) §20.3.3.5.2.5) et la troposphère zénithale de Saastamoinen (Davis 1985) projetées par la fonction de projection de Niell (1996), chaque modèle étant testé unitairement par rapport à un calcul à la main, puis transmet les résidus au RAIM instantané (surveillance autonome de l'intégrité par le récepteur) pour obtenir HPL/VPL à chaque époque (HPL : niveau de protection horizontal ; VPL : niveau de protection vertical) et émet un tableau `gnss_measurements[]` (pseudodistance, Doppler, C/N₀, corrections iono/tropo par SV (véhicule spatial, c'est-à-dire un satellite)). Plus DOP/disponibilité (DOP : dilution de précision) et RAIM à séparation de solutions à partir des orbites ; ingestion NAV multi-GNSS RINEX (Receiver Independent Exchange Format) 3 (GPS/Galileo/QZSS/BeiDou (QZSS : système japonais Quasi-Zenith Satellite System) via IS-GPS-200, vecteur d'état GLONASS (système russe Global Navigation Satellite System)) analysée → position ECEF et biais d'horloge du SV, utilisable comme source `Propagator` de premier rang ET comme bloc `rinex` de constellation en ligne (`scenarios/orbit-rinex.toml`) ; ingestion des OBSERVATIONS RINEX 3 (le format d'observation 4,00 devrait être analysé mais aucun fichier 4,00 n'a été éprouvé ; les fichiers de NAVIGATION RINEX 4 sont refusés par leur nom plutôt que mal décodés) ; un solveur de positionnement par point unique (type `pvt`, `src/pvt.rs`) qui transforme de vraies pseudodistances de code RINEX + éphéméride diffusée en une position de récepteur par moindres carrés pondérés itérés : correction de Sagnac/rotation de la Terre, horloge de satellite diffusée avec `−TGD`, combinaison sans ionosphère bifréquence L1/L2 (ou Klobuchar monofréquence), troposphère de Saastamoinen/Niell, pondération par l'élévation, DOP, et RAIM instantané, validé sur de vraies données IGS (International GNSS Service) (station ABMF, Guadeloupe, 2018-05-13) à 5,7 m en RMS (racine de la moyenne des carrés) 3-D / 1,1 m en horizontal par rapport à la coordonnée relevée de la station (`tests/pvt_abmf.rs`, `scenarios/pvt-abmf.toml`) ; et lecture/écriture d'orbites précises SP3 (Standard Product 3, le format d'orbite précise)	Un moteur de positionnement par code plus, depuis 0,36, un traitement de la phase de la porteuse sur de vraies observations : le solveur `pvt` calcule une vraie position à partir de vraies mesures de code (positionnement par point unique, au niveau du mètre, avec la combinaison sans ionosphère bifréquence) ; `rtk_real::run_rtk` réalise du RTK à courte ligne de base sur de vrais code et phase GPS bifréquence (doubles différences, filtre de Kalman flottant, fixation de l'ambiguïté entière par LAMBDA avec test du rapport, `src/lambda.rs`), et un filtre PPP statique flottant s'exécute sur de vrais code et phase avec les orbites et horloges finales de l'IGS. Les deux sont VALIDATED par rapport aux coordonnées ITRF2020 publiées de stations IGS (WTZR/WTZZ, `tests/rtk_real_wettzell_oracle.rs`, `tests/ppp_real_wettzell_oracle.rs`, seuils fixés à l'avance) ; ce qui reste absent, c'est la résolution de l'ambiguïté entière en PPP, le RTK cinématique ou en réseau et le fonctionnement en temps réel. Le lissage de porteuse de Hatch est un résultat MODELLED figé (ses seuils fixés à l'avance n'ont pas été atteints). Le type `leo-ppp` exécute un filtre PPP flottant sur des mesures qu'il simule, pour des études de convergence ; le paquet direct `gnss-sim` reste un simulateur à partir de la vérité ; BeiDou-GEO (GEO : orbite géostationnaire) exclu	fixation d'ambiguïtés PPP, RTK cinématique ou en réseau, fonctionnement en temps réel : utilisez RTKLIB/gLAB (RTKLIB : une bibliothèque libre de positionnement cinématique en temps réel)
Fusion de capteurs / navigation à l'estime INS (système de navigation inertielle)	complet	Bibliothèque à composants liés 3 axes (`src/inertial/{attitude,mechanization,imu_errors}.rs`) : attitude par quaternions avec compensation du coning/sculling, mécanisation NED (nord-est-bas) complète (vitesse de rotation de la Terre + vitesse de transport, gravité de Somigliana WGS-84), et un modèle déterministe d'erreurs d'IMU (unité de mesure inertielle) (facteur d'échelle, désalignement, sensibilité à g, quantification, rampe de vitesse modélisés). Le navigateur à composants liés est désormais branché dans un paquet GNSS/INS à couplage lâche exécutable avec une mesure de mérite (`src/fusion/pack.rs`, `kind = "gnss-ins"`) : la mécanisation à trois axes est asservie par l'EKF (filtre de Kalman étendu) à état d'erreur à 15 états (`src/fusion/{gnss_ins_ekf,closed_loop}.rs`, rétroaction de position/vitesse/attitude/biais) tant que le GNSS est disponible, puis poursuit en roue libre pendant la coupure, ce qui remplace la remise à la vérité par une vraie fusion, et rapporte l'erreur horizontale fusionnée par rapport à l'INS libre en boucle ouverte. Le paquet `inertial` historique distinct exécute toujours le budget scalaire à 1 DOF (DOF : degré de liberté) avec remise à la vérité. Une mise à jour à couplage serré sur les pseudodistances (`update_tightly_coupled` / `fuse_tightly_coupled`) est aussi mise en œuvre : elle forme l'innovation dans le domaine des distances (jacobienne de la ligne de visée sur δp) et continue de corriger avec moins de quatre satellites, là où une solution PVT (position, vitesse et temps) à couplage lâche n'existe pas. Un UKF GNSS/INS à couplage serré complet à 17 états (filtre de Kalman sans parfum) (`src/fusion/tightly_coupled17.rs`) porte la position, la vitesse, l'erreur d'attitude, les biais d'accéléromètre et de gyromètre, et l'horloge du récepteur (biais + dérive), avec une navigation à l'estime quantique CAI (CAI : interféromètre à atomes froids) : le bruit de processus de marche aléatoire de vitesse est le `q_va` dérivé de l'accéléromètre à atomes froids, qui poursuit en roue libre pendant une coupure de 120 secondes bornée à quelques centaines de mètres (contre les kilomètres d'un INS libre de qualité navigation). Cet UKF à 17 états est désormais présenté comme un scénario exécutable (`src/fusion/hybrid_ukf.rs`, `kind = "hybrid-ukf"`, accessible depuis CLI/Python/WASM/MCP) : les 15 états d'erreur de l'INS sont augmentés de la correction de biais d'accéléromètre dérivée du CAI (l'interféromètre à atomes froids fixe le plancher de marche aléatoire de vitesse `q_va`) et d'une horloge à 2 états phase + fréquence dont le bruit de processus provient du moteur d'horloge à paramètres q (`clock_state::q_from_allan`, profil d'Allan → `q_wf`/`q_rw`), piloté par le modèle d'erreur CAI encadré afin que l'exécution démontre l'hybridation entre le court terme d'une IMU classique et le long terme quantique. Sa mesure de mérite est l'autocohérence du filtre : NEES + blancheur de l'innovation (NIS) regroupées sur un ensemble Monte-Carlo par rapport à leurs bandes du χ² à 95 % (le filtre adapté tombe dans les bandes ; un filtre mal réglé est signalé, un critère objectivement vérifiable). Il s'agit d'un énoncé d'AUTOCOHÉRENCE sous le bruit modélisé, PAS d'une garantie de précision en conditions réelles : les entrées CAI/horloge sont encadrées/modélisées, le matériel CAI appartient au partenaire, et rien ici n'implique un TRL (niveau de maturité technologique)>3, un héritage de vol ou une validation externe. Le modèle déterministe d'erreurs d'IMU est configurable par capteur depuis le fichier de scénario TOML (Tom's Obvious Minimal Language) `gnss-ins` (`[imu_*.error_model]` : facteur d'échelle, désalignement, sensibilité à g, quantification, rampe de vitesse), avec par défaut une source à biais constant pur lorsqu'il est omis	Le couplage serré se fait sur les seules pseudodistances (la phase de la porteuse est dans la feuille de route) ; le scénario `hybrid-ukf` utilise une trajectoire unique à vitesse constante, de niveau, sur laquelle les états d'erreur d'attitude et de biais d'IMU ne sont que faiblement observables, de sorte que la cohérence NEES est évaluée sur le sous-ensemble estimable (position, vitesse, horloge = 8 états) ; l'observabilité complète des 17 états exige une trajectoire à manœuvres (feuille de route) ; la paire biais d'accéléromètre/inclinaison à couplage lâche est faiblement séparable, de sorte qu'un étalonnage par biais n'est pas revendiqué ; le modèle d'erreurs d'IMU omet la rectification des vibrations et la dérive due aux gradients de température ; l'UKF à 17 états et les chemins à couplage serré sont auto-validés (intégration analytique à vitesse constante, convergence de l'aide GNSS, récupération des biais, borne de coupure de 120 s limitée par le CAI, et critère de cohérence χ² NEES/NIS), et la mécanisation à composants liés elle-même est VALIDATED par rapport à NaveGo v1.4 (`tests/classical_strapdown_ins_reference.rs` : attitude identique bit à bit, vitesse/position à l'intérieur de bornes analytiques nommées), mais aucune validation croisée au niveau du filtre (NaveGo ou le jeu de données de véhicule KF-GINS) n'a été effectuée	couplage serré sur la phase de la porteuse, observabilité complète des 17 états en trajectoire à manœuvres, bibliothèque de trajectoires, validation croisée au niveau du filtre avec NaveGo/KF-GINS : P2
Intégrité / RAIM / ARAIM (surveillance autonome avancée de l'intégrité par le récepteur)	partiel	Vrai RAIM instantané dans `src/raim.rs` : solution des moindres carrés + détection de fautes par le χ² des résidus (seuil exact issu d'un χ² à gamma incomplète sans dépendance) et HPL/VPL fondés sur la pente (pbias issu d'un χ² non centré pour les P_fa/P_md configurés) ; RAIM à séparation de solutions (MHSS) avec détection/identification de fautes ; budget de risque d'intégrité ARAIM (P_HMI) (`araim_raim`) qui résout le plus petit HPL/VPL dont la somme `P_HMI = Σ_k p_fault,k·Q((PL−T_k)/σ_k)` respecte une allocation explicite de risque d'intégrité, le mode de faute à l'échelle de la constellation, bi-/multi-constellation (`araim_dual_raim`, ARAIM TN (note technique) de l'UE (Union européenne) / DO-316 ; `P_const = 0` ⇒ `araim_raim` identique bit à bit), un message de support d'intégrité explicite (`IntegritySupportMessage` : σ_URA/σ_URE/b_nom/P_sat/P_const, avec les valeurs de référence GPS+Galileo du WG-C (WG : groupe de travail)), plus un diagramme d'intégrité de Stanford(-ESA, l'Agence spatiale européenne) (le type de scénario `integrity`, et un moteur de rendu autonome `stanford_svg` des quatre zones + de la frontière `PL=error`). Documenté de bout en bout dans `ARAIM_REFERENCE.md`. Plus l'autocohérence du filtre de la mesure de mérite du scénario (borne à k σ)	Le RAIM est accessible via le type de scénario `integrity` et (0,36, facultatif) à côté de la mesure de mérite d'horloge/holdover comme bloc `integrity_fom` distinct (`[integrity]` : RAIM instantané sur un ciel prédéfini depuis un site indiqué, indisponible tant que le GNSS est refusé ; MODELLED), jamais fondu dans la mesure de mérite du holdover, qui rapporte toujours l'autocohérence ; le RAIM instantané comporte la FDE mono-satellite (détection et exclusion de fautes, `raim::snapshot_raim_fde`, VALIDATED par rapport à RTKLIB `raim_fde` dans `tests/integrity_snapshot_raim_rtklib_oracle.rs`) ; la séparation de solutions à hypothèses multiples ARAIM ADD v4.2 avec détermination de sous-ensembles multi-satellites se trouve dans `src/araim_reference.rs` (VALIDATED par rapport à Stanford MAAST, `tests/integrity_araim_stanford_oracle.rs`), mais le budget `raim::araim_raim` à sigma uniforme ne couvre toujours que les fautes à un seul SV et à l'échelle de la constellation et n'est pas conforme à l'ADD (0,36, facultatif : fautes simultanées de sous-ensembles multi-SV par la règle de sous-ensemble ADD v4.2 généralisée au-delà des paires, `araim_subset_raim`, `add_v42_protection_levels_to_order` ; MODELLED, aucune exécution MAAST au-delà des paires), et l'exclusion multi-SV n'est pas modélisée ; et `araim_dual_raim` est branché dans l'exécuteur de scénarios TOML via l'option `araim_dual` (`scenarios/araim-gps-galileo.toml`), avec un chemin de disponibilité par époque `araim_dual_constellation_availability` ; les cœurs instantané/MHSS/ARAIM sont exercés sur la vraie géométrie d'orbites précises IGS (SP3) (`tests/igs_real_data.rs`) et sur de vrais TLE GPS+Galileo de Celestrak (`tests/araim_dual_real_data.rs`, chaque satellite propagé à une même époque UTC commune, la dernière époque de TLE (jeu d'éléments à deux lignes) du jeu, 2026-06-07T07:21:04, pour un utilisateur à 400 km d'altitude incliné de 45° sur 24 h : la disponibilité sous une VAL (limite d'alerte verticale) de 12 m / une HAL (limite d'alerte horizontale) de 10 m est de 0,993 en GPS seul, de 1,000 en GPS+Galileo regroupés, et de 0,990 dans le mode double robuste aux fautes de constellation ; le chiffre publié précédemment ici, 0,21→0,67 avec le mode robuste « limité », provenait de la propagation de chaque satellite depuis sa propre époque de TLE, un ciel qui n'a jamais existé, et est retiré) ; la comparaison antérieure avec le « tableau A-3 d'EU-ARAIM-TN » est retirée (aucune source publique), et une reproduction des entrées d'URA maximale de l'étape 3 de l'ARAIM du WG-C UE-États-Unis publiée (tableaux 5 à 7, lignes Depleted et Baseline) est tentée dans `xval/araim-m3/` avec des écarts déclarés (MODELLED, voir INTEGRITY.md) ; pas certifié DO-229/ARAIM	ARAIM multi-fautes (ADD v4.2) : fait ; sous-ensembles multi-SV dans `raim` + parité gLAB dans le domaine du récepteur + branchement de la mesure de mérite : P2 (voir `INTEGRITY.md`)
Modélisation des menaces de leurrage / brouillage	partiel	Un détecteur stochastique de leurrage temporel (type `spoof`, `src/spoof.rs` + `src/detection.rs`) : quatre formes d'injection (rampe linéaire, saut en échelon, meaconing, rejeu) face à un moniteur assisté par l'horloge avec un test d'énergie χ²₁ / de Neyman–Pearson bilatéral, le seuil de détection étant fixé à partir d'un budget cible de fausses alarmes `P_fa`, et la probabilité de non-détection `P_md` rapportée à la fois en forme fermée et par Monte-Carlo (les deux concordent à quelques ×1/√N près) ; la mesure de mérite de sécurité est `1 − P_md`. Plus un modèle de brouillage par bilan de liaison (type `jamming`, `src/jamming.rs`) : rapport brouilleur sur signal à partir de la géométrie (affaiblissement en espace libre + gain de l'antenne de réception selon la direction), l'équation standard du C/N₀ effectif anti-brouillage (gain de traitement de désétalement + facteur de séparation spectrale `Q` ; Kaplan & Hegarty §9,4), la perte d'accrochage par satellite à un seuil de poursuite configurable, et une mesure de mérite `availability_under_jamming` sur une constellation Walker. Plus une suite de moniteurs de leurrage multicouche RF/mesures (RF : radiofréquence) (`src/spoof_monitors.rs`) : un test de parité de cohérence RAIM multi-satellites (`parity_raim_test`, SOS (somme des carrés) pondérée des résidus par rapport à un seuil χ²(m−4), et il signale correctement qu'un biais de mode commun est invisible au RAIM), un moniteur AGC (commande automatique de gain) (`AgcMonitor`, excès de puissance reçue au-dessus du plancher attendu), un moniteur de qualité de signal / SQM (surveillance de la qualité du signal) (`SqmMonitor`, déséquilibre des corrélateurs Early/Late), et un combineur de fusion des couches (`fuse_spoof_layers`). Ils se composent en un `CombinedSpoofDetector` intégré dont `evaluate` ingère une époque d'observables (géométrie + résidus, puissance AGC, prises Early/Late) et exécute les trois couches par la fusion pondérée en un seul appel, en renvoyant les diagnostics par couche ; il est exposé comme scénario `spoof-detect` exécutable (`src/spoof_detect.rs`, accessible depuis la CLI / Python / le bac à sable, JSON + SVG (Scalable Vector Graphics)) et caractérisé par rapport aux paramètres publiés des scénarios TEXBAT (Texas Spoofing Test Battery) (Humphreys et al., ION (Institute of Navigation) GNSS 2012 ; `tests/spoof_texbat_validation.rs`), en reproduisant le schéma de détectabilité documenté, y compris les résultats négatifs : ds2 surpuissant détecté par AGC + SQM, ds3 à puissance égale par SQM seul, ds4 à poussée de position par RAIM, et ds7 à puissance égale aligné en phase de porteuse laissé (à juste titre) au détecteur assisté par l'horloge	Le type `jamming` est un bilan de liaison : il n'a ni trajets multiples ni dynamique d'AGC dans le temps. Depuis 0,36, il accepte quatre sections facultatives : `[crpa]`, un faisceau de réseau adaptatif par canal (annulation de lobe ou MVDR issu de `src/crpa.rs`, vérifié par un recalcul numpy indépendant ; MODELLED), et `[terrain]`, la perte par diffraction unique en lame de couteau du trajet du brouilleur au-dessus d'une tuile SRTM (`src/jamming_terrain.rs`, ITU-R P.526-15 §4,1, vérifiée par un recalcul numpy indépendant sur une vraie tuile ; MODELLED, une seule lame de couteau), `[acquisition]`, l'hystérésis acquisition contre poursuite, et `[front_end]`, la lecture d'AGC stabilisée et la perte du quantificateur du CAN pour une entrée gaussienne (`src/jamming_rx.rs` ; signalée comme non valable pour les brouilleurs non gaussiens ; MODELLED). Les trajets multiples spéculaires, l'évanouissement terrestre mobile et l'AGC existent dans la couche IQ (`src/iq/channel/multipath.rs`, `src/iq/channel/land_mobile.rs`, `src/iq/frontend/agc.rs`) et ne sont pas branchés dans le type `jamming` ; la table `Q` de séparation spectrale contient les valeurs de manuel par type (CW et bande étroite 1, large bande et balayé 2 depuis 0,36), calée sur les coefficients dérivés des densités spectrales de puissance (DSP) de `navsignal` (voir la ligne du signal de navigation). Le détecteur de leurrage assisté par l'horloge est à horloge unique ; les moniteurs RF/mesures sont désormais intégrés (`CombinedSpoofDetector`) et *caractérisés par rapport aux paramètres* publiés des scénarios TEXBAT (Humphreys et al.) ; le résiduel est la validation par rapport aux vecteurs bruts** : échantillons IQ (en phase/en quadrature) de TEXBAT (qui exigent un frontal d'acquisition/poursuite SDR (radio logicielle) que kshana n'a pas, étant un simulateur et non un récepteur) ou un scénario Spirent sous licence, une suite documentée	détecteur combiné assisté par l'horloge + cohérence RAIM multi-SV intégrée + AGC + SQM + caractérisation par les paramètres TEXBAT : fait ; validation sur vecteurs bruts (TEXBAT IQ / Spirent sous licence) : suite
Modulation du signal de navigation et performance de poursuite de code	partiel	`src/navsignal.rs` : le niveau du signal entre le bilan de liaison et le domaine des mesures. Densités spectrales de puissance d'aire unité pour BPSK-R(n) (modulation par déplacement de phase binaire, chips rectangulaires) et sine-BOC(m,n) (porteuse à décalage binaire) (vérifiées en CI à l'aire unité, à la forme fermée du coefficient d'auto-séparation spectrale (SSC) du BPSK `κ = 2/(3R_c)`, et à la répartition spectrale du BOC : nulle à la porteuse, pics à ±f_s) ; le coefficient de séparation spectrale `κ = ∫ G_s(f)G_i(f) df`, qui dérive désormais le `Q` anti-brouillage utilisé par `jamming` à partir des spectres réels du signal et du brouilleur (`Q = 1/(R_c·κ)`) au lieu d'une constante représentative (la référence à large bande est recoupée en CI) ; la largeur de bande RMS (de Gabor) (BOC > BPSK : la mesure de l'information de mesure de distance / de Cramér–Rao) ; la gigue de bruit thermique de la poursuite de code par DLL (boucle à verrouillage de délai) cohérente early–late (Kaplan & Hegarty §8 : ~sub-métrique pour le C/A à 45 dB-Hz, monotone en C/N₀) ; et l'enveloppe d'erreur de trajets multiples (EML (early-minus-late) cohérent, trouvée en localisant le zéro du discriminateur composite : suppression du corrélateur étroit vérifiée). Une couche de compromis de conception des codes de télémétrie (`CodeFamily`) ajoute le lobe secondaire d'autocorrélation périodique des séquences m/Gold (`1/L` pour une séquence m) et la borne d'intercorrélation de Gold `t(n)/L` à trois valeurs, en reproduisant l'intercorrélation de Gold publiée du GPS C/A de −23,9 dB (un repère externe) et le nombre de séquences m `φ(2ⁿ−1)/n`, plus l'inversion longueur de code↔distance non ambiguë ; les garanties de Gold renvoient honnêtement None là où il n'existe aucune paire préférée (`n mod 4 = 0`), plutôt que de rapporter une borne qui ne tient pas.	Depuis 0.31.0, la couche IQ distincte (`src/iq/`, les commandes `kshana iq` ; conception dans `design/GNSS-IQ-PLAN.md`) ajoute une chaîne de récepteur logiciel : acquisition par FFT (transformée de Fourier rapide), un banc de poursuite multicanal DLL/PLL/FLL (boucles à verrouillage de délai, de phase et de fréquence), filtrage de frontal et quantification de 1 à 14 bits, et lecture en continu de jeux de données enregistrés. Un récepteur logiciel indépendant retrouve la vérité injectée de ses scènes, et les codes GPS L1 C/A et les bits LNAV (message de navigation historique) sont identiques bit à bit à gps-sdr-sim. Il manque encore : les discriminateurs de boucle supposent le triangle de corrélation BPSK idéal, il n'y a donc pas de levée de l'ambiguïté de poursuite du BOC ; les modèles de canal et de boucle sont MODELLED, contrôlés par rapport à des formes fermées et à la vérité injectée, et non par rapport à de l'IQ de terrain mesuré ; boucles scalaires uniquement (pas de poursuite vectorielle). La conception du matériel d'antenne/de charge utile RF (diagrammes de rayonnement, frontal) est délibérément hors périmètre : c'est le rôle d'un partenaire de charge utile.	ambiguïté BOC + validation de la couche IQ sur de l'IQ de terrain : P2+
Physique des capteurs PNT quantiques	partiel	La plupart des capteurs sont des coefficients d'Allan/de budget de bruit publiés (CSAC, optique), plus un accéléromètre à interféromètre à atomes froids (CAI) de premiers principes dans `src/inertial/quantum_imu.rs` : la phase de Mach–Zehnder à trois impulsions `Φ = k_eff·a·T²`, le bruit de projection quantique (de grenaille) `σ_Φ = 1/(C√N)`, la DSP de marche aléatoire de vitesse dérivée `q_va` que consomme la pile inertielle, la décroissance du contraste, la fonction de transfert aux vibrations `\|H(ω)\|` + variance à DSP blanche, et désormais les systématiques de Coriolis/rotation (`coriolis_phase`, biais équivalent `2Ω×v`) et de déplacement lumineux AC-Stark (AC : courant alternatif) (`ac_stark_phase`, annulation symétrique) + un balayage de dérive du temps de cycle (`cai_drift_sweep`), et un budget d'erreur composé de navigation à l'estime quantique-inertielle (`QuantumNavBudget`) qui réunit la marche aléatoire de vitesse à bruit blanc du CAI avec le biais résiduel (`½·b·t²`, recoupé avec l'intégrateur d'Euler indépendant `AccelModel`), l'erreur de facteur d'échelle et une dégradation facultative de stabilité à long terme (distincte de la décohérence par tir) en une seule valeur de dérive de position sur le holdover plus un holdover inertiel jusqu'au seuil, le jumeau en navigation à l'estime du holdover d'horloge. Le plancher quantique modélisé est encadré (et non apparié à la parité) par rapport aux 96 nm/s²/√Hz du gravimètre mobile de Freier et al. 2016 (arXiv:1512,05660) : il se situe en dessous et à moins de ~2 ordres de grandeur. Documenté dans `QUANTUM.md`	Systématiques de front d'onde et de pointage du faisceau non modélisées ; la limite d'ambiguïté de frange de Mach–Zehnder est modélisée (`max_unambiguous_accel`, `dynamic_range_cells` dans `src/inertial/quantum_imu.rs`), mais la levée de l'ambiguïté ne l'est pas ; les budgets exacts d'essais en vol CARIOQA-PMP (CARIOQA : Cold Atom Rubidium Interferometer in Orbit for Quantum Accelerometry) / Boeing-AOSense (qui exigent des DSP de plateforme publiées + un SNR (rapport signal sur bruit) par tir) et un préréglage JS (JavaScript) du bac à sable restent à faire	systématiques de front d'onde + reproduction d'essais en vol : P2+ (`QUANTUM-MODELS.md`)
Conception de constellation	partiel	Walker synthétique (à la fois képlérien analytique et éléments moyens SGP4, ce dernier propagé par le cœur validé à 4,12 mm : `src/walker.rs`) + visibilité et DOP multi-constellation à partir de vrais TLE (GPS+Galileo à 100 %), validés par rapport à un vrai instantané Celestrak gps-ops (`tests/igs_real_data.rs`) ; un balayage de conception du PDOP (dilution de précision de position) sur la grille `{planes × sats × inclination}` et des mesures de mérite de fraction de couverture / temps de revisite ; le type `constellation-design` exécutable (motifs Walker delta et star dans la convention i : T/P/F, listes d'éléments explicites, conceptions multi-coques et préréglages publiés, autour de la Terre, de la Lune, de Mars ou de tout autre corps catalogué) dont la géométrie Walker et les créneaux publiés de GPS, Galileo et GLONASS sont VALIDATED par rapport aux tableaux publiés et dont la dilution de précision GPS de référence mondiale est VALIDATED par rapport à la norme de performance du service de positionnement standard GPS, tandis que les cartes de couverture pour des conceptions arbitraires restent MODELLED ; un optimiseur de conception sans gradient (`optimize_walker_design`) qui explore la grille pour trouver la meilleure conception selon un objectif choisi (`MinSatellitesForCoverage` / `MaxCoverage` / `MinWorstPdop`), validé pour renvoyer le vainqueur par force brute ; et la géométrie analytique des rues de couverture (`coverage_half_angle_rad`, `street_half_width_rad` ; formes fermées de Rider/Beste, vérifiées à la main : GPS avec un masque de 5° : λ ≈ 71,2°, demi-largeur de rue à 4 satellites ≈ 62,8°)	Un dimensionnement idéalisé en nombre minimal de satellites par rues de couverture existe (`walker::StreetsCoverageDesign`) ; la correction de Rider exacte à la couture, à la frontière de plans en contre-rotation, n'est pas mise en œuvre ; le bac à sable dessine une vue 3-D d'orbites sans dépendance (`web/studio/lib/orbit3d.mjs`), et un export CZML (Cesium Language), `--export czml`, charge la géométrie dans le globe CesiumJS ; le noyau DOP est VALIDATED par rapport à gnss_lib_py (`tests/dop_reference.rs`), et la chaîne complète de visibilité multi-constellation est recoupée de bout en bout par rapport à Orekit 12,2 + gnss_lib_py (`tests/coverage_dop_full_oracle.rs`) : les conceptions terrestres concordent sur chaque seuil, mais les conceptions lunaires et martiennes manquent le seuil DOP sur une géométrie numériquement singulière, de sorte que la ligne reste MODELLED ; « haut » géodésique contre géocentrique dans le référentiel du DOP	dimensionnement par rues de couverture + vue d'orbites 3-D + contrôle croisé terrestre de bout en bout : fait ; correction de Rider exacte à la couture + DOP mal conditionné hors de la Terre : P2
Vérification et validation	partiel	Contrôles par référence externe sur tout le moteur (SGP4 par rapport à 666 vecteurs AIAA, la famille d'Allan par rapport à Stable32 et allantools, les référentiels par rapport à SOFA/ERFA, le modèle de forces et la détermination d'orbite par rapport à Orekit, l'ARAIM par rapport à l'exemple détaillé du WG-C, et d'autres ; le décompte à jour figure dans l'en-tête généré de `VERIFICATION-MATRIX.md`) ; contrôles d'Allan déterministes ; une matrice de vérification contrôlée par machine (`src/verification.rs`), un référencement croisé exigence→module→test→référence→état dont les invariants d'honnêteté sont testés unitairement : une ligne ne peut être libellée validée que si elle porte une référence externe indépendante (valeur NIST/AIAA/SOFA/IGS/publiée), de sorte qu'un contrôle interne d'autocohérence ne puisse pas se faire passer pour une validation ; produit du Markdown/CSV (valeurs séparées par des virgules) pour un référencement croisé de vérification ECSS-E-ST-10-02 (ECSS : European Cooperation for Space Standardization), et consigne comme tels les quatre manques matériels/PA (PA : assurance produit) relevant du partenaire	Les ensembles d'étalonnage couvrent pour l'instant trois contrôles à graine unique (`CALIBRATION-ENSEMBLES.md`, fixés à l'avance : l'intervalle bootstrap Monte Carlo couvre pour 96 % de 200 graines ; une tolérance de percentile est fragile selon la graine, NOT MET à 91,5 %) ; les autres lignes sont encore étalonnées sur des graines uniques. La matrice impose la classification des lignes, et la CI vérifie désormais aussi que chaque test, fichier et élément du crate qu'une ligne cite existe (`tests/verification_rows_name_a_test_that_exists.rs`, `tests/verification_rows_cite_evidence_that_exists.rs`) et que les chiffres publiés se reproduisent encore (`tests/published_figures_still_reproduce.rs`) ; elle ne note pas la référence elle-même, qu'un relecteur lit encore	ensembles d'étalonnage : P1
LEO-PNT (positionnement, navigation et synchronisation temporelle depuis l'orbite terrestre basse)	partiel	Sept types, indépendants du système, avec des préréglages publics nommés : `leo-signal` (conceptions de signaux de toute bande et structure : composantes BPSK, BOC, MBOC (BOC multiplexé) ou plates de type OFDM (multiplexage par répartition orthogonale de la fréquence), poursuite de code, acquisition, compatibilité GNSS, compromis de bande), `leo-pass` (un passage conçu, par éléments, TLE ou Walker, avec un bilan de liaison par bande : pluie, scintillation et perte d'entrée dans les bâtiments de l'ITU-R (Secteur des radiocommunications de l'Union internationale des télécommunications), ionosphère, antenne, Doppler, par rapport aux satellites GNSS MEO (orbite terrestre moyenne) en vue), `leo-navmsg` (éphéméride et horloge diffusées sur la base képlérienne de l'ICD (document de contrôle d'interface) Galileo ou sur des modèles LEO sélectionnables, ajustés et codés avec un contrôle de trame CRC-24Q (contrôle de redondance cyclique sur 24 bits)), `leo-pvt` (positionnement fusionné MEO + LEO par pseudodistance et Doppler sur n'importe quelles constellations), `leo-ppp` (convergence du PPP avec et sans augmentation LEO, sur des mesures simulées), `ntn-positioning` (bornes de positionnement 5G NTN, réseau non terrestre, à partir de la largeur de bande du signal), et `leo-pnt-chain` (un système de bout en bout, la sortie de chaque étage étant transmise au suivant). Éléments VALIDATED : les termes de liaison de l'ITU-R par rapport aux tableaux et aux exemples de validation des Recommandations, le Doppler maximal par rapport à un tableau publié, l'algorithme utilisateur Galileo par rapport à RTKLIB à 1 mm près, le CRC-24Q, les poids du SISRE (erreur de distance du signal dans l'espace)	Aucune donnée de terrain ni aucun signal enregistré ; les chiffres de positionnement, de PPP, de NTN et de synchronisation temporelle sont MODELLED (formes fermées, cohérence du filtre, comparaisons de tendances publiées) ; les préréglages proviennent de sources publiques ou sont dérivés, et ne sont pas des données d'opérateur	validation sur de vrais signaux enregistrés : P3
Spectre / environnement RF	partiel	type `spectrum` (`src/spectrum.rs`) : la bande L du GNSS (et les conceptions multibandes en ultra haute fréquence (UHF), bandes S et C) sous forme d'une densité spectrale de puissance, fréquence en abscisse et temps en descendant, sous une chronologie de brouilleurs scénarisée (brouilleurs à onde continue, à bande étroite, chirp et à large bande apparié), avec J/S (rapport brouilleur sur signal) et C/N₀ effectif (rapport porteuse sur densité de bruit) par bande ; enregistrements SigMF en entrée et en sortie et estimations spectrales de Welch d'échantillons complexes. Les spectres de signaux en forme fermée et les coefficients de séparation spectrale sont VALIDATED ; la cascade est MODELLED	Signaux GLONASS, BeiDou et Galileo E6 non modélisés ; ni frontal de récepteur ni validation sur IQ (en phase/en quadrature) enregistré	comparaison à des signaux enregistrés : P3
Confiance dans le journal de récepteur (navire et général)	partiel	`src/receiver_trust/` : moniteurs sur le propre journal d'un récepteur (rapport porteuse sur densité de bruit, cohérence de position, de vitesse et de cap, temps) avec des événements et des prédictions énoncés avant l'exécution ; sur une plateforme navire, un score de 0 à 100 avec ses raisons ; mode en direct sur un flux avec la phrase `$PKSHT` et une porte facultative. MODELLED ; à titre consultatif, pas un équipement de navigation homologué	Les seuils sont des valeurs par défaut indiquées, non mesurées par rapport à des récepteurs déployés ; un journal ne note que ce journal ; aucune entrée ni sortie radiofréquence ; pas un équipement de navigation homologué	`docs/RECEIVER-TRUST.md`, `docs/MARITIME-TRUST.md`
Paquets de preuves et télémétrie de confiance	partiel	`src/evidence/` : un paquet signé et chaîné par hachage d'une fenêtre de journal, de sa configuration et du résultat du moteur, vérifiable hors ligne, avec un jeton d'horodatage RFC 3161 facultatif. `src/telemetry/` : le flux de confiance sous forme de métriques Prometheus, d'événements syslog (CEF ou LEEF) et, en option, d'OpenTelemetry, avec un exemple de tableau de bord Grafana	Un paquet est un enregistrement technique, pas un avis juridique, et il n'indique pas ce qui a causé un événement ; la signature de l'autorité d'horodatage n'est pas vérifiée ; la télémétrie ne transmet que de la télémétrie	`docs/EVIDENCE-PACKS.md`, `docs/TRUST-TELEMETRY.md`
Flux de formation des équipages et cartes d'interférences	partiel	`src/nmea_synth/` : NMEA synthétique pour un pont, avec des événements scénarisés de brouillage, de décrochage progressif (drag-off), de leurrage temporel et de rejeu, et un journal d'instructeur (texte seul). `src/interference_map/` : cartes agrégées de navigation dégradée issues de rapports d'aéronefs et de navires sous licence ouverte et exposition d'un itinéraire, à partir de fichiers locaux	Les flux sont des données de formation, jamais destinées aux systèmes de navigation en direct d'un navire ; les cartes sont agrégées, ne sont pas une prévision, et dépendent des rapports fournis	`docs/NMEA-TRAINING.md`, `docs/INTERFERENCE-MAP.md`
Export pour banc d'essai	partiel	`src/interop/testbench.rs` : le mouvement du véhicule et les événements d'un scénario `gnss-ins`, `jamming` ou `gnss-sim` sous forme de CSV de mouvement, de NMEA, de texte de points de passage et de fichiers d'événements pour un simulateur GNSS de laboratoire	Aucun signal n'est écrit ; aucune performance de simulateur ou de récepteur n'est revendiquée ; les fichiers sont contrôlés tels que relus par les lecteurs de mouvement d'un simulateur libre (gps-sdr-sim), mais la physique de la trajectoire de vérité propre au scénario n'est pas contrôlée en externe	`docs/TEST-BENCH.md`
Vérification Galileo OSNMA	partiel	`src/osnma/` et `kshana osnma verify` : lit des pages I/NAV de Galileo ou un flux UBX et indique, par satellite et par époque, si les données de navigation sont authentifiées (clé signée à racine de Merkle, chaîne TESLA, MAC), avec la raison de l'échec d'un contrôle et un temps de référence indépendant facultatif pour la fraîcheur ; aussi `osnma_verify` en Python et en WebAssembly	Authentifie des données par rapport aux clés fournies par l'utilisateur ; ne revendique aucune performance anti-leurrage et n'est ni un service d'intégrité de navigation ni un équipement homologué ; contrôlé sur des vecteurs synthétiques, les vecteurs de test officiels de l'ICD sont un téléchargement externe	`docs/OSNMA.md`
Cartographie de compliance avec des cadres publics	partiel	`src/compliance/` et `kshana compliance-report` : sorties de Kshana associées à six cadres et normes publics de résilience, avec des sources et un écart sur chaque ligne ; une exécution ne compte que si son résultat porte les champs que son type écrit	Une cartographie est un jugement ; le rapport indique ce qu'un ensemble d'exécutions apporte des éléments de preuve en faveur de, jamais qu'un cadre est atteint ni qu'un produit est approuvé ; EN 16803 n'est cité qu'à partir du texte du catalogue	`docs/compliance/README.md`
Intégrations maritimes	partiel	Un plugin Signal K, OpenCPN via du NMEA en mode passerelle sur TCP, et une version de référence pour un petit ordinateur à côté du récepteur (`integrations/`, `deploy/`)	Testé sur une sortie synthétique enregistrée ; le plugin n'est pas publié sur npm ; à titre consultatif, pas un équipement de navigation homologué	`docs/MARINE-INTEGRATIONS.md`

Domaines plus larges des systèmes spatiaux (hors périmètre aujourd'hui)#

Plusieurs d'entre eux sont aucun ; d'autres sont désormais des modèles partial de premier ordre (les types d'analyse de mission / d'environnement ajoutés dans la série v0.17.0) : listés pour que le périmètre soit sans ambiguïté, et non sous-entendu par le silence. Kshana est un simulateur PNT, pas GMAT/STK/Orekit (STK : Systems Tool Kit) ; ces modèles adjacents sont délibérément de premier ordre et MODELLED, jamais des outils de vol validés.

Capacité	État	Note / feuille de route
Conception de mission / optimisation de trajectoire	partiel	`src/maneuver.rs` : nœuds de ΔV impulsionnels avec propagation de covariance 6×6 (référentiels d'erreur d'exécution ECI/LVLH (ECI : inertiel centré sur la Terre ; LVLH : verticale locale, horizontale locale)), intégration de poussée finie contrôlée par rapport à l'équation de Tsiolkovski en forme fermée à < 0,01 %, un solveur de Lambert à une révolution d'Izzo-2015 + un propagateur de Kepler exact à variables universelles (sorties de Lambert vérifiées en aller-retour par rapport à la vérité à deux corps), et un balayage porkchop (lancement × arrivée) C3 / V∞ d'arrivée émis sous forme de grille de contours JSON dont le minimum est contrôlé par rapport au plancher analytique de Hohmann. Pas d'optimiseur de trajectoire ; un solveur de Lambert multi-révolutions (`maneuver::lambert_multirev`, jusqu'à trois révolutions, les deux branches) est VALIDATED par rapport à pykep 3.0.1 (`tests/lambert_multirev_oracle.rs`) ; le porkchop s'exécute sur le modèle synthétique coplanaire circulaire ou, avec `maneuver::porkchop_kernel`, sur un SPK DE440 (VALIDATED par rapport aux états SPICE + au Lambert de pykep, `tests/porkchop_de440_oracle.rs`) ; `maneuver::optimise_transfer_kernel` trouve l'optimum continu de date (C3 minimal ou V∞ d'arrivée minimal, type I ou II) sur DE440, VALIDATED par rapport à un optimiseur indépendant SPICE + pykep + SciPy (`tests/transfer_optimiser_oracle.rs`) ; par rapport aux minima Terre–Mars publiés de NASA/TM-2010-216764 2026, il concorde avec les valeurs du type II et manque le C3 minimal du type I de −5,18 % (consigné). GMAT lui-même n'a pas été exécuté ; pykep est la référence de bibliothèque. Une interface d'éphéméride planétaire pour l'espace lointain (`src/ephem_provider.rs`) et une validation croisée DE440 (Development Ephemeris 440) (`xval/anise-mars-od`, 137 m @ arc martien de 1 jour) existent désormais ; voir la ligne PNT espace lointain / interplanétaire. La couche de simulation de performance au-dessus de GMAT/Orekit, pas un remplacement. P3
AOCS (système de contrôle d'attitude et d'orbite) / GNC (guidage, navigation et contrôle) / attitude	partiel	type `attitude-budget` (`src/attitude_budget.rs`) : couple de gradient de gravité `1.5·(μ/R³)·ΔI` au pire cas + budget d'erreur de pointage RSS (racine de la somme des carrés) sur des termes à 1σ par contributeur : un budget scalaire de pointage/perturbation avant matériel, MODELLED. La dynamique d'attitude de corps rigide sans couple, avec un état par quaternion (`src/attitude_dynamics.rs` : équations d'Euler + cinématique des quaternions, RK4) est VALIDATED par rapport au moyeu de vaisseau spatial de Basilisk 2.9.1 (`tests/attitude_dynamics_basilisk_oracle.rs`, quaternion à 1e-9 près sur 1e4 s), et le pic de couple de gradient de gravité par rapport au GravityGradientEffector de Basilisk (`tests/attitude_gg_torque_basilisk_oracle.rs`) ; la détermination d'attitude de Wahba se trouve dans `src/wahba.rs`. Type `aocs` (`src/aocs.rs`, `src/aocs_kind.rs`, `AOCS.md`) : une manœuvre d'orientation à pointage inertiel avec des roues à réaction équilibrées sous rétroaction MRP, des couples de roues de norme minimale avec limites de moteur ; la boucle fermée est VALIDATED par rapport à Basilisk 2.9.1 sur trois cas fixés à l'avance, à l'arrondi près. Un MEKF à partir d'un gyromètre et d'un suiveur d'étoiles (`src/aocs_mekf.rs`) peut fermer la boucle sur son estimation (MODELLED, cohérence du filtre). Pas de guidage de poursuite, de rétroaction intégrale, de gestion du moment cinétique, de magnétocoupleurs, de propulseurs, de frottement des roues ni de limites de vitesse ; pas d'environnement de couples externes dans la dynamique d'attitude ; pas un contrôleur de vol. P3
Référentiels → liés à la Terre	complet	Fait : TEME→ECEF/ITRF, le mouvement du pôle et la chaîne GCRS→ITRS fondée sur le CIO sont mis en œuvre et VALIDATED (bit à bit par rapport à SOFA/ERFA ; 4 mm de bout en bout par rapport à Vallado). Voir la ligne Référentiels ci-dessus
Communications et bilans de liaison	partiel	`src/linkbudget.rs` : un bilan de liaison de Friis pour l'espace lointain (puissance d'émission · gains d'antenne · bruit → C/N₀ · Eb/N₀ · marge) alimentant le chemin radiométrique/GSE (GSE : équipement de soutien au sol), plus les liaisons de transfert de temps optiques/RF (`src/timetransfer.rs`), et le type `link-budget`* exécutable : l'équation de liaison unidirectionnelle CCSDS-401/DSN-810-005 (DSN : Deep Space Network) `C/N₀ = EIRP − FSPL − L_other + G/T − k` avec des entrées EIRP (puissance isotrope rayonnée équivalente) / G-T et la sélection de bande S/X/Ka (bilan de liaison d'ingénierie MODELLED, pas une fiche technique de terminal étalonné). Pas de planification d'accès, pas de codage adaptatif. P2
Segment sol et opérations	partiel	type `passes` (`src/passes.rs`) : prédiction des passages de lever/coucher en station au sol : AOS/TCA/LOS (AOS : acquisition du signal ; TCA : instant de rapprochement maximal ; LOS : perte du signal), élévation maximale, durée de chaque passage et accès total sur un horizon, à partir d'un jeu d'éléments SGP4 dans le référentiel terrestre IAU 2006/2000A avec la réfraction ITU-R P.834-9 et le temps de lumière, VALIDATED par rapport à Orekit 13.1.8 pour des stations au niveau de la mer (60 cas / 1210 passages, `tests/pass_predictor_on_path_orekit_oracle.rs`) ; la fonction géométrique `passes::predict_passes` est VALIDATED par rapport au détecteur d'élévation d'Orekit 12,2 (22 scénarios / 129 passages, `tests/ground_station_pass_prediction_reference.rs`) ; pas d'optimiseur de planification ni de résolution de conflits. P3
Télémétrie / TT&C / CCSDS	partiel	TOML en entrée/JSON en sortie sur mesure ; *export et import* CCSDS OEM (Orbit Ephemeris Message) (502.0-B KVN (notation clé-valeur), GMAT/Orekit/STK) via le type `oem-interop` exécutable (pont aller-retour `src/oem.rs` `parse_oem` ; l'échange d'un objet unique respectant le format est VALIDATED par rapport à l'analyseur indépendant `oem` 0.4.5) ; analyse + émission du Tracking-Data-Message CCSDS-TDM (503) (`src/ccsds_tdm.rs`, le format d'échange radiométrique de l'espace lointain) ; et le type `space-packet` (`src/space_packet.rs`) : encodage/décodage de l'en-tête primaire du Space Packet CCSDS 133.0-B avec un aller-retour exact au bit près. Un écrivain CCSDS OMM (Orbit Mean-Elements Message, 502.0-B-2, de la famille ODM) (`src/omm.rs`) publie des éléments moyens SGP4 en KVN, et un lecteur de noyaux NAIF SPICE** en Rust pur (`src/naif_kernel.rs` : conteneur DAF, SPK de type 2, PCK binaire de type 2) alimente `ephem_provider::KernelEphemeris`. Les autres types de messages CCSDS (OPM, OCM, AEM (AEM : Attitude Ephemeris Message)) et l'écriture SPICE restent un point de la feuille de route (P2)
Interopérabilité et normes (RINEX/SP3/SPICE/CCSDS)	partiel	RINEX 3 NAV multi-GNSS : GPS, Galileo, QZSS, BeiDou MEO/IGSO (IS-GPS-200) et GLONASS (RK4 sur vecteur d'état PZ-90 (PZ : Parametry Zemli, le datum géodésique russe)), ingéré + propagé + exécutable comme une constellation mixte ; analyseur d'OBSERVATIONS RINEX 3 (pseudodistance/porteuse/Doppler/SNR par code d'observation, avec les indicateurs LLI/SSI (LLI : indicateur de perte d'accrochage ; SSI : indicateur de force du signal) ; 4,00 devrait être analysé, non testé) ; aller-retour lecture ↔ écriture d'éphémérides précises SP3-c/d (analyse + export pour Ginan/RTKLIB/gLAB) et propagateur de Lagrange d'ordre 10 (11 points) (`Propagator::Sp3Precise`) ; l'export SP3 est exposé en CLI (`kshana <orbit.toml> --export-sp3 out.sp3`, ou `export_sp3 = true`) et validé en aller-retour par rapport à la vraie constellation GPS à <0,5 m sur 24 h (`tests/sp3_export_roundtrip.rs`) ; écrivain d'éphémérides CCSDS OEM 2,0, l'export d'état TEME porteur de la vitesse pour les outils de dynamique du vol, désormais exposé en CLI (`kshana <orbit.toml> --export-oem out.oem`, ou `export_oem = true`) et contrôlé en aller-retour par rapport à l'état du propagateur (`tests/sp3_export_roundtrip.rs`). L'analyseur d'observations RINEX alimente désormais une solution de positionnement par point unique (`pvt`, validée sur de vraies données IGS ; voir la ligne GNSS / PNT). Plus l'analyse + émission de messages de données de suivi CCSDS-TDM (503) (`src/ccsds_tdm.rs`). Exports de géométrie pour les visualiseurs et les outils d'analyse de mission : CZML, KML (Keyhole Markup Language), GeoJSON et éphémérides STK (`--export`, `src/interop/`), chacun relu par un validateur écrit à partir de la spécification du format (`tests/interop_formats.rs`), un import d'itinéraire GeoJSON (`--import-route`), des enregistrements SigMF (Signal Metadata Format) en entrée et en sortie pour le type `spectrum`, et du texte de style RINEX-4 / CSV pour le message de navigation LEO (`INTEROP.md`, `STANDARDS.md`). Pas de BeiDou-GEO, pas de fixation d'ambiguïté entière en PPP ni de RTK cinématique (un PPP flottant statique et un RTK à courte ligne de base sur données réelles existent, voir la ligne GNSS / PNT), pas encore d'écrivain SPICE ni d'OPM/AEM (le lecteur OEM existe via le type `oem-interop`, l'écrivain OMM dans `src/omm.rs`, et un lecteur SPICE SPK/PCK dans `src/naif_kernel.rs`) : P2 « annexer les domaines adjacents via des formats standard »
Météorologie spatiale / environnement (iono/atmo/rayonnement)	partiel	type `space-weather` (`src/space_weather.rs`) : indices solaires/géomagnétiques (table à 28 pas Kp↔ap de l'IAGA (Association internationale de géomagnétisme et d'aéronomie), Ap quotidien, F10.7a centré sur 81 jours), température exosphérique de Jacchia-71, et un couplage de densité thermosphérique piloté par l'activité sur une atmosphère statique : MODELLED au premier ordre, PAS un modèle de densité absolue NRLMSISE. Ionosphère : le modèle diffusé de Klobuchar (VALIDATED par rapport à RTKLIB) et un lecteur de cartes de TEC (contenu électronique total) IONEX (format d'échange de cartes de l'IONosphère) (`src/ionex.rs`, testé unitairement). Une vraie carte ionosphérique globale CODE (`CODG1330.18I`) est la référence mesurée de la ligne de TEC oblique sans géométrie (`tests/geometry_free_tec_gim_oracle.rs`), mais ce test évalue la carte dans son propre générateur de jeu d'essai, de sorte que le lecteur `src/ionex.rs` lui-même n'est pas encore recoupé avec un vrai produit ; aucun modèle d'ionosphère fondé sur la physique ou piloté par la météorologie spatiale ; P2+
Navigation par carte de gravité / alt-PNT	partiel	`src/gravimeter.rs` : un modèle de mesure de gravimètre à atomes froids dont le plancher de bruit blanc est dérivé de l'ASD de l'accéléromètre CAI (`σ = ASD/√τ`), un champ d'anomalie de gravité en harmoniques sphériques pleinement normalisées de bas degré (validé par rapport aux fonctions de Legendre en forme fermée et à une anomalie à un seul terme dérivée à la main) plus des mascons synthétiques, et un filtre particulaire d'appariement de cartes de gravité (composant `mapmatch` + `particle_filter`) qui retrouve une trace sans GPS à partir de la séquence d'anomalies qu'il survole. Le banc d'essai de 60 minutes sans GPS (`run_gps_denied_gravity_nav`, `scenarios/gps-denied-gravity-nav.toml`) fait voler une coupure d'environ 700 km / une heure pendant laquelle la solution inertielle dérive jusqu'à ≈ 70 km, et un appariement hiérarchique du grossier au fin avec le bruit blanc à graine déterministe du gravimètre la retrouve à ≈ 145 m (< 500 m) : stable d'une réalisation du bruit à l'autre, et manifestement limité par le raffinement (une seule grille grossière cale à ~2 km). Plus un modèle complet du champ principal géomagnétique IGRF-14 (IGRF : International Geomagnetic Reference Field) (`src/igrf.rs` : le champ en harmoniques sphériques normalisées de Schmidt de l'IAGA jusqu'au degré/ordre 13, 2025,0 + variation séculaire, coefficients générés par machine à partir du `igrf14coeffs.txt` officiel ; validé par rapport au dipôle incliné en forme fermée, à une différence finie du potentiel scalaire, et au pôle/à l'intensité géomagnétiques connus), le champ magnétique qu'une plateforme peut apparier à une carte pour la navigation par anomalies magnétiques. Plus la navigation par référence au terrain (TERCOM/SITAN (TERCOM : appariement de contours de terrain ; SITAN : Sandia Inertial Terrain-Aided Navigation)) et le navigateur combiné gravité + magnétisme + terrain (`src/altpnt/terrain.rs`) : un analyseur fait maison de modèle numérique de terrain (MNT) SRTM (Shuttle Radar Topography Mission) `.hgt` (entiers signés de 16 bits gros-boutistes, ligne par ligne, rangée nord d'abord, vide -32768 ; validé par rapport à la spécification du pilote GDAL (Geospatial Data Abstraction Library) SRTMHGT (format de fichier de hauteur de la Shuttle Radar Topography Mission) et à une référence en forme fermée de point médian bilinéaire), un modèle d'altimètre radar/barométrique et un apparieur `run_terrain_nav` qui retrouve une trace sans GPS à partir du profil d'altitude du sol par rapport au MNT, et `run_combined_altpnt` qui fusionne trois canaux de champ scalaires par point de passage (Δg mGal · \|B\| nT anomalie crustale · altitude m) de sorte que la distribution a posteriori conjointe est plus nette (CRLB (borne inférieure de Cramér–Rao) plus basse) que celle de n'importe quel champ seul : bornée à < 500 m sur la coupure de 60 min et, en espérance, pas pire que le meilleur canal seul. Plus la navigation séquentielle (récursive) par référence au terrain, SITAN comme filtre continu (`src/altpnt/sequential.rs`, `run_sequential_trn`) : le même modèle de mesure altimètre/MNT exécuté époque par époque par le moteur SIR (rééchantillonnage par importance) de `particle_filter` (prédiction par l'incrément INS + bruit de processus → repondération par l'appariement au terrain → rééchantillonnage en cas de dégénérescence), de sorte qu'une dérive INS variable dans le temps est suivie le long de la trace là où l'apparieur par lots ne retrouve qu'un décalage constant unique : l'estimation récursive reste bornée et reconverge (final ≈ 70 m) tandis que la solution non assistée diverge sans borne jusqu'à ≈ 5 km, avec une erreur par époque qui suit le caractère distinctif du terrain et un moniteur de santé de la taille effective d'échantillon. Périmètre honnête : la carte est connue et fixe : localisation récursive par rapport à un MNT stocké (la moitié localisation du SLAM de terrain (localisation et cartographie simultanées)) ; l'estimation conjointe de carte est le RBPF distinct ci-dessous. Les quatre sont désormais branchés dans le moteur de scénarios sous `kind=` (`gravity-map`, `terrain-nav`, `combined-altpnt`, `terrain-slam`) avec un graphique SVG de dérive (`scenarios/terrain-nav.toml`, `scenarios/combined-altpnt.toml`, `scenarios/terrain-slam.toml`). 0,36 (WP-10) : le navigateur `gravity-map` accepte un vrai champ de référence facultatif (`[reference]` : EGM2008 intégré jusqu'au degré 70, ou un fichier ICGEM `.gfc`), dont la synthèse d'anomalie concorde avec le service de calcul ICGEM à environ 1e-8 mGal près (VALIDATED, `xval/icgem-egm2008/`) ; sur ce champ de degré 70, le banc d'essai de 60 min se termine à 3106 m, de sorte que le seuil < 500 m est NOT MET (fixé à l'avance et prédit : le degré 70 est trop lisse). Un Monte Carlo facultatif d'erreur de carte (`[map_error_mc]`, `scenarios/gravity-map-error-mc.toml`) montre que la solution synthétique à 144 m suppose une carte exacte (1 réalisation sur 20 à moins de 500 m sous une erreur corrélée de 2 mGal ; exploratoire). `combined-altpnt` accepte une grille magnétique crustale EMAG2v3 facultative (`[magnetic_grid]` ; EMAG2 est récupérée, non intégrée au dépôt, et aucun résultat de navigation n'est revendiqué sur elle). `terrain-nav` reste volontairement limité au MNT : c'est l'apparieur TERCOM/SITAN à canal unique, et l'appariement magnétique se trouve dans `combined-altpnt`, qui fusionne le terrain avec les canaux magnétique et gravimétrique ; un canal magnétique dans `terrain-nav` en ferait un doublon, de sorte que l'élément d'audit « EMAG2 dans terrain-nav » est couvert par le branchement de `combined-altpnt` (RM-16). Les contrôles SRTM réels s'exécutent en CI sur deux extraits pleine résolution versionnés (nœud pour nœud égaux à GDAL 3.8.4, `xval/srtm-ungate/`). L'estimation conjointe de carte existe (`run_sequential_trn_on_map`, un RBPF de style FastSLAM) : en un seul passage, il gagne 1,5 % par rapport au SITAN à carte connue sur une carte erronée, manquant son seuil de 10 % fixé à l'avance (`xval/terrain-slam-rbpf/`). Manque encore : un modèle de gravité de haut degré dans une exécution de navigation (exige un nouveau préenregistrement), un résultat de navigation magnétique sur une vraie grille, et un cas de SLAM avec revisite (fermeture de boucle). P3
Rentrée / EDL (entrée, descente et atterrissage), analyse de lancement, EO/charge utile (EO : observation de la Terre)	partiel	Géométrie MODELLED au premier ordre via trois types exécutables : `reentry` (`src/reentry.rs`, couloir balistique d'Allen-Eggers : décélération maximale, vitesses du g maximal et de l'échauffement maximal, altitude du g maximal), `launch-window` (`src/launch.rs`, azimut de lancement à deux corps `sin Az = cos i/cos lat`, Δv de changement de plan, bonus de rotation du site, opportunités quotidiennes), et `eo-coverage` (`src/eo_payload.rs`, géométrie en triangle spatial SMAD (Space Mission Analysis and Design) de fauchée / GSD (distance d'échantillonnage au sol) / accès / revisite EO). Pas de simulation EDL/aérothermique à 6 DoF, pas d'optimiseur de trajectoire, pas de radiométrie de capteur/MTF (MTF : fonction de transfert de modulation). P3
PNT lunaire / cislunaire (LunaNet)	partiel	`src/lunar.rs` : un moteur d'ARAIM lunaire réutilisant le cœur MHSS côté Terre avec les paramètres LNIS (LunaNet Interoperability Specification) de LunaNet (σ_URE ≈ 30 m, P_sat ≈ 1e-4), la réduction de référentiel cislunaire MCI↔MCMF (MCI : inertiel centré sur la Lune ; MCMF : centré sur la Lune et lié à la Lune) (`mci_to_mcmf` / `mcmf_to_mci`, un modèle simplifié de rotation moyenne à la vitesse sidérale) et la latitude/longitude/altitude sélénographiques (`mcmf_to_selenographic`), et un passage de niveau de protection au pôle sud (`south_pole_hpl_pass`) qui quantifie l'écart d'intégrité : avec une mesure de distance à 30 m, le HPL est fini mais dépasse une limite d'alerte d'opérations de surface de 50 m. `src/cr3bp.rs` ajoute le CR3BP Terre–Lune (problème restreint circulaire à trois corps) (dynamique en référentiel tournant + propagateur RK4 + constante de Jacobi + les cinq points de Lagrange, validé par rapport aux valeurs publiées de L1/L2/L3 et aux L4/L5 exacts), le cœur à trois corps dont a besoin une vraie NRHO (orbite en halo quasi rectiligne), et un correcteur différentiel à tir simple avec matrice de transition d'état (`cr3bp_jacobian`, `propagate_state_stm`, `differential_correct_halo`) qui produit des orbites en halo/NRHO L2 véritablement périodiques : la STM est validée par rapport à des différences finies, les halos corrigés se referment sur eux-mêmes à la précision machine (conservation de Jacobi), et l'initialisation par l'état d'apolune publié reproduit la NRHO L2 australe 9:2 (l'orbite Gateway) à période ≈ 6,57 j et périlune ≈ 3 250 km, en accord avec les ≈ 6,56 j / ≈ 3 370 km publiés \| Les CI (conditions initiales) de NRHO corrigées par différentiation sont désormais branchées, mais la transformation sélénocentrique (MCI/MCMF) dé-normalisée de l'orbite corrigée et la continuation de famille restent des suites ; l'orientation lunaire DE440 par axes principaux avec une vraie libration physique existe (`src/lunar_orientation.rs`, issue du PCK `moon_pa_de440`, contrôlée par rapport à SPICE `pxform` dans `tests/lunar_pa_orientation_spice_oracle.rs`), mais l'ancien chemin `lunar::mci_to_mcmf` utilise encore la rotation moyenne sans libration ni pôle en précession ; la NRHO est une solution CR3BP (circulaire, sans Soleil), non validée par rapport à une vraie éphéméride LANS/Gateway (LANS : Lunar Augmented Navigation Service) ; un type de scénario `lunar-integrity` exécutable (`scenarios/lunanet-araim.toml`) expose le passage au pôle sud depuis la CLI \| transformation sélénocentrique + continuation de famille + interface SPICE/LunaNet : P3
PNT espace lointain / interplanétaire (Mars, radiométrique)	partiel	Livré en v0.17.0. Un moteur de navigation radiométrique : temps de lumière itératif + retard de Shapiro, Doppler et distance bi-/uni-/tri-directionnels (Moyer à deux trajets), retournement cohérent de transpondeur, télémétrie régénérative/PN (PN : pseudo-bruit) (CCSDS 414), Δ-DOR (CCSDS 506), milieux plasma solaire/tropo/iono (`src/radiometric.rs`) ; analyse + émission CCSDS-TDM (503) (`src/ccsds_tdm.rs`) ; un SRIF à dynamique réduite (filtre d'information en racine carrée) avec des accélérations empiriques RTN (radiale, transverse, normale) + une horloge embarquée à 3 états + la traînée martienne (`src/deepspace_od.rs`, `clock_state.rs`, `mars_atmos.rs`) réalisant une DO en orbite basse martienne (LMO) ≈ 0,2 m en boucle fermée synthétique ; fusion unidirectionnelle + bidirectionnelle ; un cœur de dynamique multicorps (`src/body.rs`, Mars GMM-3 (GMM : Goddard Mars Model), référentiel martien IAU `src/mars_frame.rs`, une interface `EphemerisProvider` `src/ephem_provider.rs`, JD en deux parties + TT↔TDB (TDB : temps dynamique barycentrique)) ; et le scénario de PNT par relais `mars-pnt` (constellation aréostationnaire MARCONI, `src/mars_pnt.rs`) + un simulateur de performance GSE de bout en bout (`src/gse_sim.rs`). Validé par simulation (mesure de mérite en covariance/boucle fermée) ; dynamique à centre solaire recoupée par rapport à DE440 du JPL (Jet Propulsion Laboratory) (137 m @ arc de 1 jour, `xval/anise-mars-od`). Manque : validation sur de vraies données de suivi DSN/ESTRACK (ESTRACK : European Space Tracking network) ; gravité martienne dans son référentiel natif (le champ GMM-3 d/o 120 se charge depuis la table PDS SHADR, `from_shadr`, VALIDATED par rapport à pyshtools, et s'attache par `Body::with_gravity_field`, mais est évalué dans le référentiel IAU plutôt que dans le sien de Konopliv-2006) ; éphéméride de niveau DE dans le cœur (conditionnée à un noyau dans xval). P3
Système solaire et PNT autour de n'importe quel corps	partiel	type `solar-system` : positions, vitesses et constantes physiques du Soleil, des planètes, de Pluton, de la Lune et de sept lunes majeures à une époque, avec le temps de lumière entre corps ; les positions des planètes (éléments de Standish du JPL) et le temps de lumière sont VALIDATED par rapport à JPL Horizons (`tests/solar_system_horizons_reference.rs`), les lunes, Pluton et la table des planètes externes restent MODELLED. Type `body-pnt` : un orbiteur ou un atterrisseur autour de n'importe quel corps catalogué (Mars, la Lune, Europe, Ganymède, Titan et les autres) qui navigue sur des pseudodistances unidirectionnelles d'une constellation Walker locale plus une distance bidirectionnelle facultative depuis la Terre : MODELLED. Pas de noyau d'éphéméride planétaire dans le cœur (éléments analytiques), les orbites de relais `body-pnt` n'utilisent que J2 (les champs complets Mars GMM-3 d/o 120 et Lune GRAIL GL0660B d/o 660 se chargent depuis des tables PDS SHADR et s'attachent à un `Body` pour le propagateur, `src/gravity_pds.rs`). P3
Campagnes / composition de missions	partiel	type `campaign` (`src/campaign.rs`) : des types existants enchaînés sur une chronologie partagée (par exemple brouillage, puis leurrage, puis holdover avec un INS en roue libre, puis une alarme d'intégrité, puis récupération), des balayages de paramètres et des ensembles Monte Carlo à graine sur n'importe quel type, et plusieurs scénarios sous des conditions partagées avec un résumé combiné ; chaque nombre est lu dans une vraie exécution du type membre. Les identités de composition sont testées (`tests/campaign_composition_reference.rs` : une campagne à une phase reproduit l'exécution autonome octet pour octet) ; MODELLED. Une section `[optimize]` (grille ou Nelder–Mead borné sur une à trois clés, une métrique, minimiser, maximiser ou viser une cible) satisfait ses seuils en forme fermée et par force brute fixés à l'avance (`tests/campaign_optimize_reference.rs`) ; MODELLED, une recherche locale sans affirmation d'optimum global, et sans méthode à gradient ni bayésienne. P3
Rapports, animation et sorties	partiel	Chaque exécution écrit `result.json`, un graphique et un rapport (`report.html`, `report.json`) dont les libellés sont lus dans la matrice de vérification et dont la commande enregistrée reproduit le résultat octet pour octet (`tests/advanced_report_cli.rs`) ; `--animate` (svg, html ou images) rend une série temporelle sous forme d'animation (`src/animation.rs`, `ANIMATION.md`) ; `--export` écrit les formats d'échange de la ligne d'interopérabilité. Ce sont des rendus de l'exécution, pas des preuves sur la physique.

Écosystème et maturité (suivis honnêtement, pas une capacité du code)#

Domaine	État	Note
Liaisons de langage et empaquetage	partiel	Rust + Python (abi3) + WASM sur trois registres. Surfaces typées (0,36, CAP-34) : `RunOutput` Python avec accesseurs NumPy (`array`, `columns`, `series`) et `ScenarioKind` / `ErrorKind` / `KindMeta` typés par stubs ; `run_typed` JavaScript (un objet `RunOutput` typé) et `scenario_kinds`, avec le même vocabulaire dans les déclarations TypeScript. Les documents de résultats restent du JSON par type, typés seulement par leur enveloppe partagée (`units`, versions)
Éducation / expérience utilisateur (UX) d'accueil	partiel	Bac à sable du navigateur avec mode guidé livré : curseurs guidés adaptés au scénario (`web/studio/lib/guided.mjs`, jusqu'à six réglages par scénario) et visite guidée interactive (`web/studio/lib/tour.mjs`, rejouable depuis le bac à sable). Chaque exécution reçoit aussi une phrase de signification en langage courant et ses chiffres clés, lus dans le document de résultats (`web/studio/lib/meaning.mjs`, avec des modèles par type dans `meaning-kinds.mjs` ; un type sans modèle reçoit son premier chiffre principal énoncé simplement). Manque : des explications guidées par chiffre au-delà de cette phrase (le `GLOSSARY.md` en langage courant les couvre)
Communauté / gouvernance	partiel	Structure de gouvernance en place : `GOVERNANCE.md` (modèle de mainteneur bienveillant + exigence technique + frontière ouvert/fermé), `CODE_OF_CONDUCT.md`, `CONTRIBUTING.md`, `SECURITY.md`, modèles de tickets/PR (PR : demande de fusion), `FUNDING.yml`, dependabot. Fondateur unique ; une communauté externe active (contributeurs, citations) dépend des personnes et du temps et est encore en construction (démarchage en attente de relecture)
Maturité pour le financement et les achats	aucun	TRL ~3 ; pas encore de citations ni de contrats d'agences (voir les notes de stratégie)

Mis à jour le 2026-10-29 pour le moteur 0.40.0 (92 types de scénario, d'après kshana kinds --json ; nouveaux dans 0.40.0 : mission-thread, lunar-orbit-rendezvous, lunar-descent, lunar-surface et lunar-ascent). 2026-10-22 : moteur 0.39.0, 87 types, aucun nouveau type. 2026-10-19 : moteur 0.38.0, 87 types (nouveaux dans 0.38.0 : holdover-test, gnss-ssv et lunar-infrastructure). 2026-10-18 : 84 types (nouveau dans 0,37 : optical-atmosphere). 2026-10-16 : 83 types (nouveaux dans 0,36 : acm-link, aocs, ascent-losses, contact-schedule, entry-heating, eo-radiometry, lunar-station-coverage et time-transfer-budget). 2026-10-10 : moteur 0.35.0, 75 types, aucun nouveau type. 2026-10-09 et 2026-10-08 : révisions précédentes. 2026-10-04 : la ligne Signal de navigation note la couche IQ 0.31.0. 2026-09-29 : lignes LEO-PNT, spectre, PNT du système solaire / de tout corps, campagne et sortie ajoutées. Auparavant : alignement sur la matrice de capacités de 27 lignes de l'audit général du 2026-06-02 ; ligne PNT espace lointain / Mars ajoutée dans v0.17.0. Les ajouts Quantum-PNT (holdover d'horloge en l'absence de GNSS src/holdover.rs, budget d'estime quantique-inertiel composé QuantumNavBudget, compromis de conception de code de télémétrie CodeFamily, matrice de vérification vérifiée par machine src/verification.rs) ont été intégrés aux lignes Synchronisation temporelle, Capteur Quantum-PNT, Signal de navigation et V&V — chacun étiqueté vérifié ou modélisé selon sa référence indépendante réelle.

Ajouts du démonstrateur FutureNAV (modélisés, recoupés en interne, non validés en externe) : (1) banc d'évaluation de détection d'altérations RF par apprentissage automatique src/impairment_eval.rs : un corpus d'altérations étiqueté synthétique (fondé sur des paramètres, pas sur de l'IQ) + un banc ROC/AUC/confusion/Pfa-Pmd indépendant du détecteur (ROC : caractéristique de fonctionnement du récepteur ; AUC : aire sous la courbe) avec garde contre les fuites et découpage stratifié ; les détecteurs fournis sont des références transparentes de méthodes publiées, pas l'état de l'art (SOTA), et une AUC élevée ici démontre la chaîne de traitement, pas la performance sur le terrain. (2) moteur de compromis PNT quantique contre classique src/quantum_trade.rs : ingestion d'ADEV mesurés (ajustement NNLS (moindres carrés non négatifs) de σ_y²(τ)=q_wf/τ + q_rw·τ/3 + q_drift·τ³/20, vérifié en aller-retour par rapport à q_from_allan), un tableau de bénéfices de holdover temporel/inertiel qui porte sur l'artefact la réserve sur l'hypothèse de plancher, et une enveloppe de résilience sans GNSS en fonction du temps ; il quantifie le bénéfice quantique d'un partenaire, il ne valide jamais le dispositif. Les deux ont été relus de façon contradictoire (un défaut de base de dérive τ²→τ³ et une fausse affirmation de résilience « bornée indéfiniment » ont été détectés et corrigés). 911 tests de bibliothèque au moment de cet ajout, fmt+clippy propres.

Ajout d'interchange / de format standard (src/interchange.rs) : le Kshana Interchange Format (KIF), une Envelope neutre, versionnée et autodescriptive qui enveloppe tout artefact (scénario, résultat, étude de compromis) avec une étiquette format reconnaissable, la SCHEMA_VERSION source unique de vérité (la version de schéma, autrefois copiée en littéral à 15 endroits, est désormais détenue par une seule constante que tout le crate référence), la engine_version productrice, et un contrat de compatibilité explicite et testé (compatibility() : même version majeure / version mineure égale ou plus ancienne est lisible selon la discipline des champs additifs ; une version mineure plus récente ou une version majeure différente est refusée à la frontière par Envelope::parse plutôt que mal analysée en silence). Aller-retour possible (wrap→to_json→parse→payload_as::<T>()) pour toute charge utile Deserialize ; délibérément sans horodatage pour préserver la reproductibilité bit à bit de Kshana. Documenté dans SCHEMA.md pour que le format soit citable, et pas seulement émis : le positionnement « standard en attente » du cœur ouvert. 923 tests de bibliothèque au moment de cet ajout, fmt+clippy propres.

Ajouts de la version de domination FutureNAV (modélisés, recoupés en interne, non validés en externe) : (1) couche frugale de coût par couverture / ROI (retour sur investissement) src/frugal.rs : une couche de cadrage des bénéfices au-dessus du moteur de dimensionnement de constellation (walker) qui rapporte le coût par point de pourcentage de couverture et le ROI en couverture par euro par rapport à une référence de base ; le coût par satellite est une fourchette basse/nominale/haute sourcée fournie par l'appelant (aucun prix ponctuel fabriqué), de sorte que les sorties sont des plages et non de fausses valeurs ponctuelles ; un cadrage économique modélisé d'un chiffre de couverture modélisé, pas un devis. (2) cartographie de l'impact sur l'intégrité des non-détections src/integrity_impact.rs : fait correspondre un biais de position induit par un leurrage/brouillage non détecté à son erreur effective → région de Stanford (disponible / système indisponible / trompeur / dangereusement trompeur) par rapport à des limites d'alerte propres au contexte (ciel dégagé contre urbain, HAL contre VAL), en composant le RAIM classify_stanford ancré en externe ; le pont non-détection→limite d'alerte est modélisé, pas une allocation d'intégrité certifiée. Les deux sont reportés dans la matrice de vérification contrôlée par machine (src/verification.rs, invariant Validated⇒ExternalDataset intact ; le nombre de lignes à jour figure dans l'en-tête généré de VERIFICATION-MATRIX.md). La validation croisée / garde contre les fuites / découpage stratifié par paramètres pour le banc d'évaluation de l'IA était déjà livré dans src/impairment_eval.rs (stratified_split, Split::has_leakage). 951 tests de bibliothèque au moment de cet ajout, fmt+clippy propres.

Ajouts de l'étude de l'écart d'optimisme FutureNAV (modélisés, recoupés en interne par rapport à des formes fermées, non validés en externe, pas une affirmation de passage de la simulation au terrain) : une étude synthétique contrôlée de l'écart d'optimisme d'AUC entre en distribution et hors distribution pour les détecteurs d'altérations RF. (1) Détecteurs appris src/impairment_ml.rs : une carte de caractéristiques fixe + un standardiseur ajusté à l'entraînement, une référence de régression logistique (descente de gradient déterministe sur lot complet), et un MLP (perceptron multicouche ; rétropropagation SGD (descente de gradient stochastique) à graine) à une couche cachée derrière le même trait ImpairmentDetector que celui qu'utilisent les références de méthodes publiées. (2) Statistiques dérivées à la main src/eval_stats.rs : intervalles de confiance (IC) par bootstrap percentile, variance/IC d'AUC de DeLong, ρ de Spearman et régression ridge, chacun contrôlé par rapport à une forme fermée (AUC binormale Φ(d′/√2), une variance de DeLong calculée à la main, un ρ de manuel à rangs ex æquo, récupération exacte par MCO (moindres carrés ordinaires)). (3) L'étude src/impairment_study.rs : AUC par classe, la tendance de loi d'échelle par (detector,class) (écart contre 1−sévérité), et un prédicteur d'écart ridge à partir de l'en-distribution seule qui estime l'écart d'optimisme à partir des seuls diagnostics en distribution, noté par exclusion d'un détecteur à la fois et exclusion d'une classe à la fois par rapport à une référence de base qui prédit la moyenne. Artefact en une commande via cargo run --release --example optimism_study. Chaque nombre est une AUC sur des étiquettes issues du modèle d'un corpus synthétique fondé sur des paramètres ; l'écart est un décalage de sévérité synthétique→synthétique, jamais un résultat de détection sur le terrain. Reporté dans la matrice de vérification contrôlée par machine (src/verification.rs, invariant Validated⇒ExternalDataset intact).