Early access to the open-source repo is open
§ How it works

The open-source context layer is the foundation. We keep it trustworthy.

Nodal Context — interview-built and open source — grounds your agent on day one. Evaluation and observability are what Nodal adds on top: the discipline that keeps the answers right as usage scales.

Stage I — Implementation

Stand up AI analytics on top of the systems you already have

Today's leading AI agents already work for analytics. You don't need a specialized agent for every problem — you need the context and trust layer that makes any agent reliable. That layer is open source, built from an analyst interview rather than scraped from your docs.

One public data point: a thin Claude Code + Sonnet harness — no custom agent, no fine-tuning — ranked #7 on Spider 2.0-Lite, a widely used text-to-SQL benchmark. That means a general-purpose agent with the right context already competes with purpose-built systems. The misses are what show where context and measurement need to improve. Review the setup ↗

Context
GitHub Notion Snowflake Cortex Atlan
Agents
Claude Code Codex Gemini Claude
Warehouse
Snowflake BigQuery Redshift
BI
Sigma Tableau Hex Looker
analyst@nodal — answered
What's our revenue last quarter?
$4.2M
Q4 2025 · ↑ 12% vs Q3 2025
source
fct_revenue (dbt) · finance domain
fresh
3h ago
trust
94 / 100 · context match
Answered in 0.8s — no escalation
Walkthrough — what deployment looks like
Stage II — Safe rollout · Observability

Interrogate every question. Show your team every answer.

Non-technical users don't ask fully-specified questions. Nodal makes the gaps visible before SQL runs — so widening access doesn't scale plausible-but-wrong answers. And every interaction is captured: your data team sees who asked what, when, and how it was interpreted — attributed and traceable.

  • Question reframed with defaults from your documentation; assumptions in brackets the user can change.
  • Confidence score from auditable signals — entity resolution, schema grounding, doc coverage, context freshness.
  • You approve the interpretation, not the SQL.
  • Every question, every answer, every escalation — logged to your data team's Slack channel with full attribution.
  • Every under-specified question becomes a signal — and a candidate test case for the eval suite.
Claude
You

How does length of stay compare across facilities in the Northeast?

Claude
Your question, disambiguated

What is the [mean inpatient days] per facility for [all facility types] in [the Northeast region] over [trailing 12 months — assumed]?

Defaults pulled from your documentation. Change any [bracket] before I run it.

Where each default came from
  • "mean inpatient days" — dbt model fct_encounters: discharge_date - admission_date (Confluence confirmed)
  • "Northeast" — dim_facilities.region = 'Northeast' (found in 12 dashboards)
  • "all facility types" — no filter specified; you may want acute care only
  • "trailing 12 months" — assumed; not stated in your question
Confidence score 71/100
  • Core metric well-documented across sources
  • Join path validated in dbt lineage
  • Time window assumed
  • Facility scope may be broader than intended

Should I run this, or would you like to change any of the defaults?

You

Narrow to acute care only. Run it.

Observability — the full loop in action
Stage III — Continuous reliability · Evaluation

Regression tests for AI analytics — every commit, every piece.

The same discipline software engineers apply to code, applied to AI analytics. Every dbt commit, doc edit, prompt change, or model swap triggers a re-run. Drift gets attributed to the specific change that caused it. Accuracy and cost-benefit get measured per piece of the system — not assumed.

  • Re-run on every change — schema migrations, dbt commits, doc edits, prompt changes, model swaps. Failures get pinned to the commit that caused them, with affected questions, SQL diffs, and result deltas.
  • Ablation tests on each context source — drop a data dictionary, a Notion page, a glossary entry; measure the answer-quality delta against the token-cost delta.
  • Model trade-off tests — swap Claude for a cheaper model, Codex for Gemini; read off pass rate vs. cost per run.
  • Cost optimization stops being a guess — every piece of the system is benchmarked against the trust it actually delivers.
Benchmark Run — April 8, 2026

Trigger: dbt model change (commit a3f8c2d)

92 questions evaluated
88 passed
4 drifted
0 failed
Affected

dim_patients → enrollment_status

Drifted questions
  1. "Active Medicare patients by region" — result changed
  2. "Enrollment trend by quarter" — confidence score dropped -12
  3. "Payer mix for active patients" — SQL changed
  4. "Patient count by enrollment status" — result changed
View full benchmark report View dbt diff
Documentation health report
67% of answered questions relied on dbt column descriptions
23% used Confluence documentation — but 40% of those pages hadn't been updated in over a year
15% lower consistency on questions grounded in stale docs
End of dispatch

Get this running on your stack.

Book a demo