EVE Core › Docs › EVE CoreGuard API Reference
API Reference

EVE CoreGuard API Reference

The deterministic decision endpoints at api.eveaicore.com/v1 — ALLOWED, BLOCKED, or MODIFIED, every call returning a signed audit certificate you can verify offline.

The EVE CoreGuard API is a deterministic AI governance decision engine that evaluates proposed actions against versioned policy packs and returns ALLOWED, BLOCKED, or MODIFIED dispositions with a cryptographically signed audit certificate. This reference documents all endpoints, request and response schemas, decision status values, error codes, and rate limits. For background on why deterministic governance matters in regulated industries, see Deterministic AI Governance: Why Probabilistic Guardrails Fail.

1. Overview and Authentication

The EVE CoreGuard API is accessible at the following base URL. All requests and responses use JSON. TLS 1.2+ is required on all connections; plain HTTP connections are rejected.

https://api.eveaicore.com/v1

Authentication

Authenticate by including your API key in the Authorization header as a Bearer token. API keys are issued per organization and can be scoped to specific policy sets.

HTTP Header
Authorization: Bearer eve_sk_your_api_key_here
Content-Type: application/json

API keys are prefixed with eve_sk_ for production keys and eve_sk_test_ for test keys. Test keys evaluate against the same policy logic but do not generate billable decisions and cannot be used to produce certificates submitted for regulatory audit.

Key security: API keys must be stored server-side and must never be embedded in client-side code, mobile applications, or public repositories. EVE CoreGuard keys carry the ability to evaluate and block decisions — treat them with the same care as database credentials.

2. POST /decisions/evaluate

The primary endpoint. Evaluates a proposed action against a specified policy set and returns a governance decision with risk assessment, any policy violations, and a signed audit certificate.

POST /v1/decisions/evaluate Evaluate action against policy pack
EVE CoreGuard runtime gate — at a glance
Endpoint : POST https://api.eveaicore.com/v1/decisions/evaluate
Auth     : Authorization: Bearer eve_sk_...        (per-organization API key)
Body     : JSON — policy_set, request_id, user, proposed_action, context
Returns  : decision.status = ALLOWED | BLOCKED | MODIFIED
           + risk assessment, policy violations, ECDSA P-384-signed audit certificate
Engine   : deterministic rule kernel — no LLM in the decision path
Verify   : offline via pip install eve-coreguard + /.well-known/eve-pubkey
cURL — complete invocation
curl -X POST https://api.eveaicore.com/v1/decisions/evaluate \
  -H "Authorization: Bearer eve_sk_your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "policy_set": "lending_v1",
    "request_id": "req_789",
    "user": {"id": "user_123", "role": "loan_officer", "organization": "regional_bank"},
    "proposed_action": {"type": "loan_decision", "amount": 50000, "applicant_id": "app_456"},
    "model_output": {"decision": "approve", "confidence": 0.91},
    "context": {"credit_score": 720, "debt_to_income": 0.30, "employment_verified": true}
  }'

Request Schema

Field Type Required Description
policy_set string optional Optional assertion. The governing pack is bound server-side from proposed_action.type (tenant binding, then the platform default); a value that does not match the bound pack yields a signed BLOCKED decision (COREGUARD.POLICY_BINDING_MISMATCH). See Policy Sets.
user object required Identity of the agent initiating the action. Must include id. role and organization are used by role-sensitive policy rules.
proposed_action object required The proposed action to evaluate. Must include type. Additional fields are policy-specific — see policy pack documentation for the action schema your policy expects.
context object optional The decision inputs the policy evaluates (e.g. credit_score, debt_to_income, employment_verified for lending_v1). See the policy pack documentation for the fields your policy reads.
request_id string optional Caller-supplied identifier echoed in the audit record and used for idempotency.
Example Request — Lending Policy
{
  "policy_set": "lending_v1",
  "user": {
    "id": "user_123",
    "role": "loan_officer",
    "organization": "regional_bank"
  },
  "request_id": "req_789",
  "proposed_action": {
    "type": "loan_decision",
    "amount": 50000,
    "applicant_id": "app_456"
  },
  "context": {
    "credit_score": 720,
    "debt_to_income": 0.30,
    "employment_verified": true
  }
}

