EVE Core/ Docs/ Policy Packs

Concepts

EVE CoreGuard Policy Packs

Policy packs are the enforcement modules that define what EVE CoreGuard checks, blocks, modifies, and allows. Each pack is a versioned, auditable collection of rules targeting a specific regulatory domain. This page documents every first-party policy pack, the rules each enforces, example request/response pairs, and how to request a custom pack for your organization.

Policy Pack Architecture

The pack that governs a call to POST /v1/decisions/evaluate is chosen by the server, not by the caller. EVE CoreGuard resolves it from your authenticated organization and proposed_action.type: a tenant binding created by your org admin first, otherwise the platform default binding for that action type (each pack’s bound_action_types in GET /v1/decisions/policies). It then runs the action through that pack’s rule tree and returns a disposition of ALLOWED, BLOCKED, or MODIFIED along with a signed decision certificate that names the evaluated pack.

The request’s policy_set field is optional and is only an assertion. If it names a pack outside the bound pack’s family, the decision is a signed BLOCKED with violation COREGUARD.POLICY_BINDING_MISMATCH; an action type with no binding at all is a signed BLOCKED with COREGUARD.POLICY_BINDING_UNRESOLVED. An asserted pack never replaces the bound pack: if you assert a stricter member of the bound default’s family, it is evaluated in addition to the bound pack, so it can only make the decision stricter.

Packs that need a tenant binding: accessibility_v1, anti_bribery_v1, biometric_privacy_v1, childrens_privacy_v1, colorado_ai_act_v1, eu_ai_act_v1, fair_lending_v1, gdpr_data_processing_v1, legal_practice_v1 ship in the catalog but have no platform default binding. They govern a decision only after your org admin binds one or more of your action types to them; until then a request that asserts one of them is refused. The samples for these packs below assume that binding exists.

Each policy pack is composed of three layers:

  • Pre-condition rules — Structural checks that run before semantic evaluation. These verify that required fields are present, values are within acceptable ranges, and no prohibited data types appear in the action payload.
  • Semantic rules — Domain-specific checks that evaluate the meaning of the action. These include adverse action notice requirements, prohibited basis checks, clinical safety rules, and disclosure obligations.
  • Post-condition rules — Checks that apply after the action has been evaluated. These include audit completeness checks, required modification verification, and escalation triggers for high-risk decisions.

All rules within a pack are evaluated deterministically — there is no probabilistic scoring in the rule path. Each rule either fires or does not, producing a structured PolicyViolation record when triggered. The highest-severity violation across all fired rules determines the final disposition.

Programmatic Discovery

The full catalog is enumerable over the API, so your integration and your auditors can list every available pack — its version, regulatory domain, jurisdiction, and rule count — without reading this page:

GET /v1/decisions/policies # full catalog with metadata GET /v1/decisions/policies?domain=fair_lending GET /v1/decisions/policies/{policy_id} # one pack's metadata GET /v1/decisions/policy-sets # just the policy_set ids
{ "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 adverse action), FCRA, CFPB UDAAP. Four-fifths disparate-impact rule.", "source": "python" } ] }

Disposition precedence: If any rule triggers BLOCK, the disposition is BLOCKED regardless of other rules. If one or more MODIFY rules fire and no BLOCK fires, the disposition is MODIFIED. If no rules fire, the disposition is ALLOWED.

lending_v1 — Consumer Lending Creditworthiness Baseline

lending_v1 Consumer Lending — Credit Score, Debt-to-Income, Employment

The lending_v1 pack is a deterministic creditworthiness baseline for AI-assisted consumer credit decisions. It has three rules with explicit thresholds. It does not check ECOA / Regulation B fairness or adverse-action notices — those are fair_lending_v1, which an org admin binds alongside it. Default-bound action types include loan_approval, loan_denial, loan_decision, credit_decision, credit_limit_increase, mortgage_approval, underwriting and loan_*.

Required and Read Fields

  • context.credit_score — required. A request without it is a signed BLOCKED decision (COREGUARD.INSUFFICIENT_DATA), never a default approval.
  • context.debt_to_income — ratio, e.g. 0.31; checked when present.
  • context.employment_verified — boolean; a missing or false value fails EMPLOYMENT_REQUIRED.

Rules

Rule IDCheckThreshold
CREDIT_SCORE_MINCredit score is below the minimum.< 620
DTI_LIMITDebt-to-income ratio is above the maximum.> 0.45
EMPLOYMENT_REQUIREDEmployment verification is missing or false.required

Any rule that fires makes the decision BLOCKED. The risk score is a weighted composite of credit score (0.40), debt-to-income (0.35) and employment (0.25).

Sample: BLOCKED Response

BLOCK
POST /v1/decisions/evaluate { "user": { "id": "u_892", "role": "loan_officer" }, "proposed_action": { "type": "loan_approval", "amount": 50000 }, "model_output": { "decision": "approve", "confidence": 0.9 }, "context": { "credit_score": 580, "debt_to_income": 0.52, "employment_verified": true } }
{ "decision": { "status": "BLOCKED", "action": "deny_loan_approval" }, "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" } ], "modifications": null }

Abridged: the full response also carries the signed audit record. Output from the lending_v1 evaluator for this request.

fair_lending_v1 — Fairness & Adverse Action (Four-Fifths Rule)

fair_lending_v1 Fair-Lending Fairness Layer — ECOA / Reg B, FCRA, CFPB UDAAP

Where lending_v1 checks creditworthiness thresholds, fair_lending_v1 enforces the fairness and disclosure obligations an examiner reviews when a denial is challenged. It is purpose-built for AI-assisted credit decisions and pairs naturally with lending_v1 in the same evaluation flow. Every rule is deterministic — no probabilistic scoring in the decision path.

