Column name independence: how a tabular model works without headers

Column name independence means the model's answer does not depend on what the columns are called. The tabular foundation model described on this site never receives a column's name or identity. It receives the values in each column and the way those values relate to the values in other columns. Rename every column to random strings, strip the header row, or mislabel the columns on purpose, and the model sees the same input.

This page explains the design, the signals the model uses in place of names, the benchmark that tests it, what it enables across the other capabilities, and where it hurts. The measured story, with its protocol, is on a companion page: Metadata independence benchmark. Scores are left out on purpose. The model card carries them with their protocols.

The short version

• Column embeddings are always zeroed, in training and at use. The encoder builds each cell vector from value, type and position, and the part that would say which column the cell belongs to stays empty.

• Models that read headers lose roughly seven AUC points when headers vanish. The model here is the only one in my comparison whose accuracy does not fall when names are removed or replaced with noise.

• The benchmark uses twenty numerical classification datasets under three naming conditions, with rivals on the same folds and five seeds, 300 measurements in all.

• In practice no renaming, mapping or data-dictionary work is needed before the model is useful.

When a name is the only clue, the model has nothing extra to lean on, and on pure numeric classics a stronger prior-based rival still leads by a few thousandths.

Identity is not meaning

Two ideas are easy to confuse here, so it is worth separating them first.

• A column's identity is its label: age, c3, val_B. It is a string that a person or a system attached to the column.

• A column's meaning is what the numbers in it are. They might be ages, phone numbers or prices. That meaning shows in the values and in how the column moves with its neighbours.

The model throws away the first and keeps the second. This is not the same as ignoring meaning. A column of birth years still looks like birth years. What changes is where the evidence comes from.

An everyday picture

Imagine a detective handed a spreadsheet with all the headers torn off. A good detective can still say which column holds phone numbers, which holds dates of birth and which holds prices. Phone numbers have a fixed length and few repeated values. Birth years sit in a narrow band and sort into runs. Prices are skewed with a long tail. Ages rise together with years of employment. The model is trained to be that detective.

Why names are tempting

If names are available, they are the cheapest clue in the table. A column called income tells you a lot in one word. A model that has read a great deal of text knows what income is. So most systems use names, and for good reason.

The trouble is that names are a shortcut with three weaknesses.

• They can be missing. Legacy extracts, machine exports and privacy-stripped data often have no useful headers.

• They can be wrong. A column called value that is really a date. A column called price that holds a count after a migration. A model that trusts names will trust these mistakes.

• They can stop the model from looking. If a column called age always behaves a certain way in training, the model can learn the name and stop reading the values. That shortcut breaks the moment a table arrives with a column called c3.

How the encoder works

Every cell becomes a vector. The vector combines three parts, and a fourth state for blanks. See Cell encoding for the full treatment.

Position is grouping, not naming

This is a subtle and important point. Position tells the model that two cells sit in the same column, so they can attend to each other. It does not tell the model that this is the third column of the file, so it must be the age. Position is a way of grouping cells. It carries no label.

Where the zero goes

In many models there would be a fifth part, a learned vector for each column or each column name. In this model that part exists in the architecture and is always set to zero. The model never gets a column's identity as an input.

cell vector = value part + type part + position part
              + column identity part   <- always zero

Because the part is zero in every case, the three naming conditions in the benchmark are, from the model's point of view, the same input.

Not using is different from coping

A model that has learned to cope with missing names suffers a smaller loss. A model that never used names suffers no loss. The design aims for the second. There is nothing to lose because there was nothing in use.

What the model uses instead

Without names, the model leans on structure that is always present in a table.

Why attention along both axes matters

The network alternates attention over rows and over columns. A column layer lets each cell see the other values of its own column, which is how it learns what is typical for that attribute and what is strange. A row layer lets each cell see the other cells of its own record, which is how it learns that a high balance and a long tenure go together in one customer. Together these give the relations between columns that a name would otherwise have supplied. See Architecture and axial attention.

Why the global view matters

A Perceiver-style block lets a fixed number of latent vectors read all the cells and write back. This gives each cell a view of the whole table, which helps when a column's role depends on its context. See Perceiver IO.

Dependence on the target

For prediction, the model reads the labelled rows as a support set. Which columns matter for the label shows up in how the support rows compare with the query row. No name is needed to find that a column predicts churn. See In-context prediction.

The symmetries that come with it

