What it is
What a tabular foundation model is, what it reads, what it returns, and how it differs from training a model per table.
api.example.com, keys, and ids are placeholders.A tabular foundation model is pre-trained once on a very large and varied collection of tables, so that it already understands how structured data behaves. At use time it reads a table as it is and returns understanding of it, with no per-dataset training. The model described here has more than 1.5 billion parameters and belongs to the class called Data Language Models, defined in the paper this documentation is based on.
The idea
A language model reads text it has never seen and still understands it, because it learned how language works. A Data Language Model does the same for tables: it learned how columns, rows, types, units, and relationships work, so a new table needs no feature engineering, no labels, and no shared keys.
raw tables -> one pass of the model -> one bundle of outputs
What goes in
- One or more tables, from files, databases, or APIs, with real, opaque, or missing column names.
- Optionally, a target column to predict and the kind of task.
The model does not rely on column names. It reads the values, so a column called c3 holding phone numbers is understood as phone numbers.
What comes out
Every pass returns the same bundle, so you can build on it without guessing.
| Output | What it tells you |
|---|---|
| Sector | The industry a table belongs to, inferred from the values alone |
| Column profile | The role and type of each column and how much of it is missing |
| Cross-table map | Which columns and rows describe the same thing across tables, even with no shared key |
| Imputation | Values for missing cells, with a confidence per row |
| Predictions | Classification, regression, or anomaly scores, in context |
| Held-out block | A score measured on rows the model did not see |
Why a foundation model
- No per-table training. Predictions are made in context from the labelled rows already in the table.
- the model-agnostic. Different column names and orders do not matter.
- One contract. The outputs have the same shape for every table, so downstream code is written once.
Where to go next
- Architecture: the building blocks inside the model.
- Pre-training: how it learns before it sees your table.
- Capabilities: each output in detail.
- Evaluation: how results are measured and what the numbers claim.
- Limitations: what the model does not do.