What It Enforces

  • Prohibited-basis input detection — blocks any decision whose feature set contains an ECOA prohibited basis (race, color, religion, national origin, sex, marital status, age, receipt of public assistance) per 12 C.F.R. § 1002.2(z).
  • Adverse-action notice — a denial, counteroffer, or limit reduction must carry specific principal reasons under Regulation B (12 C.F.R. § 1002.9) and FCRA (15 U.S.C. § 1681m).
  • Disparate-impact signal — compares group selection rates against the four-fifths (80%) rule; a protected group rate below 80% of the highest group's rate is flagged for review (EEOC UGESP standard).
  • Proxy-variable risk — flags features that are known proxies for a prohibited basis (zip code, surname, primary language, census tract) unless a documented business necessity is supplied.
  • Model-explainability gate — a denial produced by a model flagged not-explainable cannot generate a compliant adverse-action notice and is escalated to human review.
  • Mandatory human-in-the-loop hold — any HIGH/CRITICAL finding blocks autonomous communication of the adverse decision.

Key Rules

Rule IDSeverityDescription
FL-001BLOCKProhibited-basis attribute present in the decision feature set (per-se ECOA violation).
FL-002BLOCKAdverse decision lacks the specific principal reasons required by Reg B / FCRA.
FL-003BLOCKGroup selection rate falls below the four-fifths (80%) disparate-impact threshold.
FL-004MODIFYProxy variable for a prohibited basis used without documented business necessity.
FL-005BLOCKAdverse decision produced by a non-explainable model — cannot generate a valid notice.
FL-HITL-001BLOCKMandatory fair-lending review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (Disparate Impact)

BLOCK
POST /v1/decisions/evaluate { // Requires a tenant binding: credit_decision is bound to lending_v1 by default. // With no org binding of credit_decision to fair_lending_v1 this request is a // signed BLOCK (COREGUARD.POLICY_BINDING_MISMATCH). "policy_set": "fair_lending_v1", "user": { "id": "u_412", "role": "loan_officer" }, "proposed_action": { "type": "credit_decision", "amount": 30000 }, "context": { "decision": "deny", "adverse_action_reasons": ["debt-to-income ratio too high"], "group_selection_rates": { "control": 0.62, "protected_group_a": 0.41 } } }
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "FL-003", "severity": "HIGH", "description": "Disparate-impact signal: group 'protected_group_a' selection rate 41.0% is 66% of the highest group ('control' at 62.0%), below the four-fifths (80%) threshold.", "remediation": "Hold autonomous denial; route to fair-lending compliance review with a less-discriminatory-alternative analysis." } ], "modifications": null }, "audit_record": { "policy_set": "fair_lending_v1", "disposition": "BLOCKED" } }

healthcare_v1 — Clinical AI (HIPAA-Aligned)

healthcare_v1 Clinical AI — HIPAA (45 CFR Parts 160 & 164) and 42 CFR Part 2

The healthcare_v1 pack enforces six deterministic rules for AI systems that touch clinical decisions or protected health information. It flags the action from the fields you send; it does not read free text. Default-bound action types: diagnosis, diagnose, clinical_determination, treatment_recommendation.

Required and Read Fields

  • context.action_type — required (a request without it is a signed COREGUARD.INSUFFICIENT_DATA block). Values diagnose, diagnosis, diagnostic_conclusion, differential_diagnosis and clinical_determination trigger HCA-001.
  • involves_phi / phi_fields and audit_logged (HCA-002); purpose, requested_fields and required_fields_for_purpose (HCA-003); involves_medication and dosage_specific (HCA-004); consent_documented (HCA-005); emergency_indicators and human_escalated (HCA-006).

Rules

Rule IDSeverityCheck
HCA-001CRITICALA definitive diagnostic conclusion — must be escalated to a licensed clinician.
HCA-002HIGHPHI is involved but audit_logged is not true (45 CFR 164.312(b)).
HCA-003HIGHRequested PHI fields exceed what the stated purpose requires (minimum necessary, 45 CFR 164.502(b)).
HCA-004CRITICALA specific medication dosage recommendation.
HCA-005HIGHA mental-health or substance-use disclosure without documented consent (42 CFR Part 2).
HCA-006CRITICALLife-threatening indicators present but not yet escalated to a human.

Sample: BLOCKED Response

BLOCK
POST /v1/decisions/evaluate { "user": { "id": "u_clin_04", "role": "clinical_ai" }, "proposed_action": { "type": "diagnosis" }, "model_output": { "decision": "diagnose", "confidence": 0.8 }, "context": { "action_type": "diagnose", "involves_phi": true, "audit_logged": true } }
{ "decision": { "status": "BLOCKED", "action": "deny_diagnosis" }, "risk": { "score": 0.9, "level": "HIGH", "factors": ["Attempted diagnostic determination"] }, "policy_violations": [ { "policy_id": "HCA-001", "description": "Definitive diagnostic conclusions (action_type='diagnose') must be escalated to a licensed clinician. AI systems may provide informational context only — not clinical determinations." } ], "modifications": null }

Abridged: the full response also carries the signed audit record. Output from the healthcare_v1 evaluator for this request.

insurance_v1 — Insurance Operations (NAIC-Aligned)

insurance_v1 Insurance — Underwriting Review, Claims, Premiums, Policy Changes

The insurance_v1 pack enforces five deterministic rules for US carriers. Each rule applies to one operation, selected by context.action_type. Default-bound action types: coverage_determination, claims_processing, premium_calculation, policy_modification, rate_change and claim_*.

Read Fields

  • context.action_type — selects the rule; the other fields are read only for that operation.
  • risk_score (or risk) for INS-001; fraud_indicators for INS-002; premium_factors_provided for INS-003; has_open_claims for INS-004; jurisdiction for INS-005.

Rules

Rule IDSeverityCheck
INS-001HIGHcoverage_determination with risk > 0.50 requires human underwriter review.
INS-002HIGHclaims_processing with fraud indicators > 0.30 must be escalated to the Special Investigations Unit.
INS-003MEDIUMpremium_calculation without disclosure of the rating factors used.
INS-004CRITICALpolicy_modification while claims are open (no retroactive changes).
INS-005MEDIUMproduct_launch or rate_change without a jurisdiction for state filing review.

