EVE Core/ Docs/ Policy Packs
Reference

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

Every call to POST /v1/decisions/evaluate includes a policy_set field that names the pack to invoke. EVE CoreGuard selects the corresponding evaluator, runs the action through its rule tree, and returns a disposition of ALLOWED, BLOCKED, or MODIFIED along with a signed decision certificate.

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": 27, "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 (ECOA / FCRA)

lending_v1 Consumer Lending Compliance — ECOA, FCRA, Fair Lending

The lending_v1 pack enforces compliance obligations arising from the Equal Credit Opportunity Act (ECOA), the Fair Credit Reporting Act (FCRA), Regulation B, and federal fair lending guidance. It is designed for AI systems operating in consumer lending workflows, including loan origination, automated underwriting, adverse action generation, and credit risk explanation.

What It Enforces

  • Prohibition on using protected class characteristics (race, sex, national origin, religion, age, marital status, receipt of public assistance) as inputs to credit decisions, directly or as proxies.
  • Mandatory adverse action notice requirements under ECOA and Regulation B — any BLOCKED or restricted credit action must be accompanied by the specific reasons required by 12 C.F.R. § 202.9.
  • FCRA consumer report usage controls — validates that consumer report data is being used for a permissible purpose and that dispute-related notations are not suppressed.
  • Fair lending disparate impact flag — triggers when a decision pattern across a session produces statistically anomalous outcomes on protected-class proxies.
  • APR and fee disclosure requirements — blocks any output that quotes a loan rate or fee schedule without the required TILA-style disclosure elements.
  • Prohibition on AI-generated adverse action language that does not match the CFPB-approved reason code taxonomy.

Key Rules

Rule IDSeverityDescription
lending.prohibited_basisBLOCKAction payload references a prohibited characteristic under ECOA directly or via a detected proxy feature.
lending.adverse_action_noticeBLOCKCredit denial or restriction lacks required adverse action reasons per Reg B § 202.9.
lending.fcra_permissible_purposeBLOCKConsumer report data is referenced without a declared permissible purpose.
lending.tila_disclosureMODIFYLoan offer contains rate or fee information without required TILA disclosure language.
lending.reason_code_taxonomyMODIFYAdverse action reason text does not conform to CFPB-approved reason code taxonomy.
lending.dispute_suppressionBLOCKDecision suppresses or ignores a FCRA consumer dispute notation present in the context.

Sample: BLOCKED Response (Prohibited Basis)

BLOCK
POST /v1/decisions/evaluate { "policy_set": "lending_v1", "user": { "id": "u_892", "role": "loan_officer" }, "action": { "type": "generate_credit_decision", "applicant_age": 67, "stated_rationale": "Applicant is 67 years old and likely retired; income stability uncertain." }, "context": {} }
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "lending.prohibited_basis", "severity": "HIGH", "description": "Decision rationale explicitly references applicant age, a prohibited basis under ECOA 15 U.S.C. § 1691.", "remediation": "Remove age-based reasoning. Re-evaluate using only permissible financial factors." } ], "modifications": null }, "audit_record": { "decision_id": "dec_01hwz3mq4k9p", "timestamp": "2026-05-05T14:22:11Z", "policy_set": "lending_v1", "disposition": "BLOCKED" } }

Sample: MODIFIED Response (Missing TILA Disclosure)

