More candidates than budget? Score them before you spend, and rank for the goal you actually have.

Every operations lead keeps the same list. Forty things that could be automated, a dozen leads worth a call, and the budget to act on three of them this quarter. "What should we automate first" is this question with the budget left out. The usual way to choose is to start with whatever is loudest and spread the rest evenly. A 2026 preprint on AI for mathematics gives a better procedure, and it has nothing to do with mathematics. It is about what to do when you have far more candidates than attempts, and how to pick the ranking that matches what you actually want out of the round.

The result, stated plainly.

When you have more candidate tasks than budget, spend a little effort scoring every candidate before you spend real effort on any of them, then rank for the goal you have. In the preprint, an AI asked to rate each candidate problem's difficulty and importance before any work was done produced scores predictive enough to beat spreading the attempts evenly. And the ranking that worked depended on the objective: to get the most results, rank the whole pool by odds of success; to get the single most important result, first keep only the most important few, then rank those by odds. Ranking the whole pool one way does not serve both goals.

Most AI-for-mathematics systems take a problem a human chose, attempt it, and return something the human checks. The preprint moves the human's input one level up. Instead of a problem, the human gives a direction (a branch of mathematics), and the system does the rest in three stages, each narrower and more expensive per item than the last. Find: read the literature in that direction and extract every statement that looks open. Attempt: give each one exactly one try with the strongest model. Recommend: have independent judges check what came back, and pass a short list to the expert.[1] The scarce resources, which the whole design exists to protect, are the strong model's attempts and, above all, the expert's reading time.

In the pilot, that shape ran from a corpus of about 51,000 mathematics papers down to a pool of some 4,700 open statements, one attempt each, and ended with 77 results the system called publishable. The authors read 15 of those, chosen by their own interest, and found no error in any.[1] Those are that run's counts, not a yield you can expect from another corpus, and the authors are the first to say that one of the 77 had already been settled by a route none of their searches found. What we take from the pilot is its shape, and its allocation analysis.

More candidates than budget is the normal condition.

Take a Quebec distributor. The operations lead ran a half-day workshop and came out with twelve candidate automations, from matching supplier invoices to helping with an ERP migration. The team can build three this quarter. Nine will wait, and the question is which nine. Every operations list, sales pipeline and audit backlog sits in the same condition. The only decision available is the order.

Two things about this shape matter. The first stage should be permissive: in the preprint, extraction keeps anything that might be an open problem, because a candidate dropped here can never be recovered, while a spurious one is cheap to drop later.[1] The workshop list should work the same way. Write everything down; filter nothing yet. The second is that the stages get more expensive per item as they narrow. A rough score costs minutes, a build costs weeks, and the owner's review costs an hour they do not have. The design puts the cheap, broad step first so the expensive, narrow steps only ever see what deserves them.

A rough score, before any work, is a usable signal.

The part of the preprint that transfers most directly is almost a side remark. During the checking stage, before any attempt was made, the model recorded two numbers for each candidate: a difficulty and an importance, each on a scale from zero to one. Nobody had solved anything yet; these were guesses from a model that had read the statement and its source paper. When the authors later compared those guesses to what the run actually produced, the guesses were predictive. Difficulty separated the attempts that came back with an accepted result from the ones that did not, and it kept doing so among candidates the model had rated equally important.[1] In the authors' words, "simply asking an agent in our pipeline to output difficulty and importance scores before any reasoning is spent yields scores that can be used effectively within the allocation strategies."

A pre-score is two numbers and a sentence per candidate, the odds it works and what it is worth if it does, recorded before any work starts. You do not need a precise estimate of whether an automation will work or a lead will close. You need a rough one, for every candidate, before you commit real effort to any of them. The preprint is the best evidence we have that an AI reading a candidate's description can produce a score worth sorting by; whether it does on your list is what the first slice of attempts tells you. Ask for a sentence of reasoning with each score, so a person can spot a guess that is plainly wrong. Minutes per candidate, and the whole list scored in an afternoon.

A score is a cheap stage in front of an expensive one, and our previous note argued that such stages are not automatically cheaper. Applied to an operations list, this one should pass that note's three questions, and the first slice of attempts is where you check. In the preprint it was right often enough to beat spreading effort evenly, which is the only accuracy that matters for a ranking. When it is wrong, the cost is bounded: a weak candidate gets attempted, which is what spreading effort evenly would have done anyway. And nothing starts cold, because the score does not replace the attempt or get re-done by it; it only decides the order.

There is no single best ranking.

The second finding is the one most operators have never been told. Once you have scores, the obvious move is to sort by them and work down the list. The preprint tried that, with three different definitions of success, and the best sorting was not the same for each. To get the most accepted results from a fixed number of attempts, ranking the whole pool by estimated odds of success worked best at every budget. To get the single most important result, ranking the whole pool did badly, and at the larger budgets both rankings fell behind picking at random. What worked was to discard all but the most important fraction of the pool and rank only those by odds. The authors' conclusion: "the best strategy can depend on the objective that the mathematician is optimizing for."[1]

