Skip to content

Insights

Domain knowledge worth preserving: things we've learned about insurance operations, AI in regulated decisions, and the knowledge engineering problems we're solving. Not product documentation — perspective.

Why jurisdiction rules go stale

Workers' compensation benefit schedules, medical fee schedules, and TTD rates are set by state statute and updated annually (sometimes mid-year by emergency regulation). A carrier relying on hardcoded rates in application logic will be computing incorrect reserves within months of any statutory change.

enCODE's approach: jurisdiction rules live as versioned chunks in the GKR, not in code. A rate change is a CurationStudio edit that goes through the curation lifecycle (draft → review → approved → active). The tool that consumes the rule reads the active version at runtime — no redeploy required.

The Perplexity verification pipeline (backlog item P2-15) will automate freshness checks: sweep public sources quarterly, compare against active chunks, flag mismatches for human review.

Why SIC code is the primary routing key

The Standard Industrial Classification (SIC) code is the most reliable anchor for appetite and eligibility decisions because:

  1. Carriers already capture it at submission (it appears on ACORD forms)
  2. It maps deterministically to NAICS (via the crosswalk table in reference_data)
  3. It indexes into industry vertical chunks, exclusion matrices, and class appetite tables without requiring NLP

A submission without a valid SIC code cannot pass Gate 1 of the eligibility pipeline. This is a feature, not a limitation — it forces completeness at intake.

The two failure modes of company wikis

We pre-empted both in the build spec:

Failure mode 1 — Staleness: Content accurate on day one, wrong by month three. Fixed by: git-revision-date plugin stamps every page; quarterly staleness sweep flags pages untouched in 90+ days.

Failure mode 2 — Drift from source of truth: Wiki copies a spec or governance table; the source changes; the wiki is now wrong but looks authoritative. Fixed by: the boundary rule — governed artifacts are linked, never copied.

Add an insight

Insights belong here when they would otherwise be repeated in multiple conversations, onboarding sessions, or PRs. The test: would a new developer need to learn this, and is it not already in a spec or a CLAUDE.md? If yes, write it here.

Use plain prose. No tables unless the comparison genuinely needs one. Link to source material rather than copying it.