MODIFY
{ "decision": { "status": "MODIFIED", "risk_level": "MEDIUM", "violations": [ { "rule_id": "lending.tila_disclosure", "severity": "MEDIUM", "description": "Loan offer includes APR (7.99%) without required TILA disclosure language.", "remediation": "Append required annual percentage rate disclosure per Reg Z." } ], "modifications": { "append_text": "Annual Percentage Rate (APR): 7.99%. APR is subject to change. Federal law requires lenders to disclose the cost of credit." } } }

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 { "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-Adjacent)

healthcare_v1 Clinical AI Safety — HIPAA, FDA SaMD, Clinical Documentation

The healthcare_v1 pack governs AI operating in clinical workflows — including clinical decision support, ambient documentation, prior authorization assistance, and patient-facing health information. It enforces a combination of HIPAA privacy and security obligations, FDA guidance on Software as a Medical Device (SaMD), and clinical safety standards derived from recognized clinical informatics frameworks.

What It Enforces

  • Prohibition on AI-generated definitive diagnoses — any output that presents a diagnosis without the required qualifying language ("consult a licensed clinician") is blocked or modified to add the required disclaimer.
  • Drug dosage safety bounds — outputs containing medication dosage recommendations are checked against a curated clinical reference; anomalous dosages trigger a BLOCK with a safety alert.
  • PHI exposure detection — action payloads and outputs are scanned for unintended Protected Health Information exposure, including name, MRN, date of birth, diagnosis codes, and prescription identifiers.
  • Clinical certainty calibration — prohibits absolute certainty claims in diagnostic contexts where clinical evidence is probabilistic.
  • Anatomical plausibility checks — detects anatomically impossible or implausible statements in clinical notes and summaries.
  • Mandatory referral triggers — specified symptom clusters (including chest pain, stroke indicators, suicidal ideation) require the output to include a mandated emergency referral directive.

Key Rules

Rule IDSeverityDescription
clinical.no_definitive_diagnosisMODIFYOutput presents a diagnosis without required "consult a clinician" qualifier.
clinical.drug_dosage_anomalyBLOCKMedication dosage recommendation falls outside safe clinical reference bounds.
clinical.phi_exposureBLOCKOutput contains detectable PHI elements not authorized by the declared context.
clinical.certainty_calibrationMODIFYDiagnostic output uses absolute certainty language in a probabilistic clinical context.
clinical.emergency_referralMODIFYSymptom cluster matches emergency criteria; output must include referral directive.
clinical.anatomical_plausibilityBLOCKClinical output contains anatomically implausible statement detected by structural validation.

Sample: MODIFIED Response (Diagnosis Without Qualifier)

MODIFY
{ "decision": { "status": "MODIFIED", "risk_level": "MEDIUM", "violations": [ { "rule_id": "clinical.no_definitive_diagnosis", "severity": "MEDIUM", "description": "Output states 'The patient has Type 2 Diabetes' without required clinical qualifier.", "remediation": "Append required disclaimer language." } ], "modifications": { "append_text": "This AI-generated assessment is not a medical diagnosis. Please consult a licensed healthcare provider for evaluation and diagnosis.", "flag_for_clinician_review": true } } }

Sample: BLOCKED Response (Drug Dosage Anomaly)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "clinical.drug_dosage_anomaly", "severity": "HIGH", "description": "Recommended metformin dose (8,000 mg/day) exceeds maximum safe daily dose (2,550 mg/day per clinical reference).", "remediation": "Remove dosage recommendation. Refer to prescribing clinician for dose determination." } ] } }

insurance_v1 — Automated Underwriting

insurance_v1 Insurance Underwriting — State Regulatory Compliance, Adverse Action

The insurance_v1 pack targets AI used in property and casualty, life, and health insurance underwriting. It enforces state-level unfair discrimination prohibitions, adverse action notice requirements under applicable state insurance codes, and federal protections including the Genetic Information Nondiscrimination Act (GINA) for life and health products.

What It Enforces

  • Unfair discrimination prohibition — blocks use of race, color, national origin, or religion as underwriting factors; enforces state-specific lists of prohibited characteristics (which vary by jurisdiction).
  • Credit score usage controls — in states with restrictions on insurance credit scoring (California, Hawaii, Maryland, Massachusetts, Michigan), flags non-compliant use of credit-based insurance scores.
  • GINA compliance — blocks any request to use genetic test results or genetic predisposition information in life, disability, or long-term care underwriting decisions.
  • Adverse action notice requirements — any declination, non-renewal, or significant premium increase must include state-required reason statements; missing notices trigger BLOCK.
  • Actuarial justification flag — algorithm-driven rate differentials exceeding a configurable threshold without declared actuarial basis are flagged for review.
  • Territory rating controls — validates that geographic rating factors are derived from permissible actuarial data, not proxies for protected class membership.

Key Rules