Sample: BLOCKED Response

BLOCK
POST /v1/decisions/evaluate { "user": { "id": "u_uw_17", "role": "underwriting_ai" }, "proposed_action": { "type": "coverage_determination" }, "model_output": { "decision": "deny", "confidence": 0.7 }, "context": { "action_type": "coverage_determination", "risk_score": 0.72 } }
{ "decision": { "status": "BLOCKED", "action": "deny_coverage_determination" }, "risk": { "score": 0.36, "level": "MEDIUM", "factors": ["High-risk coverage determination (risk=0.72)"] }, "policy_violations": [ { "policy_id": "INS-001", "description": "Coverage determination requires human underwriter review when risk > 0.5. Current risk=0.72." } ], "modifications": null }

Abridged: the full response also carries the signed audit record. Output from the insurance_v1 evaluator for this request.

employment_hiring_v1 — Automated Hiring (NYC LL144 / EEOC)

employment_hiring_v1 Automated Employment Decision Tools — NYC Local Law 144, Title VII, ADA

The employment_hiring_v1 pack governs Automated Employment Decision Tools (AEDTs) used to screen, rank, or reject candidates. It enforces New York City Local Law 144 (bias-audit and candidate-notice obligations), the EEOC four-fifths adverse-impact standard, and the protected-class and accommodation requirements of Title VII, the ADEA, and the ADA.

What It Enforces

  • Bias-audit currency — an AEDT must have a completed bias audit within the prior 12 months (NYC Local Law 144); a stale or missing audit blocks autonomous use.
  • Candidate notice — candidates must receive at least 10 business days' notice that an AEDT is in use.
  • Prohibited-basis feature — blocks use of a Title VII / ADEA / ADA protected class (race, sex, age, disability, etc.) as a screening feature.
  • Adverse-impact ratio — applies the four-fifths (80%) rule across group selection rates per EEOC UGESP.
  • Accommodation path — a candidate requesting a reasonable accommodation must have a documented alternative selection process (ADA).
  • Mandatory human-in-the-loop hold on autonomous rejection when any HIGH/CRITICAL finding fires.

Key Rules

Rule IDSeverityDescription
EH-001BLOCKAEDT used without a bias audit completed in the prior 365 days (NYC LL144).
EH-002MODIFYCandidate notice of AEDT use is shorter than the required 10 business days.
EH-003BLOCKProtected-class attribute present in the screening feature set.
EH-004BLOCKGroup selection rate falls below the four-fifths adverse-impact threshold.
EH-005BLOCKAccommodation requested but no alternative selection process is available (ADA).
EH-HITL-001BLOCKMandatory review triggered by any HIGH/CRITICAL finding on an adverse decision.

Sample: BLOCKED Response (Stale Bias Audit)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "EH-001", "severity": "HIGH", "description": "Automated Employment Decision Tool used but last bias audit was 500 days ago. NYC Local Law 144 requires a bias audit within the prior 365 days.", "remediation": "Complete a current bias audit before the tool is used to screen candidates." } ] }, "audit_record": { "policy_set": "employment_hiring_v1", "disposition": "BLOCKED" } }

eu_ai_act_v1 — EU AI Act (Regulation 2024/1689)

eu_ai_act_v1 EU AI Act Conformity — Articles 5, 11, 12, 14, 50; Annex III

The eu_ai_act_v1 pack maps a proposed AI action to the EU AI Act's risk tiers and enforces the operator obligations attached to each tier. It blocks Article 5 prohibited practices outright and verifies the human-oversight, logging, documentation, and transparency duties that apply to Annex III high-risk systems before deployment to the EU market.

What It Enforces

  • Prohibited practices (Article 5) — per-se block for social scoring, manipulative or exploitative techniques, untargeted facial scraping, real-time remote biometric identification, and emotion inference in the workplace or education.
  • Human oversight (Article 14) — Annex III high-risk systems must allow a natural person to oversee, interpret, and override the system.
  • Transparency (Article 50) — natural persons must be informed they are interacting with an AI system and AI-generated content must be marked.
  • Logging & traceability (Article 12) — high-risk systems must retain automatic event logs.
  • Technical documentation (Article 11 / Annex IV) — high-risk systems require a current conformity record.
  • Mandatory conformity review on any HIGH/CRITICAL finding before EU deployment.

Key Rules

Rule IDSeverityDescription
AIA-001BLOCKAction matches an Article 5 prohibited practice — unlawful in the EU market.
AIA-002BLOCKHigh-risk system lacks effective human oversight (Article 14).
AIA-003MODIFYNo AI-interaction / AI-content disclosure provided (Article 50).
AIA-004BLOCKHigh-risk system does not retain automatic event logs (Article 12).
AIA-005MODIFYHigh-risk system lacks current technical documentation (Article 11 / Annex IV).
AIA-HITL-001BLOCKMandatory conformity review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (Prohibited Practice)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "AIA-001", "severity": "HIGH", "description": "AI practice 'social_scoring' is a prohibited practice under Article 5 of the EU AI Act. Deployment is unlawful in the EU market.", "remediation": "Remove the prohibited practice. Re-scope the system to a permitted use before EU deployment." } ] }, "audit_record": { "policy_set": "eu_ai_act_v1", "disposition": "BLOCKED" } }

gdpr_data_processing_v1 — GDPR Data Processing

gdpr_data_processing_v1 GDPR Data Processing — Articles 5, 6, 9, 22, 44–46

The gdpr_data_processing_v1 pack evaluates a proposed processing operation on personal data against the General Data Protection Regulation. It verifies a valid lawful basis, gates special-category data, enforces the Article 22 safeguards for solely-automated decisions, checks data minimisation, and blocks transfers to non-adequate countries without an Article 46 mechanism.

