Le format · version 0.1.1

Le format

Un fichier de trace est du JSON brut. N’importe quel assistant IA, outil ou registre peut l’écrire, et n’importe quel auditeur peut le lire et recalculer son empreinte sans l’outil qui l’a produit.

Les mots de la trace

projet: le contenu produit par l’IA, en cours de relecture
trace: ce que consigne ce format, comme une enveloppe scellée : le projet, le rapport, le suivi et leur preuve
fichier de trace: la trace enregistrée dans un fichier, que l’on garde et que l’on dépose pour la contrôler
second lecteur: celui qui examine le projet : un protocole, un agent ou une personne
signataire: la personne qui décide et signe
vérificateur · responsable: le rôle humain qui vérifie une hypothèse · répond à une question
suivi: qui a vérifié, qui est responsable de chaque question, la décision
résultat: ce qu’est devenue la décision, des mois plus tard (prévu)
registre: où une organisation conservera ses entrées de registre (la trace sans les textes), sur ses serveurs (prévu)

Trois parties. Chacune utile à elle seule.

01 · Structure
Ce qui a été examiné
Le projet, son contexte et le rapport du second lecteur, mot pour mot : le triage et ses critères, les constats classés par impact, les hypothèses avec un vérificateur humain nommé, les questions avec leurs responsables. Une forme structurée pour les registres est prévue.
content.project · content.context
content.report
02 · Suivi
Ce que le signataire en a fait
Rempli par le signataire, jamais par un modèle : qui a vérifié, ce qu’il a vérifié lui-même, qui est responsable de chaque question ouverte, la décision et une signature, avec sa propre empreinte, son sceau et sa signature. Il peut désigner le document final et être complété plus tard, sans effacer le suivi précédent. Prévu : une réponse fermée par constat et, des mois plus tard, le résultat.
follow_up · decision · signature
03 · Preuve
Qu’il n’a pas été modifié
Une empreinte SHA-256, que chaque vérificateur recalcule à partir du fichier de trace ; le sceau de l’émetteur, posé dessus, avec son horodatage, et sa signature, que chacun contrôle avec la clé publique. Le format prévoit des horodatages qualifiés (RFC 3161) ; chez Riftveil, ce sera une option de la traçabilité AttestScope. L’empreinte permet de confirmer un texte qu’on a déjà, sans le contenir. Pas de registre distribué : chacun garde ses fichiers de trace, et peut les effacer.
proof.fingerprint · proof.seal

Ce qui le distingue

01
On atteste une portée, pas un « oui » global
Le suivi dit ce que la personne a vérifié elle-même, les questions confiées, la décision et ses conditions. Une portée structurée, constat par constat, est prévue.
follow_up.checked · questions · conditions
02
Chaque question ouverte a un responsable nommé
Le rapport suggère un responsable pour chaque question ; la personne qui signe la confie à quelqu’un, par son nom.
questions[].suggested_owner · assigned_to
03
Le suivi est écrit par la personne, jamais par un modèle
Aucun modèle n’écrit, ne suggère ni ne complète l’identifiant, l’empreinte, le sceau ou un champ du suivi.
Spécification §04 · MUST NOT
04
Deux sceaux : l’évaluation, puis la décision
Le suivi a sa propre empreinte, qui inclut celle du rapport : un suivi n’appartient qu’à un rapport, et l’heure du sceau est dans le message scellé.
riftveil-seal-v1 · riftveil-decision-v1
05
riftveil.ai ne garde ni les textes ni la liste des traces
Le fichier de trace reste chez la personne ou dans son organisation. L’émetteur ne garde ni texte, ni liste d’identifiants, ni liste d’empreintes.
Spécification §05 · vie privée
06
N’importe qui peut vérifier, sans inscription
L’empreinte est recalculée dans le navigateur de la personne qui vérifie, qui contrôle aussi la signature Ed25519 avec la clé publique de riftveil.ai ; seuls l’identifiant, les empreintes et les sceaux partent vers riftveil.ai, qui contrôle les sceaux.
POST /api/verify · riftveil.ai/verify
07
Indépendant de l’assistant IA
Rapport généré sur riftveil.ai, ou fait dans un autre assistant IA puis enregistré : l’origine est distincte, avec un libellé de sceau par origine.
riftveil-seal-v1 · riftveil-register-v1
08
Un format ouvert
Spécification publiée sur attestscope.ai et sur GitHub, avec schéma JSON et vecteurs de test : un autre outil peut écrire ou vérifier une trace, avec son propre préfixe d’émetteur.
0.1 · attestscope.ai

