H33DATA

Natural-language BI / database querying

Lets non-analysts ask data questions in plain English and get answers from the firm's data warehouse or reporting database. Translates the question into a query, runs it, and presents the result with the underlying numbers and the SQL behind them. Different from generic text-to-SQL because the pattern works against the firm's actual data model with documented semantics — it knows what 'active customer' means in your business, not what 'active customer' might generically mean. Refuses to answer questions it can't ground in the schema, surfacing uncertainty rather than guessing. The pattern's value is collapsing the 'I'll ask the data team and hear back next week' loop into something that happens in the meeting where the question came up.

WHERE THIS FITS

BUSINESS SHAPES

B2B servicesProduct companyMarketplace / two-sided

VOLUME THRESHOLD

Below 20 data questions per week a month, the payback rarely earns the build. Patterns this shape reliably pay back at 200+.

FITS BEST

Firms with a real data warehouse and business users waiting on analysts.

PAYBACK · 6-12 moBUILD · Medium-HighVALUE · $40k-$180kWHEN · has a data warehouse

FAILURE MODE TO DESIGN AROUND

Wrong SQL produces wrong answer with confident phrasing → "show me the SQL" reveal is mandatory.

REQUIREMENTS · 7 REQUIRED

Requirements describe capabilities the pattern needs in your environment, not the vendors you must buy. Any system that fills a requirement satisfies it — that’s what makes the catalog portable across the long tail of SMB tooling.

queryable_data_store
REQUIREDREADrequest
The structured data warehouse, BI database, or curated tables the pattern queries against.
DATA SHAPE
Tables and views with documented schemas, joinable relationships, indexed columns. Must be query-performant for ad-hoc analysis.
COMMONLY FILLED BY
- data warehouse with curated marts
- BI database with denormalized reporting tables
- operational database with read replica for analytical queries
semantic_layer_documentation
REQUIREDREADcorpus
What things actually mean in this business. The single most important component: without explicit semantics, the pattern guesses and gets it wrong.
DATA SHAPE
Per-table and per-column: business definition, computation rules, valid values, joins, owner. Per-metric: how computed, what it includes/excludes.
COMMONLY FILLED BY
- semantic layer in the BI tool
- structured data dictionary maintained by the data team
- metric definitions library
- dbt model documentation
user_query_surface
REQUIREDREAD + WRITErequest
Where users ask their questions, in their working environment.
DATA SHAPE
Natural language question with user identity for permissions and context.
COMMONLY FILLED BY
- chat bot for data questions
- search bar in the BI tool
- embedded query interface in the company portal
- browser extension for the data team
permission_resolver
REQUIREDREADrequest
What data the asking user is allowed to see. Critical: permissions are not an afterthought, they're a constraint on every query.
DATA SHAPE
Per-user-per-table or per-user-per-row-filter permission lookup.
COMMONLY FILLED BY
- data warehouse row-level security
- BI tool permission model
- explicit permission groups maintained by the data team
answer_destination
REQUIREDWRITErequest
Where the answer goes back to the user with the result, the query, and the trail.
DATA SHAPE
Answer with computed result, visualization where appropriate, the executed query for inspection, links to the data lineage.
COMMONLY FILLED BY
- chat reply with embedded chart and expandable query
- answer panel in the BI tool
- dedicated result view linked from the asker's working tools
query_audit_log
REQUIREDWRITEevent
Every query the pattern runs gets logged for audit, performance review, and learning.
DATA SHAPE
Per-query: user, question, generated query, result summary, execution time, any errors or fallbacks.
COMMONLY FILLED BY
- query log in the data platform
- structured audit trail in the data warehouse
- compliance archive of data access
answer_feedback_loop
REQUIREDREAD + WRITEevent
How users confirm or correct the pattern's interpretation, used to tune the semantic layer and the query generation.
DATA SHAPE
Per-answer: was it right, was the interpretation correct, what should it have been instead.
COMMONLY FILLED BY
- thumbs widget after each answer with correction interface
- weekly review with the data team of low-confidence answers
- structured feedback capture in the answer destination

RUNTIME FLOW · 8 STEPS

01
User asks a question through the query surface
user_query_surface
02
Resolve user permissions to scope the question
permission_resolver
03
Match question to semantic layer: which entities, metrics, time ranges, segments
semantic_layer_documentation
04
Generate query with full schema awareness; if uncertain about interpretation, surface options rather than guess
queryable_data_store
DECISION If interpretation is ambiguous, ask the user before running rather than guessing.
05
Execute query against the data store with permission constraints applied
queryable_data_store
06
Present the result with the underlying query visible, plus context (what was filtered, what assumptions were made)
answer_destination
07
Log query for audit
query_audit_log
08
Capture feedback for tuning
answer_feedback_loop

EMISSIONS · 3

Structured outputs this pattern produces. Other patterns and client systems can subscribe to them, which is how the catalog composes over time.

query_pattern_signal
What people actually ask about, useful for data team prioritization of marts and metrics.
CONSUMED BY
- data team roadmap
- semantic layer maintenance
- analytics priorities
semantic_gap_signal
Questions the pattern couldn't answer well due to missing definitions or model gaps.
CONSUMED BY
- semantic layer authoring
- data modeling priorities
- dbt project priorities
data_literacy_signal
Aggregate view of who's asking what across the firm, useful for understanding which teams use data and how.
CONSUMED BY
- enablement priorities
- data team capacity planning
- data culture metrics