cube: the answer engine for large data lakes
cube is a read-only instrument you point at a raw, unmodelled warehouse. It works out what the lake can answer, precomputes that bounded set into microsecond answers, and keeps every one of them honest. This is how it works, how it stays governed, and how a lake comes online.
What cube is
A live natural-language query over a warehouse is slow, and the same handful of questions get asked a thousand times a day. The set of questions people actually ask is small and bounded. cube precomputes that bounded core once, serves it in microseconds, and stays live and honest on the long tail.
The product is three machines, stacked:
A query cascade over any warehouse
Route a question to a metric, dimension and grain, resolve its arguments, turn it into a read-only query, run it, and compose the answer with its confidence attached. This is the live path, and the fallback.
The cube: a precomputed answer cache
Precompute the bounded, common set of questions once and serve each as a keyed lookup in microseconds. A miss falls through to the live cascade, so the cube is pure speed, never a substitute truth.
Honesty rails, and a flywheel
A minimum defensible base, a calibrated confidence band on every served rate, and one rule: refuse rather than fabricate. Plus a loop that keeps answers fresh and widens coverage over time.
cube is not an ETL tool, a BI dashboard, or a warehouse. It reads schemas and issues read-only queries. It never owns or mutates a lake, and it never guesses a number it cannot stand behind.
Universal connect
The hard part of pointing an answer engine at a new lake is the semantic model: nobody has told the machine what a customer, an active user, or a region is. Most tools solve this by making a human model the warehouse first. cube does not.
The engine holds no single lake's nouns. Everything a deployment needs to know about its warehouse lives in a portable ask-space spec that onboarding derives, or that your team provides. The same engine runs on a retail lake, a telco lake, or an ad-tech lake, and connects read-only across warehouses, object stores and files.
Time to a first answer on a new lake drops from a modelling project to a profiling run. The lake specifics are data, not code.
The auto-semantic-layer
This is what makes cube horizontal. Pointing an answer engine at a new lake normally requires a human to model it. cube derives that model automatically, in three stages, and puts it in front of your team to review before a single number is precomputed.
Stage 1: profile
cube connects read-only and produces a profile of the lake: tables, columns, types, keys, row counts, column cardinality, distributions, the relationship graph, and a freshness column per table. Deterministic, cheap to recompute, and warehouse-agnostic. It invents no meaning yet.
Stage 2: understand
It turns raw structure into meaning: entities (the business objects a fact hangs on), measures (aggregatable numbers), dimensions (the ways to slice them), and grains (time and aggregation resolutions). Every inference carries a confidence and its provenance, so the model is reviewable.
Stage 3: map the ask-space
It enumerates the bounded set of sensible questions as a pruned grid of metric by dimension by grain: pair a measure only with dimensions it can reach, drop slices whose base falls under the floor, cap the fan-out, and keep the questions that matter. Each one gets a read-only query builder with the join path resolved automatically.
profile 8 tables, read-only, in ~3s
the relationship graph recovered from data alone
// no schema constraints were read
understand entities, measures, dimensions, grains inferred
revenue derived from a price and a discount column,
// with no human telling cube what revenue is
map 213 questions answerable (180 breakdowns + 33 timeseries)
serve answers resolve as microsecond lookupsThat run points cube at a standard benchmark warehouse it is told nothing about, and it recovers the model, maps 213 answerable questions, and serves them, with no human modelling. The full output of that run is documented in The demo lake.
The deterministic model is sharpened by a constrained labeling pass that only labels candidates and never invents a column, followed by a human review gate. This assist is in development on top of the working deterministic layer.
Answering, and honesty
Every answer carries its trust as data, not as a footnote. The rails are applied when the cube is built and surfaced when it is served.
- Floor. A per-deployment minimum defensible base. Below it, an answer is classified below-floor and refused rather than served.
- Confidence band. Every served rate carries a calibrated 95% interval, so an answer at a base of 251 and one at 40,000 are not treated the same. Sums and counts carry their base and freshness instead: an interval only means something on a proportion. The width of the band is how much cube actually knows.
- Concentration widening. When a base is concentrated in a few underlying sources, the effective sample is smaller, so the interval widens accordingly.
- Refuse, do not fabricate. One rule the whole engine obeys. A number it cannot stand behind is refused, never invented.
On the benchmark lake, revenue by nation (a base in the hundreds of thousands) serves. Nation count by region (a base of five) is refused: the cube has the cells, but five is below the floor of 250, so it will not print a confident number. A question with no answer at all falls through cleanly and is logged, never guessed.
See it on your lake: sign in, then connect it free. Sign in →
Trust states
Every cube answer arrives in exactly one of six states, and the state is rendered before the value, everywhere: in the console, in an embedded surface, in these docs. Color is never the only carrier; each state has its own chip, wording and shape.
| State | Meaning | What you see |
|---|---|---|
| Served | Base clears the floor, cell is fresh. | The value, its base, its freshness. Rates carry the 95% band. |
| Served · wide band | Served, but the base is thin or concentration widened the interval. | "Base {n} is thin. The band is wide because cube knows less here." |
| Refused | Base below the floor. | No number. "Base {n} is below the floor of {floor}. cube will not print a confident number on {n} rows." |
| Sources disagree | Underlying sources give different values beyond tolerance. | Both values, both lineages, no blended headline number. |
| Stale | Cell older than the freshness window; serving fails open. | The value, plus "Built {time}, older than the freshness window. Rebuilds on the next tick." |
| Not covered yet | No cell exists; the ask falls through and is logged. | "No precomputed answer for this yet. It is logged." Recurring asks that clear the floor become new answers. |
A refusal is never styled as an error, because it is not one. It is the honesty rail holding. The standing line every first-time user sees on a refusal: "This is cube working as designed. A number below the floor would be a guess dressed as an answer."
When sources disagree, cube serves the disagreement instead of averaging it away. A blend would manufacture a number no source reported. The cost is a less tidy answer; the gain is that nobody trades on a number that does not exist.
See it on your lake: sign in, then connect it free. Sign in →
The flywheel
A static cache decays. cube is designed to compound: coverage widens toward real demand and routing sharpens over time, with no services engagement. On a nightly cadence, the loop does four things.
Ingest fresh data
Watch each table's freshness column. New or changed partitions mark their dependent measures dirty.
Rebuild on freshness
Rebuild exactly the dirty and expired answers, not the whole cube, so a reader never serves a number older than the deployment's freshness window.
Mine the miss-tail
Read the real questions that fell through because no answer existed. Any that recurs above a threshold and clears the floor becomes a new answer. Coverage grows toward what people actually ask.
Self-label
Every accepted answer is a gold label from question to result. Folded back in, it sharpens how cube routes the next question.
The miss log that feeds the loop is live today, and the loop's freshness rebuild, miss-tail mining and self-labeling run end-to-end on the demo lake. Hardening them for production cadence is in active development. The proactive layer, surfacing insights and automations a team did not think to ask for, is built on this loop.
The demo lake
The proof run behind the numbers on cube.ad. cube is pointed at TPC-H, a standard, public benchmark warehouse (scale factor 1, 8 tables, about 8.6 million lineitem rows), with no hints: no DDL constraints read, no semantic model supplied, no questions authored.
map 213 ask-space groups, 3,820 cells precomputed
floor 250 // per-deployment minimum defensible base
serve return rate by ship mode · RAIL
24.71% 95% CI [24.62, 24.80] n=856,484
refuse nation count by region · EUROPE
refused · base 5 < floor 250 // cells exist, floor holds
miss average shipping cost by warehouse
not covered · logged to the flywheel tail
lookup mean 3.3µs over 20,000 keyed gets // no SQL, no LLM callEvery number above is copied from the run's artifacts, not typed from memory. The same artifacts drive the gated maker console at cube.ad/console, where the full ask-space, the coverage map and the real refusals are browsable.
The run is deterministic: profile, understand, map, build, serve, all on a public dataset. The free first mile is the same run pointed at a slice of your lake.
See it on your lake: sign in, then connect it free. Sign in →
The free first mile
The first act of a cube deployment is free: point cube at a slice of your lake and it runs the whole first mile, profile, inferred semantic model, generated ask-space, first answers, with the honesty rails on. Runs are scheduled in order; Fortune 500-grade estates are fast-tracked. Sign-in captures your work email today, and access invitations go out in order.
Free is not charity; it is the flywheel's fuel, and the exchange is stated plainly:
- What your org gets: cube's best work on your lake: instant answers, honest refusals, the coverage map, the nightly widening.
- What cube gets: signal that compounds the product, never your data: schema-shape priors, ask-phrasing vocabulary, honesty calibration across lake shapes.
- The boundary: structural features are anonymized and aggregated; no row values, no query results, no identifier text leaves the deployment. Paid in-VPC deployments default all cross-deployment telemetry off.
Your data never leaves your walls; what compounds is how cube reads lakes, not what is in yours.
Qualification is deliberate: workspaces are created with a work email, and cube is built for lakes with hundreds of tables and billions of rows. The free tier caps at one lake and community cadence; the caps are stated, not hidden.
See it on your lake: sign in, then connect it free. Sign in →
Governance and security
cube is designed for regulated, security-conscious enterprises. The security posture is not a bolt-on; it is how the serving contract is shaped. Below, what holds today and what is design commitment are labelled separately.
| Property | Status | How cube enforces it |
|---|---|---|
| Read-only | Holds today | Reads schemas and issues read-only queries only. Never owns, writes to, or mutates a lake. |
| In your perimeter | Holds today | The whole engine runs inside your environment. Your data never leaves your walls. |
| Floor as k-anonymity | Holds today | The honesty floor doubles as a k-anonymity rail: no group below n=250 is ever served, so a thin slice can never single out the individuals inside it. |
| Traceable | Holds today | Every served answer carries its base size and provenance, so a number can be traced to what it was computed from. |
| Fail honest | Holds today | A miss or a refused answer returns nothing and falls through. cube never fabricates to fill a gap. |
| Authorize first | In development | Designed so every request is authorized before a lookup, scoped to tenant, row and metric. SSO/RBAC and the audit log are on the enterprise roadmap; the serving contract is shaped for them now. |
Any surface over private data is gated, never open. cube's own maker console follows the same rule: it sits behind device-approval auth, and an unauthenticated request sees nothing but the gate.
Onboarding a lake
The end-to-end path from a raw warehouse to gated, answering-in-microseconds.
1. profile read-only → structure, keys, relationships
2. understand infer model → your team reviews it
3. map ask-space → bounded, pruned, floor-cleared
4. build precompute → the honesty rails in every answer
5. serve microsecond answers, refusals included
6. compound nightly → fresh, wider, sharper over timeA human sign-off gate sits after step 2, so the semantic model is reviewed by your team before a single number is precomputed. Steps 4 through 6 are the reusable engine; step 1 through 3 are the auto-semantic-layer.
The first mile is free: sign in with a work email, connect a slice of your lake, and cube runs profile, semantic model, and first answers, scheduled in order. Sign in.
What is live today
Stated plainly, so there is no daylight between the claim and the code.
- Live and proven: profiling, the semantic model, the ask-space mapping, precompute, and serving, running end-to-end on a real unmodelled benchmark warehouse with the honesty rails attached. The flywheel loop (freshness rebuild, miss-tail mining, self-labeling) runs end-to-end on the demo lake.
- In active development: the constrained labeling assist that sharpens the two hardest inference spots, and production hardening of the nightly flywheel cadence.
- On the roadmap: SSO/RBAC and the audit log for per-principal authorization, and the proactive layer that surfaces insights and automations a team did not think to ask for.
The same rule cube applies to your data, it applies to itself: we do not claim a capability we cannot stand behind. If it is being built, it says so.
See it on your lake. Book an assessment →