What It Enforces

  • Lawful basis (Article 6) — processing must declare one of the six valid lawful bases.
  • Special-category data (Article 9) — health, biometric, racial, political, and similar data require an explicit Article 9(2) condition.
  • Solely-automated decisions (Article 22) — a decision with legal or similarly significant effect requires both a lawful ground and a human-intervention path.
  • Data minimisation (Article 5(1)(c)) — flags fields collected beyond what the stated purpose requires.
  • International transfer (Articles 44–46) — transfer to a non-adequate third country requires SCCs, BCRs, or a recognised derogation.
  • Mandatory DPO / controller review on any HIGH/CRITICAL finding.

Key Rules

Rule IDSeverityDescription
GDPR-001BLOCKNo valid Article 6 lawful basis declared for the processing operation.
GDPR-002BLOCKSpecial-category data present without an Article 9(2) condition.
GDPR-003BLOCKSolely-automated decision with legal effect missing an Article 22 safeguard or human-intervention path.
GDPR-004MODIFYData minimisation breach — fields collected beyond the stated purpose.
GDPR-005BLOCKTransfer to a non-adequate country without an Article 46 transfer mechanism.
GDPR-HITL-001BLOCKMandatory data-protection review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (No Lawful Basis)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "GDPR-001", "severity": "HIGH", "description": "No valid Article 6 lawful basis declared. Processing of personal data requires one of: consent, contract, legal_obligation, vital_interests, public_task, legitimate_interests.", "remediation": "Establish and record a valid Article 6 lawful basis before processing." } ] }, "audit_record": { "policy_set": "gdpr_data_processing_v1", "disposition": "BLOCKED" } }

securities_trading_v1 — Securities Trading (SEC / FINRA)

securities_trading_v1 Securities Compliance — SEC Rule 10b-5, Reg BI, FINRA 2111 / 5210

The securities_trading_v1 pack governs AI systems that recommend, generate, or execute trades, or that produce investment advice. It blocks insider trading and market manipulation outright, and enforces Reg BI suitability, restricted-list controls, and investment-advice disclosure obligations.

What It Enforces

  • Insider-trading block — orders referencing material non-public information are blocked under Section 10(b) and SEC Rule 10b-5.
  • Market-manipulation detection — spoofing, layering, wash trades, and marking-the-close signatures are blocked (15 U.S.C. § 78i/78j, FINRA Rule 5210).
  • Reg BI suitability — a recommendation whose risk tier exceeds a retail customer's stated tolerance is held for review (17 CFR 240.15l-1, FINRA Rule 2111).
  • Restricted / watchlist securities — trading a security on the firm restricted list is blocked pending clearance.
  • Investment-advice disclosure — definitive retail advice without required disclosures is modified to add them (Investment Advisers Act).
  • Mandatory human review before autonomous execution on any HIGH/CRITICAL finding.

Key Rules

Rule IDSeverityDescription
SEC-001BLOCKOrder references material non-public information (insider trading).
SEC-002BLOCKOrder pattern matches a manipulative-trading signature.
SEC-003BLOCKRecommended instrument risk exceeds retail customer tolerance (Reg BI).
SEC-004BLOCKSecurity is on the firm restricted / watch list.
SEC-005MODIFYRetail investment advice missing required disclosures.
SEC-HITL-001BLOCKMandatory review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (Insider Trading)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "SEC-001", "severity": "HIGH", "description": "Order on 'ACME' references material non-public information. Trading on MNPI violates Section 10(b) and SEC Rule 10b-5.", "remediation": "Block the order and route to compliance for MNPI / restricted-list review." } ] }, "audit_record": { "policy_set": "securities_trading_v1", "disposition": "BLOCKED" } }

debt_collection_v1 — Debt Collection (FDCPA / Reg F)

debt_collection_v1 Fair Debt Collection — FDCPA (15 USC 1692), CFPB Regulation F

The debt_collection_v1 pack governs AI systems that generate or send debt-collection communications. It enforces the FDCPA's contact-time, cease-communication, and anti-harassment rules, the mini-Miranda disclosure, and Regulation F's 7-in-7 calling cap.

What It Enforces

  • Contact-time window — communications must fall within 8:00 am–9:00 pm in the consumer's local time (15 U.S.C. § 1692c(a)(1)).
  • Cease-communication — a written cease request blocks all further contact (15 U.S.C. § 1692c(c)).
  • Anti-harassment — threats, profanity, and false legal threats are blocked (15 U.S.C. § 1692d/e).
  • Mini-Miranda — an initial communication must disclose it is from a debt collector (15 U.S.C. § 1692e(11)).
  • Contact-frequency cap — more than 7 calls in 7 days, or a call within 7 days of a prior conversation, is blocked (12 CFR 1006.14(b)).
  • Mandatory human review before autonomous sending on any HIGH/CRITICAL finding.

Key Rules

Rule IDSeverityDescription
DC-001BLOCKCommunication scheduled outside the 8am–9pm local contact window.
DC-002BLOCKContact attempted after a written cease-communication request.
DC-003BLOCKMessage contains abusive, threatening, or false-threat content.
DC-004MODIFYInitial communication missing the mini-Miranda disclosure.
DC-005BLOCKExceeds the Regulation F 7-in-7 call cap or post-conversation cooldown.
DC-HITL-001BLOCKMandatory review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (Cease Request Violated)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "DC-002", "severity": "HIGH", "description": "Consumer has submitted a written cease-communication request. Further contact is prohibited under 15 USC 1692c(c).", "remediation": "Suppress all further contact except statutorily permitted notices." } ] }, "audit_record": { "policy_set": "debt_collection_v1", "disposition": "BLOCKED" } }

childrens_privacy_v1 — Children's Privacy (COPPA)

childrens_privacy_v1 Children's Online Privacy — COPPA (16 CFR 312), UK Age Appropriate Design Code

The childrens_privacy_v1 pack governs AI systems that may collect data from, or direct content to, children under 13. The pack is scope-gated — it produces no findings unless the subject is a child or the service is directed to children — then enforces verifiable parental consent, minimisation, and the prohibition on profiling minors.

