One checkpoint, then compression: packaging a whole benchmark result

A benchmark result counts only if a single model can reproduce all of it. This step checks that all of the capabilities live in one object, and that compressing that object does not change them. For the tabular foundation model described here, the answer is one unified checkpoint of about 2.18 billion parameters, with the code embedded.

This page explains why packaging is part of the evidence, how I merged the pieces, how I tested the merged model, how compression was measured, how the contamination audit worked, what made the difference, and what stayed open. Scores are left out on purpose. The model card carries them with their protocols. For all boards, see Benchmarks.

The short version

• The core and every head and adapter were merged into one unified checkpoint of about 2.18 billion parameters, with the code embedded.
• One line of bootstrap gives access to every capability.
• The merged model was tested in isolation.
• The model was then dumped at half precision, 8-bit and 4-bit, and fidelity was measured with TurboQuant.
• The model card was published on 7 August 2026, after a contamination audit of the evaluation sets against the training corpus.
• The audit used an identifier blocklist and a distributional near-duplicate check.
• The numbers come from one sealed configuration per benchmark, run on the same model that serves requests.

Why packaging belongs on a benchmark page

Imagine a car maker who wins a race with a hand-built prototype, then sells a different car to the public. The race result tells you about the prototype. It says nothing about the car you can buy.

Benchmarks can fail in the same way. A research model may win each board with a slightly different build: this head from one experiment, that adapter from another, a patch that exists only on one machine. Each number is true in its own place, and no single object reproduces them all.

The remedy is to ask whether one model can do everything claimed. This page is about that check.

What the check rules out

• Special builds. A head that works only in a special build cannot sneak into a claim.
• Lost pieces. An adapter that was never preserved cannot underwrite a result.
• Hidden glue. Code that lives only in a notebook is not part of the model.
• Drift between research and serving. A benchmark number must come from the same model that serves requests.

What is inside the checkpoint

The model has a core and a set of heads and adapters on top of it. See Architecture for the full picture.

The core is more than 1.5 billion parameters. When every head and adapter is merged with the core into one checkpoint, the total is about 2.18 billion. The first model of this class had 140M parameters. See Research.

Capabilities in one object

Each capability corresponds to a board on this site.

How I merged it

I merged the core and every head and adapter into one unified checkpoint, with the code embedded. Embedding the code is the detail that makes it usable. A file of weights alone is a pile of numbers. The code says how to wire them.

One line of bootstrap

With the code inside the checkpoint, one line of bootstrap gives access to every capability. There is no separate repository to match, no matching version of a helper script, no list of steps.

# Illustrative shape only, not a specific API.
model = load_checkpoint("unified")     # one line of bootstrap
model.sector(table)
model.impute(table)
model.predict(table, target="label")
model.match(table_a, table_b)

The snippet shows the idea: one object, many capabilities. See Capabilities for what each returns.

Why a merge can go wrong

Merging is not just stacking files. Pieces that were trained and sealed at different times can disagree about names, shapes or versions.

• A head may expect a layer under one name, and the core may call it another.
• An adapter may have been sealed against an earlier body.
• A fine-tune of the last blocks, such as the delta for sector identification, changes weights that other heads also read.

Each of these has to be checked, not assumed.

The lesson from a missing adapter

On the matching board, a checkpoint that was not preserved at the time of sealing taught me to copy every sealed adapter at the moment of sealing. That rule is part of why the merge is possible at all. See Entity and schema matching.

Testing the merged model in isolation

The merged model was tested in isolation. That phrase has a precise meaning.

• The model is loaded on its own, from the single checkpoint.
• No code from research folders is on the path.
• No separately stored adapters are patched in.
• The capabilities are exercised through the same entry points a user would use.

An everyday analogy: after you pack a suitcase, you do not trust the list in your head. You open the suitcase in a clean room and check that everything on the list is inside.

What a pass means

If the merged model reproduces each capability without help from outside, then the benchmark numbers are not artifacts of a special build. A head that works only in a special build cannot sneak into a claim.

Two benefits

1. A benchmark number is not a separate research artifact. It comes from the same model that serves requests.
2. The claim cannot rest on a special build. Everything claimed lives in the object that was tested.