Tables have no natural order of rows and no natural order of columns. A model that is built for tables should give consistent answers when you shuffle them.

• Row order. Shuffle the rows and the output moves with them.

• Column order. Swap column 3 and column 7 and nothing about the data changed. The model does not care.

• Column names. Rename the columns and nothing about the data changed. The model does not care about that either.

These are all the same principle: the model should respond to the data and not to its packaging. Name independence is the third symmetry.

Why training has to close the shortcut

It would not be enough to hide names only at test time. If the model had learned during training that a column called age is special, it would build a reliance and break when the name changed.

So the zeroing is there from the start of pre-training and stays there. The self-supervised goal is masked cell modeling: hide cells and recover them from the row and the column. See masked cell modeling. To recover a hidden city, the model must use the postal code beside it. To recover a hidden age, it must use the other ages in the column. Neither route needs a name. The model is forced to learn what a phone number, a date or a price looks like from values and relations.

This is the reason the result is a property of the model and not a trick applied afterwards. See Pretraining for the objective, and for why the generator's prior must also not smuggle names back in.

The prior must not leak names

The synthetic tables used in pre-training are made by a generator, and the generator encodes beliefs about what tables look like. If the generator tied particular names to particular behaviours, the model could learn those links. Keeping column identity out of the inputs closes that route whatever the generator does. See Synthetic data generation.

Three routes by which names normally get in

To see why the benchmark is hard for other models, it helps to see how names usually enter a system.

Route one: names as text

Some language-model approaches turn a row into a sentence: age is 54, income is 71,000. The header becomes part of the text. Remove it and the sentence loses its subject.

Route two: names as learned embeddings

Other models learn a vector for each column name or column position. When a new table arrives with unfamiliar names, the vector is weak or wrong, and the network works with a blurred signal.

Route three: names as human preprocessing

Even where the model ignores names, the pipeline around it often does not. A person reads the headers, decides which columns are categories or dates, and encodes them by hand. That is a dependency on metadata too, and without headers the step stalls.

How this model avoids all three

• No text route: the model reads cells, not sentences.

• No embedding route: the identity part is zero.

• No human route: types and roles are inferred from values, so no one has to map headers first.

The benchmark in brief

The benchmark takes the claim and tries to break it. It was run on 18 July 2026.

Why numerical datasets

When a column holds free text, the text carries meaning even without a header. With purely numerical columns, the header is often the only place the meaning lives. A column of numbers between 20 and 80 could be an age, a temperature or a score. This makes numerical datasets the hardest test of whether a model needs names.

What a good result looks like

A good result looks boring. If you plot accuracy for the three conditions, you want three bars of the same height. Header readers show a staircase going down. The model shows a flat line. The point of the benchmark is the shape of the staircase.

How the comparison was kept fair

• I fixed two measurement bugs first, so that all three conditions went through the same code path.

• Rivals ran on the same folds as the model.

• Every method used five seeds.

• The model used one fixed configuration, and no variant was chosen per dataset.

• Competitor figures are third-party published values, not re-runs.

• Each run is checked for contamination against the training corpus.

The protocol follows the first paper of this model class, arXiv:2605.06290. See Research and Evaluation.

What name independence enables

The design is the base for several other capabilities. Each one needs a model that never relied on headers.

Blind sector identification

Naming the industry of a table from raw cell values only makes sense if the model never needed the headers. The benchmark zeroes the names, gives no labels and no metadata, and asks for the sector. See Blind sector identification.

The model matching

Which column in one table corresponds to which in another? Every published competitor sees column names. The model does not, and it beats the name-aware matchers on the scenarios I tested. The scorer has a name channel among its three channels, which is a component of the matcher and not of the encoder. The benchmark claim is made name-blind. See Entity and schema matching.

Entity matching

Finding which rows describe the same real-world entity with no keys relies on the values. Names are not part of the question. The margin is widest where text matching gives out, for records that describe the same entity in different words.

Imputation

Filling gaps does not need to know what a column is called. In fact, one of the measurement bugs I found in that work was that the semantic channel had been fed placeholder column names, which is a reminder that names, even fake ones, can be a leak in a harness. See Missing-value imputation.

Anomaly detection

The detector uses the imputation head's residual and nearest neighbours in embedding and raw space, none of which needs names. See Anomaly detection.

Continual learning

An adapter that does not depend on the number of columns is only possible when columns are not tied to identities. See Continual learning for tables.

