Business data queries

Make the data system authoritative

Prepare a description of the available tables, relationships, business terms and permitted queries. Define metrics such as completed deliveries or active customers in the data layer so different phrasings do not silently change the calculation.

The output is a reviewable query, its executed result and an explanation grounded in that result. The model should not invent numerical answers when it has no data.

Build the query workflow

1. Map the question to a documented metric, time range and permitted data source.
2. Give the model only the relevant schema and business definitions.
3. Validate any proposed query in application code. Use read-only credentials, allowed tables and bounded execution.
4. Execute the query in the data system and retain the query with its result.
5. Ask the model to explain the returned values without altering them. Show the time range and important exclusions to the reader.

Check business meaning

Test ambiguous dates, time zones, missing records, duplicated joins and zero-result queries. Compare the output with an analyst's reference calculation. A syntactically valid query can still use the wrong denominator or double-count records.

For document-plus-table questions, extract and normalize document fields separately before joining them to business data. Keep those source references visible.

Connect the implementation

Use text models for question interpretation and explanation. Your application owns database permissions, query validation, execution and audit records. The logistics industry workflow gives an operational context without assuming that your data may leave its required region.

Review deployment constraints before using hosted models. Estimate model costs from actual schema and result sizes using current prices, while measuring database work separately.