This was a passion weekend project started with only 60lines of code and idea to translate semantic and check sql against it. So definitely leveraged claude for documentation, testing, scaling.
However, personally I do want to redo a lot of sections that feel slop-esque. So if you do have any specific feedback on particular sections, would be happy to apply.
Fair point, I legit have a policy not to read anyone's "Thoughts" if they were AI -- hypocritical of me I went on with AI assisted documentation. I wanted a quick POC repo and I went the lazy way -- would love to redo any sections that didn't make sense.
Author here. sqlsure is a semantic inspector for SQL: it checks queries — human- or AI-written — against declared facts about your schema (grain, join cardinality, measure additivity) before execution. It never generates SQL, never reads your data, and runs in ~0.1 ms per check, fully offline. Apache-2.0.
The bug it targets: fan-out double-counting. Join orders to order_items and SUM(order_total), and every dollar is counted once per line item. The query runs fine, the dashboard renders, the number is silently wrong.
To test it, we ran it over the gold (expert-written) answer keys of the Spider and BIRD text-to-SQL benchmarks — 2,568 queries, using only the benchmarks' own PK/FK declarations as the rulebook. It raised 45 flags and zero spurious ones. For one BIRD query we executed the benchmark's own database and proved the official gold answer wrong by 8× (the fan-out factor). Filed upstream: https://github.com/bird-bench/mini_dev/issues/37
Three ways to use it: CLI (CI gate), MCP server (agents call check_sql before executing; rejections carry machine-actionable fix hints — in our benchmark, applying the hint verbatim fixed the query 10/10 times in one round), or as a Python library wrapping an existing text-to-SQL generator.
Rulebooks come from what you already have: dbt tests (unique / relationships), PK/FK declarations, or OSI semantic model YAML. Happy to answer anything about the method or the benchmark findings.
However, personally I do want to redo a lot of sections that feel slop-esque. So if you do have any specific feedback on particular sections, would be happy to apply.