Response Schema

Fields of EvaluationResponse (core/coreguard/schemas.py). Optional fields not listed here (org_id, compliance_summary, resolved_route, consistency_result, metadata) may be null.

Field Type Description
request_id string Echo of the request’s request_id.
decision object status (ALLOWED / BLOCKED / MODIFIED) and action, e.g. deny_loan_approval.
risk object score (0–1), level (LOW / MEDIUM / HIGH) and factors (strings describing what contributed).
policy_violations array One object per rule that fired: policy_id (the rule id, e.g. DTI_LIMIT) and description. Empty when nothing fired.
regulatory_impact array Each item maps a violation to a regulation: regulation, risk, severity.
counterfactual object | null Thresholds that would have produced ALLOWED (lending: credit_score_required, max_dti_allowed, employment_required).
liability_prevented object | null estimated_exposure and reason for a blocked decision.
modifications array | null For MODIFIED decisions: field, original_value, modified_value, reason. null otherwise.
audit object The signed decision record: audit_id, timestamp, decision_trace, hash, signature (algorithm-tagged; hosted production records are kms-ecdsa-p384-…, verifiable with the public key), policy_version, chain fields (chain_sequence, chain_previous_hash, chain_entry_hash), signing-key identity and the signed certificate body.
authority_trace object | null Which pack and rules decided: policy_set, evaluator, rule_ids_evaluated, winning_rule_id.
explanation string | null One-sentence rationale bound to the winning rule.
evidence object | null Signed evidence plane, present only when the request set include_evidence.
evidence_status string | null Unsigned archival state of the record, e.g. persisting or durable.
schema_version string Response schema version; a major-version change is breaking.
Example Response — ALLOWED Decision (abridged)
{
  "request_id": "req_789",
  "decision": { "status": "ALLOWED", "action": "approve_loan_decision" },
  "risk": {
    "score": 0.1995,
    "level": "LOW",
    "factors": ["Credit score: 720", "Debt-to-income ratio: 0.30"]
  },
  "policy_violations": [],
  "regulatory_impact": [],
  "counterfactual": null,
  "liability_prevented": null,
  "modifications": null,
  "audit": {
    "audit_id": "audit_48f25d5cc700",
    "decision": "ALLOWED",
    "hash": "sha256-19e76099…",
    "signature": "kms-ecdsa-p384-3066…",
    "chain_sequence": 471,
    "policy_version": "sha256:7f95b82c…",
    "certificate": { /* signed eve.decision.cert.v8 body */ }
  },
  "authority_trace": {
    "policy_set": "lending_v1",
    "evaluator": "lending_v1_evaluator",
    "rule_ids_evaluated": [],
    "winning_rule_id": null
  },
  "schema_version": "1.0"
}
Example Response — BLOCKED Decision (abridged)
// Same request with credit_score 580 and debt_to_income 0.52
{
  "request_id": "req_790",
  "decision": { "status": "BLOCKED", "action": "deny_loan_decision" },
  "risk": {
    "score": 0.3784,
    "level": "MEDIUM",
    "factors": ["Credit score: 580", "Debt-to-income ratio: 0.52"]
  },
  "policy_violations": [
    { "policy_id": "CREDIT_SCORE_MIN", "description": "Credit score 580 is below the minimum threshold of 620" },
    { "policy_id": "DTI_LIMIT", "description": "Debt-to-income ratio 0.52 exceeds the maximum threshold of 0.45" }
  ],
  "regulatory_impact": [
    { "regulation": "ECOA", "risk": "Potential discriminatory lending decision based on credit criteria", "severity": "HIGH" },
    { "regulation": "ECOA", "risk": "Debt-to-income threshold may disproportionately affect protected classes", "severity": "HIGH" }
  ],
  "counterfactual": { "credit_score_required": 620, "max_dti_allowed": 0.45, "employment_required": true },
  "liability_prevented": {
    "estimated_exposure": "$25,000 - $50,000",
    "reason": "Loan approval violates 2 policy threshold(s): credit score min, dti limit"
  },
  "modifications": null,
  "audit": { /* signed decision record, as above */ },
  "authority_trace": {
    "policy_set": "lending_v1",
    "evaluator": "lending_v1_evaluator",
    "rule_ids_evaluated": ["CREDIT_SCORE_MIN", "DTI_LIMIT"],
    "winning_rule_id": "CREDIT_SCORE_MIN"
  },
  "consistency_result": "PASS",
  "explanation": "Request BLOCKED by rule 'CREDIT_SCORE_MIN'. Credit score 580 is below the minimum threshold of 620.",
  "schema_version": "1.0"
}