Comment une trace est produite

D’une relecture à une preuve que chacun peut vérifier.

Six étapes, trois acteurs. Un second lecteur rédige la relecture, le signataire remplit le suivi et l’émetteur scelle l’empreinte. Pour contrôler une trace, chacun recalcule l’empreinte à partir du fichier de trace, puis demande à l’émetteur de confirmer le sceau.

Aucun modèle ne remplit le suivi. Une trace sort de l’étape 2 avec tous les champs du suivi vides ; seul le signataire les remplit à l’étape 3.

L’empreinte suit un profil publié. Chacun peut la recalculer à partir du fichier de trace. Un JSON canonique (RFC 8785), pour une empreinte indépendante de l’outil qui l’a écrit, est prévu.

Couche technique · version 0.1.1

Le format en trois schémas.

Le modèle de données cible du format. La version 0.1.1 met en œuvre le fichier de trace : les textes, leur empreinte, leur sceau et leur signature, et le suivi avec la décision, le document final et les suivis qu’il complète. Les champs structurés dessinés ici sont prévus pour l’entrée de registre (version 0.2).

1 · Modèle de données

2 · Chaîne de preuve

Ce que la preuve établit

Les textes n’ont pas changé depuis que l’émetteur les a scellés, à l’heure de son horloge. C’est l’émetteur qui contrôle le sceau, à partir des seules empreintes ; chacun contrôle la signature avec la clé publique de l’émetteur. Des horodatages qualifiés (RFC 3161) sont prévus.

Ce que la trace prouve, et ce qui reste à la personne qui signe

3 · Chaîne de seconds lecteurs

Un projet peut passer par plusieurs seconds lecteurs avant le signataire : un protocole, un agent spécialisé, un expert humain. Prévu pour la version 0.2 : chacun sera nommé dans la trace (readers[]) avec son type, sa famille de modèles et sa session, pour que la règle selon laquelle le second lecteur n’est jamais l’auteur puisse être vérifiée, et pas seulement affirmée.

Anatomie d’une trace · entrée de registre prévue (version 0.2)

Tout s’y compte, tout s’y vérifie, et le projet n’y figure jamais.

L’entrée de registre contiendra la structure de la relecture, pas le projet relu. Les décomptes devront correspondre à leurs listes, pour qu’un script puisse vérifier une trace sans comprendre le métier qui se trouve derrière.

issu du schéma de rapport Riftveil ajouté par AttestScope

{
  "format": "attestscope",
  "protocol_version": "1.3.3",
  "context": { "stakes_level": "CRITICAL",
               "levels_applied": [0,1,2,3,4] },
  "readers": [ { "type": "model", "model_family": "…",
                 "session": "separate" } ],
  "independence": "different_model_family",
  "findings": [
    { "id": "F1", "impact": "CRITICAL", "level": 4, "technique_id": "4.3",
      "follow_up": { "answer": "treated", "at": "2026-09-27" } },
    { "id": "F2", "impact": "HIGH", "level": 1, "technique_id": "1.4",
      "follow_up": { "answer": "deferred", "owner": "Finance" } }
  ],
  "assumptions": [ { "id": "A1", "who_can_verify": "Achats" } ],
  "questions": [ { "id": "Q1", "owner": "Achats" } ],
  "outcome": { "answer": "held", "at": "2027-03-27" },
  "fingerprint": "sha256:9f3c…e71a",
  "seal": "S1-7Q2M-…-4MH1"
}

Illustration d’une entrée de registre prévue.

Quatre façons de conserver les fichiers de trace

Chaque fichier de trace est produit de la même façon. Ce qui change, c’est l’endroit où il est conservé et qui en est responsable : toujours l’organisation, jamais le format.