What It Enforces

  • Verifiable parental consent — collecting personal information from a child under 13 requires prior verifiable parental consent (16 CFR 312.5).
  • Data minimisation — collection is limited to what is reasonably necessary to participate (16 CFR 312.7).
  • No profiling / behavioural ads — targeted advertising or profiling of a known child without consent is blocked.
  • Sensitive data — precise geolocation, audio, video, or photos from a minor require separate explicit consent.
  • Third-party disclosure — sharing a child's data requires consent and a documented retention limit.
  • Mandatory human review before autonomous collection on any HIGH/CRITICAL finding.

Key Rules

Rule IDSeverityDescription
COPPA-001BLOCKPersonal information collected from a child under 13 without verifiable parental consent.
COPPA-002MODIFYCollection from a minor exceeds what is reasonably necessary.
COPPA-003BLOCKBehavioural advertising / profiling of a known child without consent.
COPPA-004BLOCKSensitive data collected from a minor without separate explicit consent.
COPPA-005BLOCKThird-party disclosure of a child's data without consent or a retention limit.
COPPA-HITL-001BLOCKMandatory review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (No Parental Consent)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "COPPA-001", "severity": "HIGH", "description": "Personal information is being collected from a child under 13 without verifiable parental consent (16 CFR 312.5).", "remediation": "Obtain verifiable parental consent before collecting any personal information from the child." } ] }, "audit_record": { "policy_set": "childrens_privacy_v1", "disposition": "BLOCKED" } }

biometric_privacy_v1 — Biometric Privacy (BIPA)

biometric_privacy_v1 Biometric Privacy — Illinois BIPA (740 ILCS 14), Texas CUBI, Washington HB 1493

The biometric_privacy_v1 pack governs AI systems that collect or use biometric identifiers — fingerprints, faceprints, voiceprints, iris/retina scans. It is scope-gated to recognized biometric identifiers, then enforces the written-consent, retention, no-sale, disclosure, and safeguard duties of the Illinois BIPA and comparable state statutes.

What It Enforces

  • Written informed consent — a written release is required before collecting a biometric identifier (BIPA §15(b)).
  • Retention & destruction schedule — a published retention schedule and destruction guidelines must exist (BIPA §15(a)).
  • No sale or profit — selling, leasing, or profiting from biometric data is prohibited outright (BIPA §15(c)).
  • Disclosure consent — disclosing biometric data to a third party requires separate consent (BIPA §15(d)).
  • Safeguard standard — storage must meet at least the standard of care used for other confidential data (BIPA §15(e)).
  • Mandatory human review before autonomous collection/use on any HIGH/CRITICAL finding.

Key Rules

Rule IDSeverityDescription
BIO-001BLOCKBiometric identifier collected without prior written informed consent.
BIO-002MODIFYNo published retention schedule and destruction guidelines.
BIO-003BLOCKSale, lease, or profit from biometric data (prohibited outright).
BIO-004BLOCKThird-party disclosure of biometric data without separate consent.
BIO-005MODIFYStorage safeguards below the required standard of care.
BIO-HITL-001BLOCKMandatory review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (No Written Consent)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "BIO-001", "severity": "HIGH", "description": "Biometric identifier(s) ['faceprint'] collected without a prior written informed release. BIPA §15(b) requires written consent before collection.", "remediation": "Obtain a written informed release before collecting or capturing the biometric identifier." } ] }, "audit_record": { "policy_set": "biometric_privacy_v1", "disposition": "BLOCKED" } }

telehealth_prescribing_v1 — Telehealth Prescribing (Ryan Haight)

telehealth_prescribing_v1 Telehealth Prescribing — Ryan Haight Act, Controlled Substances Act, 21 CFR 1306

The telehealth_prescribing_v1 pack governs AI systems that recommend or generate prescriptions in a telehealth setting. It enforces the Ryan Haight Act's examination requirement for controlled substances, cross-state licensure, the Schedule II no-refill rule, and patient-safety checks for allergies, interactions, and dosage bounds.

What It Enforces

  • Controlled-substance examination — a controlled substance requires a qualifying medical evaluation before prescribing (21 U.S.C. § 829(e)).
  • Practitioner licensure — the prescriber must be licensed in the patient's state at the time of the encounter.
  • Schedule II no-refill — Schedule II controlled substances cannot be refilled (21 CFR 1306.12).
  • Allergy / interaction safety — blocks prescriptions matching a recorded allergy or conflicting with an active medication.
  • Dosage bounds — flags a prescribed dose above the labeled maximum.
  • Mandatory human review before autonomous issuance on any HIGH/CRITICAL finding.

Key Rules

Rule IDSeverityDescription
RX-001BLOCKControlled substance prescribed without a qualifying medical evaluation.
RX-002BLOCKPrescriber not licensed in the patient's state.
RX-003BLOCKRefill requested for a Schedule II controlled substance.
RX-004BLOCKPrescription matches a recorded allergy or active drug interaction.
RX-005BLOCKPrescribed dose exceeds the labeled maximum.
RX-HITL-001BLOCKMandatory review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (No Qualifying Exam)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "RX-001", "severity": "HIGH", "description": "Controlled substance 'oxycodone' (Schedule II) prescribed without a qualifying medical evaluation. The Ryan Haight Act (21 USC 829(e)) requires a valid examination before prescribing.", "remediation": "Require a qualifying in-person or telehealth evaluation before issuing the prescription." } ] }, "audit_record": { "policy_set": "telehealth_prescribing_v1", "disposition": "BLOCKED" } }

fair_housing_v1 — Fair Housing (FHA)

fair_housing_v1 Fair Housing — FHA (42 USC 3604), HUD Disparate Impact, FCRA

The fair_housing_v1 pack governs AI used in tenant screening, rental/sale decisions, and housing advertising. It blocks protected-basis decisions and discriminatory ads, applies the HUD four-fifths disparate-impact test to screening outcomes, enforces FCRA adverse-action notices, and requires a disability-accommodation handling path.

