Assay RecordVERSION 0.1
Position

L’IA ne sera jamais tenue responsable. Vous, oui.

Un format de trace ouvert pour ceux qui signent ce que l’IA écrit.

Le défaut que nous traitons a un nom : le biais d’automatisation avec une signature humaine.

Quand une note rédigée par l’IA tourne mal, personne n’ira demander des comptes au modèle. On les demandera à la personne qui a signé. C’est le risque ordinaire de cette décennie : des professionnels qui approuvent des décisions qu’une réponse d’IA avait déjà écrites pour eux, parce que ça se lisait bien et que la réunion était dans dix minutes.

La réponse n’attend ni moratoire ni percée technique. L’éducation, pour que chacun voie où son jugement est en train d’être transféré. La formation, pour apprendre à challenger ce qu’on lit. Une gouvernance stricte par protocole, pour que la supervision humaine laisse une trace.

Assay Record est le format ouvert de cette trace : ce qui a été vérifié, qui porte ce qui reste ouvert, et la preuve que rien n’a changé.

UN FORMAT OUVERT POUR LES DÉCISIONS ASSISTÉES PAR L’IA

La trace du jugement humain derrière une signature.

Un Assay Record consigne ce que le signataire a vérifié, ce qu’il a laissé ouvert et qui en est responsable, avant qu’il signe un projet rédigé avec l’aide d’une IA. Il prouve ce qui a été relu, et quand. Jamais que la décision était la bonne.

FICHIER · ILLUSTRATIFprotocole 1.3.3
TRIAGECRITIQUENiveaux 0 · 1 · 2 · 3 · 4
CONSTATS6
ATTRIBUÉES5/7questions avec un responsable
QUESTION À PLUS FORTE VALEURQue coûte la sortie du contrat de cinq ans si le prix augmente après la première année ?
SUIVI DU SIGNATAIRE
Poursuivre sous conditions5 questions sur 7 attribuéesVérifié par le DAFSigné
empreinte sha256 9f3c…e71asceau de l’émetteur · 2026-09-27 14:32 UTC
projetle contenu produit par l’IA, en cours de relecture
fichierle fichier que définit ce format
second lecteurcelui qui examine le projet : un protocole, un agent ou une personne
signatairela personne qui décide et signe
vérificateur · responsablele rôle humain qui vérifie une hypothèse · répond à une question
suiviqui a vérifié, qui est responsable de chaque question, la décision
résultatce qu’est devenue la décision, des mois plus tard (prévu)
registreoù une organisation conserve ses fichiers

Trois parties. Chacune utile à elle seule.

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

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 et son sceau. 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 recalculée à partir du fichier par chaque vérificateur, et le sceau de l’émetteur apposé dessus. Un horodatage par un prestataire de confiance qualifié est prévu. L’empreinte ne révèle rien du contenu. Pas de registre distribué, rien que le droit à l’effacement interdirait.

proof.fingerprint · proof.seal
COMMENT UN FICHIER EST PRODUIT

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. Personne n’a besoin de l’outil qui a produit le fichier pour le vérifier.

Second lecteurSignataireÉmetteurTout tiers SECOND LECTEUR SIGNATAIRE ÉMETTEUR TOUT TIERS 1Relecturedu projet 2Fichiersuivi laissé vide 3Suiviresponsables et décision 4EmpreinteSHA-256, profil publié 5Sceauclé de l’émetteur 6Vérifiertout tiers rapport suivi rempli fichier + sceau La vérification n’envoie que des empreintes, jamais les textes.

Aucun modèle ne remplit le suivi. Un fichier 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. Un JSON canonique (RFC 8785), pour une empreinte indépendante de l’outil qui l’a écrit, est prévu.

La vérification part du fichier. Recalculez l’empreinte à partir du fichier de preuve, puis vérifiez le sceau de l’émetteur (un seul appel, empreintes uniquement). Ne vous fiez jamais à une empreinte telle qu’elle est écrite.

COUCHE TECHNIQUE · VERSION 0.1

Le format en trois schémas.

Le modèle de données cible du format. La version 0.1 met en œuvre le fichier de preuve : les textes, leur empreinte et leur sceau, et le suivi avec la décision. Les champs structurés dessinés ici sont prévus pour l’entrée de registre.

1 · Modèle de données

LA RELECTURE LE SIGNATAIRE LA PREUVE recordformat · protocol_versioncontext.stakes_levellevels_appliedindependencehighest_value_question readers[ ]type · model_familysession findings[ ]id · impact · leveltechnique_id assumptions[ ]id · who_can_verifyif_false questions[ ]id · owner follow_upanswer: treated | deferred| already_seen | no_stake | wrongowner · at outcomeprévuanswer: held | corrected| reversed | incident | unknown prooffingerprint · sha256seal · issuertimestampplanned un par constat responsable scellé Pointillés : prévu au-delà de la version 0.1. Noms des champs comme dans la spécification.

