Decision Certificates

Every governance decision EVE CoreGuard makes is a signed, verifiable record — not just a log entry. A Decision Certificate is a cryptographically bound document that proves exactly what was decided, by which policy version, at what time, and why. This page explains what a certificate contains, how it is signed, how to verify it independently, and how long to retain it for regulatory purposes.

What Is a Decision Certificate?

When you call POST /v1/decisions/evaluate, EVE CoreGuard does two things: it evaluates the action against the requested policy pack, and it generates a Decision Certificate that permanently records that evaluation. The certificate is issued regardless of whether the decision is ALLOWED, BLOCKED, or MODIFIED — every governance decision has a certificate.

The certificate's purpose is regulatory proof. If your organization is audited by a financial regulator, a healthcare compliance officer, or a state attorney general, the certificate is the evidence that your AI system applied governance controls before the output reached an end user. The cryptographic signature on every certificate (Ed25519 in production; HMAC-SHA256 in legacy mode) makes it tamper-evident — any post-hoc modification of the decision record invalidates the signature, providing mathematical proof of record integrity.

Decision Certificates differ from conventional audit logs in three critical ways:

• Signed at issuance — The signature is computed at decision time, not appended retroactively. There is no window in which a valid certificate can be produced for a decision that did not actually occur.
• Self-describing — Every certificate carries the policy version, the governance disposition, the risk score, and a signed digest of the rule-result set (rule_results_sha256). The signed record binds these values; the full rule-result array and the policy-artifact bytes are provided in the accompanying evidence bundle rather than always inline, so a certificate can be interpreted without a live call to EVE Core but the underlying rule-result and policy artifacts are referenced by digest.
• Third-party verifiable — Ed25519 verification requires only the certificate, the verification profile below, and EVE's published public key. EVE Core does not need to be online or consulted. Note the distinction: a certificate being verifiable by any third party is not the same as it having been verified by an independent party — the latter requires an external auditor, customer, or transparency witness to actually run the check.

Certificate Signing Process

In production, each Decision Certificate is signed with Ed25519 — an asymmetric signature that any third party (your auditor or a regulator) can independently verify against EVE's published public key (/.well-known/eve-pubkey) with no shared secret. The verifier holds only the public key and cannot forge a certificate. A valid signature establishes tamper-evidence and origin against the supplied or pinned key; it does not, by itself, establish the truth of every upstream input or full runtime integrity, and CoreGuard's verdict is a statement of policy admissibility, not final business approval. Signatures are self-describing (tagged ed25519- / hmac-), so a mixed corpus stays verifiable across a key-rotation boundary. External independent verification by a third party has not yet been performed.

Schema:              eve.decision.v3   (payload_schema; audit_schema "3")

Record content hash  eve-jsonc-v1
  Serialization:     json.dumps(signed_payload, sort_keys=True, default=str)   # Python default
  Separators:        ", " and ": "   (a single space after each — NOT compact)
  Unicode:           ensure_ascii=true  (non-ASCII escaped as \uXXXX)
  Excluded fields:   "hash", "signature", and unsigned metadata (see table)
  Evidence hash:     "sha256-" + sha256(canonical_bytes).hexdigest()
  Signed message:    the UTF-8 bytes of the "sha256-<hex>" hash string
  Signature:         Ed25519 (asymmetric, independently verifiable)

Content digests      eve-request-v1 / eve-response-v1   (bind request / model output / rule results)
  Serialization:     json.dumps(obj, sort_keys=True, separators=(",",":"), ensure_ascii=True, default=str)  # COMPACT
  Digest:            "sha256-" + sha256(canonical_bytes).hexdigest()
  Bound into:        request_payload_sha256 / response_payload_sha256 / rule_results_sha256 (signed fields)

The Ed25519 signing process follows these steps:

Certificate Schema Reference

The eve.decision.v3 decision record is returned in the audit field of every POST /v1/decisions/evaluate response. The Signing status column states, for each field, whether it is part of the signed-field contract (covered by the Ed25519 signature via the record content hash), a signed digest that binds external content, or unsigned metadata. Only the fields marked Signed are covered by the signature.