Compression

Once the model is whole, the next question is size. A model of about 2.18 billion parameters is large to store and to serve. Compression reduces the size of the weights for efficient serving with minimal loss of accuracy.

What I did

I dumped the model at half precision, 8-bit and 4-bit, and measured fidelity with TurboQuant. See TurboQuant and Compression and serving.

Post-training quantization

This is post-training quantization. The model is trained once, in high precision, and its weights are rounded to fewer bits afterwards. It is the right fit for a model that is trained once and served many times.

An everyday analogy: a photograph saved at lower quality takes less space. A little detail is lost, and for most uses nobody notices. The question is how much is lost, and whether it matters for the job.

Why fidelity must be measured

The risk is that rounding adds error. Error in a weight can compound through layers. So fidelity is measured against the full-precision model on the real tasks, not assumed.

• The reference is the model before compression.
• The test is the real tasks, the ones on the boards.
• The question is whether the compressed model changes its answers where it matters.

Related methods

Other quantization methods exist, such as GPTQ and SmoothQuant. They differ in how they choose the rounding. The measurement I used was TurboQuant.

The contamination audit

A model trained on millions of tables might have seen a benchmark table. If it had, the score would flatter it. So each run is checked for contamination against the training corpus, and the model card was published on 7 August 2026 only after the audit.

The two checks

1. An identifier blocklist. Known benchmark dataset identifiers are excluded from training.
2. A distributional near-duplicate check. Tables that are close to a benchmark table in their statistics are flagged, even if they carry another name.

Why two checks

A blocklist catches tables by name. It misses a copy under a new name. The near-duplicate check catches tables by their statistics. It can flag a look-alike that is not a copy. Each covers the other's blind spot.

Related practice

The tables used to train the sector delta are excluded from the sector test set, and the test set was frozen. See Blind sector identification. For deduplication as a general idea, see Deduplication. For the wider discipline, see Pre-training.

Timeline

The packaging work took place over four days.

What made the difference

• One object. Everything claimed lives in one checkpoint.
• Embedded code. One line of bootstrap gives access to every capability.
• Testing in isolation. No outside help.
• Fidelity measured, not assumed. Half, 8-bit and 4-bit compared with the full model.
• A contamination audit before release. Blocklist and near-duplicate check.
• One sealed configuration per benchmark. Run on the same model that serves requests.

Why this is a result and not paperwork

Packaging sounds dull. It is the step that turns a collection of experiments into a product you can use. It also protects you as a reader. A claim that cannot be reproduced from one object is a claim you cannot check.

What stayed open

• Size. About 2.18 billion parameters is large. Compression helps, and fidelity must be watched at lower precision.
• Fidelity is task-specific. A compressed model that is faithful on one task may drift on another, so fidelity is measured on the real tasks.
• One checkpoint is a snapshot. A new head or a new adapter means a new merge and a new test in isolation. See Continual learning.
• Some ceilings remain. Regression and multiclass boards stay behind the leaders. See Row-level prediction.

Why I do not claim a free lunch

Compression gives smaller files and faster serving. It can also change answers. I measure the change and report it with the model card. I do not claim that every precision is as good as the full one for every task.

Protocol

• The core and every head and adapter merged into one unified checkpoint of about 2.18 billion parameters, with the code embedded.
• The merged model tested in isolation.
• Dumps at half, 8-bit and 4-bit precision, with fidelity measured with TurboQuant.
• A contamination audit of the evaluation sets against the training corpus, using an identifier blocklist and a distributional near-duplicate check.
• The model card published on 7 August 2026, after the audit.
• One sealed configuration per benchmark, with no per-dataset tuning.
• Competitor figures are third-party published values cited to their primary source, not re-run by me.
• Results under different datasets, metrics or masking schemes are never blended into one number.

See Evaluation for what a score claims.

Walking through a release checklist

The list below is the logic of the step, written as a checklist.

