From a question to a running tool.
Explore your data, find the work worth doing, and keep every answer running.
- WorkData apps
- AgentsBots and your agents
- ChecksAnswer checks
- KnowledgeKnowledge graph
- AccessAccess and audit
- EstateConnectors
What ContextBase is built from. Six parts on the systems you already run, and Data Pipelines to move data between them.
Knowledge graph
A scored, versioned map of what your data means, built from scans of every system you connect.
- Three tiers of analysisDeep introspection of your databases, structured metadata from catalogs and BI, and links to your documentation.
- Scored and versionedEach piece of context carries a confidence score, and every change to it is versioned.
- Lineage across systemsTrace a field from its sources to every view, pipeline, and report that reads it.
authorization_caseclaim_headerinquiry_caseplan_designEVIDENCE SO FARQueries20Sources9Rows436Analyzed8.3MKnowledge4Answer ready: 20 queries across 9 sources, with 4 endorsed pitfalls applied.
Ask a follow-up · sends when this answer finishesGraphPlainAnswer checks
Every answer is tested against the data it returned and what your team has approved.
- Four questions per answerDoes the data support it? Is the population right? Was the right table read? Do the filters do what the answer assumes?
- What your team approvedApproved findings attach to the tables they describe, and the checks read them.
- Nothing goes quietA check that cannot run says so. It never reads as a pass.
7 sources · 29 queries · 4,646 rows · ≈6.2 GB scanned Were copays applied correctly on those members’ claims?
Do not rely on this number yet.
5 of 8 checks found something
The answer states things the data does not show.
Check every figure against what the queries returned.
The answer says copays were applied correctly. The queries counted lines that carry a copay; none compared a copay with the plan’s benefit.
58%The returned data does not support the answer.36%The returned data is consistent with the answer, but the answer states more than the data shows.6%The returned data directly supports the answer as stated.SELECT s.line_type, COUNT(*) AS lines, SUM(CASE WHEN s.copay_amt > 0 THEN 1 ELSE 0 END) AS with_copay FROM claims.claim_line_summary s JOIN enrollment.member_eligibility_v e ON e.member_id = s.member_id WHERE s.plan_year = 2026 AND s.copay_waived = 0 GROUP BY s.line_type;The filter on copay_waived excludes rows. The number is probably understated.
Fix the filter and re-run. Do not use this figure as it stands.
This filter is on a nullable column, so it silently dropped rows: copay_waived = 0 excludes every line where the flag is empty.
71%A filter silently excludes rows the answer assumes are included.22%A filter is questionable and should be checked.7%The filters behave as the answer assumes.SELECT s.line_type, COUNT(*) AS lines, SUM(CASE WHEN s.copay_amt > 0 THEN 1 ELSE 0 END) AS with_copay FROM claims.claim_line_summary s JOIN enrollment.member_eligibility_v e ON e.member_id = s.member_id WHERE s.plan_year = 2026 AND s.copay_waived = 0 GROUP BY s.line_type;The answer ignored knowledge we surfaced.
Check whether the caveat applies here.
Knowledge was surfaced, but none of it was used. Read from the recall record, which marks each surfaced item the answer used. No model involved.
The population is close but may not match the question.
Check the date range and filters against the question.
The question is about members at their out-of-pocket max. The main query reads every member’s lines, so the share could differ for that group.
22%The queried population does not match the question.64%The queried population is close but differs in a way that could change the number.14%The queried population matches the question.SELECT s.line_type, COUNT(*) AS lines, SUM(CASE WHEN s.copay_amt > 0 THEN 1 ELSE 0 END) AS with_copay FROM claims.claim_line_summary s JOIN enrollment.member_eligibility_v e ON e.member_id = s.member_id WHERE s.plan_year = 2026 AND s.copay_waived = 0 GROUP BY s.line_type;This table is derived. It may not reconcile to line detail.
Confirm it is the right source for this question.
claim_line_summary is pre-aggregated. claim_line is the authoritative source for cost share.
27%A wrong source was read for this question.58%A defensible but non-authoritative source was read, such as a derived or pre-aggregated table.15%The authoritative source for this question was read.SELECT s.line_type, COUNT(*) AS lines, SUM(CASE WHEN s.copay_amt > 0 THEN 1 ELSE 0 END) AS with_copay FROM claims.claim_line_summary s JOIN enrollment.member_eligibility_v e ON e.member_id = s.member_id WHERE s.plan_year = 2026 AND s.copay_waived = 0 GROUP BY s.line_type;Passed Queried the estate · Relevant knowledge surfaced · Returned rows
Not run No unsurfaced pitfalls · Re-run verification
These say what was examined about this answer. They do not say the answer is correct: a query can be wrong in a way none of them can see.
Sources read
claims.claim_line_summary318,904enrollment.member_eligibility_v88,102benefit.accumulator_ledger186,420
Agents
Bots and the AI agents you already run work on approved access, inside their scope.
- Read only by defaultA new bot can read its connections and change nothing.
- Honest about its limitsAsked for data outside its scope, an agent says where the data sits instead of guessing.
- Open to your agentsThe AI agents you run elsewhere can read the same approved knowledge.
CC conn 2 · read-onlyCMS CAP Risk Assessment
What would a CMS CAP risk check look like on our data?
I looked for what a CAP risk check needs on connection 2, the only connection in my scope.
- Connection 2 holds commercial claims, eligibility, and pharmacy data for the employer book.
- The only Medicare-related tables on it are reference data: Medicare pricing tier tables, CMS benefit codes, and a CMS NPI dataset. None of them record the plan operations CMS audits.
Where the data likely is
The Medicare Advantage book (Individual MA, Group MA, D-SNP, C-SNP, plus the utilization management and case management systems) sits on a different connection. I’m not allowed to query it.
What a CAP risk check would cover, if my scope included that data
CMS audit area What I would measure Claims timeliness Share of clean claims paid within 30 days, and interest paid on late claims Coverage decisions and appeals Prior auth and appeal turnaround against the 72-hour and 7/14-day limits, plus how often denials get overturned Denial accuracy Denial rates and reason codes by line of business, and denials missing a reason code Enrollment How long enrollment transactions take to process, and how dual-eligible members are handled Part D Rejected pharmacy claims and handling of transition fills Even with that data, a check would only show risk indicators. Whether CMS issues a CAP also depends on audit findings, complaints, and Star Ratings history, which aren’t in the data estate.
Next step: if you widen my scope to the Medicare connection, I can set this up as a weekly routine that alerts you when any measure breaches its threshold.
Data apps
Answers become dashboards and apps that run on the same approved knowledge.
- Clear about what it touchesEach app declares what it reads, its inputs, and what it acts on.
- Dashboards without the modelA refresh re-runs the saved queries, so it spends no tokens.
- Shared in spacesChats, evidence, and everything built from them stay together, ready to hand to a teammate or a client.
Build the tool you need
Describe it in a sentence. It gets built against your own data, and nobody else sees it until you share it.
7 apps · 3 you can operate ·
Payment integrity
Modifier 25 Review QueueDuplicate Payment FinderOutlier ScoringPlan design
Plan Benefit Clustering ToolEmployer Cohort PickerCopay Design ComparatorOpportunity PrioritizationConnectors
ContextBase connects to thousands of databases and maps how they fit together, in days.
- The major systemsDatabases, warehouses, ETL, BI tools, code, and document stores.
- Queried in placeProfiling and cross-system analysis run on the Lakehouse (Trino and Iceberg), where the data already lives.
- One connection, both productsConfigure a connection once, and ContextBase and Data Pipelines both use it.
claim_linemember_spanprior_authorizationDataPropertiesDiagramprior_authorizationdemo_payer_dw › authShowing 1-40 of 318,000 rows · 9 cols9/9PA-26-041833197110ApprovedM-0048112Therapy2026-09-022026-09-0281487603921PA-26-0418332NULLPendedM-0120944Imaging2026-09-02NULL11932145870PA-26-041834072148ApprovedM-0093310Imaging2026-09-022026-09-0311356284470PA-26-041834795810ApprovedM-0017785Sleep study2026-09-022026-09-0211609873345PA-26-041835127447PendedM-0144029Inpatient2026-09-03NULL31740298816PA-26-0418352NULLPendedM-0144029Inpatient2026-09-03NULL31740298816PA-26-041836670553DeniedM-0061207Imaging2026-09-032026-09-0411932145870PA-26-041837097110ApprovedM-0102556Therapy2026-09-032026-09-03121487603921PA-26-041837129881ApprovedM-0038841Outpatient2026-09-032026-09-0411265530914PA-26-0418385NULLPendedM-0129930DME2026-09-04NULL11811047326PA-26-041839043239ApprovedM-0075514Outpatient2026-09-042026-09-0411265530914PA-26-041839295810ApprovedM-0011478Sleep study2026-09-042026-09-0411609873345PA-26-041840472148DeniedM-0150067Imaging2026-09-042026-09-0511356284470PA-26-041841197110ApprovedM-0088203Therapy2026-09-052026-09-0581487603921PA-26-0418419NULLPendedM-0042190Imaging2026-09-05NULL11932145870PA-26-041842095811ApprovedM-0107735Sleep study2026-09-052026-09-0511609873345PA-26-041843370553ApprovedM-0066514Imaging2026-09-052026-09-0611356284470PA-26-041844127447ApprovedM-0131872Inpatient2026-09-062026-09-0631740298816PA-26-041845097110ApprovedM-0024419Therapy2026-09-062026-09-0661487603921PA-26-0418458NULLPendedM-0097763DME2026-09-06NULL11811047326PA-26-041846229881ApprovedM-0056681Outpatient2026-09-062026-09-0711265530914PA-26-041847795810ApprovedM-0139012Sleep study2026-09-072026-09-0711609873345SELECT CELLS FOR STATSAccess and audit
No data request queue. People and agents ask for access, get it for a set window, and every query is on the record.
- A reason for every requestEach request names its reason and its systems, and an approver grants it.
- Ends on its ownAccess is time-limited and expires without anyone having to remember.
- Every query on the recordWho ran what, against which data, and when.
Waiting for approvalDuplicate payment review
Person · pi.analyst@demo-plan.com- Reason
- Find duplicate payments still recoverable this plan year.
- Access to
- claims_dw · read-onlyprovider_master · read-only
- Window
- 8 hours
- Ends on its own
- 5:14 PM
- Requested9:02 AM
- Approved by data.steward@demo-plan.comWaiting
- Access ends5:14 PM
Every query under this request lands on the audit trail.Data Pipelines
Flume’s integration platform moves data between systems, and drafts new relays from the ones you already run.
- Any protocol to any protocolOne source can feed many destinations. A canonical layer in the middle means a new destination never touches the source.
- Test, then productionDraft a relay in TEST and move it to PROD when it is right.
- Years in productionThe infrastructure behind it has moved regulated payer data between systems in production for years.
From Demo Plan · 83 live relays · checked 1h ago New integration
VendorDataEmployer nameEmployer IDsThe relay sends these employers’ members and no others.Rules from other relaysRelay name[TEST] Demo Plan → Care navigation · Demo Logistics · EligibilityFile nameDemoLogistics_CareNav_Elig_%Y%m%d.txt- Copies
- Demo Logistics
- Relay
- Named from the employer
- File
- Named from the employer
- Runs
- Monthly on the 10th, 13:00 UTC · 8 GB
Add the employer to continue.
Put it to work on your data.
Tell us which job to start with, and see ContextBase run it on your own systems.
