CONTEXT
Nsight was built for staff at large multi-site churches: executive and operations pastors, and the one data or IT person who supports them. Their numbers live in a church management system, giving platforms and spreadsheets, and someone usually maintains the weekly scorecard by hand.
THE PROBLEM
Getting an answer out of that data takes an analyst, a query and a week. Pointing a chatbot at the database doesn't fix it. It creates three new problems.
Confidently wrong
Ask a generic AI how many households give and it invents a definition on the spot, a different one each time. In a demonstration on synthetic data, a generic answer said 1,724 households. The church's own rule said 1,717. Leaders end up re-arguing what the number means instead of acting on it.
Unsafe by default
Letting a model write SQL against a live database means trusting it never to write, never to run away with a query and never to see tables it shouldn't.
No way to check
An answer without its working is just an opinion. Staff need to see the question, the rule and the query behind every number.
HOW WE SOLVED IT
- 01
Definitions are compiled once, then reused everywhere
A church writes its own rule in plain English, such as “attends a group 12 times in 52 weeks.” Nsight asks only the clarifying questions that change the answer, writes the SQL, then writes a second, independent query that must count the same people before the draft is shown. The rule is checked against numbers the church already trusts and approved by an admin. From then on every answer, dashboard and weekly report uses that exact rule instead of guessing again.
- 02
Read-only at more than one layer
Every query passes a SELECT-only safety gate that wraps it in a row limit. It then runs read-only at the database driver itself: a read-only transaction with a statement timeout, or a read-only file handle. Admins choose which tables Nsight can see at all, and connection credentials are encrypted at rest.
- 03
Show the work
Each answer streams back with its chart and the SQL behind it. Charts come from a validated spec with a rule-based fallback, so a bad model response degrades to a sensible chart instead of a broken one. Pinned dashboard widgets store their query and re-run it live, so a dashboard is never a stale screenshot.
WHAT WE CHOSE NOT TO DO
- No drag-and-drop dashboard canvas. Conversation replaces dashboard building; the layout grid is ready for drag-and-drop later if people ask for it.
- No “trusted mode” that switches off security checks for convenience. Internal certificate authorities are supported properly instead.
- No split into microservices. One codebase serves hosted and self-hosted deployments, with explicit policies for each.
WHERE IT STANDS
Nsight connects to SQL Server and Azure SQL, PostgreSQL, MySQL, BigQuery, Google Sheets, CSV uploads and church management platforms, with Microsoft sign-in and admin, member and viewer roles. Dedicated deployments can run inside the church's own Azure tenant with their own Microsoft sign-in.
- NEXT.JS
- TYPESCRIPT
- POSTGRES
- PRISMA
- CLAUDE
- OPENAI
- RECHARTS
- OIDC / ENTRA