1. Every head and adapter that a claim depends on is sealed and copied.
2. The core and the pieces are merged into one checkpoint.
3. The code is embedded in the checkpoint.
4. One line of bootstrap loads the model.
5. Each capability is exercised on its own board's entry point.
6. The merged model passes in isolation.
7. Compression dumps are made at half, 8-bit and 4-bit.
8. Fidelity is measured against the full model on the real tasks.
9. The evaluation sets are audited for contamination.
10. The model card is published, with its protocols.

Why serving matters

A model that is trained once is meant to be served many times. That changes what to optimize.

• Storage. Lower precision means smaller files.
• Memory. Smaller weights fit on smaller machines.
• Speed. Fewer bits to move can mean faster answers.
• Consistency. One checkpoint means every request meets the same model.

See Compression and serving for the serving side.

Consistency for the reader

If the model on the benchmark is the model in production, the numbers on the model card describe what you get. This is the practical value of the step.

Lessons from this step

• Ask whether one object reproduces all the claims.
• Seal and copy each piece at the moment of sealing.
• Embed the code with the weights.
• Test the merged model with nothing around it.
• Measure fidelity on the real tasks.
• Audit contamination before you publish.
• Keep the benchmark model and the serving model the same.

Fact sheet

The result in six lines

• One object holds every capability.
• It was tested alone.
• It was compressed at three precisions.
• Fidelity was measured, not assumed.
• Contamination was audited before release.
• Benchmark and serving use the same model.

Common misreadings

"Merging means averaging models"

It does not. It means combining the core with its heads and adapters into one checkpoint, so each capability keeps its own parts.

"A smaller file is always as good"

Fidelity is measured on the real tasks at each precision. A smaller file is useful only where that measurement shows the answers hold.

"The audit proves no overlap"

It lowers the risk and catches known cases with two different checks. It does not claim to prove the absence of every possible overlap.

"Embedded code means a closed black box"

It means the checkpoint is self-contained. The model is documented on this site, and its protocols are in the model card.

"One checkpoint means one task"

It means many tasks in one object. The nine capabilities in the table above share it.

Do and do not

Do:

• Package everything that a claim depends on.
• Test the package with nothing else on the path.
• Measure compression on the tasks that matter.
• Audit contamination before publishing.

Do not:

• Report a number from a build that does not ship.
• Rely on a head that exists only in a special build.
• Assume compression is free.
• Publish before the audit.

Questions to ask about any model release

• Does one object reproduce every benchmark claim?
• Is the code part of the object, or kept elsewhere?
• Was the object tested on its own?
• How was compression measured, and on which tasks?
• What checks were run for contamination, and before what date?
• Is the benchmark model the serving model?

How this connects to the rest of the model

• Architecture. The parts being merged. See Architecture.
• Pre-training. The training that produced them, and the audit that precedes release. See Pre-training.
• Capabilities. What the merged model returns. See Capabilities.
• Evaluation. What a score claims. See Evaluation.
• Limitations. What the model does not do. See Limitations.

The work in order

A walk through the isolation test

The steps below describe the logic, not a specific tool.

1. Start a clean environment with only the checkpoint.
2. Load the model with the one line of bootstrap.
3. Ask for the sector of a table with no names. This exercises the semantic head.
4. Hide some cells and ask for a fill. This exercises the imputation network.
5. Give labelled rows and ask for a prediction. This exercises the prediction head.
6. Give two tables and ask for a column alignment. This exercises the cross-table head.
7. Add a new task and check that earlier tasks are retained. This exercises the adapters.

If every step works with nothing else on the path, the checkpoint is self-contained.

What each precision is for

The table gives the general trade-off. The measured fidelity is carried with the model card.

The trade in one sentence

You give up some bits for space and speed, and you check on the real tasks that you did not give up too much.

Three habits behind the step

Seal, then copy

A sealed piece is copied at once. This turns a lost checkpoint from a disaster into a non-event.

Test the package, not the parts

Each part may work alone and still fail together. The isolation test checks the package.

Audit before you publish

An audit after publication is damage control. An audit before it is quality control.

The result in short

• One checkpoint holds every capability.
• The code travels with the weights.
• The merged model was tested alone.
• Compression was measured at three precisions.
• Contamination was checked in two ways.
• The model card came after the audit.

