Guide
Guide to the Enterprise AI Context Layer
What a context layer is, where it sits beside the warehouse and the catalog, and what it takes to give agents governed, cited answers.
Live webinar Nov 5: save your seatLive webinar Nov 5: Building Golden Records & Entity Resolution with Fluree. Save your seat
Industry · Insurance
One governed view of policy, claims, and billing for insurance AI.
Fluree gives carriers a semantic layer that adjusters, underwriters, actuaries, and AI agents can all query. It runs on FlureeDB, a verifiable knowledge graph database. Core systems stay where they are. Each role sees only the fields it’s allowed to see, and any past answer can be checked against the data as it stood at the time.
Works with
Why do insurance AI pilots stall before production?
Because a claim, its policy, and its payments live in different systems, and compliance can’t see what an AI agent saw. The pilot works in the demo. Then it meets production data, role-based access rules, and the next exam.
Policy, claims, and billing don’t agree.
A carrier might run policy admin on one platform, claims on another, and billing on a mainframe, whether that’s Guidewire, Duck Creek, Majesco, or something built in-house. Each system has its own ID for the same insured, and none of them reconciles with the others.
One record, many audiences.
An adjuster needs the claim file. An actuary needs loss data without names. An agent or broker should see their own book and nothing else. An AI layer that runs on one service account can’t tell them apart.
Regulators ask what you knew, and when.
Market-conduct exams, DOI complaints, and claims litigation turn on what the data said at decision time. If an AI agent answered from a table that has changed since, its answer is hard to reproduce.
Three steps.
No migration off the core.
From policy, claims, and billing data to governed answers, while the systems that run the business stay where they are.
Read your core systems in place.Policy, claims, and billing tables are read where they already live, in your lakehouse or SQL sources. Nothing migrates off the core. Claim files and adjuster notes become graph facts.
Resolve one insured across systems.The same policyholder, under different IDs in policy admin, claims, and billing, resolves to one governed record. A data steward reviews the matches.
Ask, with policy and replay built in.Every query runs under the asker’s policy, whether that’s an adjuster, an actuary, or an AI agent. You can rerun it later against the graph as it stood when it was asked.
Attribute-level access, enforced at the data layer.
A regulated insurer can’t keep access rules in a prompt or in each app. FlureeDB checks policy on every fact before data reaches a model, so the same claim returns a different view to each role, including AI agents.
Claim CLM-20417 · one record, four views
Adjuster
Assigned to this claim
- Shown: Policyholder details
- Shown: Coverage and limits
- Shown: Case reserves
- Shown: Injury and medical records
- Withheld: SIU referral notes
Actuary
Pricing and reserving
- Withheld: Policyholder details
- Shown: Coverage and limits
- Shown: Case reserves
- Withheld: Injury and medical records
- Withheld: SIU referral notes
Agent or broker
Their own book only
- Shown: Policyholder details
- Shown: Coverage and limits
- Withheld: Case reserves
- Withheld: Injury and medical records
- Withheld: SIU referral notes
AI claims assistant
Narrower than the adjuster
- Shown: Policyholder details
- Shown: Coverage and limits
- Shown: Case reserves
- Withheld: Injury and medical records
- Withheld: SIU referral notes
Illustrative policy. The rules are yours. Here the claims assistant gets less than the adjuster it works for: injury and medical records are withheld before anything reaches the model.
An audit trail you can replay, down to what the agent saw.
Exams, complaints, and bad-faith claims all ask what the carrier knew and when. With FlureeDB you can query the graph as it existed at any past transaction, timestamp, or commit.
Market-conduct exams
Show an examiner the data behind a claim decision as it stood on the decision date, not as it reads today.
Complaints and litigation
When a denial is challenged, rerun the same query against the same moment and get the same result.
Signed history
Every change to the graph is written as a signed commit, so its history is part of the data.
Claim CLM-20417 · water damage
“Is water backup covered on this policy?”
Asked by the claims assistant on June 9 at 14:02 UTC.
As of June 9, 14:02 UTCWhat the agent saw
Endorsement 3 is not on file.
Answer: not covered under the base form.
TodayCurrent state
Endorsement 3 was processed June 20, effective June 1.
Answer: covered.
Same query, two points in time. Replay shows the assistant answered correctly from what was on file. Today’s data alone would say it got coverage wrong.
Illustrative example
Six workflows, one governed graph.
Start where fragmented data costs the most. Each workflow you add reuses the same model of policyholder, policy, claim, and coverage.
Claims
Give adjusters and claims assistants the whole picture in one query: coverage in force on the date of loss, prior claims, payments, and the claim file, each under the adjuster’s own access rules.
Underwriting
Bring submission data, prior policies, loss history, and billing behavior together for an underwriter or an underwriting assistant, with each fact traced to the system it came from.
Policy and billing service
Answer “why did my premium change?” from endorsements, rating changes, and billing history in one place, for a service rep, an agent, or a self-service assistant.
Fraud and SIU
Follow links between claimants, providers, vehicles, addresses, and policies to surface rings that row-by-row rules miss. Investigation notes stay restricted to SIU.
Reinsurance and bordereaux
Map bordereaux from MGAs and cedents onto your model of policy and claim, then reconcile them against your own records in the graph instead of in spreadsheets.
Actuarial
Give actuaries loss and exposure data joined across policy and claims systems, with personal details withheld by policy instead of by a separate de-identified extract.
Evidence you can check today.
A published banking case study, Fluree’s own accuracy research, and a lending demo kit you can load into a free ledger.
Insurance AI questions, answered.
Short answers to what claims, underwriting, compliance, and data leaders at carriers ask us most.
As a regulated insurer, can we enforce attribute-level access at the data layer?
Yes. FlureeDB enforces access policy inside the database, on every fact, before any data reaches a model. You define the rules once, so an adjuster, an actuary, and an agent or broker can query the same claim and each get only the fields their role allows. AI agents query under policy too, and their policy can be narrower than a person’s. The security overview covers the model in more detail.
Can we keep an audit trail on every answer an AI agent gives?
Fluree keeps the data side of that trail. Every change is a signed commit, and you can query the graph as it existed at any past transaction, timestamp, or commit. Record when an agent answered, and you can rerun its query later against the graph as it stood at that moment, for an examiner, a complaint, or a court. See AI agent governance for how agents fit in.
We’re building a shortlist for a semantic layer our AI agents can query across our source systems. Which vendors belong on it?
Look for four things: one governed model of policyholder, policy, claim, and coverage that spans your systems; access enforced in the data layer rather than in each app; as-of queries, so past answers can be reproduced; and standard interfaces such as SPARQL, openCypher, GraphQL, JSON-LD, and MCP. Our comparison of data platforms for AI agents and our 2026 knowledge graph buyer’s guide cover the main options, including Stardog and Neo4j.
Do we have to migrate off Guidewire, Duck Creek, or our policy admin system?
No. Fluree works alongside your policy administration, claims, and billing systems rather than replacing them. Lakehouse tables and SQL sources are read where they live. Claim files and other documents become graph facts through document extraction; audio or video, such as recorded statements, is supported on the Fluree Enterprise tier. If you want a synced copy inside Fluree, that option exists for Iceberg tables only. The platform overview shows how the pieces fit.
Why a knowledge graph instead of RAG over our data warehouse?
Insurance questions cross systems: a claim, the policy it falls under, the endorsements in force on the date of loss, the producer, the payments. A graph keeps those relationships as data, so they aren’t rebuilt for every question. In Fluree’s 2024 study, GraphRAG for GenAI Accuracy, answers over raw relational tables scored 8–15% zero-shot; a governed knowledge graph reached 95%+ once enriched and joined.
Who implements it, and where do we start?
Start with one workflow where the data already hurts, such as claims triage, an SIU referral queue, or an exam response. Fluree works with your team directly or alongside the systems integrator you already use. Either way, the first step is a demo.
Field notes on governed data in regulated industries.
Writing from the Fluree team on financial data, data-layer security, and what AI agents need from a database.
Security
Why GenAI Security Starts at the Data Layer
Agents on uncontrolled data inherit every gap in the apps around them. Policy embedded in the data is the durable fix.
Enterprise AI
The Right Database for AI Agents
What governed data infrastructure needs when autonomous systems are in the loop, from data-layer policy to time-travel queries.
Start with one workflow.
Pick the claims, underwriting, or exam workflow where the data hurts most. We’ll show you governed answers on it, with access rules and replay in place.
Updated