2 · Chaîne de preuve

SCELLER · UNE FOIS, PAR L’ÉMETTEUR record.json textes + suivi { } entrée d’empreinte profil publié # SHA-256 9f3c…e71a demande de sceau émetteur · riftveil.ai sceau S1-… HMAC sur ID + digest VÉRIFIER · TOUT TIERS, À TOUT MOMENT 1 recalculer le digest depuis le fichier 2 demander à l’émetteur : ce sceau est-il valide ? valide · modifié
Ce que la preuve garantit

Les textes n’ont pas changé depuis que l’émetteur les a scellés, à l’heure donnée par son serveur. Un horodatage par un prestataire de confiance qualifié, indépendant de l’émetteur, est prévu.

Ce qu’elle ne garantit pas

Que la relecture était bonne, que la décision était la bonne, ni que le projet est ce qu’il prétend être. La preuve date un fichier ; le jugement reste humain.

3 · Chaîne de seconds lecteurs

l’indépendance est vérifiée maillon par maillon : jamais l’auteur, jamais la même session projet auteur : famille modèle A session 1 second lecteur 1 type : modèle famille B (protocole) session distincte second lecteur 2 type : agent spécialiste, optionnel famille B ou C second lecteur 3 type : humain ex. : juriste rôle nommé signataire suivi décision signature Pointillés : lecteurs optionnels, chacun inscrit dans readers[ ] avec son type, sa famille de modèles et sa session. Second lecteurSignataire

Un projet peut passer par plusieurs seconds lecteurs avant le signataire : un protocole, un agent spécialisé, un expert humain. Chacun est nommé dans le fichier 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’UN FICHIER

Dénombrable. Vérifiable. Jamais le projet lui-même.

Le fichier contient la structure de la relecture, pas le projet relu. Les décomptes doivent correspondre à leurs listes, pour qu’un script puisse vérifier un fichier sans comprendre le métier qui se trouve derrière.

■ issu du schéma de rapport Riftveil■ ajouté par Assay Record
{ "format": "assay-record/0.1", "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": "Procurement" } ], "questions": [ { "id": "Q1", "owner": "Procurement" } ], "outcome": { "answer": "held", "at": "2027-03-27" }, "fingerprint": "sha256:9f3c…e71a", "seal": "S1-7Q2M-…-4MH1" }
POURQUOI IL EXISTE

Une signature ne vaut que par le jugement qui la sous-tend.

Un contenu d’IA fluide se lit comme le travail de quelqu’un qui a déjà vérifié. Les personnes qui supervisent une automatisation fiable vérifient moins : le biais d’automatisation est un constat documenté de la recherche en facteurs humains, pas une hypothèse.

L’article 14(4)(b) de l’AI Act européen demande que les personnes chargées de superviser des systèmes d’IA à haut risque soient mises en mesure de rester conscientes du biais d’automatisation. Assay Record donne une trace à cette supervision. C’est un format, pas une revendication de conformité.

Qui utilise un fichier

LE SIGNATAIRE

Montre la diligence derrière une signature

Ce qui a été vérifié, ce qui a été reporté et à qui, daté et inaltéré. Un point ouvert déclaré honnêtement protège la personne qui a signé.

L’ÉQUIPE

Mesure la supervision, jamais les personnes

Part des constats traités, questions attribuées, points ouverts clos, validations sans réserve sur les relectures critiques. Agrégé par équipe de cinq signataires ou plus, jamais par personne.

L’AUDITEUR

Vérifie n’importe quel fichier, issu de n’importe quel outil

Un schéma, une empreinte à recalculer à partir du fichier de preuve, un sceau à vérifier. Un PDF seul ne prouve rien : le fichier de preuve, si.

Exemples de fichiers

CAS ILLUSTRATIFS, NON RÉELS · RÉPONSES PAR CONSTAT ET RÉSULTAT PRÉVUS
ACHATSRegrouper trois fournisseurs cloud en un seul
TriageCRITIQUE
Constats traités3 sur 6
Reportés, avec responsable1 · Finance
Résultat à six moistenu
FINANCENote de prévision trimestrielle au conseil d’administration
TriageÉLEVÉ
Constats traités2 sur 4
Jugés erronés par le signataire1
Résultat à six moiscorrigé
RHOffre d’emploi rédigée avec l’IA
TriageMODÉRÉ
Constats traités3 sur 3
Déjà vus0
Résultat à six moistenu