What a reader can take away

• Every claim on this site can be traced to one object.
• Benchmark and serving use the same model.
• Compression is measured, not assumed.
• Packaging is part of the evidence.

Where to read next

• Architecture for the parts that were merged.
• Compression and serving for the serving side.
• Pre-training for the training and the contamination checks.
• Benchmarks for the whole timeline.

The standing rules, restated

• Competitor figures are never re-run by me.
• They are cited to their primary source.
• My figures come from one sealed configuration per benchmark.
• There is no per-dataset tuning.
• Different datasets, metrics or masking schemes are never blended.
• Each run is checked for contamination.

Quick answers

• Is there one file? Yes, one unified checkpoint.
• Is the code inside? Yes.
• How do I load it? One line of bootstrap.
• Is compression available? Yes, at half, 8-bit and 4-bit.
• Was it audited? Yes, before the model card.
• Where are the scores? In the model card, with their protocols.

What the page did not claim

• It did not claim that compression is free.
• It did not claim that the audit proves the absence of every overlap.
• It did not claim that a merged model never needs re-testing.
• It did not claim fidelity numbers; those sit in the model card.
• It did not claim that size is no concern.
• It did not claim that one checkpoint removes every ceiling on the other boards.

The pieces and where they were built

Terms used on this page

• Checkpoint. A saved copy of a model's weights, here with its code.
• Head. A small module on top of the shared representation that produces one kind of output.
• Adapter. A small trained module added to a shared body. See Adapters.
• Bootstrap. The line of code that loads the model.
• Quantization. Storing weights with fewer bits.
• Fidelity. How closely a compressed model matches the full model on real tasks.
• Contamination. When test data has leaked into training data.
• Near-duplicate. A table very close to another in its statistics, even under a different name.

Frequently asked questions

What is the unified checkpoint?

It is one saved model that merges the core and every head and adapter, with the code embedded. It has about 2.18 billion parameters, and one line of bootstrap gives access to every capability.

Why merge everything into one checkpoint?

A result counts only if a single model can reproduce all of it. A benchmark number then comes from the same model that serves requests, and a head that works only in a special build cannot sneak into a claim.

How big is the model?

The core is more than 1.5 billion parameters. Merged with every head and adapter, the total is about 2.18 billion. The first model of this class had 140M parameters.

What does testing in isolation mean?

The merged model was loaded on its own from the single checkpoint, with nothing from research folders on the path and no separately stored adapters patched in. Each capability was exercised through its normal entry point.

How was the model compressed?

I dumped it at half precision, 8-bit and 4-bit. These are post-training quantization levels: the weights are trained in higher precision and stored with fewer bits afterwards. Fidelity was measured with TurboQuant.

How much smaller is 4-bit?

A 4-bit weight takes a quarter of the space of a 16-bit one. The saving in the file is real, and fidelity must be checked on the real tasks to see what, if anything, is lost.

What was the contamination audit?

An audit of the evaluation sets against the training corpus, using an identifier blocklist and a distributional near-duplicate check. The blocklist catches known benchmark identifiers, and the near-duplicate check catches tables that are close in their statistics under another name.

When was the model card published?

On 7 August 2026, after the contamination audit. The packaging work ran from 4 to 7 August 2026.

Are the benchmark numbers from a special build?

No. They come from one sealed configuration per benchmark, run on the same model that serves requests. That is the reason for the merge and the isolation test.

Does compression change the answers?

It can. That is why fidelity is measured against the full-precision model on the real tasks, and why I do not claim that every precision is equal for every task.

Summary

The last step on the timeline checks that the whole result lives in one object. The core and every head and adapter were merged into one unified checkpoint of about 2.18 billion parameters, with the code embedded, so one line of bootstrap gives access to every capability. The merged model was tested in isolation, so no special build can underwrite a claim.

The model was then dumped at half, 8-bit and 4-bit precision, and fidelity was measured with TurboQuant. A contamination audit using an identifier blocklist and a distributional near-duplicate check came before the model card of 7 August 2026. Read next: Architecture, Compression and serving, Evaluation and Limitations.