Rule IDSeverityDescription
insurance.unfair_discriminationBLOCKUnderwriting decision uses a prohibited characteristic as a rating or eligibility factor.
insurance.gina_violationBLOCKGenetic information is referenced in a life or health underwriting context.
insurance.credit_score_stateBLOCKCredit-based insurance score used in a jurisdiction where such use is prohibited.
insurance.adverse_action_noticeBLOCKDeclination or adverse action lacks required state-mandated reason statement.
insurance.actuarial_justificationMODIFYRate differential exceeds threshold without declared actuarial basis; flags for actuarial review.
insurance.territory_ratingMODIFYGeographic rating factor lacks permissible actuarial data declaration.

Sample: BLOCKED Response (GINA Violation)

BLOCK
{ "decision": { "status": "BLOCKED", "risk_level": "HIGH", "violations": [ { "rule_id": "insurance.gina_violation", "severity": "HIGH", "description": "Context includes BRCA1 genetic test result referenced in a life insurance underwriting action. Use of genetic information in life underwriting is prohibited under GINA Title II.", "remediation": "Remove genetic information from underwriting context. Re-evaluate using permissible medical history factors only." } ] } }

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" } }

enterprise_v1 — General Enterprise Assistant

enterprise_v1 Enterprise AI Guardrails — General Workplace Assistant

The enterprise_v1 pack provides broad AI governance coverage for general-purpose enterprise AI assistants — co-pilots, document drafters, HR tools, and internal knowledge systems. It enforces common enterprise compliance obligations including Title VII and ADA employment law constraints, confidentiality protections, PII/PIPA safeguards, and acceptable use policy enforcement.

What It Enforces

  • Employment law constraints — blocks AI-generated employment decisions (hiring recommendations, performance evaluations, termination suggestions) that reference protected class characteristics under Title VII, the ADA, or the ADEA.
  • Confidentiality classification controls — detects outputs that reference or reproduce content tagged as CONFIDENTIAL or RESTRICTED in the enterprise data classification schema.
  • PII minimization — flags outputs that include unnecessary personal identifiers; triggers MODIFY to redact or generalize identifiers not required for the stated purpose.
  • Legal advice boundary — blocks the AI from presenting output as legal advice or professional legal opinion; mandates "consult your legal counsel" qualifier for legal interpretation outputs.
  • Financial advice boundary — applies the same pattern for financial advice, mandating disclosure that the output does not constitute regulated investment advice.
  • Acceptable use enforcement — configurable blocklist for topics and output types designated off-limits under the customer's acceptable use policy, evaluated via keyword and semantic matching.

Key Rules

Rule IDSeverityDescription
enterprise.employment_protected_classBLOCKEmployment decision references a protected class characteristic under Title VII, ADA, or ADEA.
enterprise.confidentiality_leakBLOCKOutput reproduces content classified CONFIDENTIAL or RESTRICTED without authorization context.
enterprise.pii_minimizationMODIFYOutput includes personal identifiers not required for the declared purpose.
enterprise.legal_advice_boundaryMODIFYOutput presents legal interpretation without required "consult legal counsel" qualifier.
enterprise.financial_advice_boundaryMODIFYOutput presents investment or financial guidance without required disclosure language.
enterprise.acceptable_useBLOCKOutput matches topic or content type on customer-configured acceptable use blocklist.

Sample: ALLOWED Response

ALLOW
{ "decision": { "status": "ALLOWED", "risk_level": "LOW", "violations": [], "modifications": null }, "audit_record": { "decision_id": "dec_01hwz8nq2r4m", "timestamp": "2026-05-05T14:30:44Z", "policy_set": "enterprise_v1", "disposition": "ALLOWED" } }

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. All subsequent evaluations using that pack 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 compliance@eveaicore.com 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).

The policy_set field in your API request should always reference an explicit version (e.g., lending_v1, not lending_latest). This ensures that your integration is pinned to a specific, auditable rule set. Automatic version upgrades are never applied without customer consent.

Current Versions

PackVersionReleasedStatus
lending_v11.4.22026-04-01Current
fair_lending_v11.0.02026-06-04Current
healthcare_v11.2.12026-03-15Current
insurance_v11.1.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
enterprise_v11.3.02026-04-10Current

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.