gold
SELECT T2.Name FROM users AS T1 INNER JOIN badges AS T2 ON T1.Id = T2.UserId WHERE T1.DisplayName = 'SilentGhost'
this statement states no ordering of its own
sha256:f65c170742a69016ada884797983b89d00e1be77d044a432305ee2022ac74d8b
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)
What is the badge name that user 'SilentGhost' obtained?
the hint the set supplies: "SilentGhost" is the DisplayName of user;
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 T2.Name FROM users AS T1 INNER JOIN badges AS T2 ON T1.Id = T2.UserId WHERE T1.DisplayName = 'SilentGhost'
this statement states no ordering of its own
sha256:f65c170742a69016ada884797983b89d00e1be77d044a432305ee2022ac74d8b
from evidence-gold.json, 12 rows
| NameTEXT |
|---|
| Editor |
| Student |
| Cleanup |
| Supporter |
| Nice Question |
| Popular Question |
| Taxonomist |
| Favorite Question |
| Good Question |
| Notable Question |
| Nice Question |
| Famous Question |
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:f65c170742a69016ada884797983b89d00e1be77d044a432305ee2022ac74d8b",
"baseline_result": {
"columns": [
{
"name": "Name",
"declared_type": "TEXT"
}
],
"row_count": 12,
"truncated": false,
"rows_shown": 10,
"rows": [
[
{
"type": "str",
"value": "Editor"
}
],
[
{
"type": "str",
"value": "Student"
}
],
[
{
"type": "str",
"value": "Cleanup"
}
],
[
{
"type": "str",
"value": "Supporter"
}
],
[
{
"type": "str",
"value": "Nice Question"
}
],
[
{
"type": "str",
"value": "Popular Question"
}
],
[
{
"type": "str",
"value": "Taxonomist"
}
],
[
{
"type": "str",
"value": "Favorite Question"
}
],
[
{
"type": "str",
"value": "Good Question"
}
],
[
{
"type": "str",
"value": "Notable Question"
}
]
],
"result_hash": "sha256:f65c170742a69016ada884797983b89d00e1be77d044a432305ee2022ac74d8b"
},
"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:bdc6cffb7ed38d59be58fe8afd314a9e3bbd760cf81388e624920abb323ef1cd",
"result": {
"columns": [
{
"name": "Name",
"declared_type": "TEXT"
}
],
"row_count": 12,
"truncated": false,
"rows_shown": 10,
"rows": [
[
{
"type": "str",
"value": "Cleanup"
}
],
[
{
"type": "str",
"value": "Editor"
}
],
[
{
"type": "str",
"value": "Famous Question"
}
],
[
{
"type": "str",
"value": "Favorite Question"
}
],
[
{
"type": "str",
"value": "Good Question"
}
],
[
{
"type": "str",
"value": "Nice Question"
}
],
[
{
"type": "str",
"value": "Nice Question"
}
],
[
{
"type": "str",
"value": "Notable Question"
}
],
[
{
"type": "str",
"value": "Popular Question"
}
],
[
{
"type": "str",
"value": "Student"
}
]
],
"result_hash": "sha256:bdc6cffb7ed38d59be58fe8afd314a9e3bbd760cf81388e624920abb323ef1cd"
}
},
"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, 1 row
| Nice Question |
{
"heuristic": true,
"rows": 12,
"distinct_rows": 11,
"repeated_rows": 1,
"largest_repeat": 2,
"result_bounded": false,
"distinct_stated": false,
"set_operation": false,
"repeats_of_the_rows_shown": [
2
]
}
SELECT T2.Name FROM users AS T1 INNER JOIN badges AS T2 ON T1.Id = T2.UserId WHERE T1.DisplayName = 'SilentGhost'
result_hash sha256:f65c170742a69016ada884797983b89d00e1be77d044a432305ee2022ac74d8b recomputed from this JSON: match
record_hash sha256:c75ad76126761db04ee0794506c9244e435278be520a18bd28211ed3c0ca9138 recomputed from this JSON: match
from evidence-gold.json, 12 rows
| NameTEXT |
|---|
| Editor |
| Student |
| Cleanup |
| Supporter |
| Nice Question |
| Popular Question |
| Taxonomist |
| Favorite Question |
| Good Question |
| Notable Question |
| Nice Question |
| Famous Question |
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