1 · Conservé par soi
Avec le rapport
Personnes et équipes, dès aujourd’hui
La personne qui signe garde le rapport exporté (PDF) et son fichier de trace (JSON) sur son ordinateur, ou dans un dossier partagé du serveur de son organisation. Sans registre ni mise en place.
Disponible
2 · Microsoft 365
Dans votre Microsoft 365
Équipes sous Microsoft 365
Un kit de registre : liste SharePoint, permissions par élément, rétention Purview, notifications Power Automate. Une demi-journée pour un administrateur SharePoint.
Prévu pour le Riftveil Pro Kit · les données restent dans votre Microsoft 365
3 · Vos serveurs
Sur votre infrastructure
Organisations dotées de leur propre service informatique
Une procédure documentée pour votre équipe informatique : stockage, règles d’accès, étapes d’empreinte et d’horodatage, sur les systèmes que vous exploitez déjà.
Prévu · sous votre responsabilité
4 · Hébergé
Par Riftveil, dans l’UE
Équipes sans administrateur
Entrées de registre stockées pour vous, dans l’UE : la trace sans le projet.
Prévu

Pour les développeurs

Quatre étapes, toutes sur des standards ouverts.

Écrire le fichier de trace en JSON, selon le schéma JSON publié.
Valider le fichier de trace avec le schéma JSON publié, avec n’importe quel validateur.
Calculer l’empreinte en SHA-256, selon un profil publié.
Sceller l’empreinte et publier un point de vérification ; des horodatages qualifiés (RFC 3161) sont prévus.

Guide d’intégration

Questions

Un AttestScope Record est-il une certification ?: Non. C’est l’attestation de la personne qui signe, sur la portée de sa propre revue : scellé, il établit ce qui a été examiné, à l’heure de l’horloge de l’émetteur.
Contient-il le projet ?: Le fichier de trace, gardé par la personne qui signe ou dans le dossier partagé de son organisation, oui : c’est lui qui permet à chacun de contrôler que le texte est intact ; partagez-le comme vous partageriez le rapport. Le registre de l’organisation, prévu avec la version 0.2, gardera la structure de la relecture et les empreintes.
Qui gouverne le format ?: Riftveil publie le format. Les commentaires sont à adresser à hello@riftveil.ai.

Conserver la trace, la vérifier des mois plus tard

La trace reste chez la personne qui a signé, ou dans son organisation : riftveil.ai n’en garde aucune copie. Des mois plus tard, n’importe qui peut vérifier, sur le fichier de trace, que rien n’a changé depuis les sceaux.

Émetteur · riftveil.ai Personne qui signe Prévu

A · Où la garder Le fichier de trace reste chez vous, jamais chez l’émetteur B · Vérifier Trois contrôles, dans cet ordre ; chaque partie s’arrête à la première anomalie C · Six mois plus tard Ce que voit l’audit interne, et ce qu’un PDF seul ne peut pas montrer

A · Où la garderLe fichier de trace reste chez vous, jamais chez l’émetteur

Aujourd’hui
Sur son ordinateur
Dans le dossier de la décision, à côté du PDF exporté. Le fichier se télécharge depuis la page du rapport ; riftveil.ai n’en garde aucune copie.
Riftveil XT-261026-143205-7K3M-Q9XD-2B8F.json
Aujourd’hui
Dans un dossier partagé de l’organisation
Sur ses propres serveurs, avec les autres pièces de la décision. Possible dès aujourd’hui, sans aucun développement.
Décisions › 2026 › Contrat cloud › Riftveil XT-….json
Prévu
Registre de l’organisation
Version 0.2 : une entrée par trace, sans les textes, pour compter, suivre et retrouver. Avec le référentiel, retrouver les décisions signées sous une version donnée.
entrée de registre = la trace sans son contenu

Qui détient le fichier de trace détient les textes et les noms du suivi : le partager comme on partage le rapport.

Personne ne vérifie ? La réponse est organisationnelle : rendre le fichier de trace obligatoire dans le dossier de décision.

Partie suivante : B · Vérifier

B · VérifierTrois contrôles, dans cet ordre ; chaque partie s’arrête à la première anomalie

Fichier de tracereçu ou retrouvé
1 · Recalculer l’empreintedepuis le texte du fichier, selon son profil, dans le navigateur
Identique à celle écrite dans le fichier ?
- non
  Contenu modifié
  L’empreinte recalculée à partir du texte du fichier ne correspond pas à celle qu’il annonce.
