evidence.v1 · ed25519

El recibo, explicado

Cada cambio gobernado produce un recibo firmado: evidence.v1. Esta página es el detalle completo: qué contiene, por qué se firma como se firma, y cómo cualquiera lo verifica sin confiar en nosotros.

El recibo, anotado

// evidence.v1, un merge gobernado { "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" }
Verificá un recibo sin conexión, solo con la clave pública: $ rootblocks verify receipt.json --key rootblocks.pub ✓ signature valid · ledger #9f2a · not tampered

Entregá este archivo a cualquiera. No nos necesita para verificarlo.

  • operationType el evento gobernado: un merge, una ejecución, un release.
  • actor.agent qué agente produjo el cambio, y su sesión.
  • provenance.decision la decisión humana que autorizó este cambio. El ancla de la traza.
  • checks los gates y el alcance de rutas aplicado, tal como corrieron.
  • redaction qué se omitió del recibo, declarado, para que la ausencia también sea auditable.
  • sig / keyId / ledger ed25519 sobre bytes canónicos, la clave de firma, la posición de solo anexado.

Por qué ed25519

Las firmas se hacen sobre los bytes canónicos del recibo, así que cualquier cambio en cualquier campo rompe la firma. No hay lugar para un recibo que diga una cosa y pruebe otra.
ed25519 es un esquema de firma moderno y ampliamente auditado: claves chicas, firmas chicas, firma determinística, y sin necesidad de una autoridad certificante. La verificación es una sola operación de clave pública que corre en cualquier lado, incluso en máquinas aisladas de la red.
La clave privada se genera por instalación y nunca sale del host del daemon. Cada recibo lleva su keyId, así que la rotación y la revocación son parte del formato de evidencia, no una idea tardía.

Por qué importa la verificación sin conexión

Un auditor, un cliente o un regulador no debería tener que confiar en RootBlocks para revisar tu evidencia. rootblocks verify toma un recibo y la clave pública, y responde con matemática, no con nuestra palabra.
Esa es la diferencia entre un log y evidencia. Un log vive dentro de un sistema que puede editarlo. Un recibo se firma en un ledger de solo anexado y se verifica en cualquier lado, en cualquier máquina, sin cuenta y sin red.

Una política, completa

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

Modos de falla

Daemon caído configurable por política: fail-closed (los agentes no pueden mergear sin prueba) o fail-open (corre, marca observed, reconcilia después).
Plano de control caído los recibos se escriben primero localmente, en el ledger de solo anexado, que es lo que corre hoy. La sincronización con la nube (llegando con los design partners) se reanuda al reconectar.
Falla un gate sin commit, sin recibo. El intento en sí queda registrado como evidencia.

Qué sale de tu infraestructura

Sale
Nunca sale
hashes de contenido
código fuente
firmas ed25519
diffs
metadatos de checks (pasa/falla)
prompts del agente
IDs de decisión y de PR
contenido de archivos

Claves, y qué prueba la firma

Generada por instalación, en la primera corrida. La clave privada nunca sale del host del daemon.
Rotación cada recibo lleva su keyId, así que la rotación y la revocación están integradas en el formato de evidencia. El procedimiento de re-anclaje llega con el programa enterprise.
Nosotros probamos que esta ejecución, bajo esta política, quedó atada a esta decisión humana ratificada. No certificamos el razonamiento interno del agente, que es exactamente por qué anclamos la evidencia en la decisión humana, no en la narrativa del modelo.
checks.* + provenance.decision mapea a ISO 42001 cláusula 8 (control operacional) y SOC 2 CC8.1 (gestión de cambios).
ISO 42001 · SOC 2 →