· enCODE
Confidential · Executive pre-read · July 2026
Pre-read · The enCODE semantic layer

Every claims decision in enCODE is a queryable fact, with its governing rule attached.

You are evaluating whether platforms in this category have a real semantic layer. This pre-read shows how enCODE builds one: an insurance claims ontology, a governed knowledge graph, and a query surface on open W3C standards. It is written to frame a working session, not to replace one.

Document
enCODE Pre-read
Audience
Claims & data leadership
Read time
8 minutes
Purpose
Frame our working session
01 Executive summary One page · Four takeaways

The semantic layer is not a feature of enCODE. It is the structure of it.

Each takeaway summarizes a section of this pre-read. If only one page is read, this is the one.

I.

The questions that matter in claims are relationship questions, and document stores answer document questions.

Audit chains, hidden clusters, and portfolio views all require traversing connections across claims. Today those connections exist only in adjuster memory.

II.

Three structural gaps separate a claims data store from claims intelligence: trace, entity, and portfolio.

Each is independent, and closing all three is what a semantic layer actually means. Most platforms close none.

III.

Anyone can build a graph. enCODE's graph is governed: every edge answers to a versioned, approved rule.

Governed Knowledge Retrieval (GKR) supplies the rules; the semantic layer binds every decision to the rule that governed it. The whole layer is portable: any data store, any SPARQL endpoint, any model your policy permits.

IV.

Four operational questions prove the layer, and FNOL is where it is being built first.

One-query audit chains, repeat-entity detection, jurisdiction portfolio command, and deterministic straight-through routing. The build starts at first notice of loss: the earliest facts on any claim, governed from intake.

02 The problem Exhibit 1 of 5

Every stage of the claim produces decisions, and the record of why dissolves into isolated documents.

The claim lifecycle below is standard. What is not standard is being able to answer, months later and in one step, why any decision along it was made.

1 · Where decisions happen versus where their record survives
STAGE 01 STAGE 02 STAGE 03 STAGE 04 STAGE 05 STAGE 06 FNOL &intake Coverageanalysis Investigation Evaluation &reserving Resolution Payment &recovery DECISION DECISION DECISION DECISION CLAIM SYSTEM RECORD ADJUSTER NOTES + FILE RULE MANUALS + GUIDELINES Status codes, amounts,dates. No reasons. The reasons, in free text.Searchable, not queryable. The rules that applied.Cited nowhere, or as strings. × × NO EDGES BETWEEN THEM. ONLY KEYS AND MEMORY. THE QUESTION THAT ARRIVES LATER "Why was this claim handled this way?" (regulator, reinsurer, plaintiff counsel) Source: ElevateNow analysis. Illustrative.
Implication. The cost of this gap is not abstract: it is the file review before every audit, the reserve committee that reconstructs history by hand, and the fraud pattern nobody sees because it spans three claim files. The reasons exist. They are just not connected to anything.
03 The three gaps Exhibit 2 of 5

Three structural gaps separate a claims data store from claims intelligence: trace, entity, and portfolio.

The gaps are independent. A platform can close one and still fail the other two. Closing all three is what "semantic layer" should mean when a vendor says it.

2 · The three gaps, each with its failure mode
GAP 01 · TRACE GAP 02 · ENTITY GAP 03 · PORTFOLIO The citation is a string, not an edge The same party appears in five claims, invisibly Every rollup is a hand-built pipeline DECISION Denied RULE WC-SI-008 ? The rule id sits in a text field. You cannot ask "which rule drove the most denials this quarter." Decisions and rules never meet. CLAIM A CLAIM B CLAIM C The same employer, provider, or attorney is a spelling variant in each document. The cluster never surfaces. Patterns live between claims, not inside them. Exposure by state? Every leadership question becomes an aggregation project across collections. The pipeline is rebuilt for every new question. Source: ElevateNow analysis. Illustrative.
So what. These three gaps are the analytical frame for the rest of this document. The architecture in Section 05 closes all three with one construction: a governed graph where decisions, entities, and rules are nodes with typed edges between them.
04 Positioning Exhibit 3 of 5

Semantic layers are becoming table stakes. The differentiator is whether the graph is governed.