Packaging

The merged checkpoint carries the same property into serving, so every request meets the same name-blind model. See Unified checkpoint.

What this means in the real world

Think of a spreadsheet you inherited from a colleague who left. The columns are called val_B, metric_14 and field3. Nobody remembers what they mean.

A model that needs good headers is stuck until a person writes a data dictionary, which can be weeks of work in a large organisation. A model that does not need headers is useful on day one.

Column roles without names

The model returns a role for every column, such as email, phone, name, date, address, identifier, measure, category, currency or geo, with a type and a missing share. Those roles come from the values. That is how personal data can be flagged in a table whose headers say nothing. See Capabilities.

A fair page must say what the design gives up.

When a name is the only clue

If two columns have identical value shapes and the only difference is the label, a name-blind model has less to work with. It may express that as lower confidence.

Coded categories

A column called risk_tier that holds the digits 1, 2 and 3 is read as a small integer category and not as a risk tier. Whether the order matters, and which direction is worse, may not be settled by the values alone.

Units

A column of numbers between 0 and 100 might be a percentage, a score or a temperature in Celsius. Values and relations often settle this, and sometimes they do not.

Unusual formats

Mixed or unusual formats can still lower confidence. The model reads the data, and the data can be messy.

Pure numeric classics

On datasets without semantics, a stronger prior-based rival still leads on the metadata benchmark, usually by a few thousandths. These are tables where no name could have helped, so the contest is about raw prediction strength. My wins are concentrated on datasets where meaning matters.

Tiny tables

With few rows there is little context to infer a column's role from. Name-blind models are most exposed here.

If you want to add meaning anyway

Name independence does not forbid you from knowing what your data means. It means the model does not need you to say it.

• Write business rules down for people. A data dictionary still helps the humans who read the output.

• Pick the target yourself. You know which column is the outcome. The model can also propose one.

• Flag ordered codes. If digits 1 to 5 are strictly ordered grades, note it and check results on that column.

• Keep headers in the system of record. The model does not need them, and your database still does.

• Review low-confidence roles. A role with low confidence deserves a person.

A test you can run on your own tables

You can measure name dependence for any tabular model with a small experiment. This sketch shows the idea and is not a specific tool.

import random, string

def random_names(columns):
    return ["".join(random.choices(string.ascii_lowercase + string.digits, k=5))
            for _ in columns]

def run(model, folds, condition):
    scores = []
    for X_train, y_train, X_test, y_test in folds:     # same folds every time
        if condition == "random":
            X_train.columns = X_test.columns = random_names(X_train.columns)
        elif condition == "removed":
            X_train.columns = X_test.columns = [""] * X_train.shape[1]
        scores.append(evaluate(model, X_train, y_train, X_test, y_test))
    return scores

for seed in range(5):
    for condition in ["full", "random", "removed"]:
        report(seed, condition, run(model, folds_for(seed), condition))

Three habits make the experiment honest.

• Use the same folds for every condition and every method.

• Repeat with several seeds and look at the spread.

• Report the drop between conditions as well as the final number.

If your three results do not match

• Check that nothing else in your pipeline reads the header, such as a step that selects columns by name.

• Check that the folds and seeds are identical across runs.

• Read the weakest slice in the held-out report, which is where the model is least sure.

Design options compared

Two pipelines side by side

A header-dependent pipeline and a name-independent one differ in how many steps sit between the raw table and a prediction.

Header-dependent pipeline
  raw table
    -> read headers
    -> map headers to a data dictionary
    -> choose encoders by column meaning
    -> drop or rename columns by hand
    -> train or fit a model
    -> predict

Name-independent pipeline
  raw table
    -> model reads the cells
    -> predict

The second pipeline is shorter because the steps that depend on names are simply absent.

What the model reads and what it does not

It reads:

• Values.

• Types.

• Positions, as grouping and not as labels.

• Explicit missing markers.

• Relations between columns.

• Labelled rows in context.

It does not read:

• Column names.

• Data dictionaries.

• Table descriptions.

• The model notes.

• Any text about the table.

Common misreadings

"The model ignores meaning"

It ignores the label of a column and not what the column means. The meaning is recovered from values and relations.

"Names never help any model"

They help models that were built to use them.

"A flat line means the model is perfect"

A flat line means the header is not part of the input. The accuracy level itself is a separate question, answered by the other boards.

