Data Formulator

Microsoft Research's open-source AI data-analysis system: load data, ask in natural language, get charts and tables back, branch the investigation, compose the result into a report. MIT, Python, 16,279★ / 1,543 forks / 93 open issues / 104 watchers, created 2024-06-07 and last pushed 2026-08-15 — actively developed, currently v0.8 beta. Runs locally at localhost:5567 via uvx data_formulator, pip, or Docker. Figures read 2026-08-17 from the GitHub API.

The corpus's fourth generative-ui entry, and the one that answers that page's central question differently from the other three.

What the model emits: a chart specification

generative-ui sorts its entries by what the model actually produces — real framework code bounded at runtime (arrow-js), a restricted DSL bounded by grammar (openui), or an undisclosed artifact inside a vendor's own product (sheets-canvas). Data Formulator sits nearest OpenUI and is narrower still: the model emits specs in Flint, described as "an open-source visualization language that compiles compact chart specs into polished visualizations," covering 30+ chart types.

That is the tightest vocabulary bound in the set, because the target is not an arbitrary interface but a chart. The model cannot invent an interaction; it selects and parameterizes within a grammar whose whole output space is visualizations. Where openui bounds a model to a developer-defined component set, this bounds it to a chart algebra — a stronger constraint that buys correspondingly less range.

The direct comparison this spoke did not have

sheets-canvas is Google's Gemini generating a "mini-app" over spreadsheet data, announced four days earlier. Data Formulator is Microsoft's take on the same product idea — an agent over tabular data, emitting an interactive artifact — and the two are opposite on disclosure in every respect:

The generative-ui page's complaint about Sheets canvas was that "containment is moot because nothing is exposed — and so is inspection." Here everything is exposed and the containment question becomes answerable: the agent's output is a spec you can read, the model is one you chose, and the process runs on your own hardware. Same idea, opposite posture, from the two vendors most able to close it. That makes it the cleanest disclosure comparison in this corner, and worth more than either source alone.

Data threads — branching instead of a transcript

The design idea the project pushes hardest, and the one that touches this spoke's own preoccupations. Rather than a linear chat history, work is organized as data threads: you "branch into different questions, compare paths, and use visualizations to discover deeper insights without losing context."

That is a claim about the shape of the interaction, not the model. Every agent surface this spoke holds is a transcript — messages in order, context accumulating, earlier turns receding. A branching structure says analysis is a tree, that comparing two paths side by side is the point, and that a linear transcript loses exactly what an analyst needs. The corpus has loop-engineering and a long argument about context management; it has nothing else proposing a non-linear unit of work. Whether branching helps is unmeasured here — there is no study, no task set, no comparison against a chat baseline in the repository.

The architecture, as stated

Three named agents: a Data Analyst Agent that discovers sources, asks clarifying questions, proposes a loading plan and reviews the data; a DataAgent combining language understanding with data operations for exploration; and a Style Refinement Agent for visual polish. Provider access goes through LiteLLM, so the model is a configuration choice rather than a dependency — the same substitutability pattern this spoke tracks elsewhere. Heavy data work is pushed to DuckDB, which is what lets a local process handle datasets larger than a browser would tolerate.

Input coverage is unusually wide for a research artifact and is most of what a working analyst needs: CSV/TSV/Excel/JSON, three relational engines, two data platforms, two object stores, URLs with automatic refresh — plus extraction from images and text, so a screenshot of a table is an accepted input.

What is not established

Nothing has been run and no evaluation is held here. The repository is the project describing its own system; there is no accuracy figure, no task benchmark, no user study in what was read, and no statement of how often a generated chart misreads the data. For a tool whose output is a chart handed to a decision-maker, that gap is the one that matters — a wrong chart is more persuasive than wrong prose, not less, and the visual form is what makes it so.

T1 as the primary artifact, in the ladder's sense of provenance, not quality — the same distinction the spoke drew for ai-marketing-claude a few hours earlier, and the reason both pages say so out loud. Microsoft Research publishes a blog post and a video behind this; no paper was identified in what was read, so the research claims are currently unsourced here.

The desktop builds are, by the project's own admission, "automated preview builds," not code-signed or notarized, requiring the user to click past an OS security warning. That is the second unsigned distribution channel this hub has recorded in two weeks (cf. ../osint-wiki's termux, whose GitHub APKs carry a shared community test key), and the pattern is worth naming: preview builds ship the security warning to the user as a normal step.

Related

generative-ui · sheets-canvas · openui · arrow-js · microsoft · model-context-protocol · synthesis