Event Ledger for AI Tools | Dweve Ledger

Rust ledger for AI tool interactions with BLAKE3 hash chaining and integrity checks. Apache 2.0 terms; publishing in the second release round.

Groupes d'algorithmes par type de données

Gouvernance des connaissances qui utilise Ledger comme épine dorsale d'audit.

Analyser la source en arbres avec des nœuds adressés par contenu.

Transcriptions d'exécution dans un bac à sable. Ledger capture ce qui s'est passé ; Selvedge capture comment cela s'est exécuté.

Certificats d'étapes de raisonnement au sein d'une seule décision, pas de provenance d'événements à travers un système.

Ledger publie dans le deuxième cycle du programme de version fondatrice de Dweve ; une fois cela fait, pointez la construction vers votre backend de stockage et inspectez votre première ajout, vérification de hachage et relecture en une seule exécution locale.

Chaque événement. Chaîné par hachage. Interrogeable.

Journal d'événements typé et chaîné par hachage

Ledger est fourni comme crate Rust, ABI C, processus sidecar et binaire de service. Le modèle sidecar est le déploiement de production le plus courant. Le même format d'événement circule dans toutes les variantes.

Choisir selon l'échelle et le besoin d'audit

Mémoire pour les tests. JSONL pour la portabilité. SQLite pour l'embarqué. Postgres pour la puissance des requêtes. S3 pour l'archivage. La forme du journal et la chaîne de hachage sont identiques sur les cinq. La migration entre les niveaux est une opération de copie, pas un réencodage.

Consentement, DPIA, effacement, droits des personnes.

Session et rejeu, plus point de contrôle.

Les appels d'outil, les approbations, les artefacts, les vérifications de politique et les modifications système conservent chacun leur propre forme typée. Cela rend l'historique suffisamment précis pour être interrogé sans aplatir chaque événement en une ligne de journal ambiguë.

Les chiffres sont un instantané de référence en mémoire provenant de la source Ledger fournie, pas un SLA publié. Exécutez le harnais inclus avant de dimensionner une charge de travail.

Instantané, 100 événements, intégrité BLAKE3.

Instantané en mémoire, ledger_append_event.

Typé, chaîné par hachage et interrogeable.

Allez à un horodatage, reconstruisez l'état.

Les ancres de confiance scellent un segment.

Chaque entrée intègre le hachage précédent.

Une des 23 variantes typées est ajoutée à la fin.

Les événements sont typés, hachés avec BLAKE3, signés avec Ed25519 aux ancres de confiance et persistés dans le backend de votre choix. Le pipeline est le même quel que soit le stockage. Survolez une étape pour lire son contrat.

Impossible de reconstruire l'état à partir du seul journal.

Les horloges multi-processus dérivent. Pas d'ordre canonique.

Troncature en fin, rotation des journaux, facile à modifier.

Texte libre, recherche par grep uniquement, champs ambigus.

La plupart des systèmes d'IA écrivent des journaux texte non structurés que personne ne peut rejouer. Les tableaux de bord SIEM résument, mais ne peuvent pas reconstruire une décision. Les auditeurs se retrouvent avec de la prose.

Les journaux ne peuvent pas rejouer un système

Pas de courtier ni de service d'événements hébergé.

Parcours linéaire, aucune dépendance à un solveur.

Une seule commande. Le rejeu parcourt chaque événement dans l'ordre, vérifie la chaîne BLAKE3 et reconstruit l'état à tout horodatage. Les chiffres ci-dessous sont un instantané de benchmark en mémoire provenant du code source Ledger fourni, et non un SLA publié. Exécutez le harnais sur votre propre matériel.

Coupé d'Internet, pour les enregistrements les plus sensibles.

Une région cloud ancrée dans un pays européen, sous les règles européennes.

Il fonctionne sur les ordinateurs gérés par votre propre équipe, dans vos murs.

Un seul enregistrement, pas de reconstruction

Propriétés du projet et modes de déploiement pris en charge ; pas une revendication de niveau de service ou de capacité.

Aucun requis pour ajouter, vérifier ou rejouer.

Une chaîne sur tous les backends pris en charge.

Un enregistrement conçu pour accompagner le système

Liste des logiciels et attestation, enregistrés.

Demandé, accordé ou refusé, enregistré dans l'ordre.

Un incident d'IA est enregistré dès qu'il est détecté.

Consentement, analyse d'impact, effacement et droits des personnes, chacun un événement typé.

Rejouez n'importe quelle fenêtre directement à partir des événements enregistrés.

État que vous ne pouvez pas reconstruire

Les événements d'approbation regroupent l'acteur, la portée et le résultat.

Les liens de hachage rendent visible toute suppression, réorganisation ou modification.