"Twenty datasets proves it for all tables"

It is a measurement on a bounded sample under a stated protocol. The claim is limited to what was measured.

"A name-blind model needs no humans"

It needs no human to rename or document columns. A person still decides what to predict and whether to act on a result.

"Fine-tuning on masked headers gives the same thing"

It narrows the gap for a name-reading model, but the architecture keeps a path for names to enter. Here there is no such path, so there is nothing for a later training run to quietly re-open.

A checklist before trusting a name-blind result

• Did the three naming conditions use the same folds and seeds?

• Was one configuration used for all of them?

• Was any win inside seed noise dropped?

• Does any step in the pipeline read the header?

• Are low-confidence column roles reviewed?

• Are ordered codes and units checked where they matter?

• Was contamination checked against the training corpus?

Where to read next

• Metadata independence benchmark for the protocol and the work in order.

• Architecture and Cell encoding for the design.

• Limitations for what the model does not do.

• Benchmarks for all the boards.

Fact sheet

Terms used on this page

• Column embedding. A learned vector that tells a network which column a cell belongs to. Here it is zeroed.

• Metadata. Information about the data rather than the data itself: names, types, descriptions.

• Position. A grouping signal that marks which row and column a cell belongs to, without naming them.

• Support set. The labelled rows the model reads as context for a prediction.

• Latent vectors. A small fixed set of vectors that read the whole table and write back to the cells.

• Seed. The starting number of a random process, fixed so a run can be repeated.

• Source selection. Choosing the best of several variants per dataset after seeing the results.

• Contamination. When test data has leaked into training data.

Quick answers

• Does the model need headers? No.

• Does it need a data dictionary? No.

• Can wrong names mislead it? No, it never sees them.

• Does it always win? No, a rival leads by a few thousandths on pure numeric classics.

• Does column order matter? No.

• Where are the scores? In the model card, with their protocols.

Frequently asked questions

What does column name independence mean?

It means the model's output does not depend on column names or other descriptions of the table. The encoder builds each cell vector from the value, the type and the position, and the part that would identify the column is always zero. Rename the columns to random text, or remove the header row, and the model receives the same input.

How can a model know what a column is without its name?

From the values and their relations. Phone numbers have a fixed length and few repeats, birth years sit in a narrow band, prices are skewed, and some columns move together. Alternating attention over rows and columns lets each cell compare itself with its neighbours, and a set of latent vectors gives it a view of the whole table.

Does the model lose accuracy when headers disappear?

No. In my comparison it was the only model whose accuracy does not fall when names are removed or replaced with noise, while models that read headers lose roughly seven AUC points. The test used twenty numerical classification datasets in three naming conditions.

Why is it a design feature and not a patch?

Because the column identity part of the encoder is always zeroed, in pre-training and at use. The model cannot lean on a name even if it wanted to, so it must learn roles from values. Training a name-reading model on hidden headers narrows the gap but leaves a path for names to enter.

Does that make the model better than every rival?

No. My wins are concentrated on datasets where the relations between columns carry the signal a name would have supplied. On pure numeric classics without semantics, a stronger prior-based rival still leads, usually by a few thousandths.

Can misleading column names fool the model?

No, because it never receives them. A column called value that is really a date is judged on its values. This is a real advantage with old or migrated systems where names drift from content.

Does it mean I never need a data dictionary?

You do not need one for the model to work. A dictionary still helps people read the output, and it helps where the meaning of a code is a business rule that values alone cannot show.

When does being name-blind hurt?

When a name is the only clue: two columns with identical value shapes, coded categories whose order matters, ambiguous units, or tiny tables with little context. The model may report these as lower confidence.

Does name independence also apply to schema matching?

Yes. The model aligns columns across tables by content and beats every name-aware matcher on the scenarios I tested while running name-blind. The matcher's scorer includes a name channel as one of three, separate from the encoder, and the benchmark claim is made name-blind.

Summary

Column name independence is a design decision with a measured payoff. The model zeroes column identity in its encoder from the first day of pre-training, so it reads values, types, positions and the relations between columns and nothing else. The three naming conditions on the benchmark are the same input for it, which is why its accuracy stays flat while header readers lose roughly seven AUC points.

The same decision supports blind sector identification, name-blind schema and entity matching, imputation, anomaly detection and a width-free adapter for continual learning. Read the protocol in Metadata independence benchmark, the design in Architecture, and the limits in Limitations.