# Contrat du fichier utilisateur

JSON UTF-8 sans BOM. Objet : version=1, asOf (entier Unix en secondes), maxAgeSeconds (entier1..31536000), context, observations. Champs facultatifs seulement : pilot et verificationReports. asOf est votre instant explicite, pas une horloge automatiquement actualisée.

context contient serviceId, serviceVersion, task, region. Chaque valeur : identifiant ASCII1à200 caractères, premier alphanumérique, suivants alphanumériques ou . _ : / @ -. Les identifiants ci-dessous suivent la même règle. Fournir les valeurs détenues, sans inventer d'identité.

observations : liste éventuellement vide. Chaque ligne contient id, context (quatre champs), observedAt (entier Unix >=0), provenance (operator/synthetic/external/unknown), sourceId, sourceGroup (identifiant ou null), evidenceRef (identifiant ou null), contested (booléen). external est une déclaration, jamais admission. Doublons id/evidenceRef et groupes contradictoires sont exclus, pas fusionnés en témoignages.

verificationReports facultatif : l'omettre sans rapport compatible détenu. Chaque entrée : evidenceRef correspondant à une observation, provenance={producer,artifactRef,corpus}, report. producer=B03/153 ; artifactRef identifiant ; corpus=synthetic_historical ou unknown. report : schema=datoka.verify.api-policy-result.v1, expectedContext={issuer,scope}, recordedAt, result={status,code éventuel,checks}. Le formateur fourni reference/b03-153/politique-rapport.mjs définit les combinaisons exactes acceptées. Conserver le rapport reçu, ne pas fabriquer ses checks pour le rendre valide. Autre format : conserver dans son outil d'origine. Aucun rapport authentifié ici.

pilot facultatif : snapshot agrégé compatible datoka.reputation.observations ou enveloppe record. Non nécessaire pour vos observations ; ne pas reconstruire des lignes individuelles depuis cet agrégat. Sa signature n'est pas vérifiée.

## Importer un rapport déjà détenu sans le réécrire

L'entrée du produit est une analyse avec context et observations, pas le rapport B03 seul. Si votre fichier porte directement schema=datoka.verify.api-policy-result.v1, conservez-le comme pièce ; il se place dans report d'une entrée verificationReports, liée par evidenceRef à l'observation que vous détenez. Ne créez pas une observation pour donner une autorité au rapport. Sans observation correspondante, ce parcours ne permet pas d'importer le rapport isolé.

Le format0.3 accepte uniquement ce contrat B03/153, pas tout JSON contenant une signature. Omettre verificationReports permet une analyse déclarative sans rapport compatible ; cela ne doit pas masquer une pièce défavorable : conservez-la séparément et indiquez son absence du périmètre analysé.

### Vérifications de forme à faire en lecture seule

- Chaque entrée possède exactement evidenceRef, provenance, report. Chaque provenance possède exactement producer, artifactRef, corpus. producer=B03/153 ; corpus=synthetic_historical ou unknown ; artifactRef reste la référence originale. Une référence de rapport ne peut être répétée ni absente des observations.
- report possède schema, expectedContext, recordedAt et result. expectedContext contient issuer et scope : identifiants ASCII1à128caractères, premier alphanumérique, suivants alphanumériques ou . _ : -. Ce contexte API ne remplace pas context(serviceId/serviceVersion/task/region) de Reputation.
- recordedAt est une chaîne UTC strictement au format AAAA-MM-JJTHH:MM:SS.sssZ, avec exactement trois chiffres de millisecondes. Une date sans millisecondes ou avec décalage horaire est refusée par ce lecteur, même si elle désigne le même instant. Ne pas changer la date ou le rapport original pour forcer l'import ; retrouver l'export compatible déjà détenu ou conserver la pièce hors de cette entrée. Le lecteur ne convertit pas silencieusement les horloges.
- result contient status, checks et éventuellement code. checks contient exactement neuf champs : signature, context, currentTrustPolicy, responseBody, completeExchangeVerified, providerOriginVerified, payment, authorization, factualAccuracy. Les trois premiers valent verified ou not_checked ; responseBody vaut not_checked, matches, differs ou not_included. Dans ce contrat, completeExchangeVerified=false, providerOriginVerified=false ; payment, authorization et factualAccuracy valent not_checked.

