evidence.v1 · ed25519

Der Beleg, erklärt

Jede kontrollierte Änderung erzeugt einen signierten Beleg: evidence.v1. Diese Seite ist das vollständige Detail: was er enthält, warum er so signiert wird, und wie ihn jeder verifizieren kann, ohne uns zu vertrauen.

Der Beleg, kommentiert

// evidence.v1, ein kontrollierter Merge { "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" }
Verifizieren Sie einen Beleg offline, nur mit dem öffentlichen Schlüssel: $ rootblocks verify receipt.json --key rootblocks.pub ✓ signature valid · ledger #9f2a · not tampered

Geben Sie diese Datei an jeden weiter. Er braucht uns nicht, um sie zu verifizieren.

  • operationType das kontrollierte Ereignis: ein Merge, eine Ausführung, ein Release.
  • actor.agent welcher Agent die Änderung erzeugt hat, und seine Session.
  • provenance.decision die menschliche Entscheidung, die diese Änderung autorisiert hat. Der Ankerpunkt der Spur.
  • checks die Gates und der durchgesetzte Pfad-Scope, so wie sie tatsächlich liefen.
  • redaction was aus dem Beleg entfernt wurde, deklariert, damit auch das Fehlen prüfbar ist.
  • sig / keyId / ledger ed25519 über kanonische Bytes, der Signaturschlüssel, die Position im append-only Ledger.

Warum ed25519

Signaturen werden über die kanonischen Bytes des Belegs erstellt, sodass jede Änderung an jedem Feld die Signatur bricht. Es gibt keinen Raum für einen Beleg, der eine Sache sagt und eine andere beweist.
ed25519 ist ein modernes, breit geprüftes Signaturverfahren: kleine Schlüssel, kleine Signaturen, deterministische Signierung, und keine Zertifizierungsstelle erforderlich. Die Verifizierung ist eine einzelne Public-Key-Operation, die überall läuft, auch auf netzisolierten Maschinen.
Der private Schlüssel wird pro Installation generiert und verlässt nie den Daemon-Host. Jeder Beleg trägt seine keyId, sodass Rotation und Widerruf Teil des Nachweisformats sind, kein nachträglicher Gedanke.

Warum Offline-Verifizierung wichtig ist

Ein Auditor, ein Kunde oder eine Aufsichtsbehörde sollte RootBlocks nicht vertrauen müssen, um Ihren Nachweis zu prüfen. rootblocks verify nimmt einen Beleg und den öffentlichen Schlüssel und antwortet mit Mathematik, nicht mit unserem Wort.
Das ist der Unterschied zwischen einem Log und einem Nachweis. Ein Log lebt innerhalb eines Systems, das es bearbeiten kann. Ein Beleg wird in einen append-only Ledger signiert und lässt sich überall verifizieren, auf jeder Maschine, ohne Konto und ohne Netzwerk.

Eine Policy, vollständig

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

Fehlermodi

Daemon nicht erreichbar konfigurierbar per Policy: fail-closed (Agenten können ohne Nachweis nicht mergen) oder fail-open (läuft, markiert als beobachtet, gleicht später ab).
Kontrollebene nicht erreichbar Belege werden zuerst lokal geschrieben, in den append-only Ledger, der heute läuft. Die Cloud-Synchronisation (kommt mit den Design-Partnern) setzt sich bei erneuter Verbindung fort.
Ein Gate schlägt fehl kein Commit, kein Beleg. Der Versuch selbst wird als Nachweis protokolliert.

Was Ihre Infrastruktur verlässt

Verlässt
Verlässt nie
Inhalts-Hashes
Quellcode
ed25519-Signaturen
Diffs
Check-Metadaten (bestanden/fehlgeschlagen)
Agenten-Prompts
Entscheidungs- und PR-IDs
Dateiinhalte

Schlüssel, und was die Signatur beweist

Generiert pro Installation, beim ersten Lauf. Der private Schlüssel verlässt nie den Daemon-Host.
Rotation jeder Beleg trägt seine keyId, sodass Rotation und Widerruf fest im Nachweisformat verankert sind. Das Re-Anchoring-Verfahren kommt mit dem Enterprise-Programm.
Wir beweisen dass diese Ausführung, unter dieser Policy, an diese ratifizierte menschliche Entscheidung gebunden war. Wir zertifizieren nicht das interne Denken des Agenten, und genau deshalb verankern wir den Nachweis in der menschlichen Entscheidung, nicht in der Modell-Erzählung.
checks.* + provenance.decision entspricht Abschnitt 8 der ISO 42001 (operative Kontrolle) und SOC 2 CC8.1 (Änderungsmanagement).
ISO 42001 · SOC 2 →