What It Enforces

  • Protected-class basis — blocks any housing decision referencing an FHA protected class (race, color, religion, sex, national origin, familial status, disability) per 42 U.S.C. § 3604.
  • Discriminatory advertising — blocks ads expressing a protected-class preference or limitation (42 U.S.C. § 3604(c)).
  • Disparate-impact screening — applies the four-fifths rule to tenant-screening selection rates (HUD 24 CFR 100.500).
  • Adverse-action notice — a screening-report-based denial must include the FCRA notice (15 U.S.C. § 1681m).
  • Disability accommodation — a reasonable-accommodation request needs a documented handling path (42 U.S.C. § 3604(f)).
  • Mandatory human review before autonomous denial / publishing on any HIGH/CRITICAL finding.

Key Rules

Rule IDSeverityDescription
FH-001BLOCKHousing decision references an FHA protected class.
FH-002BLOCKAdvertisement expresses a protected-class preference or limitation.
FH-003BLOCKTenant-screening selection rate fails the four-fifths disparate-impact test.
FH-004BLOCKScreening-based denial missing the FCRA adverse-action notice.
FH-005BLOCKReasonable-accommodation request without a documented handling path.
FH-HITL-001BLOCKMandatory review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (Discriminatory Advertisement)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "FH-002", "severity": "HIGH", "description": "Housing advertisement expresses a preference or limitation based on a protected class: ['children']. Prohibited under 42 USC 3604(c).", "remediation": "Remove the protected-class preference language before publishing the listing." } ] }, "audit_record": { "policy_set": "fair_housing_v1", "disposition": "BLOCKED" } }

marketing_tcpa_v1 — Marketing & Outreach (TCPA / CAN-SPAM)

marketing_tcpa_v1 Marketing Compliance — TCPA (47 USC 227), Telemarketing Sales Rule, CAN-SPAM

The marketing_tcpa_v1 pack governs AI systems that generate or send marketing calls, texts, and emails. It enforces TCPA consent for autodialed messages, the Do-Not-Call registry, calling-time windows, opt-out suppression, and CAN-SPAM email requirements.

What It Enforces

  • Prior express written consent — autodialed/prerecorded marketing calls or texts require it (47 U.S.C. § 227, 47 CFR 64.1200).
  • Do-Not-Call — blocks contact to a DNC-registered number without an exemption (16 CFR 310.4(b)).
  • Calling-time window — blocks marketing calls outside 8:00 am–9:00 pm recipient local time.
  • Opt-out suppression — a prior STOP / unsubscribe blocks all further marketing across channels.
  • CAN-SPAM — marketing email must carry a valid physical address and a functioning unsubscribe link (15 U.S.C. § 7704).
  • Mandatory human review before autonomous sending on any HIGH/CRITICAL finding.

Key Rules

Rule IDSeverityDescription
TCPA-001BLOCKAutodialed/prerecorded marketing message without prior express written consent.
TCPA-002BLOCKContact to a Do-Not-Call-registered number without an exemption.
TCPA-003BLOCKMarketing call outside the 8am–9pm recipient local-time window.
TCPA-004BLOCKContact after a prior opt-out (STOP / unsubscribe).
TCPA-005MODIFYMarketing email missing a physical address or functioning unsubscribe.
TCPA-HITL-001BLOCKMandatory review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (Opt-Out Violated)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "TCPA-004", "severity": "HIGH", "description": "Recipient previously opted out (STOP / unsubscribe). Further marketing contact across any channel is prohibited until consent is re-established.", "remediation": "Suppress the recipient across all marketing channels." } ] }, "audit_record": { "policy_set": "marketing_tcpa_v1", "disposition": "BLOCKED" } }

anti_bribery_v1 — Anti-Bribery / Anti-Corruption (FCPA / UKBA)

anti_bribery_v1 Anti-Bribery & Anti-Corruption — FCPA (15 USC 78dd-1), UK Bribery Act 2010

The anti_bribery_v1 pack governs AI systems that approve payments, gifts, or third-party engagements. It blocks unapproved payments to government officials and facilitation payments, enforces gift pre-approval thresholds, requires third-party due diligence, and flags business-linked donations.

What It Enforces

  • Foreign-official payment — blocks an unapproved payment or thing of value to a government / foreign official (FCPA 15 U.S.C. § 78dd-1).
  • Facilitation payment — blocks "grease" payments outright (UK Bribery Act 2010).
  • Gift / hospitality threshold — gifts above the firm threshold require pre-approval.
  • Third-party due diligence — engaging an intermediary/agent requires completed anti-corruption due diligence.
  • Charitable / political donation — flags donations linked to obtaining or retaining business.
  • Mandatory human review before autonomous disbursement on any HIGH/CRITICAL finding.

Key Rules

Rule IDSeverityDescription
ABC-001BLOCKUnapproved payment / gift to a government or foreign official.
ABC-002BLOCKGift / hospitality above the pre-approval threshold without approval.
ABC-003BLOCKThird-party intermediary engaged without anti-corruption due diligence.
ABC-004BLOCKFacilitation ("grease") payment — prohibited outright.
ABC-005BLOCKBusiness-linked charitable / political donation without compliance review.
ABC-HITL-001BLOCKMandatory review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (Foreign-Official Payment)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "ABC-001", "severity": "HIGH", "description": "Payment or thing of value directed to a government / foreign official without compliance approval. Prohibited corrupt payment risk under FCPA (15 USC 78dd-1) and the UK Bribery Act.", "remediation": "Block the disbursement and route to the anti-corruption compliance function for review." } ] }, "audit_record": { "policy_set": "anti_bribery_v1", "disposition": "BLOCKED" } }

clinical_trials_v1 — Clinical Trials (ICH-GCP)

clinical_trials_v1 Good Clinical Practice — ICH E6(R2), 21 CFR 50 / 56 / 312

The clinical_trials_v1 pack governs AI systems that support clinical-trial conduct — enrollment, randomization, dosing, adverse-event handling, and protocol adherence. It enforces informed consent, IRB approval, eligibility criteria, expedited SAE reporting, and blinding integrity.

