§ How it works

See the questions. Check the answers. Catch regressions.

Nodal gives data teams observability and evaluation for self-service analytics. Review questions captured from connected AI workflows, test answers against analyst-approved references, and investigate changes. People keep using their supported agents; your team keeps control of the business definitions.

01 · Observe questions →02 · Evaluate answers →03 · Share context →

Compare the platform, hands-on sprint, and free tools →

Pillar I — Observability

See what your organization actually asks.

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.

Observability in the docs ↗

Claude · illustrative workflow

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

Review needed · assumptions remain

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.

Pillar II — Evaluation · CI for analytics

Test context like code — when the business changes, nothing should break.

Every code change gets a pull request. A number gets none — it just ships. Nodal gives analytics its CI: every dbt commit, doc edit, prompt change, or model swap triggers a re-run, drift gets attributed to the specific change that caused it, and accuracy gets 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.

Evaluation & drift detection in the docs ↗

Illustrative evaluation report · sample figures

Example trigger: dbt model change (sample commit a3f8c2d)

92 questions evaluated

88 passed

4 drifted

0 failed

Affected

dim_patients → enrollment_status

Drifted questions

"Active Medicare patients by region" — result changed
"Enrollment trend by quarter" — confidence score dropped -12
"Payer mix for active patients" — SQL changed
"Patient count by enrollment status" — result changed

View full benchmark report View dbt diff

Watch · A dbt change and the answers it affects

Shorelane is Nodal’s open reliability testbed: a fictional commerce business with synthetic data, a public warehouse, dbt models, and business questions with documented reference answers. What is Shorelane? →

This recording demonstrates rerunning saved questions after a dbt change and inspecting affected answers. A changed answer needs review against its approved reference before it is called a failure. The healthcare report above is illustrative and separate from this demonstration.

Pillar III — Governed context

Your governed context, every agent.

Keep one source of truth. Leave model logic, lineage, and column metadata in dbt. Maintain analyst-confirmed business meaning in your context repository.
Give your agents the same definitions. Connect supported agents to the context your team owns, rather than maintaining a separate glossary for each tool.
Use what you already have. Bring existing context or build it with the free Nodal Context tools. Your team controls access to each source.

Business meaning

Nodal Context · your GitHub

Approved definitions, dashboard filters, caveats, and evaluation cases.

Technical context

Your dbt project

Models, column metadata, tests, and lineage. Keep these definitions here.

Supporting evidence

Your other context

Query history, team documentation, and existing semantic definitions. Surface conflicts for review.

Ask where you already work

Your AI agent of choice

Claude Code · Codex · Cursor

Uses the business meaning and technical context together.

Query the data

Your warehouse

Snowflake · BigQuery · Redshift

Run read-only queries under your approved identity.

Check the answer

Your reference dashboards

Use analyst-approved dashboard figures and filters as reference evidence for evaluations.

How the pieces work together: each source keeps its role and owner. Agents need approved access to the relevant sources; sharing business context alone does not grant dbt, warehouse, or dashboard access.