oui
2 · Contrôler le sceauidentifiant, empreinte recalculée et sceau envoyés à riftveil.ai
Réponse de riftveil.ai
- non valide
  Sceau non valide
  Ce fichier n’a pas été émis par riftveil.ai sous cet ID, ou il a été modifié.
- autre origine
  Origine falsifiée
  Le sceau est valide, mais pour une autre origine que celle annoncée par le fichier.
- valide
  Sceau valide
  « Rapport généré sur riftveil.ai le … Le texte ci-dessous est intact. »
Comparerle texte scellé au document qu’on vous a remis
3 · Contrôler le suiviempreinte recalculée (elle inclut celle du rapport), puis sceau et heure envoyés
Résultat pour le suivi
- différente
  Décision modifiée
  Son contenu ne correspond plus à son empreinte. Ne vous y fiez pas.
- pas de sceau
  Décision présente mais non scellée
  Rien ne prouve quand elle a été prise ni qu’elle n’a pas été modifiée.
- non valide
  Sceau de la décision non valide
  Ne vous y fiez pas.
- valide
  Suivi scellé
  « Suivi scellé par riftveil.ai le … », à l’heure de son serveur.

La règle

On vérifie le fichier de trace, jamais un PDF, une capture ou un imprimé seul : l’identifiant, l’empreinte et le sceau peuvent être recopiés sur un document modifié.

Lecture du schéma

Vert : le résultat tient ; montrer le texte scellé.
Rouge : ne vous fiez pas à ce document.
Ardoise : présent, mais rien ne le prouve.

Chaque contrôle s’arrête à la première anomalie, pour la partie concernée, comme le demande la spécification. Le suivi n’est contrôlé que si le rapport est intact.

Qui vérifie ? N’importe qui, sans inscription, sur riftveil.ai/verify ou avec le module intégré à un autre site.

Ce qui part vers riftveil.ai

L’identifiant
Les empreintes, recalculées par le vérificateur
Les sceaux
L’heure du sceau du suivi

Jamais

Les textes : projet, contexte, rapport, suivi
Une empreinte telle qu’écrite dans le fichier : elle est toujours recalculée

Requête

POST /api/verify
{ id, fingerprint, seal,
  decision?: { fingerprint,
               seal, sealedAt } }

Réponse

{ valid: true, id, issuedAt,
  origin, decision?: {
    valid, sealedAt } }
ou { valid: false }

Point d’accès ouvert à tout site : il reçoit des empreintes seulement et ne garde rien. Préfixes reconnus : riftveil.ai/issuers.json.

Partie suivante : C · Six mois plus tard

C · Six mois plus tardCe que voit l’audit interne, et ce qu’un PDF seul ne peut pas montrer

Trace intacteAudit interne, six mois après la décision

« Qui a validé ce contrat, et sur quelle base ? »

Elena envoie le fichier de trace. La page de vérification recalcule les empreintes dans le navigateur, fait contrôler les deux sceaux par riftveil.ai, puis affiche :

Page de vérification · riftveil.aiXT-261026-143205-7K3M-Q9XD-2B8F

Sceau valide. Rapport généré sur riftveil.ai le 26/10/2026 … Le texte ci-dessous est intact. · Origine : généré sur riftveil.ai

Suivi scellé par riftveil.ai le 26/10/2026 …

Ce que la personne a vérifié: Les prix des années 2 à 5 des trois offres, avec les achats.
Question 1: « Que coûte la sortie du contrat si le prix augmente après la première année ? » Confiée à Daniel Murphy, responsable des achats.
Décision: Je poursuis avec conditions
Conditions: Signature du contrat seulement après l’analyse du coût de sortie, présentée au conseil.
Signature: Elena Lambert, directrice financière · signature électronique simple

Le sceau porte sur la date et l’intégrité du texte ; le fond du projet et la décision restent ceux de la personne qui signe, sous le nom qu’elle a déclaré.

Illustration : un vrai fichier porte le préfixe RV de riftveil.ai ; un fichier d’essai XT serait refusé à la vérification.

Document modifiéLe PDF circule, le fichier de trace fait foi

Avant la réunion, quelqu’un retouche le PDF.

