enCODE — Knowledge & Rules Engine

enCODE is the carrier's rules engine: appetite, exclusions, jurisdiction requirements, and claims protocols encoded once, versioned, cited, and compiled to the carrier's compute. When an AI agent makes a decision, it cites enCODE — not "the model said so."

---

What problem it solves

Insurance AI verdicts must be defensible. A claim denial, an underwriting decline, or a reserve recommendation will be reviewed by a supervisor, a regulator, or a reinsurer. If the answer is "the LLM decided," the program is a liability. enCODE makes every answer traceable to a specific rule version that a human wrote, reviewed, and approved.

---

How it works — the GKR

The core of enCODE is the Governed Knowledge Repository (GKR) — a curated, ontology-indexed database of knowledge chunks.

What a chunk is: A discrete, versioned unit of insurance knowledge. Examples: - An industry vertical appetite statement ("Restaurants: Eligible for GL up to $5M, conditional above") - A coverage exclusion ("No product liability for pharmaceutical manufacturers") - A WC jurisdiction rule ("California: TTD rate = 66.67% of AWW, min $242.86, max $1,619.15 as of 2026-01-01") - A triage rule ("FNOL flagged for litigation if attorney representation indicated at intake")

Current scale: 1,425 knowledge chunks · 8,010 ontology edges · 7,749 reference data records · 14 chunk types across underwriting, FNOL, claims authority, and binding authority

Two-layer content model: - Platform layer (platform_only) — carrier-neutral baselines that ship to all deployments - Carrier layer (carrier_supersedes) — per-tenant overrides that take precedence at runtime

This means a carrier can override a platform-level appetite position without touching shared code.

---

The three-gate eligibility pipeline

For underwriting submissions, enCODE runs a zero-LLM deterministic eligibility check before any AI agent sees the submission:

Gate 1 — Hard Exclusions
  SIC code → NAICS crosswalk → exclusion matrix lookup
  Result: PASS / FAIL (short-circuits on FAIL — no further processing)
    ↓
Gate 2 — Vertical Appetite
  SIC → vertical index → industry_vertical chunks
  Result: ELIGIBLE / CONDITIONAL / DECLINE
    ↓
Gate 3 — Operations Exclusion
  Keyword match on business_description against operations_exclusion chunks
  Result: PASS / FLAG

Every gate produces a citable verdict with the specific chunk ID and version that governed the decision.

---

CurationStudio — how rules get into enCODE

Rules don't go directly into the database. They go through CurationStudio, the knowledge curation platform that enforces the governance lifecycle:

draft → review → approved → active → stale → revalidated → expired → superseded

CurationStudio is live at gkr-curationstudio.elevatenow.tech. It provides: - A 32-page React UI for browsing, authoring, and reviewing chunks - A 5-module pipeline for extracting knowledge from carrier documents - An immutable audit log of every mutation (who changed what, from what, to what, and when) - Ontology edge management (CLASSIFIES, GOVERNS, INFORMS, SUPERSEDES relationships between chunks)

---

Key demoboards

Artifact	What it covers	Link
Semantic Layer Executive Pre-read	Claims ontology, knowledge graph architecture, PolicyGraph design	View
Engineering Architecture (Internal)	Three-repo runtime, four human gates, component map, semantic layer attachment	View

Full asset index → Asset Library

---

Key repositories

Repo	Purpose
elevatenow-platform/elevatenow-rule-layer/CurationStudio/	GKR backend (FastAPI) + Studio UI (React)
Tool_Chest/Tools/	Python tools that read chunks at runtime
elevatenow-workbench/	Frontend that renders enCODE agent outputs

Do not query elevatenow_gkr directly from tools. All GKR queries go through interfaces/gkr_query.py.