CEDX Warehouse · Data & Analytics
CEDX Warehouse is the managed analytical store for the estate: 320 tables tracked against freshness SLAs, credits and storage watched by domain, and natural-language answers that show their thinking steps and the SQL they ran.
The Freshness SLA screen doesn't hide its worst row. ops.tickets_283 sits at the top — 81 hours old against a 4-hour SLA, 20.25× over, priority 1805.5. An honest warehouse leads with that.
Runs on demo data — the header reads “4.2K credits/day · demo seed” on the screen itself.
What it is
320 tables carry age against SLA in a risk queue scored by impact: ops.tickets_283 at 81h against 4h — 20.25× over, with 26 consumers reading it anyway. An SLA simulator and the scoring model sit one tab away.
“What was net revenue last week?” returns $4.21M, down 3.8%, with the thinking steps listed: interpreted via the certified metric in sem_revenue_360, resolved core.orders, planned the SQL. The generated SQL prints below the answer.
4.2K credits a day and 84 TB of storage break down by domain — Commerce at a 1,420 credit index against Support's 210 — and by warehouse, where report_3xl_5 burns 907 credits a day on 11 active queries.
Product tour
Not a mockup and not a concept deck. This is what opens at /app/data-warehouse.
01 — Overview
Credits, active queries, storage and SLA breaches on one row; estate health reads 88 with the components listed. The alert feed explains itself: etl_large scanned 48 TB because an INSERT skipped the partition prune on raw.orders.
02 — Ask
412 AI questions a day run against governed semantic views at 4.1s median latency, spending 3.6 of the day's 4.2K credits. Suggested questions stay in scope: fill rate by DC, the finance warehouse's cost this week, which tables are past SLA.
03 — Freshness SLA
166 tables at risk — age at least 75% of SLA — and 146 breaching, each with consumers, impact and a priority score; ops.tickets_283 leads at 1805.5. Effort is marked S, M or L so the queue doubles as a work plan.
Who runs it
Roles, not references. We have no named customers yet, so nobody in these photographs is quoted, credited or claimed as one.
Works the freshness risk queue: partition prunes, backfills, and the etl_large job that scanned 48 TB before the alert priced the fix.
etl_large · 48 TB scanned
Certifies the semantic views Ask grounds against — sem_revenue_360 and the 14 others — and watches credit-per-question against the daily total.
15 semantic views · 91% grounded
Watches warehouses up, cache hit and cost spikes: 11 of 18 warehouses running, 41% cache hit rate, 11 high cost spikes on the health ring.
warehouses · 11 of 18 upThe shape of it
Every figure below is legible in the captures above. Nothing here is a projection of your estate — it is the state of the demo data.
How it runs
Tables land in the catalog — 320 of them — each with a declared freshness SLA and a domain.
Queries and semantic views run on the compute warehouses; 86 active queries and a 41% cache hit rate on the demo estate.
Ask interprets the question against certified views, shows its thinking steps, and runs the SQL it prints.
Credits, freshness and cost spikes roll into the estate health score and the priced alert feed.
One record
Warehouse is not a database with a dashboard bolted on. Its tables, views and SLAs are the substrate the rest of the estate's numbers stand on.
The 320 tables stay fresh because Sync's 72 jobs move 48.2M rows a day — a lag breach there lands here as a stale table.
CEDX InsightThe governed metric layer reads this catalog; the two Ask screens resolve through the same semantic views.
CEDX EmbeddedAnswer embeds — 30 of them, 63K questions in 30 days on the demo estate — execute against these governed views inside other products.
CEDX CopilotAsk AI sits on every Warehouse screen; the assistant cites the same tables and views the console tracks.
Limits
Finding this out on the third call is worse for you than reading it here, and worse for us.
Start
Open it right now
Your tables, your SLAs
Warehouse with the rest of it
Questions
Yes. Every screenshot is a capture of the running build, and you can open the same build at /app/data-warehouse. It runs on demo data, which the header states on screen.
The table is older than it promised to be. ops.tickets_283 is 81 hours old against a 4-hour SLA with 26 consumers, which scores it priority 1805.5 and puts it at the top of the risk queue — the queue is the work list, ordered by impact and effort.
Answers execute against governed semantic views. The screen lists its thinking steps — interpreted the certified metric, resolved core.orders, planned the SQL — prints the generated SQL, estimates the credits, and flags uncertified views before anything runs.
It is broken down two ways on the overview: by domain (Commerce at a 1,420 index, Support at 210) and by warehouse (report_3xl_5 at 907 credits a day on 11 queries). The cost-spike alerts name the cause — etl_large's 48 TB scan was an INSERT without a partition prune.
No certification has been issued. What we can evidence about hosting, encryption, tenant isolation and production access is written up on the security page.
Live build, demo data, no card. Everyone has an ops.tickets_283; the demo estate's is on screen.