Two axes decide the category: how connected the data is, and whether the knowledge applied to it has a lifecycle. Most tools you are evaluating sit on the left or the bottom.

3 · The claims AI landscape on two axes
GOVERNED KNOWLEDGE UNGOVERNED KNOWLEDGE DOCUMENT GRAIN RELATIONSHIP GRAIN Q1 · GOVERNED, ISOLATED Q2 · GOVERNED, CONNECTED Q3 · UNGOVERNED, ISOLATED Q4 · UNGOVERNED, CONNECTED Rules engines governed rules, no claim graph Warehouse + BI aggregates, no reasons RAG copilots fluent answers, no anchor Generic graph platforms edges without a rule lifecycle enCODE semantic layer Every edge answers to a versioned rule. Source: ElevateNow analysis. Category positions are directional, not vendor rankings.
Read this as. A due-diligence test, not a market map. Ask any platform two questions: can you traverse from a decision to the rule that governed it, and does that rule have a version, an approver, and an effective date? Q2 is where both answers are yes.
The enCODE thesis · in one sentence

Anyone can build a knowledge graph. The question that matters is whether every edge in it answers to a governed rule.

ElevateNow · July 2026
05 Architecture Exhibit 4 of 5

Your data stays where it is. ElevateNow ships the intelligence layer on top of it.

Three components travel with every deployment: a registry that defines what can be said, a pipeline that admits facts only through a gate, and a query surface that answers in plain language. Incoming FNOL and claim documents are structured by Document Intelligence and governed to the same ontology, through the same gate, as your structured data. Institutional knowledge is governed through Governed Knowledge Retrieval (GKR). Nothing in the stack requires a specific vendor, store, or model.

4 · What the client brings, what ElevateNow ships
THE CLIENT BRINGS ELEVATENOW SHIPS · THE PORTABLE INTELLIGENCE LAYER CLAIM DOCUMENTS FNOL, medical reports, correspondence. The narrative stream. CLAIMS DATA STORE Any system: claims admin, warehouse, document store. Nothing migrates. INSTITUTIONAL KNOWLEDGE Rules, authority matrices, jurisdiction guidelines 01 · enc: REGISTRY Ontology definitions, predicate dictionary, validation shapes. Defines what can be said; governs both fact streams below. 02 · ENRICHMENT + PROMOTION GATE · BOTH FACT STREAMS, ONE GATE DOCUMENT INTELLIGENCE Structures incoming FNOL and claim documents against the same ontology definitions ENRICHMENT PASS Spec-driven mapping reads your store, mints candidate facts STAGING Candidate facts from both streams, not yet trusted THE GATE validation + human review GOVERNED GRAPH Versioned, provenanced, permanent, no personal data 03 · NLQ ENGINE Plain-language ask on governed query templates. Model neutral: routes to the LLM your policy permits Extracted links and inferences always take the human-review tier; nothing extracted is trusted without validation. GKR · GOVERNED KNOWLEDGE RETRIEVAL Rule lifecycle: draft, review, approved, active, superseded THE ARTIFACT Answer + governance trace: template, predicates, rules cited The graph serializes to Turtle or JSON-LD and loads into any SPARQL endpoint you already run. Embedded by default; your endpoint at scale. VERSIONED RULE CITATIONS OPEN STANDARDS RAIL W3C RDF · SPARQL 1.1 · SHACL validation · PROV provenance · Turtle / JSON-LD export. No proprietary graph format. Your data exits in a standard. Source: ElevateNow platform architecture. Simplified for reading.
SHIP 01 · Registry
enc: registry
The portable vocabulary. Every entity, relationship, and rule of admission, defined once and shipped with every deployment.
What it holds
  • Entities at claim, exposure, and decision grain
  • A predicate dictionary: every relationship named and typed
  • Line-of-business extensions: WC, Auto, GL as separate registries
  • Validation shapes that enforce what the graph may admit
  • Authority tiers and jurisdiction as first-class dimensions
  • Versioned; your extensions live in your own namespace
