TabPFN and Prior Labs: why a foundation model for tabular data still needs forward deployed engineers

A customer sends you an export from their ERP: a few thousand order rows, a few dozen columns, and a very everyday question: “Tell us in advance which orders will be delivered late.” Someone will inevitably add: “Why not give it to a chatbot and see if it can guess?”

This is exactly where many engineers get stuck. When SAP announced its acquisition of Prior Labs on 4 May 2026, it said plainly that LLMs struggle to make predictions on structured business data, because they have only a superficial understanding of tables, numbers and statistics. The customer’s order table sits squarely in that weak spot.

Prior Labs makes TabPFN, a foundation model built specifically for tabular data. Products of this kind hand the FDE a very specific job: to prove honestly, on the customer’s own table, that the foundation model is worth more than the old approach.

A model that learned how to learn from fake data

With tabular data, the familiar approach is to train a separate model for each problem, usually gradient boosting, and then tune its parameters. TabPFN takes a different route. According to the paper published in Nature in January 2025, it is a learning algorithm, and that algorithm was itself learned from millions of synthetic datasets.

The University of Freiburg’s press release gives a concrete figure: the model was trained on 100 million synthetic datasets. The notable detail is that it learned from no customer’s real data at all. What it learned is how to look at an unfamiliar table and predict straight away.

The published results are strong. On datasets of up to 10,000 samples, the paper reports that TabPFN outperforms all previous methods by a wide margin. Freiburg adds that it needs only 50% of the data to reach the same accuracy as the previous best model.

If the foundation model is that good, why does someone still need to sit with the customer?

Because a benchmark is not the customer’s table. Real tables have columns overwritten after the event, customer IDs that change format halfway through, and a “late” label that each warehouse defines differently. A foundation model cannot fix those things on its own.

Nor does Prior Labs sell the model as a sealed black box. As early as its funding round in early 2025, the company said TabPFN allows fine-tuning on a business’s proprietary data. By December 2025, when it was selling to enterprises, fine-tuning on a company’s own data was still part of the pitch.

And fine-tuning on customer data means someone has to go on site: understand the data, build the pipeline, measure the results, then explain them to the decision-makers.

SiliconANGLE describes Prior Labs’ aim as helping businesses understand and use the complex information that matters most to their operations. That kind of information rarely sits ready in a clean table. Turning it into a usable one is the work of the person sitting next to the customer.

What an honest pilot looks like

Picture a distributor with 1,800 customers. Each customer is one row captured on a given date, with 40 columns and a label column for “churns in the next quarter”. Suppose only 90 customers churn, or 5%.

A lazy model that predicts “nobody churns” achieves 95% accuracy without catching a single customer. Because it gives every customer the same score, its ROC AUC is exactly 0.5, no better than a coin toss. So accuracy is ruled out from the start, replaced by ROC AUC and precision in the highest-risk group.

But the question you need to answer is not “Is TabPFN good?” The right question is: on this table, how much better than the baseline is it, and how much data does it need?

The code below follows that approach: the same time-based split, several data sizes, several models.

from sklearn.metrics import roc_auc_score

# Fixed time-based split: train on the past, test on the later period
df = df.sort_values("snapshot_date")
cut = int(len(df) * 0.7)
train, test = df.iloc[:cut], df.iloc[cut:]
X_train, y_train = train[features], train["churn"]
X_test, y_test = test[features], test["churn"]

def learning_curve(make_model, fractions=(0.25, 0.5, 1.0)):
    scores = {}
    for frac in fractions:
        n = int(len(X_train) * frac)
        model = make_model()
        # Take the n rows closest to the test period
        model.fit(X_train.iloc[-n:], y_train.iloc[-n:])
        proba = model.predict_proba(X_test)[:, 1]
        scores[frac] = roc_auc_score(y_test, proba)
    return scores

# make_baseline: tuned gradient boosting
# make_foundation: tabular foundation model
results = {name: learning_curve(fn) for name, fn in
           {"baseline": make_baseline, "foundation": make_foundation}.items()}

The learning curve is the most valuable part. If the foundation model using 50% of the data already matches the baseline using 100%, you have checked Freiburg’s claim for yourself on real data. For the customer, that result is very practical: they can start with one region’s data instead of waiting to gather data for the whole country.

And if the two curves overlap, that is a result too. Report it as it is, then propose the next step: perhaps fine-tuning, perhaps cleaning the labels first.

Doing it yourself: in what order?

Start by sitting with someone who understands the business to define the label, and ask of every column: is this value known at the time of prediction? That question blocks most data leakage before you write a line of code.

Next, lock the split and build a strong, properly tuned baseline. A weak baseline makes every gap meaningless, and a sharp-eyed person on the customer’s side will spot it immediately. Only then run the foundation model and the learning curves on the same split.

Finally, make a conditional recommendation. If the foundation model wins clearly and consistently, trial it in a real workflow. If it wins narrowly, consider fine-tuning on the customer’s own data, an option already part of Prior Labs’ enterprise offering. If it does not win, keep the baseline and record why.

Mistakes that cost a pilot its credibility

The most common mistake is leakage: a column such as “actual delivery date” slips into the inputs and makes every model look excellent. The second is putting benchmark results on a slide in place of results measured on the customer’s table. The Nature figure is a reason to try, not evidence for this project.

The third mistake is forgetting the scope. If the customer’s table goes far beyond 10,000 rows, you have left the range the 2025 paper demonstrated, and you must measure again rather than extrapolate.

The last mistake is promising the security team things you have not checked. That the model was pre-trained on synthetic data says nothing about where the customer’s data goes afterwards.

Before the security meeting, ask the vendor directly: what customer data does the model need at prediction time, where is the data stored during fine-tuning, and whose infrastructure does the model run on?

How this skill shows up on a CV

With more than 3 million downloads, TabPFN is a widely used open-source tool, so you can practise right away without waiting for a project. The 1,800-customer pilot above is an exercise you can build yourself with public data.

When reading a job description for a forward deployed ML Engineer at a foundation model company, look for phrases such as fine-tuning on customer data, model evaluation, and working directly with customers.

Then write your CV to prove exactly those things. Do not write “experienced with tabular ML”; write: what problem, which baseline, which metric, how large a gap, at what data size.

People hiring FDEs want to see that you know how to measure before you know how to praise. A model that has learned from 100 million fake tables still needs one person to ask the hardest question on the real table: at the time of prediction, did we actually know this column yet?