Chaque carte résume un fichier. Le fichier contient sa structure, son suivi et sa preuve. Aucun ne contient le projet.

Quatre façons de conserver les fichiers

Chaque fichier 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

Particuliers, première utilisation

Le signataire conserve le rapport exporté (PDF) et son fichier (JSON) dans ses propres dossiers. Pas de registre, pas de mise en place.

Gratuit
2 · MICROSOFT 365

Dans votre tenant

É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.

Inclus dans le Riftveil Pro Kit · les données restent dans le tenant
3 · VOS SERVEURS

Sur votre infrastructure

Organisations dotées de leur propre IT

Une procédure documentée pour votre équipe IT : stockage, règles d’accès, étapes d’empreinte et d’horodatage, sur les systèmes que vous exploitez déjà.

Procédure sur demande · sous votre responsabilité
4 · HÉBERGÉ

Par Riftveil, dans l’UE

Équipes sans administrateur

Fichiers stockés pour vous, dans l’UE. Uniquement le fichier, jamais le projet.

Prévu

Outils qui écrivent des fichiers

Mettre en œuvre la spécification
Riftveil

Protocole ouvert qui challenge un contenu produit par l’IA avant qu’un humain signe. Produit le fichier sur riftveil.ai et enregistre les rapports réalisés dans ChatGPT, Claude ou Microsoft 365 Copilot.

RÉFÉRENCE
Votre outil

Un outil de relecture, une plateforme GRC ou un framework d’agents peut écrire des fichiers. Tant qu’il n’existe pas de tests de conformité, la règle est simple : des fichiers de preuve valides selon le JSON Schema, vérifiables auprès de leur émetteur.

OUVERT
POUR LES IMPLÉMENTEURS

Quatre étapes, toutes sur des standards ouverts.

1Écrire le fichier en JSON, selon le JSON Schema publié.
2Valider le fichier avec le JSON Schema publié, avec n’importe quel validateur.
3Calculer l’empreinte en SHA-256, selon un profil publié.
4Sceller l’empreinte et publier un point de vérification ; un horodatage qualifié (RFC 3161) est prévu.
QUESTIONS
Un Assay Record est-il une certification ?Non. Il prouve ce qui a été relu et quand. Il ne dit jamais que la décision était la bonne.
Contient-il le projet ?Le fichier conservé dans un registre, non : seulement la structure de la relecture et son empreinte. Le fichier de preuve conservé par le signataire, oui, pour que chacun puisse vérifier que le texte est intact ; partagez-le comme vous partageriez le rapport.
Un rapport réalisé dans un autre assistant peut-il être enregistré ?Oui. Son empreinte est enregistrée auprès d’un émetteur comme Riftveil, et le fichier indique « enregistré », jamais « généré ». Il prouve la date et l’intégrité du texte, pas que la méthode a été bien appliquée.
Un modèle peut-il remplir le suivi ?Non. Un outil conforme laisse le suivi vide jusqu’à ce que le signataire réponde.
Faut-il Riftveil pour l’utiliser ?Non. Riftveil est l’implémentation de référence ; tout outil peut écrire et lire des fichiers.
Qui gouverne le format ?Human Frontier en assure la gestion. Tant que la version de travail est ouverte, les commentaires sont à adresser à hello@riftveil.ai.
Jamais le projet dans un registreLe texte reste chez le signataire, dans le fichier de preuve.
Le signataire remplit, jamais un modèleLe suivi et le résultat viennent uniquement de personnes.
Par équipe, jamais par personneLes indicateurs de supervision commencent à cinq signataires.
Une preuve sans registre distribuéUne empreinte et le sceau de l’émetteur. Un horodatage qualifié plus tard, si nécessaire.

Licence et gouvernance

Libre d’utilisation, protégé dans son nom. La spécification s’ouvre davantage à mesure qu’elle mûrit ; elle ne se referme jamais.

SPÉCIFICATION · VERSION 0.xCC BY-ND 4.0

Libre d’utilisation et de partage avec attribution. Pas de versions modifiées tant que le format mûrit.

SPÉCIFICATION · À PARTIR DE 1.0CC BY 4.0

Libre d’utilisation, d’adaptation et de réutilisation, avec attribution.

SCHÉMA ET VALIDATEURApache 2.0

Libre d’utilisation dans tout produit, avec une licence de brevet explicite.

LE NOMAssay Record

Le nom d’un format ouvert. Libre d’utilisation pour les outils qui écrivent des fichiers valides.

La version 0.1 est ouverte aux commentaires.

Lire la version de travailCommenter par e-mail