Architecture & Data Flow

For security & procurement review · June 2026

EVE AI Core is a deterministic governance control plane. A proposed action is evaluated against a versioned policy before it executes; the verdict and its inputs are sealed into a signed, independently verifiable Decision Certificate; and that certificate is appended to a tenant-bound, hash-chained audit log. The diagram below shows exactly where customer data enters, what is governed, and what is retained.

Request path Evidence & audit Policy & identity Tenant boundary
PER-TENANT ISOLATION BOUNDARY Client / Agent proposed action + decision context API Gateway authn / authz tenant resolve rate limit Pre-Execution Governance Gate deterministic eval veto core + policy Verdict ALLOWED / BLOCKED / MODIFIED Versioned Policy e.g. lending_v1 Decision Certificate ECDSA P-384 signed Audit Chain hash-chained, tenant-bound Offline Verifier /verify · /agent-proof TLS bind version

Request path (blue) is governed before execution; evidence path (green) is signed and appended to a tamper-evident, tenant-bound chain and is independently verifiable offline.

Stage by stage

  1. Ingress (TLS).

    The client or agent sends a proposed action plus only the decision-context fields it chooses to include. The customer controls field minimization.

  2. API Gateway.

    Authenticates the caller (JWT or scoped API key), resolves the tenant, and applies rate limiting. From here on, all state and evidence are scoped to that tenant.

  3. Pre-Execution Governance Gate.

    A deterministic evaluation runs against the tenant's selected policy version before any action executes. Charter HARD_BLOCK rules and ethical red lines are never relaxed. The output is ALLOWED, BLOCKED, or MODIFIED.

  4. Policy binding.

    The verdict is bound to the exact versioned policy that produced it (e.g. lending_v1), so a decision can always be replayed against the policy in force at the time.

  5. Decision Certificate.

    The inputs, verdict, policy version, and tenant are sealed into a cryptographically signed record (ECDSA P-384 (AWS KMS) in production).

  6. Audit chain.

    The certificate is appended to a hash-chained, tenant-bound audit log; retention is configurable up to 7 years, and deletion produces signed receipts.

  7. Offline verification.

    Any party can verify a certificate or audit record without contacting EVE, at /verify or /agent-proof.

What is and isn't retained

Retained

the signed decision records and the tenant-bound audit chain, for the retention period the customer configures.

Customer-controlled

which decision-context fields are sent at all — EVE governs and logs what it receives; it does not require fields the customer chooses to withhold.

Deletable

customer-initiated deletion is supported across memory layers and produces HMAC-signed, hash-chained deletion receipts (see DPA §10).

Isolated

governance state and audit chains are per-tenant; non-SaaS deployments keep all data inside the customer's chosen boundary (see deployment models).

Go deeper

This diagram is the procurement-level view. For the full technical treatment of the governance protocol and hardware-compilable veto logic, see the Whitepaper. For controls and posture, see Security and the Procurement Packet.

Security Overview →
Encryption, access control, audit logging, retention.
Procurement Packet →
Pre-answered questionnaire, sub-processors, onboarding.
Verify Evidence →
Paste any record and check it offline.