Affirmations et réalité : registre des surdéclarations
Un audit indépendant d'une version antérieure de Kshana a recensé quatorze surdéclarations (OC-0…OC-13) : des endroits où une surface publique (README, bac à sable, étiquettes de FoM (figure de mérite), paquets de scénarios) décrivait une capacité plus fortement que ne la livrait le code. Cette page est le registre de clôture : chaque ligne indique la surdéclaration d'origine, la manière dont elle a été résolue et les preuves. Deux types de résolution apparaissent :
- Retirée de l'affirmation : la formulation a été corrigée pour correspondre au code (reformulation honnête, aucun changement de capacité). « Zéro code = zéro affirmation. »
- Supplantée : la capacité réelle a ensuite été construite et testée, de sorte que l'affirmation forte est devenue exacte.
Un garde-fou de régression (tests/no_overclaims.rs) analyse les surfaces publiques en production (README.md, docs/CAPABILITY.md, docs/GLOSSARY.md, web/capabilities.json, web/index.html, web/README.md, et les pages d'accueil de crates.io, PyPI (Python Package Index) et npm README.crates.md, README.pypi.md, README.npm.md) à chaque exécution de la CI (intégration continue) et échoue si l'une des formulations de surdéclaration abandonnées réapparaît sans réserve, de sorte qu'une ligne ne puisse pas régresser silencieusement depuis GREEN.
Les quatorze lignes sont GREEN.
| OC (surdéclaration) | Surdéclaration d'origine | Résolution | État | Preuves |
|---|---|---|---|---|
| OC-0 | « estimateur de fusion de Kalman conjoint » laissait entendre un filtre unique à covariance croisée ; le code exécutait deux estimateurs indépendants | Supplantée : un véritable filtre de Kalman couplé horloge+position à covariance croisée a été construit | 🟢 | src/fusion/coupled.rs (7 tests, dont un ensemble de 100 essais couplé contre découplé qui exige que le RMS (moyenne quadratique) de position du filtre couplé soit inférieur à 0,6 fois celui du filtre découplé et que le filtre couplé l'emporte dans au moins 90 des 100 essais) ; CAPABILITY « Fusion de capteurs » → complète |
| OC-1 | « RAIM (surveillance autonome de l'intégrité par le récepteur) de détection de leurrage assistée par l'horloge » laissait entendre un détecteur RAIM multi-satellites | Retirée de l'affirmation → Supplantée : reformulée comme une borne de détectabilité du leurrage fondée sur la stabilité de l'horloge ; le véritable RAIM/ARAIM (HPL/VPL (HPL : niveau de protection horizontal ; VPL : niveau de protection vertical)) est ensuite arrivé | 🟢 | src/raim.rs (30 tests : instantané + ARAIM à séparation de solutions, HPL/VPL, FDE (détection et exclusion de pannes), diagrammes de Stanford) ; docs/INTEGRITY.md |
| OC-2 | « démonstrateur de brouillage » sans aucun code de brouillage derrière | Supplantée : un modèle de brouillage par bilan de liaison J/S → C/N₀ effectif → perte d'accrochage a été construit | 🟢 | src/jamming.rs (10 tests) ; ligne « Résilience » du README |
| OC-3 | « Modèle de bruit à variance d'Allan complet d'une IMU (centrale inertielle) sur un trièdre d'IMU » : le modèle était à axe unique | Retirée de l'affirmation → Supplantée : reformulée comme un budget d'erreur à 1 DOF (degré de liberté) ; un INS (système de navigation inertielle) strapdown à trois axes a ensuite été livré | 🟢 | src/inertial strapdown à trois axes (attitude par quaternion, mécanisation NED (nord-est-bas), coning/sculling) ; ROADMAP « Inertiel » |
| OC-4 | « Intégration PNT (positionnement, navigation et synchronisation temporelle) hybride » laissait entendre un filtre GNSS/INS (GNSS : système mondial de navigation par satellite) couplé ; c'était un budget d'erreur d'estime | Retirée de l'affirmation → Supplantée : reformulée comme de l'estime avec un réaccrochage configurable ; une véritable fusion GNSS/INS à couplage serré a ensuite été livrée | 🟢 | src/fusion/tightly_coupled17.rs (UKF (filtre de Kalman sans parfum) à 17 états avec estime quantique par CAI (CAI : interféromètre à atomes froids)) ; CAPABILITY « Fusion de capteurs » → complète |
| OC-5 | « validé à ~2 % » laissait entendre un seuil serré et imposé | Retirée de l'affirmation : VALIDATION.md indique le seuil imposé (20–25 % en moyenne sur les graines) ; « ~2 % » désignait une observation typique, et non le seuil |
🟢 | docs/VALIDATION.md en-tête « Sur les tolérances » |
| OC-6 | « déterministe entre plateformes » sans preuve versionnée | Retirée de l'affirmation : chaîne d'outils épinglée à une version exacte ; hachages de référence (golden) par scénario versionnés avec une porte de reproductibilité. (L'identité bit à bit entre OS/architectures (OS : système d'exploitation) reste un point ouvert, énoncé honnêtement.) | 🟢 | rust-toolchain.toml (canal 1.93.0) ; tests/golden.rs (valeurs numériques à 1e-6 près) ; tests/cross_platform_golden.rs (hachage de l'empreinte d'entrée et de la forme de chaque résultat, exécuté sur la matrice de CI Linux, macOS et Windows) ; scripts/check-reproducible.sh |
| OC-7 | « simulateur PNT hybride quantique-classique » laissait entendre une physique quantique de premiers principes | Retirée de l'affirmation → Supplantée : reformulé comme un simulateur de résilience PNT utilisant des modèles de performance de capteurs quantiques ; la physique CAI de Mach–Zehnder de premiers principes est ensuite arrivée | 🟢 | src/inertial/quantum_imu.rs (26 tests : phase de Mach–Zehnder, bruit de projection 1/√(N·C²·T²), fonction de transfert des vibrations, effets systématiques de Coriolis + AC-Stark (AC : courant alternatif)) ; docs/QUANTUM.md |
| OC-8 | La FoM « Performance d'intégrité » laissait entendre une intégrité aéronautique HPL/VPL/RAIM | Retirée de l'affirmation + Supplantée (en couches) : la FoM de scénario par exécution est honnêtement étiquetée auto-cohérence du filtre (et non intégrité aéronautique) ; le véritable ARAIM HPL/VPL est présenté séparément, de sorte que les deux ne soient jamais confondus | 🟢 | src/fom.rs:80 (integrity : auto-cohérence, avec réserve) ; src/raim.rs + docs/INTEGRITY.md (véritable ARAIM) |
| OC-9 | FoM de sécurité présentée comme toujours significative, même sans attaque | Retirée de l'affirmation : la FoM de sécurité (1 − P_md) est cadrée dans le contexte du détecteur de leurrage et n'est significative que lorsqu'un scénario d'attaque est configuré |
🟢 | Ligne « Résilience » du README ; la FoM de sécurité est définie au point de spécification opérationnellement nuisible |
| OC-10 | La FoM « Performance de positionnement » laissait entendre une précision complète dans le domaine des positions | Retirée de l'affirmation : étiquetée pos_rms_m à 1 DOF pour les paquets inertiel/hybride, explicitement et non une précision CEP/2DRMS 2-D (CEP : erreur circulaire probable) ni pondérée par le DOP (DOP : dilution de précision) |
🟢 | Tableau des figures de mérite du README (ligne « Performance de positionnement ») |
| OC-11 | des chiffres de FoM inertielle lus comme des statistiques d'ensemble alors qu'ils venaient de graines uniques | Retirée de l'affirmation : une exécution unique est signalée par monte_carlo: false ; runs = N fournit la moyenne/la dispersion/l'IC bootstrap à 95 % |
🟢 | Tableau de FoM du README ; tests d'enveloppe de couverture des scénarios |
| OC-12 | le scénario de la « constellation GPS (Global Positioning System) SGP4 (Simplified General Perturbations 4) » utilisait des TLE (jeux d'éléments à deux lignes) synthétiques de substitution | Supplantée : le scénario intègre désormais un véritable instantané Celestrak gps-ops daté, avec des sommes de contrôle strictes |
🟢 | scenarios/orbit-sgp4-gps.toml (gps-ops réel, strict_checksum) ; tests/scenario_coverage.rs |
| OC-13 | La chaîne de version du README s'écartait de Cargo.toml |
Retirée de l'affirmation : un garde-fou de CI vérifie que le badge d'état du README correspond à Cargo.toml |
🟢 | scripts/check-version-sync.sh |
0,35 : des affirmations maintenues étroites, et une correction#
Les fonctionnalités de 0,35 ont été rédigées avec leurs limites énoncées à côté de l'affirmation, et les mêmes garde-fous (tests/no_overclaims.rs, et le garde-fou de formulation dans tests/compliance_report.rs) analysent les pages qui les décrivent. Ce tableau ne fait pas partie du registre à quatorze lignes ci-dessus ; il consigne, pour les nouvelles surfaces, ce qui est affirmé et ce qui ne l'est pas.
| Surface | Ce qui est affirmé | Ce qui ne l'est pas |
|---|---|---|
Score de confiance du navire (receiver_trust, $PKSHT, passerelle, Signal K, OpenCPN) |
un score de 0 à 100 et des motifs tirés des propres NMEA d'un récepteur, MODELLED | à titre consultatif, et non un équipement de navigation homologué ; le score d'un journal n'est pas un énoncé sur d'autres récepteurs ; il ne rend pas une position plus précise |
| Flux NMEA de formation d'équipage | NMEA synthétique de passerelle avec événements scénarisés et un journal d'instructeur | texte seulement, aucune sortie radiofréquence ; jamais pour les systèmes de navigation en service d'un navire ; à titre consultatif, et non un équipement de navigation homologué |
| Paquets de preuves | un enregistrement technique signé, vérifiable hors ligne | pas un avis juridique ; n'indique pas ce qui a causé un événement, qui en était responsable, ni que le journal montre ce que le récepteur a réellement reçu |
| Carte des interférences | cellules agrégées de navigation dégradée issues de rapports sous licence ouverte | pas une prévision ; l'exposition d'un itinéraire est une part de cellules, et non un risque |
| Export pour banc d'essai | le mouvement du véhicule et les événements d'un scénario dans des fichiers qu'un simulateur de laboratoire peut lire | aucun signal n'est écrit ; aucune performance de simulateur ou de récepteur n'est revendiquée |
| Cartographie de compliance avec des cadres publics | les lignes en faveur desquelles un ensemble d'exécutions apporte des éléments de preuve, avec une lacune sur chaque ligne | jamais qu'un cadre est satisfait ni qu'un produit est approuvé ; une étiquette de type de scénario seule n'est pas une preuve |
Correction consignée dans 0,35. Une version antérieure de docs/RESILIENCE-CROSSWALK.md et des commentaires du module de résilience décrivait sept « catégories de techniques » du DHS Resilient PNT Conformance Framework. La version 2,0 de ce cadre définit des fonctions de base (Prevent, Respond, Recover), des niveaux de 0 à 4 et huit exigences numérotées, et aucune liste de sept catégories. Les noms des sept sous-scores émis par le moteur de notation sont propres à Kshana, et la table de correspondance le dit désormais.
Comment une ligne reste GREEN#
Les affirmations fortes (OC-0/2/7/8 et les moitiés supplantées de OC-1/3/4/12) sont GREEN parce que la capacité est livrée et testée, et non parce que la formulation a été adoucie. Les lignes retirées de l'affirmation sont GREEN parce que la formulation en production correspond au code. Le test de garde-fou rend la seconde catégorie applicable : si une formulation de surdéclaration abandonnée revient sur une surface publique, la CI passe au rouge. Voir tests/no_overclaims.rs.