For your claims organization
Your lines, decision points, and authority structure extend the core in a carrier namespace, with ownership defined up front, never negotiated after the fact.
SHIP 02 · Pipeline
Enrichment + gate
The connected record. Document facts and data facts both enter as candidates; the gate decides what becomes trusted.
What it enforces
  • Two intake streams, one gate: Document Intelligence structures incoming FNOL and claim documents; a mapping spec per source system reads your structured store
  • Permanent identifiers with no personal data in them
  • Staging first: candidate facts held until validated; document-derived links default to human review
  • Promotion gate: automated validation plus human review
  • Reserve revisions as version chains, never overwrites
  • Every decision edge cites a versioned, approved rule, with full provenance per batch
For your claims organization
Works against the claims store you already run: core system, warehouse, or document database. Nothing migrates, and extraction output never writes directly into the trusted record.
SHIP 03 · Query
Governed query, plain language
The payoff. Ask in plain terms; the engine matches a governed query template, runs it, and answers only from the results.
What it answers
  • Full decision chain for any claim in one query
  • Repeat-entity clusters across the whole book
  • Portfolio rollups by jurisdiction, line, severity
  • Which rule drove which outcomes, over time
  • Prose is constrained to the result set: the answer never editorializes
  • Questions outside the template library return visibly marked as generated, with the query attached
For your claims organization
Every answer carries a governance footer: which template ran, which predicates, which rules. Model neutral: it routes to the LLM your policy permits, including on-premise.
Read together. The three shipped components are one design: the registry defines what can be said, the pipeline controls what is admitted as fact, and the query surface makes the admitted facts answer questions in plain language. Remove any one and the other two degrade to a diagram.
06 The artifact Exhibit 5 of 5

One query returns what three systems and a file review return today, with the governing rule attached.

Below is a fatality case rendered as the graph sees it. Synthetic case, real structure. Everything inside the bracket returns from a single traversal.

5 · A governed decision trace, one traversal
ONE QUERY CLAIM · WC Case WC-1042 · FL Fatality · marine logistics EXPOSURE Coverage × claimant identifier: CLM-3c57 (no PII) PARTY · EMPLOYER Harborline Logistics RESERVE · v2 SUPERSEDES v1 $105K indemnity + expense DECISION · AUTHORITY GATE Route: Claims Director review reason: fatality + reserve threshold RECOVERY · SUBROGATION Third-party contractor identified GOVERNING RULE · GKR AUTH-WC-FL-014 · v1.2 approved · effective 2026-03-28 clickable in the workbench HAS EXPOSURE HAS PARTY HAS RESERVE HAS DECISION HAS RECOVERY CITES Legacy path to the same answer: claim system lookup, reserve report export, subrogation log, plus a file review to find the reason. Four steps, no rule citation. Source: ElevateNow. Synthetic case, illustrative values.
Why this matters. The same construction answers three other questions that prove the layer: the repeat employer invisible across separate claim files, the portfolio rolled up by jurisdiction with exposure and priority, and the straight-through case routed autonomously with a citable reason. Ask any of them in plain language and the answer arrives with a governance footer naming the template, the predicates, and the rules it cites. These four are the demonstration set; your top ten become the acceptance set.
07 Working session agenda Six items · 60 minutes

The goal of our meeting is a working session, not a demo.

We would rather spend the hour on your questions and your book than on our slides. The pre-read exists so the session can start at the interesting part.

  1. 01

    Your ten questions come first.

    We start from the operational questions your directors ask today, not from our demonstration script.

  2. 02

    Ontology fit to your book.

    Which lines and decision points matter first for you: Workers Compensation, Auto, General Liability, and in what order.

  3. 03

    The governance walkthrough.

    The rule lifecycle, the promotion gate, and how a citation reaches the adjuster's screen.

  4. 04

    Data prerequisites, stated plainly.

    What we need from your claims data to activate the graph, and what we never put in an identifier.

  5. 05

    Standards and exit rights.

    What W3C RDF, SPARQL, SHACL, and PROV mean for your architecture team, your integrations, your model policy, and your ability to leave.

  6. 06

    Open questions.

    The questions your team is already asking about any platform in this category. We would like to hear them before we propose anything.

ElevateNow Founding Team
enCODE · Governance-first AI for insurance operations
Confidential · Pre-read v1
July 2026