ClueLabs

In this short document, you’ll learn how ClueLabs finds gaps in frontier models, sources the data needed to close them, and proves which datasets improve model performance—helping labs deploy new models faster and at a lower cost.

Our thesis

A common AI data pipeline starts with the data.

A team sources or creates a dataset.

The data is cleaned and labeled.

The model is trained.

Then the team runs evals to see what changed.

This process leaves one costly choice at the start:

Which data should the team buy or build first?

A team can know that it needs better finance data, code, legal work, or science tasks.

That still does not tell the team which type of data will produce the largest improvement gain.

Money gets spent before the value of that data is known.

And this oftentimes, creates waste.

Waste in capital, time, and model efficiency.

In the LESS study, models trained on a selected 5% of the available instruction data often beat models trained on the full dataset for target tasks.

DataComp-LM found that stronger data filtering improved MMLU by 6.6 points while using 40% less compute than a prior open-data model.

So while the amount of data matters, the quality of data matters more.

ClueLabs focuses on acquiring high quality training data to improve models.

We do this by moving measurement of data to the front of the acquisition process.

We identify a model gap and create a data spec
We acquire data to fit the spec
Training tests show which data creates the strongest improvement gain.
Those results guide the next data purchase.

This creates a data pipeline driven by model performance.

The ClueLabs pipeline

ClueLabs begins with an eval.

We establish an eval and baseline first, make changes to the model or training data, run the eval again, then use the results to improve the next training set.

Assume Model X is being tested on finance work.

The eval shows:

Accounting: 91%

Valuation: 86%

Financial modeling: 82%

Distressed debt: 54%

The 54% score gives us a target.

Domain experts review the failed tasks.

They find that the model understands debt and financial statements.

The main break appears when the model has to reason through complex talks between creditors during a restructuring.

That finding becomes the data spec.

Instead of buying broad “finance data,” ClueLabs can search for records tied to the exact skill.

The spec may call for past restructuring files, creditor talks, investment memos, risk work, deal choices, and later outcomes.

Our acquisition team then finds firms that own this data and secures the rights needed for the approved use.

The model gap decides the source.

Some gaps call for existing enterprise records.

Others need new work created by experts.

Many need a mix of both.

The source is chosen after the skill gap is clear.

The expert layer

Experts enter the ClueLabs pipeline in two places.

The first is the eval.

A good benchmark needs tasks that reflect real work and clear rules for grading the output.

For a distressed debt gap, people with real experience in that field help define the tasks and scoring rules.

They also review failed model answers to find the cause of the break.

The second expert role begins after data is acquired and cleaned.

Raw company data can contain strong knowledge without being ready for training.

An expert can find the parts that matter, link the source files, mark the real outcome, label the skill, and review the quality of the work.

A real case can then become a training task with a clear input, goal, answer, outcome, and scoring guide.

Experts can also create new training data around gaps that remain.

This can include reference answers, preference data, hard cases, grading rules, and RL tasks.

Experts make the data easier to train on.

The held-out eval measures whether that work made the model better.

That difference is important.

An expert can say that a record is correct, rare, or useful.

Only a model test can show whether that record helps move the target score.

Proving the data works

Once the data is ready, ClueLabs runs controlled training tests.

The original eval stays separate from the training set.

This prevents the model from learning the test itself.

Assume the starting score was:

Base Model X: 54%

We then test different data packs.

These numbers are an example.

Keep the benchmark held out.

Keep the training setup as steady as possible.

Change the data.

Run the model again.

Then measure the change.

For larger tests, the data can be split by source, record type, skill, date, or expert label.

This lets us see where the gain came from.

The result may show that generic restructuring files add little value while cases that include creditor talks and final outcomes create a much larger gain.

That finding goes back to the acquisition team.

The next buy can focus on records with those traits.

Data that adds little value gets less budget.

Data tied to a strong gain gets more attention.

This is also why the ClueLabs model is different from simply buying rare data and calling it valuable.

The model helps price the value of the data.

Research on targeted data selection supports this approach. LESS found that a small, selected training set can beat the full set on target skills, while DataComp-LM showed that better filtering can improve quality while cutting training compute.

The ClueLabs position

Experts, evals, training data, and post-training are already part of the frontier AI data market.

Scale offers all of these pieces through its Data Engine. Mercor now offers expert datasets, benchmarks, failure analysis, post-training work, and enterprise data licensing. micro1 also sells expert human data, training environments, and model eval tools.

So those pieces alone are not the ClueLabs position.

The part we make central is the link between model failure and data acquisition.

A failed eval becomes a buying spec.

That spec drives the search for new proprietary data.

Controlled training then shows which source produced the strongest improvement gain.

The gain becomes the signal for the next acquisition.

In simple terms:

ClueLabs turns model failure into a data buying signal.

And the package you receive is: Audited data ready for model improvement.

This also changes the role of our acquisition engine.

We are not searching for data first and finding a use for it later.

A measured need already exists before the search begins.

A score of 54% on distressed debt leads to a clear search for data tied to that failure.

A later score of 72% tells us which data worked.

The remaining 28% shows us where to look next.

What the lab receives

A ClueLabs package is built around a defined model gap.

For a finance project, the lab can receive the licensed source data, cleaned records, expert labels, training tasks, reference answers, scoring rules, and a held-out eval.

The package also includes the test record.

It shows the starting model score, the training setup, the data used in each run, and the score after each change.

This lets the lab see the link between the data and the target skill.

The lab can review the source, test samples, and run the same framework inside its own stack.

The next model version then creates new information.

The ClueLabs flywheel

The full system is:

Measure the model gap → write the data spec → acquire the right data → clean and prepare it → add expert knowledge → build the training set → run controlled training → re-test on the held-out eval → measure which data worked → use that result to guide the next acquisition.

Then the cycle starts again.

This gives frontier labs a clearer reason for every new data purchase.

It also turns data sourcing from a supply-driven process into a model-driven one.