A manager asks a question and gets the number, definition, and SQL.
The user does not wait for a basic report. The answer is immediately checkable because the metric definition and executed query sit beside the number.
Measured on 12 test questions
This version answers questions about four approved metrics and shows the definition, result, and executed SQL. It uses a synthetic warehouse and does not connect to client data.
- Recorded run
- Measured on 12 test questions
- Measurement scope
- Questions about business data
- Verified
- synthetic data
Problem, solution, and result
The problem
A simple question about sales or margin joins the analyst's queue. The answer arrives late, and competing definitions of the same metric produce conflicting numbers.
How the system works
The system identifies the metric and builds a query against one of four approved views. A validator checks the SQL, and the database role has read-only access. The answer includes the result, metric definition, and executed query.
What we tested
This version answers questions about four approved metrics and shows the definition, result, and executed SQL. It uses a synthetic warehouse and does not connect to client data.
For whom
This is a good automation candidate when leaders repeatedly ask for the same metrics and analysts spend time rerunning routine queries.
Question → SQL → checkable result
- 01The system uses only approved views
- 02The database role is read-only
- 03The answer shows the metric definition and executed SQL
- Business type
- Companies with a data warehouse and recurring management questions
- Input
- A plain-language question about net revenue, margin, active customers, or average order value
- Boundary
- The system reads only four approved views and cannot write anything to the database
- Cost
- USD 0.004400 per question; USD 0.052794 for the recorded 12-question run.
- Security
- The system can read only approved views and has no permission to change data.
- Speed
- We measure response time in a pilot using the client’s actual metrics and data volume.
- Trace
- Each result retains the question, metric definition, and query used to calculate the answer.
- Similar system build
- from €6,000 net (approx. $6,500) · 4–10 weeks
Reference exchange rates: USD 1 = PLN 3.72; EUR 1 = PLN 4.30. PLN amounts are rounded, with the measurement currency retained in parentheses.
Where automation stops
The analyst owns the scope
The system reads only four approved views and cannot write data. An out-of-scope question receives a clear explanation. The analyst owns metric definitions and decides when the catalogue expands.
- Boundary
- The system reads only four approved views and cannot write anything to the database
- Cost
- USD 0.004400 per question; USD 0.052794 for the recorded 12-question run.
- Security
- The system can read only approved views and has no permission to change data.
- Speed
- We measure response time in a pilot using the client’s actual metrics and data volume.
What still needs testing
The slowest of 12 answers took 8.64 s. This sample is too small to set a daily service level. A pilot also tests ambiguous questions and the wider schema of the production warehouse.
Estimated impact
Calculate the impact at your volume
This estimate uses the stated volume. Enter your own numbers to assess the possible impact in your company. The result is confirmed only during a pilot.
Today
110 h
With the system
24 h
Time or cost saved
Modelled scenario: 65-100 h/mo, base 86 h
- Volume
- Modelled scenario: 120 questions/mo
- Formula
- 120 x 43 min / 60
- Calculation status
- medium
Data in the screenshots. The names, amounts, and documents shown in the screenshots are synthetic. Client data remains private. Measurements describe the demonstrator and are kept separate from production outcomes.
Working surfaces
The analyst owns metric definitions and handles questions outside the approved scope.
Managers can check routine numbers before a meeting. Analysts focus on definitions, new metrics, and questions that require analysis. The estimate below assumes 120 questions per month and can be recalculated with your volume.
Three views for the person asking
Question field
A plain-language business question with no SQL required.
Result card
The number, metric definition, and relevant period.
Result basis
The executed SQL and source view, ready for analyst review.
System screens
See how the system works in practice
These desktop and mobile screenshots come from the running application. They show the process and the points where a person makes the decision.
- Screens
- 12
- px
- 1440 · 390
- 021440×1132
The executed SQL displayed below the answer. - 031440×1100
A clear explanation when the approved scope cannot answer a question.
Open the remaining screen archive (9)
- 041440×1100
Refused questions - 051440×1100
Approved measures - 061440×1100
Sources and views - 071440×1100
Run history - 081440×1503
Measurement scope and limits - 091440×1100
A single question record - 101440×1100
A refused question, a second case - 111440×1100
A write attempt stopped before the database - 121440×1100
A second question record
Technology stack
The model plans; code and database permissions enforce scope
LangChain runs one query plan. The validator blocks disallowed SQL. A separate PostgreSQL role enforces read-only access, a 500-row limit, and an 8 s timeout.
- PostgreSQL 17
- the warehouse and the layer of record; a separate role logs in with no write privilege, holding SELECT in the analytics schema
- FastAPI (Python 3.13)
- runs the query plan, syntactic validation, and limited execution; the validator's allowlist fixes the scope at four approved views
- LangChain + Anthropic model
- generates the answer in a closed schema; picks a metric from the catalogue and never authors one
- Langfuse v2 (local)
- records the question, the executed SQL, latency, and token usage without sending traces outside the stack
- Next.js
- the data workroom: conversation, SQL notebook, and refusal register behind a server-side proxy
The client receives the code, metric catalogue, test data, and documentation. The warehouse connection and final metric definitions are built during implementation.
Technical details and measurements
The working loop
From business question to checkable number
The system selects a metric, builds a query, and validates it before execution. An out-of-scope question stops with an explanation and goes to the analyst.
Business question
Approved metric selection
SQL validation and execution
Out of scope → clear explanation
Result with definition and SQL
System architecture
Metric catalogue, SQL validator, and read-only account
The model plans a query in a closed format. The validator limits it to four views, and database permissions independently block writes.
- 01
Semantics
Metrics have one definition.
The semantic layer defines what net revenue, margin, or an active customer means. The model picks a metric from the catalogue and never authors one, and the definitions are open for inspection next to the answer, so a dispute about a number ends at the definition.
- 02
Validation
The query passes through a sieve.
Only four analytical views are allowed. Other relations, CTEs, system functions, comments, multiple statements, and write operations are rejected before execution.
- 03
Execution
A read-only role, with limits.
A separate database role without write privileges executes the query, with a 500-row limit and an 8-second timeout. The role's grant sits in a migration, visible in the repository, and even a successfully injected statement has nothing to write with.
- 04
Trace
Every question stays in the chain.
The question, the executed SQL, latency, and token usage go to a local Langfuse and never leave the stack. Separately, every run appends its steps, decision, and tool call to a hash chain in the database, where altering a recorded event breaks the chain; the documented test run verified 12 of 12. We compute cost afterwards from the tokens used and the provider's published pricing.
Why this is not a chat with your database
The system answers only questions computable from the approved views and shows how it computed them. It holds no free-form conversation about the data and claims no knowledge outside the scope. The validator enforces that boundary even when the model misbehaves, with no additional orchestration layer.
- Four analytical views define the entire scope
- The validator works independently of model quality
- A refusal is explicit and carries its reason
- The executed SQL and the decision of every question enter the hash chain
Want to assess a similar process in your company?
- A 30-minute call with the engineer who would lead the work.
- A review of the processes that cost you the most time and money.
- A written summary of what to automate first and the likely cost range.
Times are shown in your own time zone. We work with clients across time zones.
The scan is free and creates no obligation. If automation is unlikely to pay off, the written recommendation will say so.