Skip to content
Get startedRequest a demo

/knowledge-graph

Your tribal knowledge, attached to your data and code.

A living graph your company owns and runs. Agents keep it current as your systems change, and your team approves what goes in. It becomes the system of record for what you know.

Request a demoSee it in the product

What it is

A model of how your business runs, approved by the people who own it.

What counts as an active member. How paid PMPM is measured. Your team’s rules, written down and attached to the tables they describe.

01 · How it builds

It builds itself, from the systems you already run.

Nothing has to move first. Agents read your databases, code, documents, and BI, and write each entry themselves. Where sources disagree, they resolve it and record how.

Pick a source

DefinitionProposed · awaiting review

Allowed amount, after the lesser-of rule

The claim line’s allowed amount after the lesser-of rule, set by a stored procedure, documented in the benefits configuration wiki, and read by the monthly paid claims dashboard.

Applies to claims.claim_line.allowed_amt1 of 4 sources read

Demo data

One column, four sources, one entryFig. 01

It learns with your team.

When someone corrects a query or a term, it becomes a proposal. A person approves it, and every later answer carries it. As proposals hold up, agents approve the routine ones on their own.

A denied line can sit on a partially denied case.

auth.authorization_line · line_status

Source record
Case A-104 is Partial. Its line 02 has line_status D.
Current reading
The filter reads the case status, so it misses this line.
Proposed
Read line_status when a question asks about denied lines.

Demo data

From evidence to approved knowledgeFig. 02

02 · What’s inside

A wiki your team can read, filed by how your business runs.

Each entry is written in plain words and attached to the tables it describes. Agents file new entries where they belong.

KnowledgeSearch knowledge⌘K
ExploreReviewGraphAll entriesNew entry
PitfallEndorsedDemo data

Members are charged cost share past their out-of-pocket maximum

benefits.accumulator holds rows where oop_after exceeds oop_limit, so the cap was not enforced and the member paid.

Updated 1mo ago · Endorsed by Benefits configuration

Applies to

benefits.accumulatorbenefits.filed_benefitbenefits.plan_config

Connected

Part of Accumulators

View in graph

The accumulator ledger replays each member’s claims in service-date order and applies no cap. Where adjudication did not honor the out-of-pocket maximum, the member was charged cost share and the ledger recorded it. The result needs no join to find.

Select from benefits.accumulator where oop_after is greater than oop_limit. Each row already carries the member, plan year, plan, claim, service date, and the cost share applied, so the member and the refund amount are both on it.

Nothing in cases.inquiry_case explains this. No case type covers an out-of-pocket breach, so every row found this way is a confirmed overcharge, not a population to triage.

There is a second, quieter way the cap can be wrong. oop_limit comes from the configured plan in benefits.plan_config, which disagrees with the filed plan in benefits.filed_benefit for some plans. Join benefits.filed_benefit on plan and benefit element to check the limit itself.

The remedy is a member refund and a fix to how claims apply the cap.

The knowledge wiki, liveFig. 03

03 · What runs on it

Each tool reads only the knowledge it needs.

ContextBase reads the shape of each question: the tables it touches and what it asks for. It pulls in only the entries that apply, so answers stay fast. Apps, dashboards, and bots are built the same way, from the same approved entries.

Trace a tool

  • PitfallDenied auths still paidAlso read by the app
  • PitfallLines counted twiceAlso read by the dashboard

Demo data

Each tool reads only what appliesFig. 04

Versioned

Every change goes into the graph, versioned.

Approved knowledge goes into the graph, and every answer reads it from there. Each change records who approved it and when, and old versions stay on the record. The graph also syncs to a Git repo on your account, so your team can review it, diff it, and keep it.

The history

222 commits in the last yeargit@your-org:knowledge.git

metrics/paid_pmpm.md Metric

-pharmacy: excluded+pharmacy: included unless the question asks for medical only

Demo data

Open to your agents

Your agents read it too.

Your own agents, and any MCP client, read the same approved knowledge. The AI your teams already use answers from what your team approved.

AsksWhich denied authorizations still paid this plan year?

Reads4 approved pitfalls on auth.authorization_case

AsksNightly RADV check

ReadsProvider types CMS accepts · approved by Risk adjustment

AsksWhat should I watch for on auth.authorization_case?

ReadsClaims paid on an authorization that was denied

AsksHow is paid PMPM measured?

Readsmetrics/paid_pmpm.md · approved by Finance

Approved onceRead everywhere

Start with what your team already knows.

Connect one system. Its first scan completes within hours, and your team starts approving what ContextBase finds.

Request a demoHow a finding is added

Know. Build. Learn. Repeat.

© 2026 Flume