The query compiled. It ran successfully. It returned data. Four things were wrong with it, none of which produced an error, a warning, or any signal that would indicate a problem.
Internal test accounts were included: 23 employee accounts and seed data that was never excluded. Trial accounts were counted as active: status = 'active' applies equally to trials and paying accounts. Migrated churned records were not filtered: a legacy migration left status = 'active' on closed accounts. The MRR field included one-time fees: the column name implies recurring, the content doesn't.
SQL correctness and analytical correctness are different things. A query can be syntactically valid, semantically coherent, and operationally wrong simultaneously. The database has no way to flag this. It executes what it receives.
The knowledge required to write the correct query exists: it lives with the people who built the tables, the ones who learned the edge cases, the decisions made in migrations that never made it into documentation. None of it is accessible at query time.
The failure mode that matters most for AI-generated data work is the query that passes every test and returns the wrong number with complete confidence.