Full Certificate Example (eve.decision.v3)

A sanitized, independently verifiable sample. Scenario: an autonomous agent requested a capability outside its declared envelope and an action exceeding its blast-radius limit; CoreGuard blocked autonomous execution and queued mandatory human review. Signed fields are covered by the signature; hash/signature/decision_trace and the chain_* coordinates are unsigned.

Verify this sample offline with the public key ed25519:zb1bX3Y_eHJIsB1q (fingerprint sha256:cdbd5b5f763f787248b01d6a4a0a7e8fde73ad18e2d5b4942d5a2822d8a79fd2). Two self-contained sample verifiers are provided — Python (verify_certificate.py) and Node (node verify_certificate.mjs) — and two additional vendor-reproduced cross-checks exist: the eve-coreguard SDK verifier and the standalone repository verifier (scripts/verify_eve_decision.py).

Offline Verification

Decision Certificates are designed to be verified without a network connection and without calling any EVE CoreGuard API. Verification requires:

• The full signed evidence record (as received or stored).
• For Ed25519 records: EVE's published public key from /.well-known/eve-pubkey (no shared secret).

Verification procedure (schema eve.decision.v3):

1. Record hash. Take the signed-field payload (every Signed field from the schema table — not hash, signature, or unsigned metadata), serialize with eve-jsonc-v1 (json.dumps(payload, sort_keys=True, default=str) — sorted keys, a single space after each comma and colon, ensure_ascii=true; do not strip the whitespace), compute "sha256-" + sha256(canonical_bytes).hexdigest(), and compare to the record's hash.
2. Signature. Verify the Ed25519 signature over the UTF-8 bytes of that sha256-<hex> hash string, against the published public key. A match establishes tamper-evidence and origin against that key — it does not establish the truth of upstream inputs. (Legacy hmac- records are checked with the shared HMAC key — internal tamper-evidence only, not third-party proof.)
3. Key identity. Derive the public-key fingerprint (sha256(SPKI DER)) and kid (ed25519: + base64url of that digest, first 16 chars) from the supplied public key, and confirm they match the certificate's signature_key_id, the published fingerprint, and — where both are supplied — that the PEM and JWK describe the same key. To attribute a certificate to EVE, pin EVE's fingerprint out-of-band.
4. Content binding. When you hold the original inputs, recompute the request, model-output, and rule-results digests with the compact eve-request-v1 / eve-response-v1 canonicalization and confirm they match the signed request_payload_sha256, response_payload_sha256, and rule_results_sha256. This proves those exact inputs produced this decision.

A verifier should report these checks individually (schema recognized, signature valid, hash reproduced, fingerprint derived and matched, kid matched, PEM/JWK matched, each digest matched or not evaluated) rather than a single "fully verified" result, and must fail visibly on any modified signed field, signature, key, fingerprint, or digest preimage.

Compliance Retention Guidance

How long you retain Decision Certificates depends on the regulatory regimes that govern your AI deployment. The following table summarizes minimum retention requirements by regulatory domain.

Python Verification Example

The eve-coreguard Python SDK (PyPI, v0.2.0) includes a built-in offline verifier. The example below is a minimal, standalone check of the record hash + Ed25519 signature for an eve.decision.v3 record, using only cryptography plus the standard library. It intentionally verifies only those two properties (signature integrity). It does not by itself check key identity or reproduce the request / model-output / rule-results digests — for the full per-field verification (key-identity checks and content-digest reproduction, with individual PASS/FAIL statuses) use the two self-contained sample verifiers verify_certificate.py and node verify_certificate.mjs, or the standalone repository verifier scripts/verify_eve_decision.py.

Using the EVE CoreGuard Python SDK (v0.2.0), the offline verifier eve_coreguard.evidence.verify_decision_record() performs the full eve.decision.v3 check (hash, signature, and the signed content digests). The decision chain is a separate, unsigned mechanism: chain-inclusion integrity is verified over the append-only chain state by the repository chain verifier, not by single-certificate signature verification.