gold
SELECT T1.Views FROM users AS T1 INNER JOIN badges AS T2 ON T1.Id = T2.UserId WHERE T2.Date = '2010-07-19 19:39:08.0'
this statement states no ordering of its own
sha256:335dc45fb6e06b53f3dc8dd07f90d10935d9acda685c63a58b6ca2a372deb4af
R-SET GOLD-ONLY duplicate-full-row
codebase_community · dev_20251106-00000-of-00001 from https://huggingface.co/datasets/birdsql/bird_sql_dev_20251106/resolve/3c11fb193e5439b338e23677fa0aae11e8b85db9/data/dev_20251106-00000-of-00001.json (commit 3c11fb19, downloaded 2026-09-07)
State the number of views of users who obtained the badge on 7/19/2010 7:39:08 PM.
the hint the set supplies: on 7/19/2010 7:39:08 PM refers to Date = '2010-07-19 19:39:08.0'
This question was audited without a prediction beside it, so there is nothing to compare the gold with. The probes below read the gold alone.
SELECT T1.Views FROM users AS T1 INNER JOIN badges AS T2 ON T1.Id = T2.UserId WHERE T2.Date = '2010-07-19 19:39:08.0'
this statement states no ordering of its own
sha256:335dc45fb6e06b53f3dc8dd07f90d10935d9acda685c63a58b6ca2a372deb4af
from evidence-gold.json, 13 rows
| ViewsINTEGER |
|---|
| 178 |
| 8 |
| 52 |
| 48 |
| 82 |
| 102 |
| 174 |
| 44 |
| 178 |
| 52 |
| 114 |
| 8 |
| 16 |
A smell is a mechanical reason to read this gold statement again. It is a heuristic: it does not state that the statement is wrong, and a maintainer decides.
this statement orders by a text column holding only numbers, and ordering it as a number gives a different answer, so the gold may be sorting 9.5 above 10
the statement states no top level ORDER BY
{
"heuristic": true,
"reason": "the statement states no top level ORDER BY"
}
this statement cuts its result at a LIMIT that does not decide which rows come back, so a different but equally correct statement can return other rows and score zero
the statement states no LIMIT
{
"heuristic": true,
"reason": "the statement states no LIMIT"
}
rerun over the same rows in another physical order this statement gives another answer, so its result depends on how the rows are stored and not only on the data
{
"heuristic": true,
"rule": "R-SET",
"baseline_result_hash": "sha256:335dc45fb6e06b53f3dc8dd07f90d10935d9acda685c63a58b6ca2a372deb4af",
"baseline_result": {
"columns": [
{
"name": "Views",
"declared_type": "INTEGER"
}
],
"row_count": 13,
"truncated": false,
"rows_shown": 10,
"rows": [
[
{
"type": "int",
"value": 178
}
],
[
{
"type": "int",
"value": 8
}
],
[
{
"type": "int",
"value": 52
}
],
[
{
"type": "int",
"value": 48
}
],
[
{
"type": "int",
"value": 82
}
],
[
{
"type": "int",
"value": 102
}
],
[
{
"type": "int",
"value": 174
}
],
[
{
"type": "int",
"value": 44
}
],
[
{
"type": "int",
"value": 178
}
],
[
{
"type": "int",
"value": 52
}
]
],
"result_hash": "sha256:335dc45fb6e06b53f3dc8dd07f90d10935d9acda685c63a58b6ca2a372deb4af"
},
"planner_statistics": {},
"shuffle": {
"seed": "1",
"row_limit": 300000,
"tables": [
"users",
"badges"
],
"tables_not_shuffled": [],
"tables_skipped_for_size": {
"postHistory": 303155
},
"tables_not_reached_by_a_copy": {}
},
"shuffled_copies": {
"run": true,
"verdict": "equal",
"differs": false,
"result_hash": "sha256:e359856d14f2b16ed9bd58c0013c4f307aa4e68b506a523510dcb4fe791d0215",
"result": {
"columns": [
{
"name": "Views",
"declared_type": "INTEGER"
}
],
"row_count": 13,
"truncated": false,
"rows_shown": 10,
"rows": [
[
{
"type": "int",
"value": 178
}
],
[
{
"type": "int",
"value": 102
}
],
[
{
"type": "int",
"value": 178
}
],
[
{
"type": "int",
"value": 52
}
],
[
{
"type": "int",
"value": 16
}
],
[
{
"type": "int",
"value": 8
}
],
[
{
"type": "int",
"value": 82
}
],
[
{
"type": "int",
"value": 114
}
],
[
{
"type": "int",
"value": 8
}
],
[
{
"type": "int",
"value": 44
}
]
],
"result_hash": "sha256:e359856d14f2b16ed9bd58c0013c4f307aa4e68b506a523510dcb4fe791d0215"
}
},
"plan_variant": {
"run": false,
"reason": "the plan variant was not asked for"
}
}
this statement returns the same whole row more than once and never says DISTINCT, so a statement answering the same question once per row disagrees on multiplicity alone
from smells.json, 3 rows
| 178 |
| 8 |
| 52 |
{
"heuristic": true,
"rows": 13,
"distinct_rows": 10,
"repeated_rows": 3,
"largest_repeat": 2,
"result_bounded": false,
"distinct_stated": false,
"set_operation": false,
"repeats_of_the_rows_shown": [
2,
2,
2
]
}
SELECT T1.Views FROM users AS T1 INNER JOIN badges AS T2 ON T1.Id = T2.UserId WHERE T2.Date = '2010-07-19 19:39:08.0'
result_hash sha256:335dc45fb6e06b53f3dc8dd07f90d10935d9acda685c63a58b6ca2a372deb4af recomputed from this JSON: match
record_hash sha256:2c97d631ae6d2993d426194fccebb7a47d69049c3424f029f8d1b81d037c0e7b recomputed from this JSON: match
from evidence-gold.json, 13 rows
| ViewsINTEGER |
|---|
| 178 |
| 8 |
| 52 |
| 48 |
| 82 |
| 102 |
| 174 |
| 44 |
| 178 |
| 52 |
| 114 |
| 8 |
| 16 |
re-run this statement read-only against SQLite 3.53.4 | file=/private/tmp/attestql-runs/data/dev/dev_databases/codebase_community/codebase_community.sqlite | size=481419264 under the session settings and over the data this record's fixture digest names, and compare the two results under R-SET