Business users don’t care whether a tabular model, a forecasting model, or a relational model processes their spreadsheet. They want to know which customers may leave, how much inventory to order next month, or, perhaps most importantly, whether a promotion would actually change purchasing behavior.
The question comes first. The model should follow.
Today, those questions still lead to different tools and workflows. Classification needs labeled examples. Forecasting needs a time axis and a horizon. A question about customers, orders, and payments may need joins across several tables. Foundation models for structured data can reduce the need to train a separate model for every new task, but the user still needs to frame the question and check the answer.
If the models can handle different forms of structured data, why should the business user have to choose one by name?
Carla has taken a first step with Timestral support. When it detects a timestamp column in a Google Sheet, it suggests time-series forecasting as the modeling task. The user can switch to TabICLv2 for classification or regression. The data provides a cue; the person decides which question to ask.
Different questions, different data
Start with customer churn. A team has one row per customer, account attributes, and a known outcome for past customers. It wants to know which current customers may leave. TabICLv2 can use the labeled rows as context to score new ones. Our customer churn dataset shows the shape of that task.
Now consider a grocery team planning next week’s orders. Its records are ordered by date, and the answer is a sequence of future values. The model needs a forecast horizon and must use only information available when the forecast is made. You can see this with the Rohlik grocery orders dataset and interactive forecast.
Both teams begin with a spreadsheet and a business question. One needs a risk score for each row; the other needs estimates across time. If the churn team also has linked account and activity records, a relational approach can use those connections. NVIDIA’s Kumo churn example follows that route. The question stays recognizable while the available data changes how a model can answer it.
From isolated projects to an emerging AI category
These approaches grew in separate research tracks. Now infrastructure providers are putting them in one place. NVIDIA’s Structured Data Models repository groups tabular, relational, forecasting, and anomaly models. That includes TabICLv2, the tabular foundation model already powering classification and regression in Carla. NVIDIA’s Kumo overview connects its model family to outcomes such as risk scoring, demand forecasting, and anomaly detection.
On November 4, 2026, Thoughtworks placed foundation models for structured data in the Assess category of its Technology Radar. Its recommendation is to explore the technique and understand its effect on an enterprise. Neither NVIDIA nor Thoughtworks invented structured data. Together, they give a shared name and a practical evaluation frame to work that was scattered across model families.
Unifying the models in a developer library is only half the story. The other half is making that diversity disappear from the user’s workflow. The task and assumptions behind a model choice still need to be visible.
What does the model landscape look like?
The map groups examples by the question they answer and the data they need. It includes causal effect estimation as a fifth, adjacent research direction beyond NVIDIA’s current Kumo lineup.
The structured data foundation model landscape
13 EXAMPLES
One table
Will this customer churn?
Ordered observations
What happens over the next interval?
Linked tables
What can related records tell us?
Unusual signals
Which measurements break the expected pattern?
Effects of actions
Would sending the promotion change who buys?
The boundaries overlap. Anomaly detection is not limited to time series, although Kumo Anomaly in this map works with time-series signals. The data shape and the task both matter.
From research to spreadsheets
NVIDIA provides models and developer tooling. Carla brings supported predictions into Google Sheets, where teams already inspect records and discuss decisions. Today, Carla runs TabICLv2 for classification and regression and Timestral-123M for forecasting through browser WebGPU. Model inference runs on the user’s device, without sending the selected data to an external model API.
Try a forecast in your browser
The demo opens on Orders, using sample grocery demand. Select Run Live Forecast to compute a forecast with Timestral-5M on your device. Carla’s Google Sheets forecasting feature uses Timestral-123M; our implementation and benchmark post explains the distinction.
You can also explore the full Rohlik dataset. The tabular model comparison covers deployment trade-offs, and our string-encoding guide shows one data-preparation problem that still needs care.
The spreadsheet interface does not make every answer trustworthy by default. A churn label can leak future information. A forecast can accidentally use a promotion field that was unknown at forecast time. Carla should make those assumptions visible as the workflow grows. A model suggestion is useful only when the person can inspect and change it.
Prediction is not causation
Consider a marketing sheet with customer characteristics, who received a promotion, and who purchased. TabICLv2 can predict who is likely to buy. A purchase score tells you who may buy. An uplift estimate asks who buys because you sent the offer. The customers with the highest purchase scores may have bought anyway.
NVIDIA’s Kumo overview discusses recommendations alongside predictions. A recommended action is not, by itself, evidence that the action caused an outcome.
CausalPFN estimates average and conditional treatment effects from a table containing covariates, treatment, and outcome. Its project is licensed under Apache-2.0. Do-PFN and CausalFM are other examples in the map. An Estimate campaign uplift workflow is a possible Carla experiment, not a current feature. It would need a defensible study design or identification assumptions; a pretrained model cannot remove unobserved confounding.
The next interface for business AI
The longer-term experience starts with the user’s question. Software reads the task and data shape, suggests a suitable model, shows the inputs and assumptions it used, and lets the user test the result. Carla’s timestamp-based forecasting suggestion is an early instance of that idea. Carla does not yet route questions across all five areas, and it does not run relational, anomaly, or causal foundation models in the browser.
The business user has a spreadsheet and a question. Model choice should become an implementation detail, with its assumptions still open to inspection.
Want to see what this looks like today? Run the interactive forecast above, then explore grocery demand on the Rohlik dataset.
Ready to try it on your own data? Install the Carla Chrome extension and open it in your Google Sheet. Carla runs model inference in your browser, so the selected rows are not sent to a separate model API.
