Query logic review before reporting

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.