Un enregistrement typé remplace les jointures médico-légales sur des journaux partiels.

Ce que cela économise, ce que cela réduit comme risque

Conservez la même forme d'événement en mémoire, SQLite, Postgres, S3 ou votre backend.

Reconstruisez l'état à partir des événements au lieu de vous fier à un instantané.

Chaque entrée prolonge la chaîne, donc les modifications silencieuses échouent à la vérification.

Les nouveaux événements sont ajoutés sans réécrire l'historique antérieur.

Le moment le plus difficile est lorsqu'un auditeur ou un régulateur pose une question précise et que l'équipe doit fouiller. Ledger répond autrement : les choses qu'une revue interroge, le consentement, les incidents, les approbations, la chaîne d'approvisionnement, l'utilisation des outils, sont chacune enregistrées comme leur propre événement scellé lorsqu'elles se produisent. Choisissez une question ci-dessous et voyez quel événement enregistré détient déjà la réponse.

L'autre question qu'une revue pose est de savoir où le logiciel est autorisé à s'exécuter. Le même format d'enregistrement et les mêmes choix de stockage fonctionnent dans votre propre bâtiment, dans une région cloud européenne, ou entièrement isolés d'Internet. Passer de l'un à l'autre est une copie, pas une reconstruction coûteuse, donc la décision n'est jamais définitive.

Une revue d'approvisionnement pose deux questions simples : qu'est-ce que cela économise, et qu'est-ce que cela réduit comme risque ? Ledger évite aux équipes de recoudre des preuves à travers des journaux partiels lors d'un incident. Sa chaîne en ajout seul expose également toute tentative de modifier l'historique après coup.

Les applications changent, les fournisseurs bougent, et le stockage est remplacé. Ledger conserve un historique d'événements typé à travers ces changements, chaque entrée étant liée à la précédente. Les opérations peuvent tracer un incident, répondre à un audit, ou reconstruire l'état sans recoudre des journaux partiels.

L'enregistrement et son format simple vous appartiennent, pour le relire à tout moment.

Il reste à côté du système qu'il mémorise, sans autre compte ni tableau de bord sur le chemin.

Il peut se trouver sur un ordinateur dans votre propre bâtiment, pas chez un inconnu au loin.

Il peut rester sur un ordinateur dans votre propre bâtiment, proche de chez vous.

Il raconte exactement la même histoire sur chaque ordinateur, à chaque fois.

Vous pouvez le relire à partir de n'importe quel moment, comme rembobiner une vidéo maison.

Chaque ligne est scellée à la précédente, donc un changement discret se révèle.

Vous vous demandez plus tard ce qui s'est passé, ou quand ? C'est écrit pour vous.

Relisez-le sur n'importe quel ordinateur et vous obtenez exactement la même histoire.

Cette ligne est scellée à la ligne précédente, donc personne ne peut la modifier discrètement.

Quand l'IA fait quoi que ce soit, une nouvelle ligne est notée.

Fonctionne aux côtés du système dont il se souvient.

Toute falsification se voit immédiatement.

Le carnet reste avec le système qui l'utilise. Il n'y a pas de compte séparé à vérifier ni de tableau de bord distant à croire : votre propre équipe peut lire la même histoire ordonnée dès qu'une question se pose.

Il est légitime de se demander ce qui se passe si quelque chose tourne mal. Et si l'enregistrement était modifié ? Et si vous oubliez ? Et s'il dit quelque chose de différent ailleurs ? Choisissez une inquiétude ci-dessous et voyez, en termes simples, comment un enregistrement honnête y répond, pour qu'il y ait une chose de moins à vous empêcher de dormir.

Vous n'avez pas à comprendre toute la mécanique. Voici l'ensemble, du début à la fin, en quatre moments du quotidien. Quelque chose se produit, cela est écrit et verrouillé, cela reste exactement le même sur chaque ordinateur, et vous pouvez toujours poser des questions à ce sujet plus tard.

Pensez-y comme à un carnet qu'un outil d'IA tient pour lui-même. Chaque fois qu'il fait quelque chose, il écrit une ligne de plus en bas, et il ne revient jamais effacer ce qui est déjà là. Feuilletez les pages en termes simples ci-dessous pour voir, avec des images du quotidien, ce que chaque partie de ce carnet fait réellement pour vous.

Ledger est un enregistrement d'événements pour les systèmes d'IA. Il conserve un historique en ajout seul qui ne peut pas être modifié discrètement, de sorte que lorsqu'un auditeur ou un régulateur demande ce qui s'est passé, vous avez une réponse directe. Il est construit dans l'UE et peut fonctionner entièrement sur une infrastructure que vous contrôlez : un seul enregistrement de qui a appelé quoi, qui a approuvé quoi, et ce qui s'est passé ensuite.