Databricks was the system of record for The Gilded Ace. Exploration started in DuckDB on a laptop. Every number in the write-up was recomputed in the warehouse and checked against the gold table named in the claims appendix.
How we used it
The repo sits in the workspace as a Git folder, so the Parquet and the notebooks are the same commit. Three steps run on serverless compute and the Free Edition SQL warehouse, in the Unity Catalog schema workspace.dashboard_royale.
01_load_data creates that schema and a volume, copies the source files in, and registers each one as a Delta table. The largest is machine_day, 56,110 rows, one per machine per day.
02_build_gold is Spark SQL. It builds the g_* tables the decision actually uses. g_machine_day joins the daily view to game_math and keeps sums, not ratios: coin-in, theo, bet-squared, and spin counts. Luck and hit rate are computed later as a ratio of those sums, so a judge can change the dates without averaging averages. g_fault_tickets joins each repair to floor_locations, which is what gives all 1,207 faults a bank. g_property_day rolls the floor up to one row per day.
The forecast is SQL, not a separate training job. g_forecast freezes a weekday mean and a constant mean on January–April, then scores both on May–June. g_forecast_scores stores the error. On the holdout, the weekday mean cuts mean absolute error from about $218,000 to about $69,000, and to about $51,000 when events announced in advance are included. g_budget_plan does not hard-code prices. It joins our quantities to action_catalog and applies the catalog formula, quantity times unit cost plus daily cost over the lead time. That is where the $6,000, $15,000, and $7,500 come from.
build_dashboard.py writes an AI/BI dashboard, dashboard_royale.lvdash.json, with period parameters over those tables. Free Edition can share that dashboard only with people on the same account, so 03_export_public reads the same g_* tables with spark.sql and writes three JSON files. GitHub Pages serves them. The browser recomputes every ratio as a ratio of sums for the period, zone, or bank on screen. Changing the gold SQL and rerunning the export is how the public page stays aligned with the warehouse.
Where it was useful
The joins are the part a laptop file would have gotten wrong. A machine’s payout variance lives in game_math, its location in the daily view, and a repair’s bank only in floor_locations. Doing that once, in Delta, meant the scorecard, the downtime chart, and the budget all read the same keys.
The time split was useful because it is a WHERE on gaming_date, visible in the notebook. Train rows never include May or June, and the event variant can use only events already known in training. The model page is a query against g_forecast_scores, so the comparison with the constant baseline is the table, not a number pasted into a slide.
The catalog join was useful for the budget. Lead days and unit costs stay in action_catalog. Changing a quantity rebuilds cost_usd instead of leaving a typed dollar amount behind.
How it helped
It kept one definition of the floor. The AI/BI dashboard and the public site are two views of the gold tables, so the house-win figure, the Back Forty comparison, and the forecast error do not drift apart. A claim in the appendix names the g_* table that produces it. When a filter on the public page needs a column the export lacked, as the bank did on faults, the fix is a join in 02_build_gold and a fresh export, not a second calculation in JavaScript.
It also made the recommendation auditable. Inspection, the promotion, and wayfinding each cite a result from those tables, and the promotion’s success test is the frozen weekday forecast stored in g_forecast. The warehouse is what turned a ranked list of weak machines into a plan we could price and measure.
An AI coding assistant helped draft the notebooks and the Spark SQL. We reran the notebooks in Databricks and checked each published figure against the queries in submission/CLAIMS_EVIDENCE.md.
Built With
- css
- databricks
- html
- javascript
- python
- sql
