Özer Cem KELAHMETKELAHMET
Tabular foundation model · Using the model

Introduction

What the model is, what one call returns, and the two ways to consume it.

Informational documentation. This section explains how a tabular foundation model of the Data Language Model class works: what goes in, what comes out, and how results are evaluated. It is based on the paper Data Language Models: A New Foundation Model Class for Tabular Data (arXiv:2605.06290). It is reference material, not a hosted service: hosts such as api.example.com, keys, and ids are placeholders.

The model is a Data Language Model (DLM): a foundation model that understands tabular data natively. Send tables and databases as they are, across any number of sources; one call returns what the data is, how the sources relate, what is missing, and what can be predicted from it. No shared keys, no labels, no preprocessing.

text
 tables in ─────────►   the model   ─────────►  the bundle
 any number of sources                        sector · column profile · cross-table map
 no shared keys                               missing-value imputation · predictions
 no labels · no preprocessing                 every output carries its confidence

What one call returns

Every pass, whether a quick run, an endpoint creation, or a call to a live endpoint, emits this bundle (the held-out report lives on the endpoint object):

Output What it is
Sector The industry sector of each table, from cell values alone. Top-1 and top-5, each with a confidence.
Column profile Per column: role, type, missingness, PII flag, with a confidence.
Cross-table map Which columns and rows across 2+ tables are the same attribute or entity, with no shared keys.
Missing-value imputation Filled numeric and categorical cells, with a row-level confidence.
Predictions Classification, regression, or anomaly on a target column, with a per-row confidence.
Held-out report Accuracy on rows the model never saw. Endpoints only.

The vocabulary is identical across the API and the platform. Field-by-field shapes: Outputs.

Two modes

A quick run (POST /v2/run) is stateless: one pass, the bundle back, nothing stored. An endpoint (POST /v2/endpoints, then POST /v2/serve/:id) pins data, carries a held-out report, and serves at a stable URL. See Endpoints.

Surfaces

  • REST API at https://api.example.com/v2/: plain JSON over HTTPS, idempotency keys, job polling, and a per-endpoint OpenAPI description for every live endpoint. Any HTTP client works.
  • Platform at the platform: Dashboard, Data, Quick run, Workspace, Endpoints, Reports, Chat, API. Platform.
  • Base models: runs and new endpoints default to the latest foundation model; every model, its status, and its card live in the model registry. Models.

  • Quickstart: Key, first run, first endpoint.

  • Outputs: Every field of the response.
Type to search.
    ↑↓ navigate↵ open