| État enregistré | Combinaison acceptée par le lecteur |
|---|---|
| verified_signed_declaration | Aucun code ; signature/context/currentTrustPolicy=verified ; responseBody=matches |
| incomplete, code=response_not_included | Les trois contrôles précédents=verified ; responseBody=not_included |
| incomplete, code=expected_context_required, legacy_trust_requires_explicit_mode, policy_input_unavailable ou policy_verifier_unavailable | Les trois contrôles et responseBody=not_checked |
| invalid, code=artifact_mismatch | Les trois contrôles=verified ; responseBody=differs |
| invalid, code=trust_context_or_document_invalid | Champs et valeurs autorisés ci-dessus conservés tels que rapportés ; aucune réussite déduite |

Cette table aide à reconnaître un export existant ; elle ne sert pas à produire des contrôles ou réécrire un refus. Aucune de ces combinaisons n'authentifie une source à la relecture. Un code0 sauvegardé n'est pas une admission Reputation ; code2 et dates restent historiques. Le corps non inclus dans le document contrôlé peut être conservé ailleurs, comme dans le cas synthétique173.

### Reprise après invalid_verification_report

Conserver l'entrée et le rapport originaux. Comparer les noms de champs, types, référence liée, doublons et date avec cette notice. Si le problème vient de l'assemblage de l'entrée, corriger seulement cet assemblage vers un nouveau fichier ; si le rapport lui-même est d'un autre format, ne pas lui attribuer des checks pour le rendre compatible. Utiliser l'outil d'origine ou une analyse distincte dont les limites sont explicites. Relancer init vers un nouveau dossier, puis show. Aucun nouveau reçu, achat, signataire ou appel réseau n'est requis par cette correction de forme.

Pour reprendre une révision existante, utiliser le fichier dossier produit par init/apply (schema=datoka.reputation.local-case.v1). Le fichier exporté par export est une analyse, pas un dossier à rouvrir avec apply/show. Conserver toujours le dernier dossier et l'événement non appliqué, notamment en cas de case_output_too_large.


## Événement de révision

Objet exact : eventId, at, actorRef, action, targetIndex, targetId, note, patch. eventId unique ; at entier Unix >= instant précédent ; actorRef identifiant déclaré ; note1à500caractères sans contrôle. Historique déclaratif, non signé, non inviolable.

- contest / withdraw_contestation : index à partir de0 et id exacts de la ligne, patch=null. L'état doit changer.
- rectify : cible index/id exacte ; patch contient seulement observedAt, context complet, sourceGroup ou evidenceRef. serviceId/id/sourceId/provenance immuables. Ne pas laisser un rapport orphelin après changement de référence.
- reevaluate : targetIndex=null, targetId=null, patch=null ; at strictement supérieur à asOf. Observations et rapports restent inchangés.

Une correction ne crée aucune autorité. Pour une autre observation originale, préparer une entrée distincte en conservant la pièce et l'ancien dossier. Ne pas réécrire rétroactivement l'historique.


# RésultatsJSON, dossiers et notes — permission adoptée le26 octobre2026

Permission adoptée avec les conditions du26 octobre2026, distincte des droits sur les six sources. Les commandes sauvegardent une entrée/dossier, des révisions déclaratives, un diagnostic texte et une analyseJSON ; elles n’exportent pas les modulesJS du logiciel. Les fichiers contiennent identifiants, contexte, dates, provenance, motifs, rapports, notes et avant/après. Ils ne sont ni anonymisés ni signés/inviolables.

La permission logicielle n’ajoute pas d’interdiction de conserver, copier, utiliser, annoter/rectifier et transmettre ces résultats dans les usages personnels/professionnels et travaux pour destinataires/clients, **dans la limite des droits réellement détenus sur toutes les données et pièces concernées**, des règles de confidentialité, accès et protection applicables. Ce n’est pas une déclaration que ces données appartiennent à l’utilisateur ou à Datoka, ni une autorisation de rendre publiques des données de tiers. Aucun droit tiers n’est accordé ou garanti par cette clause.

Conserver la provenance et les lacunes utiles ; signaler corrections/annotations pour ne pas attribuer à Datoka ou au producteur de preuve une conclusion modifiée. Utiliser les révisions prévues et conserver les originaux ; une modification externe du JSON ne crée ni authentification ni historique inviolable. Les droits de partage d’une note ou du JSON ne donnent pas la permission de redistribuer les six sources/paquet complet.

Pas d’envoi automatique : chaque partage effectif doit être autorisé sur son destinataire, sa portée et ses pièces. Le terminal peut conserver stdout/stderr ; choisir les fichiers et les emplacements avec les permissions appropriées. Aucun fichier utilisateur, clé, registre, capture ou rapport réel ne figure dans l’archive remise. Une date ou signature rapportée n’est pas une vérification nouvelle ; scoreNULL/nonévalué/admission0/publicationfalse conservés.