What It Enforces

  • Informed consent — documented consent is required before any trial procedure (ICH-GCP §4.8, 21 CFR 50).
  • IRB / ethics approval — the protocol and its current version must have active IRB/IEC approval (21 CFR 56).
  • Eligibility criteria — a subject failing inclusion/exclusion criteria must not be enrolled.
  • Serious adverse event reporting — an SAE must be reported within the mandated window (21 CFR 312.32).
  • Blinding integrity — no unblinding of a masked trial without an authorized emergency procedure.
  • Mandatory human review before autonomous trial action on any HIGH/CRITICAL finding.

Key Rules

Rule IDSeverityDescription
CT-001BLOCKTrial procedure attempted without documented informed consent.
CT-002BLOCKNo active IRB approval for the protocol / current version.
CT-003BLOCKSubject fails inclusion/exclusion eligibility criteria.
CT-004BLOCKSerious adverse event unreported / past the reporting window.
CT-005BLOCKUnauthorized unblinding of a masked trial.
CT-HITL-001BLOCKMandatory review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (Unreported SAE)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "CT-004", "severity": "HIGH", "description": "Serious adverse event has not been reported and is 48h past awareness (window 24h). 21 CFR 312.32 mandates expedited SAE reporting.", "remediation": "Report the SAE to the sponsor/IRB/FDA immediately per the protocol timeline." } ] }, "audit_record": { "policy_set": "clinical_trials_v1", "disposition": "BLOCKED" } }

accessibility_v1 — Digital Accessibility (WCAG / ADA / 508)

accessibility_v1 Digital Accessibility — WCAG 2.1 AA, ADA Title III, Section 508, EN 301 549

The accessibility_v1 pack governs AI systems that generate or modify user-facing content or interfaces. It checks WCAG 2.1 Level AA success criteria — text alternatives, colour contrast, keyboard operability, form labels, and media captions — before content is published.

What It Enforces

  • Text alternatives — non-text content must carry alt text / a description (WCAG 1.1.1).
  • Colour contrast — text/background contrast must meet the AA ratio (4.5:1 normal, 3:1 large) (WCAG 1.4.3).
  • Keyboard operability — interactive elements must be keyboard operable (WCAG 2.1.1).
  • Form labels — form inputs must have programmatic labels (WCAG 3.3.2).
  • Captions / transcript — pre-recorded media must provide captions or a transcript (WCAG 1.2.x).
  • Mandatory human review before autonomous publishing on any HIGH finding.

Key Rules

Rule IDSeverityDescription
A11Y-001BLOCKNon-text content lacks a text alternative (WCAG 1.1.1).
A11Y-002BLOCKText contrast ratio below the WCAG AA minimum (WCAG 1.4.3).
A11Y-003BLOCKInteractive elements not keyboard operable (WCAG 2.1.1).
A11Y-004MODIFYForm inputs missing programmatic labels (WCAG 3.3.2).
A11Y-005MODIFYPre-recorded media missing captions or transcript (WCAG 1.2.x).
A11Y-HITL-001BLOCKMandatory review triggered by any HIGH finding.

Sample: BLOCKED Response (Insufficient Contrast)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "A11Y-002", "severity": "HIGH", "description": "Text contrast ratio 2.00:1 is below the WCAG AA minimum 4.5:1 for normal text (WCAG 1.4.3).", "remediation": "Adjust foreground/background colours to meet at least a 4.5:1 contrast ratio." } ] }, "audit_record": { "policy_set": "accessibility_v1", "disposition": "BLOCKED" } }

gambling_compliance_v1 — Gambling & Responsible Gaming

gambling_compliance_v1 Responsible Gaming — UIGEA, State Gaming Rules, UK Gambling Commission LCCP

The gambling_compliance_v1 pack governs AI systems operating in online gambling / sports betting. It enforces age verification, geolocation, self-exclusion registers, responsible-gaming deposit/loss limits, and problem-gambling harm intervention before any wager.

What It Enforces

  • Age verification — a player must be verified at or above the legal minimum age before any wager.
  • Geolocation — wagering is permitted only from a licensed/permitted jurisdiction.
  • Self-exclusion — a player on a self-exclusion register or in an active cool-off is blocked.
  • Deposit / loss limit — a wager or deposit exceeding the player's responsible-gaming limit is blocked.
  • Affordability / harm signal — high-risk play patterns trigger responsible-gaming intervention.
  • Mandatory human review before the autonomous wager/deposit on any HIGH/CRITICAL finding.

Key Rules

Rule IDSeverityDescription
GAM-001BLOCKPlayer under the legal age or age not verified.
GAM-002BLOCKWager originates from a non-permitted jurisdiction.
GAM-003BLOCKPlayer on a self-exclusion register or active cool-off.
GAM-004BLOCKWager/deposit exceeds the player's responsible-gaming limit.
GAM-005BLOCKProblem-gambling harm signal detected.
GAM-HITL-001BLOCKMandatory review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (Self-Exclusion)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "GAM-003", "severity": "HIGH", "description": "Player is on the self-exclusion register. All wagers and deposits must be blocked until the exclusion expires and is affirmatively lifted.", "remediation": "Block the wager and suppress the account from gambling activity." } ] }, "audit_record": { "policy_set": "gambling_compliance_v1", "disposition": "BLOCKED" } }
legal_practice_v1 Professional Responsibility — ABA Model Rules 1.6 / 1.7 / 5.5 / 7.1, UPL Statutes

The legal_practice_v1 pack governs AI systems that generate legal content or operate in a law-practice context. It guards against unauthorized practice of law, confidentiality breaches, conflicts of interest, prohibited advertising claims, and — critically for AI — fabricated legal citations.

What It Enforces

  • Unauthorized practice of law — definitive legal advice to a non-client without a relationship or "not legal advice" disclaimer (ABA Model Rule 5.5).
  • Confidentiality — blocks output referencing another client's confidential information (Model Rule 1.6).
  • Conflict of interest — engagement conflicting with an existing matter without a documented waiver (Rules 1.7 / 1.9).
  • Attorney advertising — blocks guarantees of outcome and unsubstantiated comparative claims (Model Rule 7.1).
  • Citation integrity — flags unverified legal citations that may be fabricated.
  • Mandatory human review before autonomous delivery on any HIGH/CRITICAL finding.