Field values above are from evaluate_hardened for these requests (signature shortened; hosted production signs with AWS KMS ECDSA P-384). Long audit fields are elided.

Audit record retention: EVE CoreGuard retains all audit records for 7 years by default, accessible via the audit retrieval API. Records are stored with hash-chain integrity — any tampering is cryptographically detectable. You do not need to store the audit records yourself to satisfy regulatory requirements, though you may optionally retrieve and archive them.

3. GET /decisions/health

Returns the operational status of the EVE CoreGuard evaluation engine. Use this endpoint for load balancer health checks and monitoring integrations. This endpoint does not require authentication and does not generate audit records.

GET /v1/decisions/health Engine health check — no auth required
Example Response — Healthy
{
  "status": "healthy",
  "service": "coreguard",
  "policy_sets_loaded": 31
}

Returns HTTP 200 when healthy. policy_sets_loaded is the count of registered policy packs. To enumerate the packs themselves with metadata, use the catalog discovery endpoints below.

4. Catalog Discovery

The full policy-pack catalog is enumerable over the API so your integration and your auditors can inventory the deterministic controls in force — each pack's id, version, regulatory domain, jurisdiction, and rule count — without hard-coding a list. These endpoints return public product metadata and do not require authentication or generate audit records.

GET /v1/decisions/policies Full catalog with metadata (optional ?domain= filter)
GET /v1/decisions/policies/{policy_id} Metadata for a single pack (404 if unknown)
GET /v1/decisions/policy-sets Just the policy_set ids
Example Response — GET /v1/decisions/policies
{
  "count": 31,
  "policies": [
    {
      "policy_id": "fair_lending_v1",
      "version": "1.0.0",
      "domain": "fair_lending",
      "jurisdiction": "US",
      "rule_count": 6,
      "notes": "ECOA (15 USC 1691), Regulation B (12 CFR 1002.9), FCRA, CFPB UDAAP.",
      "source": "python"
    }
  ]
}

Each record’s bound_action_types lists the action types the platform default binding maps to that pack; an empty list means the pack governs nothing until your org admin binds it. The policy_id is the value you may send as the optional policy_set assertion to POST /v1/decisions/evaluate. Full per-pack rule documentation — every rule, severity, and regulatory citation — is published at /docs/policy-packs.

5. Decision Status Values

Every evaluation response includes a decision.status field with one of three values. The status is deterministic: the same request against the same policy version always produces the same status.

Status Meaning When It Occurs Caller Action
ALLOWED Action passes all policy rules No rules triggered; risk score below all thresholds; all mandatory checks passed Proceed. Archive the audit record for regulatory retention.
BLOCKED Action violates one or more policy rules A hard-block rule triggered; risk score above policy ceiling; prohibited action type detected Do not proceed. Present applicable adverse action notice if required. Log policy_violations for your compliance record.
MODIFIED Action permitted with required changes Action is within policy scope but requires specific additions or adjustments — e.g., a mandatory disclosure, an amount cap, or a supervisory review step Apply all changes specified in the modifications object, then proceed. The audit record documents which modifications were required.

On BLOCKED vs. MODIFIED: The distinction is policy-defined, not heuristic. A rule that identifies a hard prohibition — using a protected-class proxy variable, exceeding a statutory limit, proposing a clinically contraindicated action — produces BLOCKED. A rule that identifies a gap requiring remediation — missing a disclosure, an amount needing adjustment — produces MODIFIED. Policy authors have explicit control over which outcome each rule triggers.

6. Risk Levels

