- Every run is recorded: what ran, the SQL it executed, audit results and everything it printed. Agents and people ask in SQL, then check live state with the same command. + Every run is recorded: what ran, the SQL it executed, audit results and everything it printed. It's all SQL: agents and people query the history, then check live state with the same command.
-sqb recall query "SELECT substr(invocation_started_at, 1, 16) AS run, outcome, - violation_count FROM audit_results WHERE audit_name = 'revenue_is_non_negative' - ORDER BY run DESC LIMIT 3" -run | outcome | violation_count -2026-10-20T00:01 | warn | 1 -2026-10-20T00:00 | pass | 0 -2026-10-19T23:59 | pass | 0 - -sqb recall output last --tail 4 - daily_revenue - audit revenue_is_non_negative returned 1 row -✓ Completed with warnings PASS=89 WARN=1 FAIL=0 … +sqb recall query "SELECT substr(a.invocation_started_at, 1, 16) AS run, + a.outcome, a.violation_count, i.status, i.exit_code FROM audit_results a + JOIN invocations i USING (invocation_id) + WHERE a.audit_name = 'revenue_is_non_negative' ORDER BY run DESC LIMIT 3" +run | outcome | violation_count | status | exit_code +2026-10-20T00:01 | warn | 1 | completed | 0 +2026-10-20T00:00 | pass | 0 | completed | 0 +2026-10-19T23:59 | pass | 0 | completed | 0 sqb recall query --backend warehouse "SELECT r.revenue_date, r.total_revenue_cents, p.payment_id, p.amount_cents FROM prod.daily_revenue r JOIN prod.stg_payments p @@ -395,7 +391,7 @@+sqb recall query --backend warehouse "SELECT payment_id, order_id, amount_cents, paid_at + FROM prod.stg_payments WHERE amount_cents < 0" +payment_id | order_id | amount_cents | paid_at +9 | 8 | -2200 | 2026-04-03 15:42:00Find out what happened, then check what's true now
Real output from SQLBuild's example project, trimmed to the relevant lines. During a migration the old table is never modified, archives can be renamed back until they expire, and every move is recorded. In step 09 the audit started warning on the latest run, the build still finished, and the bad - row is still in prod: a refund recorded as a negative payment. Three queries, no log digging. + row is still in prod: a refund recorded as a negative payment. Two queries, no log digging. History stays in a SQLite file in your project, or in ClickHouse for a team. No service, no account, no paid tier. How migrations work · diff --git a/website/src/content/docs/docs/concepts/observability/recall.mdx b/website/src/content/docs/docs/concepts/observability/recall.mdx index d0ac97d210..308c971459 100644 --- a/website/src/content/docs/docs/concepts/observability/recall.mdx +++ b/website/src/content/docs/docs/concepts/observability/recall.mdx @@ -13,36 +13,26 @@ The waffle shop example's `daily_revenue` model has an audit, `revenue_is_non_ne severity. One night the payments feed starts recording a refund as a negative payment. The unit tests still pass, because they run on mocked data. The build finishes with a warning that nobody reads. -The next morning, ask when the audit started failing: +The next morning, ask when the audit started failing, and what each of those builds reported: ```bash sqb recall query --format table \ - "SELECT invocation_started_at AS run, outcome, violation_count FROM audit_results - WHERE audit_name = 'revenue_is_non_negative' ORDER BY run DESC LIMIT 3" + "SELECT a.invocation_started_at AS run, a.outcome, a.violation_count, i.status, i.exit_code + FROM audit_results a JOIN invocations i USING (invocation_id) + WHERE a.audit_name = 'revenue_is_non_negative' ORDER BY run DESC LIMIT 3" ``` ``` -run | outcome | violation_count ---------------------------- | ------- | --------------- -2026-10-20T00:01:44.784683Z | warn | 1 -2026-10-20T00:00:34.652468Z | pass | 0 -2026-10-19T23:59:23.827831Z | pass | 0 +run | outcome | violation_count | status | exit_code +--------------------------- | ------- | --------------- | --------- | --------- +2026-10-20T00:01:44.784683Z | warn | 1 | completed | 0 +2026-10-20T00:00:34.652468Z | pass | 0 | completed | 0 +2026-10-19T23:59:23.827831Z | pass | 0 | completed | 0 3 rows ``` -See what that run printed, exactly as the scheduler saw it: - -```bash -sqb recall output last --tail 4 -``` - -``` - daily_revenue - audit revenue_is_non_negative returned 1 row - -✓ Completed with warnings PASS=89 WARN=1 FAIL=0 INSUFFICIENT=0 SKIP=0 TOTAL=90 (3.08s) -``` +The audit started warning on the latest build, and that build still exited 0, so nothing alerted. Then check what is true in the warehouse now, with the same command: From bd973bc2adc76050b8320c4c34cae4f37b8a9b23 Mon Sep 17 00:00:00 2001 From: Kevin Longe <273747162+kvlonge@users.noreply.github.com> Date: Tue, 20 Oct 2026 01:17:30 +0100 Subject: [PATCH 2/4] docs: shorten the warehouse query in Recall step 09 --- .../docs/concepts/observability/recall.md | 16 +++++++--------- website/public/index.html | 13 ++++++------- .../docs/docs/concepts/observability/recall.mdx | 16 +++++++--------- 3 files changed, 20 insertions(+), 25 deletions(-) diff --git a/src/sqlbuild/.agents/skills/sqlbuild/references/docs/concepts/observability/recall.md b/src/sqlbuild/.agents/skills/sqlbuild/references/docs/concepts/observability/recall.md index 64d44f43b5..dd9e5d9a0a 100644 --- a/src/sqlbuild/.agents/skills/sqlbuild/references/docs/concepts/observability/recall.md +++ b/src/sqlbuild/.agents/skills/sqlbuild/references/docs/concepts/observability/recall.md @@ -54,22 +54,20 @@ Then check what is true in the warehouse now, with the same command: ```bash sqb recall query --backend warehouse --format table \ - "SELECT r.revenue_date, r.total_revenue_cents, p.payment_id, p.amount_cents - FROM prod.daily_revenue r JOIN prod.stg_payments p - ON CAST(p.paid_at AS DATE) = r.revenue_date - WHERE p.amount_cents < 0" + "SELECT payment_id, order_id, amount_cents, paid_at FROM prod.stg_payments WHERE amount_cents < 0" ``` ``` -revenue_date | total_revenue_cents | payment_id | amount_cents ------------- | ------------------- | ---------- | ------------ -2026-04-03 | -1250 | 9 | -2200 +payment_id | order_id | amount_cents | paid_at +---------- | -------- | ------------ | ------------------- +9 | 8 | -2200 | 2026-04-03 15:42:00 1 row ``` -The bad row is still in prod, and payment 9 explains it. A coding agent can follow the same steps: -every answer is a SQL query over the [views](#querying-history), with the same output in `--json`. +Payment 9 is a refund recorded as a negative payment, and it is still in prod. A coding agent can +follow the same steps: every answer is a SQL query over the [views](#querying-history), with the +same output in `--json`. ## What is recorded diff --git a/website/public/index.html b/website/public/index.html index 19f722d1d1..166b15b669 100644 --- a/website/public/index.html +++ b/website/public/index.html @@ -380,18 +380,17 @@Find out what happened, then check what's true now
2026-10-20T00:00 | pass | 0 | completed | 0 2026-10-19T23:59 | pass | 0 | completed | 0 -sqb recall query --backend warehouse "SELECT r.revenue_date, r.total_revenue_cents, - p.payment_id, p.amount_cents FROM prod.daily_revenue r JOIN prod.stg_payments p - ON CAST(p.paid_at AS DATE) = r.revenue_date WHERE p.amount_cents < 0" -revenue_date | total_revenue_cents | payment_id | amount_cents -2026-04-03 | -1250 | 9 | -2200
Real output from SQLBuild's example project, trimmed to the relevant lines. During a migration the old table is never modified, archives can be renamed back until they expire, and every move is recorded. - In step 09 the audit started warning on the latest run, the build still finished, and the bad - row is still in prod: a refund recorded as a negative payment. Two queries, no log digging. + In step 09 the audit started warning on the latest run, the build still exited 0, and the cause + is still in prod: a refund recorded as a negative payment. Two queries, no log digging. History stays in a SQLite file in your project, or in ClickHouse for a team. No service, no account, no paid tier. How migrations work · diff --git a/website/src/content/docs/docs/concepts/observability/recall.mdx b/website/src/content/docs/docs/concepts/observability/recall.mdx index 308c971459..b3d4f96ca1 100644 --- a/website/src/content/docs/docs/concepts/observability/recall.mdx +++ b/website/src/content/docs/docs/concepts/observability/recall.mdx @@ -38,22 +38,20 @@ Then check what is true in the warehouse now, with the same command: ```bash sqb recall query --backend warehouse --format table \ - "SELECT r.revenue_date, r.total_revenue_cents, p.payment_id, p.amount_cents - FROM prod.daily_revenue r JOIN prod.stg_payments p - ON CAST(p.paid_at AS DATE) = r.revenue_date - WHERE p.amount_cents < 0" + "SELECT payment_id, order_id, amount_cents, paid_at FROM prod.stg_payments WHERE amount_cents < 0" ``` ``` -revenue_date | total_revenue_cents | payment_id | amount_cents ------------- | ------------------- | ---------- | ------------ -2026-04-03 | -1250 | 9 | -2200 +payment_id | order_id | amount_cents | paid_at +---------- | -------- | ------------ | ------------------- +9 | 8 | -2200 | 2026-04-03 15:42:00 1 row ``` -The bad row is still in prod, and payment 9 explains it. A coding agent can follow the same steps: -every answer is a SQL query over the [views](#querying-history), with the same output in `--json`. +Payment 9 is a refund recorded as a negative payment, and it is still in prod. A coding agent can +follow the same steps: every answer is a SQL query over the [views](#querying-history), with the +same output in `--json`. ## What is recorded From 12a41df4af46c19ecce9c7348bd3f7fded25f04e Mon Sep 17 00:00:00 2001 From: Kevin Longe <273747162+kvlonge@users.noreply.github.com> Date: Tue, 20 Oct 2026 01:20:02 +0100 Subject: [PATCH 3/4] docs: restore sqb recall output in Recall step 09 --- .../docs/concepts/observability/recall.md | 19 ++++++++++++++++--- website/public/index.html | 7 ++++++- .../docs/concepts/observability/recall.mdx | 19 ++++++++++++++++--- 3 files changed, 38 insertions(+), 7 deletions(-) diff --git a/src/sqlbuild/.agents/skills/sqlbuild/references/docs/concepts/observability/recall.md b/src/sqlbuild/.agents/skills/sqlbuild/references/docs/concepts/observability/recall.md index dd9e5d9a0a..02ca9d0593 100644 --- a/src/sqlbuild/.agents/skills/sqlbuild/references/docs/concepts/observability/recall.md +++ b/src/sqlbuild/.agents/skills/sqlbuild/references/docs/concepts/observability/recall.md @@ -50,7 +50,20 @@ run | outcome | violation_count | status | exit_code The audit started warning on the latest build, and that build still exited 0, so nothing alerted. -Then check what is true in the warehouse now, with the same command: +See what that build printed, exactly as the scheduler saw it: + +```bash +sqb recall output last --tail 4 +``` + +``` + daily_revenue + audit revenue_is_non_negative returned 1 row + +✓ Completed with warnings PASS=89 WARN=1 FAIL=0 INSUFFICIENT=0 SKIP=0 TOTAL=90 (3.08s) +``` + +Then check what is true in the warehouse now, with `sqb recall query` again: ```bash sqb recall query --backend warehouse --format table \ @@ -66,8 +79,8 @@ payment_id | order_id | amount_cents | paid_at ``` Payment 9 is a refund recorded as a negative payment, and it is still in prod. A coding agent can -follow the same steps: every answer is a SQL query over the [views](#querying-history), with the -same output in `--json`. +follow the same steps: the history is SQL over the [views](#querying-history), and every query can +return `--json`. ## What is recorded diff --git a/website/public/index.html b/website/public/index.html index 166b15b669..403ef3367c 100644 --- a/website/public/index.html +++ b/website/public/index.html @@ -380,6 +380,11 @@
- Every run is recorded: what ran, the SQL it executed, audit results and everything it printed. It's all SQL: agents and people query the history, then check live state with the same command. + Every run is recorded: what ran, the SQL it executed, audit results and everything it printed. Agents and people ask in SQL, then check live state with the same command.
sqb recall query "SELECT substr(a.invocation_started_at, 1, 16) AS run,