analytical applications
Put analysis inside your application.
Turn operational records into derived datasets, statistics, charts and KPIs without sending your users to a separate tool to understand their own data. Analyse it. Find the cause. Act on the record. In one application.
Explore the live demo What the statistics layer knows →
Vanilla JavaScript. Zero runtime dependencies. Every figure computed in the page, with nothing fetched at runtime.
Open the full demo → The statistics layer → Derived datasets →
the question a chart cannot answer
Dashboards tell you something is wrong. Applications let you investigate why.
A dashboard is a picture of a conclusion someone else reached. It shows a number that has moved and stops there, and the next question, which line, which batch, which of the records behind that number, is the one it was never built to take. So the person reading it exports a file and the investigation leaves your product.
What a dashboard gives you
A figure, and a shape. Something is up. Nothing on the screen can be asked a second question, so the trail ends at the picture.
What an application gives you
The same figure, and a way in. Narrow it, break it down, find the part that is causing it, and open the record underneath, without leaving the screen or losing what you were doing.
The demo above is that round trip, in three clicks. Four process figures say the plant is not holding tolerance. Click a line and every figure, both charts and both panels recompute over that line alone, and the cause is on screen. Click one of the readings that broke the limits and the grid scrolls to the record behind it: the machine, the operator, the batch, the shift, and the conditions it was running under. Insight, cause, record.
derived datasets
Build datasets from datasets.
Any grid can be built from another one. Narrow it to the rows that matter, group it into a summary, bucket a date column by day or by quarter, expand a nested array into one row each, join a second dataset to bring its fields across, or profile a column and get its shape as rows. What comes out is an ordinary grid: sortable, filterable, chartable, exportable, and able to be the source of the next one.
The part that matters is that a derived dataset stays connected to the one it came from. It reads the rows its source is currently showing, so filtering the source rewrites every panel built on it, to whatever depth you have chained them, with no second query and no second copy of the data. A pick in a summary can push the other way too, narrowing the dataset it summarises, so a reader moves up and down the chain by clicking rather than by writing anything.
Narrow and reshape
A row predicate, a group, a date bucket, an array expanded one row per element, a ranked top few, or the rows that make up the first share of a total. Each is a line of configuration rather than a pipeline you maintain.
Bring another dataset in
Match rows against a second grid on a key they share and carry its fields across, so a summary can group on a field that lives somewhere else. Or read several sources as one set before the rest of the work runs, each row still saying where it came from.
Derive again
A derived grid is a grid, so it can be the source of the next one. Chain them as deep as the question needs and a filter at the top still moves every level below it.
Nothing can disagree
Every panel reads the same rows through the same column handles, so a median in a summary and a median in the totals row underneath are the same number by the same definition. Not two implementations that usually agree.
How derived datasets work → See three levels chained → See the path back up →
statistics, in the page
Statistics are part of the application.
Not a service you call and not a library you bolt on. The grid knows what its own numbers say, computed over exactly the rows on screen, so narrowing the data narrows every figure with it. Put them in a tile, in the totals row, in a panel beside the grid or in your own layout, and they all come from the same pass over the same rows.
Distributions and quantiles
Everything worth knowing about a column in one pass: how many rows carry a value, how many distinct, the median and the quartiles, the spread, the shape, the outliers and the histogram. Forty-one reductions, any of which can be a totals row.
Relationships
Correlation by rank as well as by value, a least-squares fit with its R squared drawn on the scatter, and a multi-term model whose coefficients, standard errors and collinearity you can read in a panel. The residuals, the leverage and the influence come back as ordinary columns you can sort and filter on.
Time series
Growth, volatility and the worst drawdown of a series. Rolling averages, trailing medians and change on the period before, as real columns. Smoothing, a forecast that carries the band around it, a seasonal split into trend, pattern and what is left, and an autocorrelation plot that shows how far back the series depends on itself.
Process quality
Declare the tolerance on the column and Cp, Cpk, Pp and Ppk, a control chart with its own limits and the customer's drawn apart, a moving-range chart beside it and every rule break marked and numbered all read the same three numbers. Nothing can hold two ideas of what the limits are.
Anomalies
The rows that do not belong, by a robust per-column score, by the fence a box plot draws, or by distance from the joint centre, which catches a row that is only impossible in combination. Judge a reading against its recent neighbours instead, so a slow drift never becomes the baseline. Every flag carries the score and the reason behind it.
Ready-made panels
The statistics panel, the regression panel and the insights panel are the end-user half of all of it: a column picker, the figures, the shape, the model, and which columns most separate what the user has filtered to from everything else. Turn one on with a line of configuration.
The statistics layer in full → Charts drawn from the same rows → KPI tiles →
numbers your users can act on
A figure that overstates itself is worse than no figure.
Analysis inside a product is read by people who will act on it, quickly, and question it less than they would question a report. So the figures say what they are.
An index comes with its interval
A capability index measured on thirty parts can pass a requirement and still have demonstrated almost nothing. The bounds sit under the value in the tile and in the panel, at the level they were computed for, because a tile is where a number is read fastest.
An estimate says it is one
A trailing median stays exact while its window is small and comes from a sketch beyond that, and a companion column reports exactly which rows are approximate. A partial window is stamped with how much of itself it actually covers, so a two-day average is never shown as a seven-day one.
Uncertainty, not verdicts
An interval says the mean is 42 and the data pins that down to between 39 and 45. It does not say 42 differs from 40. There are no significance flags, no stars and no badges anywhere in the surface, and where a p-value is shown it is shown as the plain number it is, with the method that produced it named beside it.
The same definition everywhere
Every figure is computed through the column handles the totals row uses, so a median in a derived summary is the same number as the median in the footer beneath it, by the same definition. Two panels on one screen cannot quietly disagree.
the same screen, every industry
Wherever the answer is in the records.
A quality engineer, a revenue analyst and an incident responder are doing the same thing: taking a figure that moved, breaking it down until the cause is visible, and opening the record behind it. Only the columns change.
Manufacturing and quality
Tolerances, capability, control charts and the readings that broke the limits, exactly like the screen above. There is a build-along tutorial for it.
Analytics inside a product
Pivot, cross-filter and fit a model over the same dataset a user is already working in. See the analytics workbench tutorial.
Operations and incidents
The same analysis over a feed that never stops, with a live stream routed to every panel at once. See realtime applications.
Datasets too big to send
Push the filtering, sorting and paging into the engine and analyse what comes back. See DuckDB and Parquet.
Your users shouldn't have to export data to understand it.
Development on localhost needs no licence key, so you can point a derived panel and a statistics tile at your own data and see the real screen before you decide anything. Licence per domain when you ship.