# 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.

> Informational documentation, based on the paper Data Language Models: A New Foundation Model Class for Tabular Data (arXiv:2605.06290, https://arxiv.org/abs/2605.06290). Reference material, not a hosted service; hosts, 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.

```text
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.