| Test irrealisable | Spec §5.0 / TC-NOM-12 / Plan §3, §11.1 | Le plan ne definit ni registre public ni mecanisme d’inclusion des definitions normatives (canonicalization_id, leaf_ordering_id, hash_algorithm_id/version, proof_format_id) dans la preuve ; seules les valeurs d’ID sont transportees. | Un auditeur externe ne peut pas verifier les identifiants sans source normative disponible avec la preuve ; TC-NOM-12 non realisable. | BLOQUANT |
| Non-conformite Spec | Spec §5.0 (evenement valide) / Plan §5.1, §5.6 | Le plan impose ISO 8601 pour event_time, window_start et window_end alors que la specification ne contraint pas le format. | Rejet possible d’evenements conformes a la spec ; divergence contractuelle en audit. | MAJEUR |
| Hypothese implicite | Spec R1 + §5.0 / Plan §13.1 (H-01, H-03) | Le plan suppose que events[] est clos et que les fenetres sont non chevauchantes sans mecanisme d’enforcement. | Si les hypotheses sont fausses, determinisme (I1) et periodicite (R15-R16) ne sont pas garantis ; non-conformite possible. | MAJEUR |
| Hypothese implicite | Spec R11, R18 / Plan §5.5, §5.8, §11.2 | L’encodage de left | | right n’est pas explicitement fixe : TreeBuilder hash des valeurs hex concatenees, tandis que verifyProof calcule sur des bytes decodees. |
| Non-conformite Spec | Spec §9 / Plan §12.2 | Le plan formule comme contrainte une regle classee “objectif de conception, non testable” dans la specification (confidentialite au-dela des hashes). | Exigence non testable ajoutee ; audit contestable. | MINEUR |
| Hypothese implicite | Spec R20 / Plan §2, §5.9 | Le plan indique “SHA-256” comme choix technique tout en listant SHA-384/SHA-512 comme algorithmes autorises. | Ambiguite sur la liste autorisee effective ; interpretation variable pour TC-NOM-10. | MINEUR |