QUERIES
6 months, captured illustrative
12,400 queries → 380 query patterns
Six Moments · One Operating Loop
Builds the case. Lands the change. Measures predicted vs realized.
Dashboards show spend. Audits recommend once. Auto-tuners act opaquely. Spotonix Advisor turns your observed workload into ranked, evidence-backed recommendations — grounded in fingerprint-level attribution — applies approved changes through your own dbt workflow, and measures predicted vs realized against an agreed baseline.
The handoffs the incumbents leave open
Dashboards observe. Catalogs list. Audits recommend. Auto-tuners act. Each closes one handoff and leaves the next one open. Advisor connects the loop.
01 / Profile
Spotonix ingests query history, plans, schema, dbt lineage, and BI assets. Every query that actually ran is captured, grouped, and resolved against your Context Graph. We start from how the warehouse is used, not what last month's invoice said.
QUERIES
6 months, captured illustrative
12,400 queries → 380 query patterns
SCHEMA + LINEAGE
Warehouse + dbt
tables, joins, models, dependencies
BI ASSETS
Dashboards + reports
what your team actually consumes
PLANS + SAMPLES
Cost-relevant only
parsed/sampled for attribution
02 / Ledger
Tables, materialized views, and warehouses — each paired with the queries that touch it, how often, and at what filters. The materialized view that refreshes hourly — about 4,320 times over six months — to serve three queries. The clustering key 78% of queries already filter on. The warehouse idle most of the day. This is the hard part: a catalog can list your assets; only the Ledger can pair them with the queries that touch them.
One asset. Its ledger entry, six months in. illustrative
| Asset | mv_daily_sales_rollup |
|---|---|
| Type | materialized view · hourly refresh |
| Queries served | 3 (over 6 months of observed workload) |
| Refresh count | ~4,320 (hourly × ~180 days) |
| Refresh-to-serve ratio | 1,440 : 1 |
| Source-query latency without it | under 20 seconds |
| Dependent dashboards | 0 (observed) |
Every table, materialized view, and warehouse gets its own ledger entry. Cases (Moment 3) read this ledger to find which assets earn their keep and which don't.
03 / Case
A Case binds the workload evidence, the rule that fired, the proposed action, the estimated ROI, confidence, blast radius, reversibility, dbt-managed ownership, and the measurement plan — into one artifact your team can approve. Advisor doesn't fire every rule that matches; it arbitrates a ranked portfolio and surfaces only the few worth human attention.
mv_daily_sales_rollup.A Case is not a tip. It is the full operating contract for a change.
04 / Change
Approved Cases land as dbt-native changes — config, model, PR, MCP action — with dry-run, ownership detection, rollback windows, and approval gates. The trust ladder is yours: Observe → Advise → Propose → Autopilot. Every Change is approved by your team until a specific class earns delegation through measured outcomes.
The Change lands as a dbt pull request your team reviews like any other. illustrative
-{{ config(materialized='incremental', schedule='hourly') }}
+{{ config(materialized='ephemeral', enabled=false) }}
+# Disabled per Case #1: served 3 queries in 6 months, refresh ≈ $4,200/mo.
+# Cohort measurement plan + rollback path attached.
+# Reversibility: revert this PR; MV rebuilds in next scheduled run.05 / Proof
After a change merges, Advisor measures the exact queries the Case targeted — before and after — against a comparison group of similar untouched queries. The before/after baseline nets out workload drift. The Health Record records predicted vs realized impact and files back to the Context Graph. (Before/after measurement is the operating method; the productized version is the v2 milestone.)
Health Record — Case #1, after 14 days of measurement. illustrative
| Predicted | Realized | |
|---|---|---|
| Refresh credits avoided | ≈ 4,200 / month | 4,180 / month |
| Cohort p50 latency | no regression | +1.6s (under threshold) |
| Control cohort delta | — | −0.3% (drift only) |
| Hypothesis | — | Confirmed |
Confirmed → filed back to the Context Graph. The "decommission unused MV" pattern climbs one rung on the trust ladder.
06 / Playbook
Confirmed Cases become Health Records in the Context Graph. Over time, repeated successful patterns become reusable Playbooks — and a Playbook with enough Proofs in its band can climb the trust ladder, one rung at a time. Autonomy is not a switch. It is earned per play, by measured outcomes.
Example Playbook entries illustrative
The wedge
The first engagement starts with decommissioning unused materializations, pipelines, and warehouses — not because we begin at Autopilot, but because it is the cleanest first Case. Low blast radius. Short Proof window. A direct test of the Ledger: what does this asset cost, what queries does it actually serve, and what breaks if it goes away?
mv_daily_sales_rollup; 3 queries / 6 months; ≈ $4,200/mo refresh.The trust ladder
A class of Change earns its next rung only when it has landed inside its predicted band six times running, with before/after Proof against a comparison group. Every rung carries undo. Most teams stay at Advise for the first quarter.
Honesty edge: Before/after measurement is the operating method in preview engagements. The productized version against a comparison group is the v2 milestone. We will not headline guaranteed savings before that ships — every preview number is an estimate, every measured number is reported as measured.
The preview
Phase 1 · Assessment · 30 days · read-only
Read-only credentials to one warehouse + your dbt project. Six months of query history captured. Top ten ranked Cases with evidence and predicted impact. Executive readout and go / no-go on Phase 2.
Phase 2 · Change sprint · optional · ~30 days
You pick one or two low-blast-radius Cases. Advisor drafts each Change as a dbt PR; your team approves before merge. The first Health Record after merge records predicted vs realized against an agreed baseline.