The reason is plain. The most important candidates are usually the hardest, so a ranking by odds of success fills the budget with sure things that do not matter much, and a single big win never gets an attempt. A ranking by importance alone fills it with long shots. Restricting first and ranking second is how you buy a real chance at the big one without spending the whole budget on lottery tickets. Here is the distributor's list with our illustrative scores, and the budget of three spent two ways.

The letters are the twelve candidates. Each sits at the odds the score gave it and the hours it saves a month if it works. A is the invoice matcher, near-certain and small. I is a rewrite of the dispatch sheet, one in three and worth sixty hours. L is the ERP migration, one in ten and worth the most. The slope is the point: the candidates worth the most are the ones least likely to work on the first build, which is exactly what the preprint found in its own pool, where important and hard were almost the same thing. Add the third objective, the most hours saved in total, and all three rankings pick a different three.

The table is a conversation to have before the quarter starts. The first row ships three things and almost certainly ships all three; the owner sees a program that works. The last row has a one-in-three chance of landing the dispatch rewrite and a one-in-ten chance of landing the ERP work, and a fair chance of shipping nothing at all this quarter. Both are defensible. What is not defensible is running the first ranking while the owner is expecting the third, which is the default outcome when nobody writes the goal down before sorting the list.

Three questions before you rank.

Before a backlog is sorted, a pipeline is worked, or an AI is told which items to try first: the same three questions, in this order. The flow below is ours, drawn from the preprint's allocation analysis.

The same three questions, with what each wrong answer costs:

1. What is the goal of this round? Most wins, most total value, or one big win. These are different rankings, and they pick different candidates from the same list. A round with no stated goal gets sorted by whoever is loudest, which is a fourth ranking nobody chose.
2. Does every candidate have a rough score, before any work? Two numbers and a sentence, for all of them, not just the favourites. A score taken after work has started is a justification, not a signal.
3. Who reviews the survivors, and how many can they read? The review is the narrowest stage and the one with a hard ceiling. If the owner can read two things this quarter, attempting ten is waste dressed as ambition.

What to do this week.

1. Write the direction, not the task.

   "Everything that touches the shared inbox" is a direction. "Build the invoice matcher" is a candidate someone already picked. Give the system, or the workshop, the direction and let it produce the list.

2. List everything before you filter.

   A candidate left off the list can never be scored. A weak one costs a minute to drop. Err toward too many.

   target: one list, every candidate, no ranking yet
3. Score every candidate with two numbers and a sentence.

   Odds it works, value if it does, and why. Let an AI take the first pass from the candidate descriptions, then have one person skim for scores that are plainly wrong. Our note on pricing the question is the same move applied to a single decision; here it is applied to the whole list.

   target: the whole list scored in an afternoon, nothing built
4. Name the goal, then pick the ranking.

   Most wins: sort by odds. Most value: sort by odds × value. One big win: keep the top fraction by value, then sort by odds. Write the goal at the top of the list so the ranking can be checked against it later.

5. Attempt a slice, then re-rank.

   Spend a third of the budget on the top of the list, look at what came back, and re-score the rest with what you learned. The scores improve as the round runs; the ranking should too.

6. Protect the review.

   The person who decides reads only what survived the check. Our note on checking attempts covers what that check has to be; here, the point is that nothing reaches the owner that has not passed it.

What this does not claim.

A preprint, one lab, one domain, one run. The paper is a single-lab preprint, not peer reviewed, and its pilot is one run in one branch of mathematics with one chain of models. The allocation analysis was done afterwards on that run's outcomes, and the fractions that worked (the top tenth by importance, in their run) are specific to it. We cite the direction of the findings and the authors' own framing, not any figure as a rate.

Fifteen of 77, chosen by interest. The authors reviewed 15 of the 77 results the system called publishable, selected by what interested them, and found no error. That is not "77 correct results", and we do not treat it as one. The pipeline counts above describe that run's shape only.

Mathematics has a cleaner "success" than operations. A proof is accepted or it is not. An automation can work and still not be adopted; a lead can close small. The two-number score and the three rankings carry over; the crispness of the outcome does not, which is one more reason to treat the scores as rough and re-rank as the round runs.

Illustrative numbers. The distributor, the twelve candidates, their odds and their hours are ours, built to show how the rankings diverge. They are not a benchmark and not a client record. We do no mathematical discovery, and nothing here should be read as a claim that we do.

If you have a list of candidate automations and the budget for a few of them, send the list through the contact form as it stands, unranked, and tell us what the round has to prove. Scoring a backlog before anything is built is where our assistants and agents work usually starts.