evidence.v1 · ed25519

Le reçu, expliqué

Chaque changement gouverné produit un reçu signé : evidence.v1. Cette page en est le détail complet : ce qu'il contient, pourquoi il est signé de cette façon, et comment n'importe qui peut le vérifier sans nous faire confiance.

Le reçu, annoté

// evidence.v1, un merge gouverné { "schema": "evidence.v1", "operationType": "code.merge", "actor": { "agent": "claude-code", "session": "7f3a" }, "provenance": { "decision": "DEC-214", "pr": 477 }, "checks": { "typecheck": "pass", "test": "pass:142", "scope": "src/payments/*" }, "redaction": "none", "sig": "ed25519:46367c53", "keyId": "sha256:", "ledger": "#9f2a" }
Vérifiez un reçu hors ligne, avec seulement la clé publique : $ rootblocks verify receipt.json --key rootblocks.pub ✓ signature valid · ledger #9f2a · not tampered

Remettez ce fichier à n'importe qui. Il n'a pas besoin de nous pour le vérifier.

  • operationType l'événement gouverné : un merge, une exécution, une release.
  • actor.agent quel agent a produit le changement, et sa session.
  • provenance.decision la décision humaine qui a autorisé ce changement. L'ancrage de la trace.
  • checks les gates et le périmètre de chemins appliqué, tels qu'ils ont réellement tourné.
  • redaction ce qui a été retiré du reçu, déclaré, pour que l'absence soit elle aussi auditable.
  • sig / keyId / ledger ed25519 sur les octets canoniques, la clé de signature, la position dans le ledger en écriture seule.

Pourquoi ed25519

Les signatures sont faites sur les octets canoniques du reçu, donc tout changement dans n'importe quel champ casse la signature. Il n'y a pas de place pour un reçu qui dit une chose et en prouve une autre.
ed25519 est un schéma de signature moderne et largement audité : petites clés, petites signatures, signature déterministe, et aucune autorité de certification requise. La vérification est une simple opération à clé publique qui tourne n'importe où, y compris sur des machines isolées du réseau.
La clé privée est générée à chaque installation et ne quitte jamais l'hôte du daemon. Chaque reçu porte son keyId, donc la rotation et la révocation font partie du format de preuve, pas une réflexion après coup.

Pourquoi la vérification hors ligne compte

Un auditeur, un client ou un régulateur ne devrait pas avoir à faire confiance à RootBlocks pour vérifier votre preuve. rootblocks verify prend un reçu et la clé publique, et répond avec des mathématiques, pas avec notre parole.
C'est la différence entre un log et une preuve. Un log vit à l'intérieur d'un système qui peut le modifier. Un reçu est signé dans un ledger en écriture seule et se vérifie n'importe où, sur n'importe quelle machine, sans compte et sans réseau.

Une politique, en entier

policy: payments-tier scope: allow: ["src/payments/**", "test/payments/**"] deny: ["**/secrets/**", "infra/**"] gates: [ typecheck, test, lint ] # all required allowedTools: [ Edit, Read, "Bash(npm *)" ] limits: { maxFiles: 40, maxRuntime: "20m" } onGateFail: block # no commit, no receipt

Modes de défaillance

Daemon hors service configurable par politique : fail-closed (les agents ne peuvent pas merger sans preuve) ou fail-open (ça tourne, marqué observé, réconcilié plus tard).
Plan de contrôle hors service les reçus sont d'abord écrits localement, dans le ledger en écriture seule, qui est ce qui tourne aujourd'hui. La synchronisation cloud (à venir avec les design partners) reprend à la reconnexion.
Un gate échoue pas de commit, pas de reçu. La tentative elle-même est enregistrée comme preuve.

Ce qui sort de votre infrastructure

Sort
Ne sort jamais
les empreintes de contenu
le code source
les signatures ed25519
les diffs
les métadonnées de checks (réussi/échoué)
les prompts de l'agent
les identifiants de décision et de PR
le contenu des fichiers

Les clés, et ce que la signature prouve

Générée à chaque installation, au premier lancement. La clé privée ne quitte jamais l'hôte du daemon.
Rotation chaque reçu porte son keyId, donc la rotation et la révocation font partie du format de preuve, pas une réflexion après coup. La procédure de réancrage arrive avec le programme entreprise.
Nous prouvons que cette exécution, sous cette politique, a été rattachée à cette décision humaine ratifiée. Nous ne certifions pas le raisonnement interne de l'agent, ce qui est exactement pourquoi nous ancrons la preuve dans la décision humaine, pas dans le récit du modèle.
checks.* + provenance.decision correspond à la Clause 8 de l'ISO 42001 (contrôle opérationnel) et à SOC 2 CC8.1 (gestion des changements).
ISO 42001 · SOC 2 →