CoreGuard Policy Packs
Policy packs are the enforcement modules that define what 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
Every call to POST /v1/decisions/evaluate includes a policy_set field that names the pack to invoke. 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.
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)
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)
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. 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 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 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 [email protected] or speak with your account manager.
Custom rule constraints: Custom rules can add restrictions and new enforcement obligations to a base pack. Custom rules cannot disable or weaken rules in the base pack — each versioned base pack's core protections are immutable. This design ensures that compliance obligations derived from law cannot be configured away at the application layer.
Versioning and Changelog
Policy packs follow semantic versioning. The major version number increments when a rule change would break existing integrations — for example, when a new BLOCK rule is added that would cause previously-ALLOWED requests to be BLOCKED. Minor version increments add new MODIFY rules, refine rule logic without changing disposition outcomes, or update reference data (such as drug dosage bounds).
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 |
| healthcare_v1 | 1.2.1 | 2026-03-15 | Current |
| insurance_v1 | 1.1.0 | 2026-02-28 | Current |
| enterprise_v1 | 1.3.0 | 2026-04-10 | Current |
Full changelogs for each pack are available in the CoreGuard Changelog. Enterprise customers receive advance notice of all planned major version releases.