Proof
Voyez la décision. Comprenez exactement ce que la trace établit.
Inspectez une trace de contrôle d’exemple, la règle appliquée et les empreintes associées à une réponse encadrée. Une trace de décision explique le contrôle. La réalisation d’un paiement, d’un remboursement ou d’une réservation doit être confirmée à sa source.
Les exports signés, les valeurs d’empreinte, les résultats externes et les reçus HMAC sont des contrôles différents.
Reçu de conformité
Exemple chiffréÉchantillon synthétique
- Empreinte d’entrée
0x92f2242f4701ee89…83b61cea- Empreinte de sortie
0x8a09586162b314e2…d79c6b92- Empreinte de preuve
0xa8154f5f53e495a5…af2231ba- Code d’authentification (HMAC)
0xed8c2d6ef474c9e5…1433dd3cClé d’Audact nécessaire
Exemple chiffré. Acme GmbH, Nova Industries et Kestrel Industries sont fictifs ; aucune donnée client n’apparaît ici. Ce sont des valeurs du reçu d’exemple disponible à /sample-receipt.json. /receipt-explorer recalcule dans votre propre navigateur les trois valeurs sans clé : l’empreinte d’entrée, l’empreinte de sortie et l’empreinte de preuve. Le code d’authentification (le champ nommé signature dans le fichier) est un HMAC sous une clé symétrique que détient Audact ; il ne peut pas être contrôlé sans elle.
Filiation des preuves
Une décision, et ce que chaque niveau de la trace établit.
Commencez par la décision elle-même, en mots simples. Ouvrez ensuite chaque niveau de la trace, de l’événement de décision à un résultat externe : ce qu’il établit, et où il s’arrête.
Une décision, en mots simples
Exemple synthétique · aucune interaction réelle
The agreement covers the renewal of the Müller account. The proposed terms are within the policy limits. Please proceed.The agreement covers the renewal of the Müller account. The proposed terms are within the policy limits. Please proceed, subject to legal confirmation of the jurisdiction clause.Ajouté par le contrôle
- Verdict
- MODIFY
- Version de règle
- DE_v1.1.0
- Configuration
- 12
Le contrôle a renvoyé MODIFY : le texte libéré ajoute une condition que le brouillon omettait. La trace nomme la version de règle et la version de configuration, et conserve les deux textes sous forme d’empreintes, pas de mots.
Il s’agit du fichier d’exemple public qu’utilise l’explorateur de reçus. Il n’est pas lié à l’exemple Voice de la page d’accueil. Les textes d’exemple sont en anglais, comme dans le fichier.
Les quatre niveaux de la trace
- Trace de décision:
Le verdict, la version de règle et la version de configuration en vigueur pour ce contrôle, enregistrés comme un événement de la chaîne de preuves.
N’établit pas
Que la règle était la bonne pour votre entreprise, ou ce que l’appelant a entendu. Une trace de décision explique le contrôle ; ce n’est pas une transcription.
- Reçu:
- Recalcul de l’exemple:
- Vérificateur public:Pas encore disponible
Que la trace est intacte : une modification ou une réorganisation ultérieure est détectable par recalcul par rapport à un commitment conservé.
Trois valeurs se recalculent sans clé à partir de l’exemple public : l’empreinte d’entrée, l’empreinte de sortie, l’empreinte de l’événement de preuve précédent.
N’établit pas
Qui l’a émis, et si l’événement sous-jacent est avéré.
Le code est HMAC-SHA256 sous une clé symétrique détenue par Audact, donc quiconque peut le contrôler peut aussi le produire : l’émetteur ne peut pas être contrôlé publiquement.
- Export de production:
- Racines de Merkle:
Que le fichier d’export, pris dans son ensemble, provient du détenteur de la clé de signature et n’a pas changé depuis sa signature. Sa clé publique est servie à /v1/keys/{kid}.
Les racines de Merkle sont publiées, chacune chaînée à la précédente, à api.audact.ai/v1/metachain. N’importe qui peut les lire sans clé ni compte.
N’établit pas
Que les reçus qu’elle contient portent une signature : ils gardent leur HMAC, que seul Audact peut contrôler.
Qu’un appel donné est inclus dans une racine : une preuve n’existe qu’après l’agrégation de la fenêtre de l’appel. Et un service qui contrôle un reçu pour un tiers : il n’en existe aucun aujourd’hui.
Que les racines sont ancrées en dehors d’Audact : Audact les publie lui-même, une racine n’est donc pas un ancrage indépendant fourni par un tiers.
Que l’export a été contrôlé de bout en bout par une partie extérieure à Audact. Et le pack de preuves mensuel, qui n’a pas été mesuré.
- Source de résultat:Aucune source de clôture connectée
Seul le système qui a exécuté une action peut la confirmer : un agenda, un CRM, un prestataire de paiement ou un ERP, avec son propre identifiant et son heure.
N’établit pas
Une trace de décision ou un reçu ne prouve pas qu’une réservation, une remise ou un paiement a eu lieu dans un autre système.
Aucune source de résultat n’est liée à l’exemple de cette page, ni à l’exemple Voice de ce site.
Limites de la preuve
Ce que montre chaque contrôle — et ce qu’il ne montre pas.
Chaque contrôle répond à une question, et aucun ne répond à celle d’un autre. Lu dans son propre périmètre, un enregistrement est exact.
- Artefact ou contrôle
Exemple de reçu
L’empreinte d’entrée, l’empreinte de sortie et l’empreinte de l’événement de preuve précédent
- Ce qu’il montre
- Trois valeurs se recalculent à partir d’éléments du même fichier d’exemple — dans votre propre navigateur, sans clé.
- Ce qu’il ne montre pas
- Qui a émis le fichier, ni si quoi que ce soit a réellement été dit ou exécuté.
- Artefact ou contrôle
HMAC-SHA256 du reçu
- Ce qu’il montre
- Un code d’authentification sous une clé symétrique propre à chaque locataire, détenue par Audact. Quiconque détient cette clé peut le contrôler.
- Ce qu’il ne montre pas
- Pas une signature à clé publique : il ne désigne aucun émetteur indépendant et n’offre aucune non-répudiation — quiconque peut le contrôler peut aussi le produire.
- Artefact ou contrôle
Chaîne de racines de Merkle
- Ce qu’il montre
- Les racines de Merkle sont publiées, chacune chaînée à la précédente, à api.audact.ai/v1/metachain. N’importe qui peut les lire sans clé ni compte.
- Ce qu’il ne montre pas
- L’inclusion d’un appel individuel : il faut pour cela le chemin de Merkle propre à cet appel, tiré de son rapport au titre de l’article 50, confronté à la bonne racine. Une racine seule ne prouve ni un appel ni un résultat. Les racines se trouvent sur le point d’accès propre à Audact ; aucun ancrage chez un tiers n’existe aujourd’hui.
- Artefact ou contrôle
Export signé ECDSA-P256
mesuré sur des appels par navigateur plutôt que sur une ligne téléphonique · testé à nouveau le 26 août 2026, après le déploiement
- Ce qu’il montre
- L’intégrité et l’authenticité du conteneur d’export lui-même, dans le cadre des hypothèses documentées de clé et de confiance, lorsqu’un contrôle extérieur à Audact réussit. Sa clé publique est servie à /v1/keys/{kid}.
- Ce qu’il ne montre pas
- Que chaque reçu qu’il contient soit contrôlable publiquement — les reçus gardent leur HMAC, que seul Audact peut contrôler — ni que les événements sous-jacents soient avérés. Aucune partie extérieure à Audact n’a encore contrôlé l’export de bout en bout.
- Artefact ou contrôle
Horodatage RFC 3161
- Ce qu’il montre
- Un horodatage rapporté par freeTSA.org pour l’empreinte qui lui a été transmise.
- Ce qu’il ne montre pas
- Pas un horodatage eIDAS qualifié : freeTSA.org est un service public gratuit, pas un service de confiance qualifié. Il ne dit rien de la survenue d’un événement métier.
- Artefact ou contrôle
C2PA, sur demande
- Ce qu’il montre
- Un manifeste C2PA distinct pour l’enregistrement d’un appel : émis sur demande, lié à cet enregistrement par une empreinte et marqué comme généré par IA, dans le périmètre testé.
- Ce qu’il ne montre pas
- Qu’un manifeste C2PA distinct satisfait à l’article 50, paragraphe 2 pour un déploiement donné : l’obligation incombe au fournisseur du système générateur. Ni un filigrane intégré à l’audio, ni une émission automatique pour chaque appel, ni une chaîne de signature issue d’une autorité de certification tierce : aujourd’hui la chaîne s’arrête à une racine Audact.
- Artefact ou contrôle
Événement de résultat métier externe
Résultat: Aucune source de clôture connectée- Ce qu’il montre
- Une preuve uniquement dans les limites des droits et de la signification du système de référence qui le rapporte : prestataire de paiement, CRM, ERP ou agenda.
- Ce qu’il ne montre pas
- Il ne peut pas être déduit d’un seul reçu Audact. Un engagement inscrit dans un reçu est un engagement, pas un événement accompli.
Champ par champ
Ce que contient un reçu
Un reçu est un objet par interaction encadrée. La plus grande partie est une trace : vous pouvez la lire, et la lire vous dit ce que le système estimait à ce moment-là. Trois valeurs peuvent être recalculées sans clé, à partir du reçu, du texte sur lequel elles ont été calculées et de l’événement précédent de la chaîne (dans le fichier d’exemple : sample_texts et preceding_event) : sans compte, sans accès à nos systèmes. Le code d’authentification est calculé sous une clé symétrique que détient Audact : il authentifie le reçu mais ne peut pas être contrôlé sans la clé.
- Champ
- receipt_format_version
- Ce qu’il consigne
- La version du schéma du reçu. '1.0.0' dans cet exemple.
- Contrôle
- Lire
- Champ
- call_id
- Ce qu’il consigne
- L’identifiant unique de l’interaction.
- Contrôle
- Lire
- Champ
- timestamp
- Ce qu’il consigne
- Le moment où le reçu a été écrit, d’après l’horloge de la plateforme.
- Contrôle
- Lire
- Champ
- input_hash
- Ce qu’il consigne
- SHA-256 du texte d’entrée, tel que le système l’a reçu.
- Contrôle
- Champ
- output_hash
- Ce qu’il consigne
- SHA-256 du texte de sortie, tel que le système l’a renvoyé. Verdict MODIFY : diffère de input_hash.
- Contrôle
- Champ
- verdict
- Ce qu’il consigne
- La décision de la porte de contrôle : ALLOW, BLOCK ou MODIFY.
- Contrôle
- Lire
- Champ
- config_version
- Ce qu’il consigne
- La version de configuration active au moment de l’interaction.
- Contrôle
- Lire
- Champ
- config_seal_hash
- Ce qu’il consigne
- SHA-256 de la configuration à cette version.
- Contrôle
- Lire
- Champ
- policy_version
- Ce qu’il consigne
- La version de la politique appliquée à cette interaction.
- Contrôle
- Lire
- Champ
- evidence_hash
- Ce qu’il consigne
- SHA-256 de l’événement de preuve précédent dans la chaîne de preuves de l’appel.
- Contrôle
- Champ
- auth_mechanism
- Ce qu’il consigne
- L’algorithme d’authentification : 'hmac-sha256'.
- Contrôle
- Lire
- Champ
- signature
- Ce qu’il consigne
- HMAC-SHA256 sur la charge utile authentifiée, sous une clé symétrique que détient Audact. Malgré le nom du champ, c’est un code d’authentification et non une signature.
- Contrôle
- Clé nécessaire
Chaque nom de cette colonne est un champ du reçu d’exemple à /sample-receipt.json, orthographié comme le fichier l’orthographie : ouvrez le fichier et chacun s’y trouve.
La chaîne
Chaque reçu nomme l’événement qui le précède.
Un reçu ne se tient pas seul. Avant son écriture, l’empreinte de l’événement précédent dans la chaîne de preuves de l’appel y est intégrée sous le nom evidence_hash, de sorte que les événements d’un même appel forment une seule chaîne ordonnée. Le schéma ci-dessous montre la même idée sur l’ancien exemple illustratif, où chaque reçu porte l’empreinte du reçu qui le précède.
C’est ce qui rend une modification visible. Modifiez une valeur dans un reçu et son empreinte change ; l’enregistrement qui suit porte toujours l’ancienne empreinte, et les deux cessent de correspondre. Rien ici n’empêche une modification ; elle devient visible pour quiconque parcourt la chaîne.
Reçu RCP-899
- Porte l’empreinte de
0xc15f…df07- Sa propre empreinte
0xe48f…5a07
Reçu RCP-900
- Porte l’empreinte de
0xe48f…5a07- Sa propre empreinte
0x42c8…5196
Reçu RCP-901
- Porte l’empreinte de
0x42c8…5196- Sa propre empreinte
0x44a7…4be4
Si l’un change
Chaque reçu qui le suit cesse de correspondre, et la première discordance nomme la position où la chaîne s’est rompue. L’ajout seul est notre façon d’écrire. La détectabilité est ce que vous pouvez contrôler.
Journal d’audit
Chaîne d’événements en ajout seul. Toute modification ou réorganisation ultérieure est détectable en recalculant la chaîne par rapport au commitment que nous avons conservé.
Inclusion
Comment l’inclusion dans une racine est contrôlée.
Les reçus sont agrégés en racines de Merkle par locataire ; les racines sont publiées à api.audact.ai/v1/metachain. Les quatre étapes ci-dessous montrent le recalcul du chemin sur un ancien exemple illustratif qui porte les champs du chemin, présentés ici sous forme abrégée. Pour un appel réel, la preuve d’inclusion figure dans son rapport au titre de l’article 50.
- Chemin à partir de ce reçu
- Empreintes voisines utilisées
- Autres reçus du lot
Quatre étapes
- 1
Hacher les cinq champs de base
Prenez receipt_id, issued_at, input_hash, output_hash et previous_receipt_hash, écrivez-les sous une forme fixe (clés dans l’ordre alphabétique, sans espace) et calculez le SHA-256. Cette valeur est la feuille, et le reçu la porte sous le nom receipt_hash. Ce n’est pas une empreinte de l’ensemble du reçu.
- 2
Intégrer la première empreinte voisine
Décodez la feuille et la première empreinte de merkle.path en octets, placez l’empreinte voisine du côté que nomme son champ side, joignez les deux et calculez le SHA-256 de la paire.
- 3
Remonter
Répétez l’opération pour chaque entrée restante de merkle.path, un niveau à la fois, jusqu’à ce qu’il ne reste qu’une seule valeur.
- 4
Comparer
Comparez cette valeur à merkle.root. Une valeur égale signifie que ce reçu correspond à la racine que porte le fichier lui-même. Pour confirmer l’inclusion, cette racine est contrôlée par rapport à la racine publiée à api.audact.ai/v1/metachain, avec la preuve d’inclusion du rapport de l’appel au titre de l’article 50.
Aucune de ces quatre étapes n’utilise de clé : le reçu et son chemin suffisent. Elles établissent que le reçu correspond à la racine qu’il porte. L’inclusion dans la racine publiée se contrôle avec la preuve d’inclusion du rapport de l’appel au titre de l’article 50 ; les racines se trouvent à api.audact.ai/v1/metachain.
Tiré de l’ancien exemple illustratif
- Champ
- receipt_hash
- Dans l’exemple
- 0x44a7eb700e052017…88b04be4
- Champ
- merkle.leaf_index
- Dans l’exemple
- 2
- Champ
- merkle.path
- Dans l’exemple
- right · left · right
- Champ
- merkle.root
- Dans l’exemple
- 0x4ff330dbe475e710…a8901b00
À faire vous-même
Démontez un reçu.
L’explorateur parcourt l’exemple détaillé champ par champ, avec les fichiers d’exemple à côté. Rien de tout cela ne nécessite de compte.
- Explorateur de reçus
Parcourez l’exemple détaillé champ par champ.
- Reçu d’exemple (JSON)
Valeurs synthétiques, arithmétique réelle : trois valeurs se recalculent à partir du seul fichier. Le fichier ne porte aucun chemin de Merkle ; l’inclusion se contrôle avec la preuve du rapport d’un appel au titre de l’article 50.
- Reçu d’exemple (PDF)
La même trace sous une forme qu’un délégué à la protection des données peut lire.
- API Evidence Vault
Comment les reçus sont écrits et récupérés.
- Comment le recalculer — la forme exacte
La forme exacte des trois recalculs, ce qui ne peut pas être contrôlé sans clé, et un script Node sans dépendances qui affiche ok trois fois sur le fichier.
Chaîne de preuves
Trois de ces valeurs peuvent être recalculées dès aujourd’hui sans clé, à partir du reçu, du texte sur lequel elles ont été calculées et de l’événement précédent de la chaîne : sans compte, sans accès à notre base de données.
Contrôler le code d’authentification exige la clé symétrique propre au locataire, que détient Audact.
Control what AI can cause. Prove what follows.
D’où vient un reçu
Un reçu est ce que laisse derrière lui un appel encadré.
Voice est l’application dont il provient : téléphonie, information de la personne au titre de l’article 50 et politique par pays au même endroit, avec un reçu visible dans le produit pour les interactions encadrées.