Cloud acceptance record¶
This page records cloud acceptance runs that actually happened, using the columns of the release validation record template. It is published on the public docs site, so only release-relevant results are kept here. Account identifiers, user and project IDs, invoice amounts, and account security configuration are left out. The full record template stays private when it holds those details.
2026-11-01: first real-warehouse acceptance builds¶
The first warehouse builds of both editions, run against disposable targets that were created for the run and torn down afterwards. This is not a release candidate: no tag, archive, or clean-install evidence is recorded here.
- Operator: a Claude Code agent session, under the owner's 2026-11-01 delegation of cloud acceptance runs on disposable targets (dedicated dataset or schema, bytes-billed cap, X-Small auto-suspending warehouse, teardown afterwards; stop if a run could exceed about USD 1). The runbook records this delegated exception to its human gate. The owner can reverse it. The owner signed off these results on 2026-11-02; see Sign-off.
- Commit:
6956a82(main), plus the BigQuery test-severity change described below. - Cost review beforehand: BigQuery source tables total about 38 MB (TheLook
order_items,products,usersmetadata), and every dbt query had a 1 GBmaximum_bytes_billedcap. The Snowflake seeds are 7 rows, on an X-Small warehouse with 60 s auto-suspend, a 900 s statement timeout, and a 1-credit resource monitor that suspends it immediately.
| Edition | Python / dbt / adapter | Command | Status (passed / skipped / failed) | Target type (never credentials) | Models/tests result | Cost/bytes reviewed? | Evidence reference |
|---|---|---|---|---|---|---|---|
| BigQuery | 3.11 / 1.12.6 / dbt-bigquery 1.12.1 | cloud_acceptance_preflight.py bigquery |
passed (exit 0) | Disposable dataset <project>.starterkit_accept_20261101, US, 24 h default table expiry |
18 PASS checks | n/a (offline) | Run output (not retained) |
| BigQuery | same | dbt debug |
passed | same | connection OK | n/a | Run output (not retained) |
| BigQuery | same | dbt build (main as-is) |
failed | same | PASS=20 ERROR=1 SKIP=10: not_null_stg_products_product_name found 2 TheLook products with no name, so mart_daily_product_sales and its tests were skipped |
yes | Run output (not retained) |
| BigQuery | same | dbt build (after the severity change) |
passed | same | PASS=30 WARN=1 ERROR=0 SKIP=0 (3 views, 2 tables, 25 data tests, 1 unit test); the warning is the same 2 unnamed products | yes | Run output (not retained) |
| BigQuery | same | dbt build --select +mart_daily_product_sales_incremental --vars '{enable_incremental_example: true}', run twice |
passed | same | PASS=17 WARN=1 both times. The first run created the table (180.3k rows); the second ran as an incremental MERGE over the 90-day window (56.5k rows) |
yes | Run output (not retained) |
| BigQuery | same | Incremental vs full comparison, then --full-refresh of both marts and the comparison again |
passed | same | Both times: 180,296 rows in each; EXCEPT DISTINCT both ways returned 0 rows; completed revenue totals equal |
yes | Run output (not retained) |
| Snowflake | 3.11 / 1.12.6 / dbt-snowflake 1.12.4 | cloud_acceptance_preflight.py snowflake |
passed (exit 0) | Disposable DBT_KIT_CI_ACCEPT_20261101_DB.DBT_KIT_CI_ACCEPT_20261101_SCHEMA, X-Small warehouse, non-admin role DBT_KIT_ACCEPT_ROLE, key-pair service user |
21 PASS checks | n/a (offline) | Run output (not retained) |
| Snowflake | same | dbt debug |
passed | same | connection OK | n/a | Run output (not retained) |
| Snowflake | same | dbt seed |
passed | same | PASS=2 (3 customers, 4 orders) | yes | Run output (not retained) |
| Snowflake | same | dbt build |
passed | same | PASS=16 WARN=0 ERROR=0 SKIP=0 (2 seeds, 2 views, 1 table, 11 data tests) | yes | Run output (not retained) |
| Snowflake | same | Incremental example | skipped | n/a | fct_orders_incremental is not on main at this commit, although editions/Snowflake/docs/operations.md and docs/mart-contract.md document it |
n/a | n/a |
Cost observed.
- BigQuery:
region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECTfor the run window shows 118 dbt query jobs (job labeledition=bigquery) with 180.5 MB processed and 1.02 GB billed. The total is mostly BigQuery's 10 MB per-table minimum. FourbqCLI inspection queries billed another 0.11 GB. At the US on-demand list price of USD 6.25 per TiB, that is about USD 0.006 for the whole run. That figure is a list-price equivalent, not the invoice. The billed amount was not available, because Cloud Billing Reports lag and no billing export is configured. The project's monthly free query allowance may make the billed amount zero. - Snowflake:
- The disposable warehouse's
INFORMATION_SCHEMA.WAREHOUSE_METERING_HISTORYshows 0.036 compute credits for the run window. The resource monitor agreed, at 0.04 credits rounded. QUERY_HISTORY_BY_WAREHOUSEshows 47 queries, 5.9 s of execution time in total, and 0.0015 cloud-services credits before the daily adjustment.- One more 60 s minimum resume was needed to read the metering view, which adds at most about 0.017 credits. That puts the upper bound for the run at about 0.055 credits.
- Billed credits from
METERING_DAILY_HISTORYand an invoice currency amount were not captured. That view lags by hours, and the objects were dropped first. Per the Snowflake cost-check guide, no dollar figure is derived from a generic credit price.
- The disposable warehouse's
Teardown.
- BigQuery:
bq rm -r -f -dremoved the dataset. A follow-upbq showreturnedNot found. - Snowflake: the operator dropped the database (with its schema, seeds, views, and table), the warehouse, the resource monitor, the service user, and the acceptance role. Follow-up
show databases,show warehouses,show resource monitors,show users, andshow rolesfor each name returned no rows.
Findings.
- Default BigQuery build failed on real data. The public TheLook
productstable has 2 rows with a nullname. Thenot_nulltest onstg_products.product_namefailed, and dbt skippedmart_daily_product_salesand its tests.product_nameis a descriptive attribute, not a key, so that test now hasseverity: warnand a column description. Key tests are unchanged. - The BigQuery incremental example matches a full refresh. This holds on the current source snapshot only. The run did not exercise late changes or deleted groups on the warehouse; those are still covered offline only.
- The Snowflake incremental example was missing from
main. At this commit it existed only on an unmerged branch. Resolved by #26, which landedfct_orders_incrementalonmain, and verified on a disposable Snowflake target on 2026-11-02 (see below). - Least-privilege run identity. The Snowflake dbt run connected as a disposable service user with key-pair authentication and only the non-admin acceptance role, not as an administrator. Both were dropped at teardown.
Evidence retention. Raw command output from this session was not kept beyond the session. The figures above were copied from the observed dbt summaries and the warehouse metadata queries. Re-run the commands in the runbook to reproduce them.
Evidence checklist status (this run): operator, date, edition, commit, and disposable identity are recorded. Provisioning was done with the runbook's operator commands, not Terraform. The preflight exited 0 for both editions, dbt debug passed, and build summaries, cost, and teardown are recorded above. No credentials, profile files, or customer data were committed. The profiles lived under the ignored editions/*/.dbt/ paths and were deleted after the run, and the Snowflake key pair was generated in a temporary directory and deleted.
2026-11-02: Snowflake incremental example¶
A Snowflake re-run that closes finding 3 of the 2026-11-01 entry: the default build plus the incremental example fct_orders_incremental, on a new disposable target created for the run and torn down afterwards. This is not a release candidate: no tag, archive, or clean-install evidence is recorded here.
- Operator: a Claude Code agent session, under the same 2026-11-01 owner delegation. The dbt commands ran between 20:42 and 20:45 UTC on 2026-11-01, and teardown followed at about 20:53 UTC, which was 2026-11-02 in the owner's time zone; the object names use the
20261102suffix. - Commit:
5f062db(main), which includes #26. - Cost review beforehand: the Snowflake seeds are 9 rows (3 customers, 6 orders), on an X-Small warehouse with 60 s auto-suspend, a 900 s statement timeout, and a 1-credit resource monitor that suspends it immediately.
| Edition | Python / dbt / adapter | Command | Status (passed / skipped / failed) | Target type (never credentials) | Models/tests result | Cost/bytes reviewed? | Evidence reference |
|---|---|---|---|---|---|---|---|
| Snowflake | 3.11 / 1.12.6 / dbt-snowflake 1.12.4 | cloud_acceptance_preflight.py snowflake |
passed (exit 0) | Disposable DBT_KIT_CI_ACCEPT_20261102_DB.DBT_KIT_CI_ACCEPT_20261102_SCHEMA, X-Small warehouse, non-admin role DBT_KIT_ACCEPT_20261102_ROLE, key-pair service user |
21 PASS checks | n/a (offline) | Run output (not retained) |
| Snowflake | same | dbt debug |
passed | same | connection OK | n/a | Run output (not retained) |
| Snowflake | same | dbt seed |
passed | same | PASS=2 (3 customers, 6 orders) | yes | Run output (not retained) |
| Snowflake | same | dbt build |
passed | same | PASS=17 WARN=1 ERROR=0 SKIP=0 (2 seeds, 2 views, 1 table, 13 data tests); the warning is not_null_stg_orders_source_updated_at, set to warn for the documented null-timestamp order 5005 |
yes | Run output (not retained) |
| Snowflake | same | dbt build --select +fct_orders_incremental --vars '{enable_incremental_example: true}', run twice |
passed | same | PASS=13 WARN=1 both times, including assert_fct_orders_incremental_timestamp_contract. The first run created the table (6 rows); the second ran as an incremental MERGE over 4 rows (the in-window, null-timestamp, and future-dated orders) |
yes | Run output (not retained) |
| Snowflake | same | Incremental vs --full-refresh comparison |
passed | same | The incremental result was copied aside, then the same selection was rebuilt with --full-refresh (PASS=13 WARN=1). 6 rows in each; EXCEPT both ways returned 0 rows; amount totals equal |
yes | Run output (not retained) |
Cost observed.
- The disposable warehouse's
INFORMATION_SCHEMA.WAREHOUSE_METERING_HISTORYshows 0.075 compute credits for the hour that covers the run. The resource monitor agreed, at 0.08 credits rounded. QUERY_HISTORY_BY_WAREHOUSEshows 138 queries (105 of them tagged by dbt), 12.75 s of execution time in total, and 0.004 cloud-services credits before the daily adjustment.- The metering view lagged, so it was read three times. The last read came after the warehouse had auto-suspended and needed one more 60 s minimum resume that the metering row may not include, which adds at most about 0.017 credits. That puts the upper bound for the run at about 0.09 credits.
- As on 2026-11-01, billed credits from
METERING_DAILY_HISTORYand an invoice currency amount were not captured, and no dollar figure is derived from a generic credit price.
Teardown. The operator dropped the database (with its schema, seeds, views, and tables), the warehouse, the resource monitor, the service user, and the acceptance role. Follow-up show databases, show warehouses, show resource monitors, show users, and show roles for the 20261102 names returned no rows.
Findings.
- The Snowflake incremental example matches a full refresh on Snowflake. Snowflake casts and the
MERGEbehaved as the offline regression expects for the seeded boundary, null-timestamp, and future-dated orders. This holds for the synthetic seed only. No seeded timestamp falls near the build date, so thecurrent_date()future cutoff and session time zone handling were not exercised. The run did not simulate a late correction by editing the seed between runs, so late arrivals and stale-timestamp corrections are still covered offline only. - Least-privilege run identity. As on 2026-11-01, dbt and the comparison queries ran as a disposable key-pair service user with only the non-admin acceptance role. The administrator role was used only to provision, read metering, and tear down. The acceptance role was not granted to it, so it could not read the dbt tables.
Evidence retention. Raw command output from this session was not kept beyond the session. The figures above were copied from the observed dbt summaries and the warehouse metadata queries.
Evidence checklist status (this run): operator, date, edition, commit, and disposable identity are recorded. Provisioning was done with the runbook's operator commands, not Terraform. The preflight exited 0, dbt debug passed, and build summaries, cost, and teardown are recorded above. No credentials, profile files, or customer data were committed. The profile lived under the ignored editions/Snowflake/.dbt/ path and was deleted after the run, and the key pair was generated in a temporary directory and deleted.
Sign-off¶
Signed off by: owner, 2026-11-02 — accepted as pilot evidence for both editions, including the BigQuery product_name test severity change to warn. Not a release candidate: no tag, archive or clean-install evidence.