The risk.level field is a categorical summary of the computed risk.score. Risk is assessed independently of the governance verdict — an ALLOWED decision can have a MEDIUM risk level if it passes policy rules but exhibits characteristics that warrant elevated monitoring.

Level Score Range Meaning Typical Disposition
LOW 0.00 – <0.35 Action is well within policy parameters. No risk factors detected. ALLOWED. Standard audit retention.
MEDIUM 0.35 – <0.60 One or more risk factors detected but below blocking threshold. May warrant supervisory attention or enhanced monitoring. ALLOWED or MODIFIED depending on rule configuration. Flagged for enhanced audit retention in most policy packs.
HIGH 0.60 – 1.00 Multiple risk factors or a single critical risk factor detected. Policy hard-block rules typically trigger in this range. BLOCKED or MODIFIED with mandatory escalation. The signed audit record is automatically marked for regulatory priority retention.

7. Policy Sets

A policy set is a versioned collection of rules compiled from regulatory requirements and organizational policies. Policy sets are immutable once published — a version number and a date stamp uniquely identify the exact rules that were in effect for any historical evaluation. This immutability is what enables audit replay: you can resubmit any historical request against the exact policy version that was active at the time and receive an identical verdict.

The catalog spans 31 deterministic policy packs across regulated domains — consumer lending and fair lending, securities trading, banking/AML, insurance, healthcare and telehealth prescribing, clinical trials, employment/hiring, fair housing, debt collection, marketing/TCPA, anti-bribery, children's and biometric privacy, GDPR, the EU AI Act, gambling, legal practice, accessibility, and more. The table below is a representative selection; enumerate the full, current catalog programmatically via GET /v1/decisions/policies, and read every pack's rules at /docs/policy-packs.

Policy Set ID Version Coverage Availability
lending_v1 1.0.0 ECOA / Reg B disparate impact rules, adverse action notice requirements, Fair Housing Act proxy variable detection, HMDA reportable action identification, LTV and DTI threshold enforcement All tiers
fair_lending_v1 1.0.0 ECOA / Reg B prohibited-basis detection, adverse-action notice completeness, four-fifths disparate-impact test, proxy-variable risk, and model-explainability gating for AI credit denials All tiers
securities_trading_v1 1.0.0 Insider-trading (SEC Rule 10b-5) and market-manipulation blocking, Reg BI suitability, restricted-list enforcement, and investment-advice disclosure for AI trading/advice systems Pro and Enterprise
healthcare_v1 1.0.0 HIPAA minimum necessary standard, clinical decision support safety rules, off-label recommendation detection, contraindication blocking, documentation completeness enforcement Pro and Enterprise
chat_safety_v1 1.0.0 Default content-safety pack for chat and assistant traffic (chat, model_inference, llm_prompt, llm_completion): blocks a prompt or response that matches the harmful-content pattern batteries and allows benign conversation. regulated_chat_v1 and harmful_content_v1 are members of the same family and may be asserted in addition. All tiers
custom Varies Tenant-authored policy rules deployed to your isolated namespace. Custom rules may extend any base policy set. Custom policy sets undergo EVE Core review before activation to verify they do not weaken base-pack protections. Enterprise only

To retrieve metadata for a specific pack — version, domain, jurisdiction, rule count, and the regulatory basis — call GET /v1/decisions/policies/{policy_id}. Each pack's complete rule catalog (every rule ID, severity, regulatory citation, and triggering condition) is documented at /docs/policy-packs.

8. Python SDK Quickstart

The eve-coreguard package provides a typed, synchronous Python client with automatic retry and independent offline evidence verification. Install with pip:

Installation
pip install eve-coreguard

Current SDK versions: eve-coreguard 0.2.10 (Python evaluation client) · eve-proof 0.3.0 · evecore 0.1.4 · eve-verify 1.0.0 (PyPI + npm, offline certificate verifier) · eve-ai-governance 0.4.0 (npm, Node offline verifier). The client is synchronous; there is no async client at this time.

Basic Evaluation
# Synchronous usage
from eve_coreguard import CoreGuardClient

client = CoreGuardClient(api_key="eve_sk_your_api_key_here")

