EVE Trust

Trust EVE decisions because you can verify the evidence yourself — not because we ask you to.

Who this is for

Decision-makers, auditors, and partners who need a defensible basis for trusting a governed decision. You want the trust model stated plainly: what is proven, what is pilot-validated, what is experimental, and what the evidence does and does not establish.

The problem

"Trust us" is not a control. Marketing language is not evidence. You need to know exactly which claims are backed by tests and reports, which are still in pilot, and what a signed record actually attests. EVE's trust model is designed so a third party can confirm the important parts independently.

What EVE's trust model rests on

• Deterministic decisions. EVE CoreGuard makes a deterministic policy decision (ALLOW / BLOCK / MODIFY) before a governed action executes, with no LLM in the decision path. Same inputs, same verdict — replayable.
• Signed, bound evidence. Every governed decision can produce a signed evidence record bound to the decision (Ed25519 in production configuration, HMAC-SHA256 fallback).
• Independent verification. Signed evidence can be verified independently and offline, in Python, Node, or the browser, without trusting the EVE server.
• Honest readiness labels. Each capability carries an explicit readiness level; nothing is presented as more mature than its tests and reports support.

Readiness: deterministic decisions are PILOT_READY; signed evidence, offline verification, and jcs-1 canonicalization are SUPPORTED.

How it works

1. A decision is computed deterministically and produces a signed evidence envelope over jcs-1.
2. You (or an auditor) receive the envelope and the Ed25519 public key.
3. You verify it offline — integrity, signature, schema — without contacting or trusting EVE.
4. If it verifies, you know the record is authentic and unaltered. If anything was changed, verification fails.

Technical example

from core.eve_sdk import verify_evidence

report = verify_evidence("decision", envelope)
# {"valid": True, "reason": "certificate verified", "checks": {...}}

Signed evidence example

{
  "content_hash": "…",
  "canon": "jcs-1",
  "signature": "ed25519-…",
  "decision": { "action": "BLOCK", "reason_codes": ["…"], "decision_id": "…" },
  "llm_in_decision_path": false
}

Verifier example

import { verifyEvidence } from "@eve/coreguard";
const report = verifyEvidence(envelope, { publicKeyPem });
// { valid: true, signature: "ed25519-valid" }

Readiness at a glance

• SUPPORTED: signed decision evidence, offline verification, jcs-1 canonicalization.
• PILOT_READY: CoreGuard deterministic decisions, agent monitoring/sequence/budget controls, MCP execution binding, authenticated identity, distributed consumption (in the documented test topology), artifact scanning, shadow evaluation, red-team harness.
• EXPERIMENTAL: framework adapters other than the generic adapter.

Overall, the EVE SDK core is a RELEASE CANDIDATE WITH EXCLUSIONS.

Deployment options

Trust properties hold across embedded, hosted, sidecar, MCP-gateway, and sovereign/offline modes. Verification runs anywhere Python ≥3.9, Node ≥18, or a browser is available. In every mode, a service error fails closed.

Readiness

Deterministic decisions are PILOT_READY. Signed evidence, offline verification, and jcs-1 are SUPPORTED. Framework adapters other than generic are EXPERIMENTAL. The EVE SDK core overall is a RELEASE CANDIDATE WITH EXCLUSIONS.

Limitations

• Verification proves that evidence is authentic and unaltered — it does not attest that the underlying decision was correct.
• The zero-LLM property covers the governance verdict only; the governed application may still use LLMs.
• Independent verification requires the Ed25519 public key; the HMAC fallback is symmetric and not independently verifiable.
• jcs-1 is a constrained RFC 8785 profile (no non-integer floats / NaN / Infinity), not full compliance.
• Distributed consumption is validated single-host in the documented topology, not proven multi-host. MCP is at-most-once, not remote exactly-once.
• Only the generic framework adapter is validated; others are experimental and wrapper-enforced adapters are bypassable by a direct underlying-tool call. Hard enforcement requires a gateway or sidecar.
• The release-candidate clients are distributed privately for pilots — install the pilot artifact, not a public pip/npm install (see readiness for public-registry status).

Next step

Request sample signed evidence and the public key, verify it yourself, and then start a pilot on that basis.