Key Rules

Rule IDSeverityDescription
LAW-001BLOCKDefinitive legal advice to a non-client without a relationship or disclaimer (UPL).
LAW-002BLOCKOutput references another client's confidential information.
LAW-003BLOCKConflict of interest without a documented waiver.
LAW-004MODIFYProhibited outcome guarantee or unsubstantiated comparative claim.
LAW-005BLOCKUnverified — possibly fabricated — legal citations.
LAW-HITL-001BLOCKMandatory review triggered by any HIGH/CRITICAL finding.

Sample: BLOCKED Response (Unverified Citation)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "LAW-005", "severity": "HIGH", "description": "Legal citations/authorities in the output are unverified and may be fabricated. Unverified citations in legal filings have led to sanctions; every authority must be checked before delivery.", "remediation": "Verify every cited authority against an authoritative legal database before delivery." } ] }, "audit_record": { "policy_set": "legal_practice_v1", "disposition": "BLOCKED" } }

General Assistant and Chat Traffic

There is no general-purpose “enterprise” pack. An earlier version of this page described one; it was never in the built-in catalog, is not returned by GET /v1/decisions/policies, and a request that names it is refused. General assistant, co-pilot and chat traffic is governed by the content-safety packs below.

chat_safety_v1 Content Safety — Open Chat and Assistant Traffic

Chat-shaped action types (chat, chat_message, chat_response, message, response, model_inference, llm_prompt, llm_completion, completions, embeddings) are bound by default to the content-safety family. chat_safety_v1 governs by default; a request may assert another member of the family, which is evaluated in addition and can only make the decision stricter.

PackWhat it does
chat_safety_v1Allow benign, block harmful: matches the prompt or response text against the harm-pattern batteries from harmful_content_v1. Any harm match is BLOCKED; there are no form or disclosure rules, so ordinary conversation is not blocked.
regulated_chat_v1Regulated-context overlay (RC-001–RC-007): legal, medical and financial advice limits, crisis escalation, minor protection, regulated-product disclaimer and retention disclosure.
harmful_content_v1Direct harmful-content detection across 7 harm categories; the default for agent tool calls, agent chain steps and RAG retrieval.

Employment decisions are governed by employment_hiring_v1, and personal-data handling by pii_handling_v1. Organization-specific rules (confidentiality classes, acceptable-use lists) need a custom pack bound to your action types; see Requesting Custom Policy Packs.

Requesting Custom Policy Packs

Every regulated industry has compliance requirements that no standard pack fully addresses. EVE CoreGuard supports fully custom policy packs — authored in collaboration with EVE Core's policy engineering team and your compliance counsel — that encode your organization's specific regulatory obligations, internal policies, and risk tolerance thresholds.

Custom Pack Development Process

  1. Requirements intake — Your legal and compliance team documents the regulatory obligations and internal policies the pack must enforce, including the specific actions, outputs, and data elements in scope.
  2. Rule authoring — EVE Core's policy engineering team translates regulatory text and internal policy into EVE CoreGuard rule definitions. Each rule is mapped to a specific statutory or policy citation.
  3. Simulation testing — The draft pack is run against a corpus of synthetic test cases, including adversarial edge cases. Results are reviewed with your compliance team before deployment.
  4. Version assignment — The finalized pack is assigned a versioned identifier (e.g., regional_lending_v1) and deployed to your EVE CoreGuard instance. It governs a decision once your org admin binds your action types to it; all subsequent evaluations under that binding are tied to the specific rule version in the audit certificate.
  5. Ongoing maintenance — As regulations change, EVE Core provides pack update notifications and a structured amendment process so your enforcement layer stays current.

Custom pack development is available on Enterprise plans. To begin the requirements intake process, contact [email protected] or speak with your account manager.

Custom rule constraints: Custom rules can add restrictions and new enforcement obligations to a base pack. Custom rules cannot disable or weaken rules in the base pack — each versioned base pack's core protections are immutable. This design ensures that compliance obligations derived from law cannot be configured away at the application layer.

Versioning and Changelog

Policy packs follow semantic versioning. The major version number increments when a rule change would break existing integrations — for example, when a new BLOCK rule is added that would cause previously-ALLOWED requests to be BLOCKED. Minor version increments add new MODIFY rules, refine rule logic without changing disposition outcomes, or update reference data (such as drug dosage bounds).

Every pack identifier names an explicit version (e.g., lending_v1, not lending_latest), and the signed certificate records the evaluated pack’s identity and digest. If you send policy_set as an assertion, use the explicit id (or the immutable reference <namespace>/<policy_id>@<digest>) so a binding change is refused rather than silently applied. Automatic version upgrades are never applied without customer consent.

Current Versions

PackVersionReleasedStatus
lending_v11.0.02026-04-01Current
fair_lending_v11.0.02026-06-04Current
healthcare_v11.0.02026-03-15Current
insurance_v11.0.02026-02-28Current
employment_hiring_v11.0.02026-06-04Current
eu_ai_act_v11.0.02026-06-04Current
gdpr_data_processing_v11.0.02026-06-04Current
securities_trading_v11.0.02026-06-04Current
debt_collection_v11.0.02026-06-04Current
childrens_privacy_v11.0.02026-06-04Current
biometric_privacy_v11.0.02026-06-04Current
telehealth_prescribing_v11.0.02026-06-04Current
fair_housing_v11.0.02026-06-04Current
marketing_tcpa_v11.0.02026-06-04Current
anti_bribery_v11.0.02026-06-04Current
clinical_trials_v11.0.02026-06-04Current
accessibility_v11.0.02026-06-04Current
gambling_compliance_v11.0.02026-06-04Current
legal_practice_v11.0.02026-06-04Current

Full changelogs for each pack are available in the EVE CoreGuard Changelog. Enterprise customers receive advance notice of all planned major version releases.

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.