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.
Contents
- Policy Pack Architecture
- lending_v1 — Consumer Lending (ECOA / FCRA)
- fair_lending_v1 — Fairness & Adverse Action (Four-Fifths Rule)
- healthcare_v1 — Clinical AI (HIPAA-Adjacent)
- insurance_v1 — Automated Underwriting
- employment_hiring_v1 — Automated Hiring (NYC LL144 / EEOC)
- eu_ai_act_v1 — EU AI Act (Regulation 2024/1689)
- gdpr_data_processing_v1 — GDPR Data Processing
- securities_trading_v1 — Securities Trading (SEC / FINRA)
- debt_collection_v1 — Debt Collection (FDCPA / Reg F)
- childrens_privacy_v1 — Children's Privacy (COPPA)
- biometric_privacy_v1 — Biometric Privacy (BIPA)
- telehealth_prescribing_v1 — Telehealth Prescribing (Ryan Haight)
- fair_housing_v1 — Fair Housing (FHA)
- marketing_tcpa_v1 — Marketing & Outreach (TCPA / CAN-SPAM)
- anti_bribery_v1 — Anti-Bribery / Anti-Corruption (FCPA / UKBA)
- clinical_trials_v1 — Clinical Trials (ICH-GCP)
- accessibility_v1 — Digital Accessibility (WCAG / ADA / 508)
- gambling_compliance_v1 — Gambling & Responsible Gaming
- legal_practice_v1 — Legal Practice (ABA Model Rules)
- enterprise_v1 — General Enterprise Assistant
- Requesting Custom Policy Packs
- Versioning and Changelog
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:
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)
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 ID | Severity | Description |
|---|---|---|
| lending.prohibited_basis | BLOCK | Action payload references a prohibited characteristic under ECOA directly or via a detected proxy feature. |
| lending.adverse_action_notice | BLOCK | Credit denial or restriction lacks required adverse action reasons per Reg B § 202.9. |
| lending.fcra_permissible_purpose | BLOCK | Consumer report data is referenced without a declared permissible purpose. |
| lending.tila_disclosure | MODIFY | Loan offer contains rate or fee information without required TILA disclosure language. |
| lending.reason_code_taxonomy | MODIFY | Adverse action reason text does not conform to CFPB-approved reason code taxonomy. |
| lending.dispute_suppression | BLOCK | Decision suppresses or ignores a FCRA consumer dispute notation present in the context. |
Sample: BLOCKED Response (Prohibited Basis)
Sample: MODIFIED Response (Missing TILA Disclosure)
fair_lending_v1 — Fairness & Adverse Action (Four-Fifths Rule)
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 ID | Severity | Description |
|---|---|---|
| FL-001 | BLOCK | Prohibited-basis attribute present in the decision feature set (per-se ECOA violation). |
| FL-002 | BLOCK | Adverse decision lacks the specific principal reasons required by Reg B / FCRA. |
| FL-003 | BLOCK | Group selection rate falls below the four-fifths (80%) disparate-impact threshold. |
| FL-004 | MODIFY | Proxy variable for a prohibited basis used without documented business necessity. |
| FL-005 | BLOCK | Adverse decision produced by a non-explainable model — cannot generate a valid notice. |
| FL-HITL-001 | BLOCK | Mandatory fair-lending review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (Disparate Impact)
healthcare_v1 — Clinical AI (HIPAA-Adjacent)
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 ID | Severity | Description |
|---|---|---|
| clinical.no_definitive_diagnosis | MODIFY | Output presents a diagnosis without required "consult a clinician" qualifier. |
| clinical.drug_dosage_anomaly | BLOCK | Medication dosage recommendation falls outside safe clinical reference bounds. |
| clinical.phi_exposure | BLOCK | Output contains detectable PHI elements not authorized by the declared context. |
| clinical.certainty_calibration | MODIFY | Diagnostic output uses absolute certainty language in a probabilistic clinical context. |
| clinical.emergency_referral | MODIFY | Symptom cluster matches emergency criteria; output must include referral directive. |
| clinical.anatomical_plausibility | BLOCK | Clinical output contains anatomically implausible statement detected by structural validation. |
Sample: MODIFIED Response (Diagnosis Without Qualifier)
Sample: BLOCKED Response (Drug Dosage Anomaly)
insurance_v1 — Automated Underwriting
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 ID | Severity | Description |
|---|---|---|
| insurance.unfair_discrimination | BLOCK | Underwriting decision uses a prohibited characteristic as a rating or eligibility factor. |
| insurance.gina_violation | BLOCK | Genetic information is referenced in a life or health underwriting context. |
| insurance.credit_score_state | BLOCK | Credit-based insurance score used in a jurisdiction where such use is prohibited. |
| insurance.adverse_action_notice | BLOCK | Declination or adverse action lacks required state-mandated reason statement. |
| insurance.actuarial_justification | MODIFY | Rate differential exceeds threshold without declared actuarial basis; flags for actuarial review. |
| insurance.territory_rating | MODIFY | Geographic rating factor lacks permissible actuarial data declaration. |
Sample: BLOCKED Response (GINA Violation)
employment_hiring_v1 — Automated Hiring (NYC LL144 / EEOC)
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 ID | Severity | Description |
|---|---|---|
| EH-001 | BLOCK | AEDT used without a bias audit completed in the prior 365 days (NYC LL144). |
| EH-002 | MODIFY | Candidate notice of AEDT use is shorter than the required 10 business days. |
| EH-003 | BLOCK | Protected-class attribute present in the screening feature set. |
| EH-004 | BLOCK | Group selection rate falls below the four-fifths adverse-impact threshold. |
| EH-005 | BLOCK | Accommodation requested but no alternative selection process is available (ADA). |
| EH-HITL-001 | BLOCK | Mandatory review triggered by any HIGH/CRITICAL finding on an adverse decision. |
Sample: BLOCKED Response (Stale Bias Audit)
eu_ai_act_v1 — EU AI Act (Regulation 2024/1689)
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 ID | Severity | Description |
|---|---|---|
| AIA-001 | BLOCK | Action matches an Article 5 prohibited practice — unlawful in the EU market. |
| AIA-002 | BLOCK | High-risk system lacks effective human oversight (Article 14). |
| AIA-003 | MODIFY | No AI-interaction / AI-content disclosure provided (Article 50). |
| AIA-004 | BLOCK | High-risk system does not retain automatic event logs (Article 12). |
| AIA-005 | MODIFY | High-risk system lacks current technical documentation (Article 11 / Annex IV). |
| AIA-HITL-001 | BLOCK | Mandatory conformity review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (Prohibited Practice)
gdpr_data_processing_v1 — GDPR Data Processing
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 ID | Severity | Description |
|---|---|---|
| GDPR-001 | BLOCK | No valid Article 6 lawful basis declared for the processing operation. |
| GDPR-002 | BLOCK | Special-category data present without an Article 9(2) condition. |
| GDPR-003 | BLOCK | Solely-automated decision with legal effect missing an Article 22 safeguard or human-intervention path. |
| GDPR-004 | MODIFY | Data minimisation breach — fields collected beyond the stated purpose. |
| GDPR-005 | BLOCK | Transfer to a non-adequate country without an Article 46 transfer mechanism. |
| GDPR-HITL-001 | BLOCK | Mandatory data-protection review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (No Lawful Basis)
securities_trading_v1 — Securities Trading (SEC / FINRA)
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 ID | Severity | Description |
|---|---|---|
| SEC-001 | BLOCK | Order references material non-public information (insider trading). |
| SEC-002 | BLOCK | Order pattern matches a manipulative-trading signature. |
| SEC-003 | BLOCK | Recommended instrument risk exceeds retail customer tolerance (Reg BI). |
| SEC-004 | BLOCK | Security is on the firm restricted / watch list. |
| SEC-005 | MODIFY | Retail investment advice missing required disclosures. |
| SEC-HITL-001 | BLOCK | Mandatory review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (Insider Trading)
debt_collection_v1 — Debt Collection (FDCPA / Reg 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 ID | Severity | Description |
|---|---|---|
| DC-001 | BLOCK | Communication scheduled outside the 8am–9pm local contact window. |
| DC-002 | BLOCK | Contact attempted after a written cease-communication request. |
| DC-003 | BLOCK | Message contains abusive, threatening, or false-threat content. |
| DC-004 | MODIFY | Initial communication missing the mini-Miranda disclosure. |
| DC-005 | BLOCK | Exceeds the Regulation F 7-in-7 call cap or post-conversation cooldown. |
| DC-HITL-001 | BLOCK | Mandatory review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (Cease Request Violated)
childrens_privacy_v1 — Children's Privacy (COPPA)
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 ID | Severity | Description |
|---|---|---|
| COPPA-001 | BLOCK | Personal information collected from a child under 13 without verifiable parental consent. |
| COPPA-002 | MODIFY | Collection from a minor exceeds what is reasonably necessary. |
| COPPA-003 | BLOCK | Behavioural advertising / profiling of a known child without consent. |
| COPPA-004 | BLOCK | Sensitive data collected from a minor without separate explicit consent. |
| COPPA-005 | BLOCK | Third-party disclosure of a child's data without consent or a retention limit. |
| COPPA-HITL-001 | BLOCK | Mandatory review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (No Parental Consent)
biometric_privacy_v1 — Biometric Privacy (BIPA)
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 ID | Severity | Description |
|---|---|---|
| BIO-001 | BLOCK | Biometric identifier collected without prior written informed consent. |
| BIO-002 | MODIFY | No published retention schedule and destruction guidelines. |
| BIO-003 | BLOCK | Sale, lease, or profit from biometric data (prohibited outright). |
| BIO-004 | BLOCK | Third-party disclosure of biometric data without separate consent. |
| BIO-005 | MODIFY | Storage safeguards below the required standard of care. |
| BIO-HITL-001 | BLOCK | Mandatory review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (No Written Consent)
telehealth_prescribing_v1 — Telehealth Prescribing (Ryan Haight)
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 ID | Severity | Description |
|---|---|---|
| RX-001 | BLOCK | Controlled substance prescribed without a qualifying medical evaluation. |
| RX-002 | BLOCK | Prescriber not licensed in the patient's state. |
| RX-003 | BLOCK | Refill requested for a Schedule II controlled substance. |
| RX-004 | BLOCK | Prescription matches a recorded allergy or active drug interaction. |
| RX-005 | BLOCK | Prescribed dose exceeds the labeled maximum. |
| RX-HITL-001 | BLOCK | Mandatory review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (No Qualifying Exam)
fair_housing_v1 — Fair Housing (FHA)
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 ID | Severity | Description |
|---|---|---|
| FH-001 | BLOCK | Housing decision references an FHA protected class. |
| FH-002 | BLOCK | Advertisement expresses a protected-class preference or limitation. |
| FH-003 | BLOCK | Tenant-screening selection rate fails the four-fifths disparate-impact test. |
| FH-004 | BLOCK | Screening-based denial missing the FCRA adverse-action notice. |
| FH-005 | BLOCK | Reasonable-accommodation request without a documented handling path. |
| FH-HITL-001 | BLOCK | Mandatory review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (Discriminatory Advertisement)
marketing_tcpa_v1 — Marketing & Outreach (TCPA / 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 ID | Severity | Description |
|---|---|---|
| TCPA-001 | BLOCK | Autodialed/prerecorded marketing message without prior express written consent. |
| TCPA-002 | BLOCK | Contact to a Do-Not-Call-registered number without an exemption. |
| TCPA-003 | BLOCK | Marketing call outside the 8am–9pm recipient local-time window. |
| TCPA-004 | BLOCK | Contact after a prior opt-out (STOP / unsubscribe). |
| TCPA-005 | MODIFY | Marketing email missing a physical address or functioning unsubscribe. |
| TCPA-HITL-001 | BLOCK | Mandatory review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (Opt-Out Violated)
anti_bribery_v1 — Anti-Bribery / Anti-Corruption (FCPA / UKBA)
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 ID | Severity | Description |
|---|---|---|
| ABC-001 | BLOCK | Unapproved payment / gift to a government or foreign official. |
| ABC-002 | BLOCK | Gift / hospitality above the pre-approval threshold without approval. |
| ABC-003 | BLOCK | Third-party intermediary engaged without anti-corruption due diligence. |
| ABC-004 | BLOCK | Facilitation ("grease") payment — prohibited outright. |
| ABC-005 | BLOCK | Business-linked charitable / political donation without compliance review. |
| ABC-HITL-001 | BLOCK | Mandatory review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (Foreign-Official Payment)
clinical_trials_v1 — Clinical Trials (ICH-GCP)
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 ID | Severity | Description |
|---|---|---|
| CT-001 | BLOCK | Trial procedure attempted without documented informed consent. |
| CT-002 | BLOCK | No active IRB approval for the protocol / current version. |
| CT-003 | BLOCK | Subject fails inclusion/exclusion eligibility criteria. |
| CT-004 | BLOCK | Serious adverse event unreported / past the reporting window. |
| CT-005 | BLOCK | Unauthorized unblinding of a masked trial. |
| CT-HITL-001 | BLOCK | Mandatory review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (Unreported SAE)
accessibility_v1 — Digital Accessibility (WCAG / ADA / 508)
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 ID | Severity | Description |
|---|---|---|
| A11Y-001 | BLOCK | Non-text content lacks a text alternative (WCAG 1.1.1). |
| A11Y-002 | BLOCK | Text contrast ratio below the WCAG AA minimum (WCAG 1.4.3). |
| A11Y-003 | BLOCK | Interactive elements not keyboard operable (WCAG 2.1.1). |
| A11Y-004 | MODIFY | Form inputs missing programmatic labels (WCAG 3.3.2). |
| A11Y-005 | MODIFY | Pre-recorded media missing captions or transcript (WCAG 1.2.x). |
| A11Y-HITL-001 | BLOCK | Mandatory review triggered by any HIGH finding. |
Sample: BLOCKED Response (Insufficient Contrast)
gambling_compliance_v1 — Gambling & Responsible Gaming
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 ID | Severity | Description |
|---|---|---|
| GAM-001 | BLOCK | Player under the legal age or age not verified. |
| GAM-002 | BLOCK | Wager originates from a non-permitted jurisdiction. |
| GAM-003 | BLOCK | Player on a self-exclusion register or active cool-off. |
| GAM-004 | BLOCK | Wager/deposit exceeds the player's responsible-gaming limit. |
| GAM-005 | BLOCK | Problem-gambling harm signal detected. |
| GAM-HITL-001 | BLOCK | Mandatory review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (Self-Exclusion)
legal_practice_v1 — Legal Practice (ABA Model Rules)
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 ID | Severity | Description |
|---|---|---|
| LAW-001 | BLOCK | Definitive legal advice to a non-client without a relationship or disclaimer (UPL). |
| LAW-002 | BLOCK | Output references another client's confidential information. |
| LAW-003 | BLOCK | Conflict of interest without a documented waiver. |
| LAW-004 | MODIFY | Prohibited outcome guarantee or unsubstantiated comparative claim. |
| LAW-005 | BLOCK | Unverified — possibly fabricated — legal citations. |
| LAW-HITL-001 | BLOCK | Mandatory review triggered by any HIGH/CRITICAL finding. |
Sample: BLOCKED Response (Unverified Citation)
enterprise_v1 — General Enterprise 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 ID | Severity | Description |
|---|---|---|
| enterprise.employment_protected_class | BLOCK | Employment decision references a protected class characteristic under Title VII, ADA, or ADEA. |
| enterprise.confidentiality_leak | BLOCK | Output reproduces content classified CONFIDENTIAL or RESTRICTED without authorization context. |
| enterprise.pii_minimization | MODIFY | Output includes personal identifiers not required for the declared purpose. |
| enterprise.legal_advice_boundary | MODIFY | Output presents legal interpretation without required "consult legal counsel" qualifier. |
| enterprise.financial_advice_boundary | MODIFY | Output presents investment or financial guidance without required disclosure language. |
| enterprise.acceptable_use | BLOCK | Output matches topic or content type on customer-configured acceptable use blocklist. |
Sample: ALLOWED Response
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
- 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.
- 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.
- 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.
- 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. - 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
| Pack | Version | Released | Status |
|---|---|---|---|
| lending_v1 | 1.4.2 | 2026-04-01 | Current |
| fair_lending_v1 | 1.0.0 | 2026-06-04 | Current |
| healthcare_v1 | 1.2.1 | 2026-03-15 | Current |
| insurance_v1 | 1.1.0 | 2026-02-28 | Current |
| employment_hiring_v1 | 1.0.0 | 2026-06-04 | Current |
| eu_ai_act_v1 | 1.0.0 | 2026-06-04 | Current |
| gdpr_data_processing_v1 | 1.0.0 | 2026-06-04 | Current |
| securities_trading_v1 | 1.0.0 | 2026-06-04 | Current |
| debt_collection_v1 | 1.0.0 | 2026-06-04 | Current |
| childrens_privacy_v1 | 1.0.0 | 2026-06-04 | Current |
| biometric_privacy_v1 | 1.0.0 | 2026-06-04 | Current |
| telehealth_prescribing_v1 | 1.0.0 | 2026-06-04 | Current |
| fair_housing_v1 | 1.0.0 | 2026-06-04 | Current |
| marketing_tcpa_v1 | 1.0.0 | 2026-06-04 | Current |
| anti_bribery_v1 | 1.0.0 | 2026-06-04 | Current |
| clinical_trials_v1 | 1.0.0 | 2026-06-04 | Current |
| accessibility_v1 | 1.0.0 | 2026-06-04 | Current |
| gambling_compliance_v1 | 1.0.0 | 2026-06-04 | Current |
| legal_practice_v1 | 1.0.0 | 2026-06-04 | Current |
| enterprise_v1 | 1.3.0 | 2026-04-10 | Current |
Full changelogs for each pack are available in the EVE CoreGuard Changelog. Enterprise customers receive advance notice of all planned major version releases.