La décision devient « Je poursuis », sans conditions. L’identifiant, l’empreinte et le sceau imprimés sur le PDF n’ont pas changé : le PDF seul ne prouve rien. Le fichier de trace, lui, montre le texte scellé ; la différence apparaît.

Fichier de trace · texte scellé le 26/10/2026 à 16:05:12 UTC

Décision: Je poursuis avec conditions
Conditions: Signature du contrat seulement après l’analyse du coût de sortie, présentée au conseil.

PDF remis au conseil · retouché

Décision: Je poursuis
Conditions: Signature du contrat seulement après l’analyse du coût de sortie, présentée au conseil.

Sur la page de vérification« Comparez ce texte au PDF ou au document qu’on vous a remis. S’ils diffèrent, le document a été modifié. »

Et si l’on retouche le fichier ?La vérification le dit : « Décision modifiée : son contenu ne correspond plus à son empreinte. »

D · La portée de la preuveCe que la trace prouve, et ce qui reste à la personne qui signe

Ce que la trace prouve

Ce qui a été examiné : le projet, le contexte et le rapport exacts.
Ce que la personne en a fait et la portée qu’elle déclare : ce qu’elle a vérifié elle-même, à qui chaque question est confiée, sa décision et ses conditions.
L’heure, selon l’horloge du serveur Riftveil.
Que rien n’a changé depuis.

Ce qui reste à la personne qui signe

Juger si la décision est la bonne.
Riftveil pose les questions. La personne qui signe atteste ce qu’elle a examiné, et dans quelle limite. La décision, et sa conformité aux règles qui s’appliquent, relèvent de votre organisation.
Aujourd’hui, sur riftveil.ai : signature électronique simple, sous le nom que la personne a déclaré ; l’identité vérifiée relève de l’organisation. Prévu : l’identité donnée par le compte de l’organisation, ou une signature qualifiée.

Aujourd’hui

En service · spécification 0.1.1

Chaque sceau est posé par riftveil.ai (HMAC-SHA256) et se contrôle sur riftveil.ai, à partir des seules empreintes. Dans l’outil en ligne, la date est l’horodatage Riftveil : l’heure de son horloge.

Chaque trace de la version 0.1.1 porte une signature Ed25519, avec des clés publiques publiées, pour refaire le contrôle sans passer par riftveil.ai. Prévu : un horodatage qualifié en option, ou celui de l’organisation, pour une date indépendante.

Exemple illustratif : personnes, organisations et montants sont fictifs. Le préfixe XT est réservé aux essais : les sceaux et les signatures de l’exemple sont faits avec les clés de test publiques et ne valent jamais pour une décision. Exemple dans l’état en service (spécification 0.1.1) : le rapport et le suivi portent chacun un sceau et une signature de riftveil.ai ; la signature se contrôle avec la clé publique de riftveil.ai, sans passer par riftveil.ai.

La suite Spécification

Le format

Les mots de la trace

Trois parties. Chacune utile à elle seule.

Ce qui a été examiné

Ce que le signataire en a fait

Qu’il n’a pas été modifié

Ce qui le distingue

On atteste une portée, pas un « oui » global

Chaque question ouverte a un responsable nommé

Le suivi est écrit par la personne, jamais par un modèle

Deux sceaux : l’évaluation, puis la décision

riftveil.ai ne garde ni les textes ni la liste des traces

N’importe qui peut vérifier, sans inscription

Indépendant de l’assistant IA

Un format ouvert

D’une relecture à une preuve que chacun peut vérifier.

Le format en trois schémas.

1 · Modèle de données

2 · Chaîne de preuve

3 · Chaîne de seconds lecteurs

Tout s’y compte, tout s’y vérifie, et le projet n’y figure jamais.

Quatre façons de conserver les fichiers de trace

Avec le rapport

Dans votre Microsoft 365

Sur votre infrastructure

Par Riftveil, dans l’UE

Quatre étapes, toutes sur des standards ouverts.

Conserver la trace, la vérifier des mois plus tard

A · Où la garderLe fichier de trace reste chez vous, jamais chez l’émetteur

Sur son ordinateur

Dans un dossier partagé de l’organisation

Registre de l’organisation

B · VérifierTrois contrôles, dans cet ordre ; chaque partie s’arrête à la première anomalie