result = client.evaluate(
    tenant_id="bank_001",
    user={"id": "user_123", "role": "loan_officer"},
    proposed_action={"type": "loan_decision", "amount": 50000},
    context={"credit_score": 720, "debt_to_income": 0.30, "employment_verified": True},
    policy_set="lending_v1",  # optional assertion; loan_decision is bound to lending_v1
)

print(result.verdict)                  # ALLOWED / BLOCKED / MODIFIED
print(result.risk.level)               # LOW / MEDIUM / HIGH
print(result.decision_id)              # id of the signed decision record

# Check for violations
for v in result.policy_violations:
    print(f"Rule {v.policy_id}: {v.description}")
Verify decision evidence offline (no shared secret)
# Ask the server to attach a signed governance evidence record.
result = client.evaluate(
    policy_set="lending_v1",
    user={"id": "user_123", "role": "loan_officer"},
    proposed_action={"type": "loan_decision", "amount": 50000},
    context={"credit_score": 720},
    include_evidence=True,          # populates result.signed_governance
)

# Production decision records are signed with ECDSA P-384. They are verifiable
# offline by anyone holding only the public key — no API call, no shared
# secret. This is the same proof shown at /agent-proof and /verify.
verdict = client.verify_evidence_offline(result.signed_governance)
print(verdict.algorithm)   # "ecdsa-p384" (asymmetric, public-key verifiable)
print(bool(verdict))       # True — recomputed hash + signature both valid

# Fully independent: fetch the public key once, verify anywhere later.
from eve_coreguard import verify_decision_record, fetch_public_key_pem

pubkey = fetch_public_key_pem("https://api.eveaicore.com")  # /.well-known/eve-pubkey
verdict = verify_decision_record(result.signed_governance, public_key_pem=pubkey)
print(verdict.valid)
Handling MODIFIED Decisions
result = client.evaluate(
    tenant_id="bank_001",
    user={"id": "user_123"},
    proposed_action={"type": "loan_decision", "amount": 250000},
    context={"credit_score": 720, "debt_to_income": 0.30, "employment_verified": True},
)

if result.verdict == "MODIFIED":
    for m in result.modifications or []:
        print(f"{m.field_name}: {m.original_value} -> {m.modified_value} ({m.reason})")
    # Apply changes and re-evaluate, or apply changes to the output
    # directly and attach the audit certificate to the record

9. Error Codes

All API errors return a JSON body with an error object containing a code string, a human-readable message, and where applicable a field indicating which request parameter caused the error.

HTTP Status Error Code Cause and Resolution
400 invalid_request The request body is malformed or missing required fields. Check the field property in the error response for the specific parameter that is invalid or absent.
401 unauthenticated The Authorization header is absent or does not contain a valid Bearer token. Verify your API key is correctly formatted and has not been revoked.
403 forbidden Your API key is valid but is not authorized to access the requested policy set or endpoint. API keys can be scoped to specific policy sets — check your key's scope in the developer dashboard.
404 policy_not_found Returned by GET /v1/decisions/policies/{policy_id} for an unknown pack. On POST /v1/decisions/evaluate an unknown or non-matching policy_set is not an HTTP error: it is a signed BLOCKED decision (COREGUARD.POLICY_BINDING_MISMATCH).
422 validation_error The request structure is valid JSON but fails semantic validation — for example, a required field within the action object that the specified policy set expects. The details array lists each specific validation failure.
429 rate_limit_exceeded Your organization has exceeded its per-minute request limit. The response includes a Retry-After header indicating how many seconds to wait before retrying. See Rate Limits.
500 internal_error An unexpected server-side error occurred. The response includes a request_id you can provide to support. EVE CoreGuard is designed with fail-closed semantics — in the event of an internal error on a BLOCKED or MODIFIED path, the error is surfaced rather than defaulting to ALLOWED.

Fail-closed behavior: If EVE CoreGuard encounters an internal error during policy evaluation, it returns a 500 rather than silently passing the request through as ALLOWED. This is intentional. A governance system that fails open under load or error conditions is not a governance system — it is a performance-mode bypass. Design your integration to handle 500 responses by halting the action and escalating for human review.

10. Rate Limits

