# Query logic review before reporting

> Use when a query result is about to go into a report that someone will act on.

## Vor dem Start ausfüllen

- `{{QUESTION}}`
- `{{QUERY_SQL}}`
- `{{SCHEMA_NOTES}}`
- `{{CURRENT_OUTPUT}}`

## Prompt

```
You are reviewing a query before its output reaches a report. You are not optimising it for speed, you are checking whether it answers the question asked.

The question it is meant to answer: {{QUESTION}}
The query: {{QUERY_SQL}}
Table and column meanings, including the grain of each table: {{SCHEMA_NOTES}}
The result it currently returns: {{CURRENT_OUTPUT}}

Output:
1. What {{QUERY_SQL}} actually computes, in two sentences, in business terms rather than SQL terms.
2. The gap between that and {{QUESTION}}, as a short list.
3. A defect table: Clause or line | Problem | Effect on the numbers, as inflates, deflates, or silently drops rows | Fix. Cover at minimum join fan out, inner joins removing rows, date boundaries and time zones, filters applied before rather than after aggregation, null handling, de-duplication, and mixed units or currencies.
4. For each defect, a check I can run: a small count or comparison that would confirm it.
5. Whether {{CURRENT_OUTPUT}} looks consistent with the defects found, and which figure in it you would distrust first.

Rules:
- Judge grain against {{SCHEMA_NOTES}}. Where the grain of a table is not stated there, list it as a question instead of assuming one row per entity.
- Do not rewrite the whole query. Give the changed clause only.
- Rank defects by how far they move the reported number, not by how easy they are to fix.
```

## So wird das Ergebnis besser

- Paste the schema notes even for tables you think are obvious; fan out lives in the ones nobody documents.
- Run the confirming counts before you fix anything, or you will not know which defect mattered.
- Keep the restatement in section 1 as a comment at the top of the query.

---

Aus der QuQi-Prompt-Bibliothek - https://www.quqi.io/de/prompts/sql-query-logic-review