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 echter Beleg aus unserem eigenen Repo, gekürzt.
{
"schemaVersion": "rootblocks.evidence/v1",
"evidenceId": "observed-pr-57-d1aea6afcbf1",
"operationType": "code.merge",
"status": "passed",
"assurance": "observed",
"actor": { "type": "tool", "id": "rootblocks-scan" },
"checks": [
{ "id": "review-gap", "status": "failed", "severity": "error" }
],
"provenance": {
"pullRequest": "Rootblocks/rootblocks-cloud#57",
"review": { "decision": "merged", "reviewer": "anrasi" }
},
"redaction": { "status": "not-needed", "rules": [] }
}
// + eine abgetrennte ed25519-Signatur { keyId, value }
Verifizieren Sie einen Beleg offline, nur mit dem öffentlichen Schlüssel:
$ npx rootblocks-verify rootblocks-receipt.json --key rootblocks.pub
✓ signature valid · schema evidence.v1 · not tampered
Ja: dieser Beleg enthält einen fehlgeschlagenen Check, einen von einem Agenten geschriebenen PR, der ohne Review selbst gemergt wurde, in unserem eigenen Repo. Der Scan lief durch (status: passed) und hielt die Lücke ehrlich fest. Genau diese Lücke existiert RootBlocks, um sie sichtbar zu machen.
Geben Sie diese Datei an jeden weiter. Er braucht uns nicht, um sie zu verifizieren.
Apache-2.0 Das Belegformat ist eine offene Spezifikation, veröffentlicht auf standards.rootblocks.com, und der Verifier ebenso: mit npx ausführen, ohne Konto und ohne Anmeldung. Lesen, forken, oder anhand des Schemas einen eigenen schreiben. Würden wir morgen verschwinden, lässt sich jeder Beleg, den Sie bereits haben, weiterhin verifizieren. Nachweise, die vom Überleben ihres Anbieters abhängen, sind keine Nachweise.
- operationType das kontrollierte Ereignis: ein Merge, eine Ausführung, ein Release.
- provenance.agent welcher Agent die Änderung erzeugt hat, und mit welchem Modell. Verschieden vom actor der Operation.
- decisionRefs die menschliche Entscheidung, die diese Änderung autorisiert hat, per id referenziert. Der Ankerpunkt der Spur.
- assurance das Siegel: wie stark der Beleg abgesichert ist. observed, proven, traced, enforced.
- 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.
- signature abgetrennt: ed25519 über die kanonischen Bytes, plus die id des Signaturschlüssels.
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.* + decisionRefs entspricht Abschnitt 8 der ISO 42001 (operative Kontrolle) und SOC 2 CC8.1 (Änderungsmanagement).