Rate limits are applied per API key at the per-minute level. Limits are enforced with a sliding window. Burst capacity is available on Pro and Enterprise tiers: you can exceed the per-minute rate for up to 10 seconds before the limit is enforced.

Tier Requests / Minute Concurrent Connections Audit Retention Custom Policy Sets
Free 100 5 90 days No
Pro 1,000 25 7 years No
Enterprise Custom (SLA-backed) Custom 7 years + archival export Yes

Rate limit headers are included in every response:

Rate Limit Response Headers
X-RateLimit-Limit:      1000
X-RateLimit-Remaining:  987
X-RateLimit-Reset:      1746444660  # Unix timestamp of next window reset

Frequently Asked Questions

How do I call the EVE CoreGuard runtime gate?

Send an authenticated POST to https://api.eveaicore.com/v1/decisions/evaluate with a JSON body containing policy_set, request_id, user, proposed_action, and context. The response returns decision.status — ALLOWED, BLOCKED, or MODIFIED — plus a risk assessment, any policy violations, and an ECDSA P-384-signed audit certificate that verifies offline with the eve-coreguard Python SDK and the public key at /.well-known/eve-pubkey. In Python: pip install eve-coreguard, then CoreGuardClient(api_key=...).evaluate(...). See the at-a-glance block and cURL example above.

What authentication does the EVE CoreGuard API use?

The EVE CoreGuard API uses Bearer token authentication. Include your API key in the Authorization header as Authorization: Bearer {your_api_key}. API keys are issued per organization and can be scoped to specific policy sets. Contact [email protected] to request an API key for your organization.

What is the latency of the POST /decisions/evaluate endpoint?

EVE CoreGuard's evaluation engine is implemented as a pure deterministic function with no model inference in the critical path. In an in-process rule-evaluation micro-benchmark (excluding network and model inference), the gateway decision measured approximately 0.07 milliseconds per operation. The audit certificate generation, including ECDSA P-384 signing (HMAC-SHA256 dev fallback), adds negligible overhead — orders of magnitude faster than LLM-based safety filters, which typically add 200–2,000ms to each request.

How do I verify a EVE CoreGuard decision record?

Each audit record carries a self-describing signature field whose prefix names the algorithm. There are two distinct verification models, and they are not interchangeable:

  • ECDSA P-384 / ECDSA-P256 (kms-ecdsa-p384-…, ecdsa-p256-…) — public-key, independently verifiable. Production decision records are asymmetrically signed. Anyone can verify them offline with only the public key (served unauthenticated at /.well-known/eve-pubkey) — no API call and no shared secret. This is what makes independent third-party verification possible — publicly verifiable evidence of record integrity and signing-key possession, not by itself legal non-repudiation — and it is the proof demonstrated at /agent-proof and /verify. Verify with client.verify_evidence_offline(record) or the standalone verify_decision_record(record, public_key_pem=...).
  • HMAC-SHA256 (hmac-…) — shared-secret, server-side / tenant-scoped only. Legacy and internal integrity records use a symmetric key. HMAC proves integrity to a party that already holds the same secret; it cannot be verified with a public key and is not a third-party proof. Verify with the shared key via verify_decision_record(record, hmac_key=...).

For external audit and customer-facing evidence, use the ECDSA P-384 records and the public key. Do not present an HMAC signature as publicly verifiable proof.

What happens when EVE CoreGuard returns MODIFIED status?

A MODIFIED decision means the requested action is conditionally permitted, but the policy engine has identified required changes that must be applied before the action can proceed. The response includes a modifications object describing the required changes — for example, requiring the addition of an adverse action notice, capping a loan amount to a policy-compliant maximum, or mandating a supervisory review step. The caller is responsible for applying the modifications before presenting the output to the end user or downstream system.

Try EVE CoreGuard Now

Test the API in our interactive demo — no API key required. See ALLOWED, BLOCKED, and MODIFIED decisions with live, signed audit records in under 30 seconds. Then prove a record yourself: tamper one field and watch verification fail.

Part of the EVE AI Core control plane Deterministic AI Governance Control Plane → Policy decisions that return the same result for the same input every time, before execution.