Cryptographic AI Audit Logs

A log you cannot verify is a log you have to trust. EVE evidence is different: each record is signed and canonicalized so a reviewer can confirm — independently, offline, without contacting EVE — that the record is authentic and unaltered.

The cryptography

Signatures — Ed25519 in production configuration, with an HMAC-SHA256 fallback.
Canonicalization — records are signed over jcs-1, a versioned canonicalization with proven byte-for-byte parity across Python, TypeScript, and the browser for the supported value domain.
Independent verification — verify in Python, Node, or the browser using the Ed25519 public key.
Tamper evidence — altering any signed field causes verification to reject the record.

Verify offline

import { verifyEvidence } from "@eve/coreguard";

const report = verifyEvidence(envelope, { publicKeyPem: pubkey });
if (!report.valid) throw new Error("tampered or unauthentic");
// report.signature === "ed25519-valid"; canon "jcs-1"

A Python-signed jcs-1 envelope verifies in TypeScript as ed25519-valid; a tampered envelope is rejected — validated cross-language in the RC manifest.

Readiness

Signed evidence, offline/independent verification (Python, Node, browser), and jcs-1 canonicalization are SUPPORTED. Cross-language ed25519-valid verification and tamper rejection are validated in the RC manifest.

Limitations

Verification proves authenticity and integrity of the record — it does not attest that the decision the record describes was correct.
The HMAC-SHA256 fallback is symmetric and is not independently verifiable; asymmetric independent verification requires the Ed25519 public key.
jcs-1 is a constrained RFC 8785 profile: it does not serialize non-integer floats / NaN / Infinity (fail-closed), so it is not full RFC 8785 float coverage. Signed artifacts use the supported domain.

Next step

Ask for a signed evidence sample from a pilot and run the offline verifier in your own environment.