Verification asymmetry.

Ask an operations lead which workflow to hand to an AI system first, and the answer is almost always the same: the one that costs the most to run today. That instinct is understandable, and it is wrong — not because the workflow doesn't matter, but because the number that predicts safe delegation isn't what the workflow costs. It's a different ratio entirely: what it costs to check an output against what it costs to produce it. Call that ratio verification asymmetry. Where checking is nearly free — a balance reconciles, a schema validates, a total foots — long automated chains are tractable even when individual steps are imperfect, because errors get caught before they compound. Where checking costs as much as doing the work in the first place, no amount of model capability changes the calculus, because the organization has no cheap way to know whether the output was right.

The portfolio gets built in the wrong order

The common portfolio-building instinct points in exactly the wrong direction. A firm looks at where its people spend the most expensive hours — drafting client communications, assembling a compliance memo, reasoning through a concentrated-position strategy — and reaches for AI there first, because that's where the visible cost sits. It's also where verification is hardest: judgment calls that reasonable experts would resolve differently, conclusions that can only be checked by redoing the analysis. The workflow that looks like the biggest win on a cost spreadsheet is often the one an organization is least equipped to trust, because trusting it requires the same expensive judgment the automation was supposed to remove.

Compare that to a workflow nobody would call impressive: reconciling a batch of new-account forms against a checklist of required fields and signatures. Automating it saves less money per hour than the compliance memo. But checking the output costs almost nothing — a missing signature is either there or it isn't — so a wrong output gets caught immediately, cheaply, and before it reaches a client or a regulator. The unglamorous workflow is safer to automate aggressively precisely because it's boring to verify. The glamorous one is dangerous to automate precisely because it's interesting to verify. Use-case selection driven by "what's expensive to do" instead of "what's cheap to check" produces impressive demos and unshippable systems. Selection driven by verification cost produces the reverse: unglamorous rollouts that actually ship, hold up, and compound.

Five classes of verification cost

The taxonomy underneath this is five verification cost classes, ordered by how a wrong output gets caught:

Capability benchmarks generally measure something adjacent to none of this. They measure whether a model can produce a good answer, not whether an organization can cheaply tell a good answer from a bad one once it's produced. Those are different questions, and the gap between them is where automation programs quietly fail — not because the model was wrong often enough to notice, but because nobody could tell how often it was wrong at all.

The same asymmetry, aimed at a different question

This is not a new observation about the world, and claiming otherwise would be the first thing a careful reader disproved. Jason Wei, in "Asymmetry of verification and verifier's rule" (July 15, 2025), sets out the underlying structure directly: some tasks are much easier to verify than to solve, and that gap is becoming one of the most consequential facts in AI. He states it as a rule — the ease of training AI to solve a task is proportional to how verifiable the task is, and all tasks that are possible to solve and easy to verify will be solved by AI. Wei also draws the distinction to the P = NP question, noting that his rule makes no claim about how long solving takes and extends past computational tasks entirely.

What is being added here is not the asymmetry. It's the question the asymmetry is aimed at. Wei's rule is a claim about training: which tasks AI labs will be able to build systems that solve, because verifiability is what makes a reinforcement-learning environment possible. This essay makes a claim about deployment: which tasks a particular institution can safely hand over, because verifiability is also what makes an internal control possible. Those are different verifiers. Wei's is a research team constructing a reward signal. Ours is a compliance officer at 4pm on a Friday, deciding whether to sign something.

The distinction matters because the two claims have a shared consequence that neither states alone. If Wei is right that easy-to-verify tasks are the ones AI will conquer, and the argument here is right that easy-to-verify tasks are also the ones an institution can safely delegate, then capability and deployability advance together rather than in tension. The anxious enterprise question — what happens when models get good enough at judgment work to take it over — has a less dramatic answer than it sounds: the tasks where an organization cannot cheaply check the output are largely the same tasks where there is no clean training signal either. The frontier moves where verification is cheap, on both sides at once. That is our inference from Wei's reported claim, not his.

Wei makes one further point that this essay's later argument depends on, and it deserves attribution rather than rediscovery: verification cost is not fixed. It can be improved by front-loading work — an answer key for a math problem, a test suite with real coverage for a coding problem. LeetCode is that observation industrialized. Where a firm can build the equivalent for its own judgment-heavy work, it moves a workflow down the ladder without waiting for a better model. He is also candid that the asymmetry sometimes runs backward: fact-checking an essay can cost more than writing it, which is Brandolini's law wearing an engineering hat, and it is the honest name for what V4 feels like from the inside.

The strongest argument against everything above

The strongest objection is straightforward: isn't verification asymmetry just a capability problem in disguise? If the model gets good enough — reasons carefully enough, cites its sources precisely enough — won't V3 and V4 work eventually collapse toward V1, the way spell-checking collapsed from "have an editor read it" to "the software just knows"?

The objection deserves to be taken seriously, because it's half right. Model capability does change the probability that a given attempt succeeds. What it does not change is an organization's ability to tell, cheaply and reliably, whether this particular attempt was one of the successes. Those are orthogonal properties. A model can become dramatically better at drafting a defensible position on a concentrated-equity strategy without making it any cheaper to confirm that a specific draft is defensible — because confirming it still requires the same domain judgment that produced the draft in the first place. Verification cost is a property of the task's structure, not of the model attempting it. Proofreading moved from V3 toward V0 for spelling specifically, because someone built a mechanical check — a dictionary lookup — that didn't require re-deriving the answer from expertise. That is exactly Wei's front-loading move, and it is available to firms as engineering work. What is not available is a capability trend that manufactures such a check on its own for "is this the right strategic recommendation." Better models make V3 and V4 tasks easier to attempt. They do not make those tasks cheaper to check, and checking is the actual bottleneck.

There's a tempting shortcut here, and it deserves a direct answer: why not use a second model to check the first one's output, and drive verification cost toward zero that way? For V0–V1 work, that's often reasonable — a model flagging an obvious schema violation is just another mechanical check, no different in kind from a linter. For V3 and V4 work, it's a trap I'd call correlated grader risk. The concern is that a grader trained on data similar to, and with blind spots similar to, the system it's grading may fail in the same places, on the same inputs, at the same time — which means it can pass errors a human reviewer would have caught, invisible to both systems for the same underlying reason. Structural independence — a different model, a different context, an adversarial framing instructed to find the disagreement rather than confirm the draft — reduces the correlation, but it doesn't eliminate the deeper problem: whoever checks the checker still needs a way to verify that the check itself is any good, and that verification has a cost too. Adding a second AI step doesn't remove verification asymmetry. It moves the cost up one level and hopes nobody asks where it went.

There's a second reason capability alone can't rescue high-verification-cost workflows, and it's arithmetic rather than argument. A multi-step automated process has end-to-end reliability that decays geometrically with chain length: twenty steps at a genuinely strong 95% per-step reliability compound to 0.95²⁰ ≈ 36% — worse than a coin flip, from a model that would look excellent on any single-step benchmark. That arithmetic assumes step failures are independent, which real pipelines rarely are; correlated failures can push the number either direction. It's a bound to reason with, not a measurement. A practical way to interrupt that exponent is to stop the chain and check it before errors compound, which is exactly what verification does. But checking only helps if it's cheap enough to happen at every step that needs it. In a V0 workflow, that's free, so long chains survive. In a V3 workflow, checking every step costs as much as doing every step, so the exponent runs unchecked — and a capable model doesn't change that trade, it just makes each doomed step look more convincing on the way down.

Put a number on it

The two examples that follow are constructed, not observed. The step counts and rates are illustrative figures chosen because a reader can check them against their own operation; no client's data appears here, and neither example describes an engagement. The arithmetic is the point, and the arithmetic is reproducible.

Take a mid-size RIA's new-account intake: twelve steps from application receipt to funded account, at roughly fourteen minutes of staff time per file at $45/hour fully loaded — $10.50 per file. Most of that time is mechanical: field-matching, signature verification, cross-referencing a checklist. Verification cost here is V0–V1, because a missing field is binary and a mismatched name is binary. Note what the chain length would otherwise do: twelve steps at 95% per-step reliability compound to 0.95¹² ≈ 54%, so an unverified version of this workflow would produce a clean file barely half the time. It survives automation precisely because the checks are free — the exponent gets interrupted at every step at no cost. Automating the chain and spot-checking a sample runs perhaps ninety seconds of reviewer time per file at the same loaded rate: $1.13, or a bit under a tenth of the original. Cheap verification is not the whole test, and a risk officer reading this will already have the objection: several steps in that chain carry identity controls and, where a firm's own program requires it, anti-money-laundering review of every file rather than a sample. Verification cost tells you what review can cost. It does not tell you what a regulator or your own program requires it to cost — which is the second axis, and the next section.

Now take the same firm's quarterly client-suitability memo — the document that explains why a concentrated position or an illiquid allocation still fits a client's stated objectives. It costs an advisor perhaps ninety minutes to draft well, at a considerably higher loaded rate, so the visible savings from automating the draft look larger on paper than the intake workflow's. But checking that draft — confirming the reasoning holds, that no material fact was misapplied, that it would survive a compliance review or, worse, a client complaint — costs nearly the same ninety minutes, because there is no shortcut to re-deriving whether the judgment was sound. Verification cost is roughly 90–100% of generation cost: V3. Automate the draft, and the firm hasn't removed ninety minutes of work — it's added a drafting step in front of the ninety minutes of review that was always going to be necessary, and quietly encouraged the reviewer to trust the draft more than they'd trust a blank page. That's a worse system than the one it replaced, wearing a faster one's clothes.

The same ratio reframes a question firms usually ask backwards. Instead of "which vendor has the best benchmark score," ask what a vendor's system costs to verify, and who's paying that cost — the firm, or the vendor, priced into the contract. A vendor quoting an impressive capability number on a V3 task, with no proposed verification mechanism cheaper than redoing the work by hand, hasn't priced the actual product. They've priced the demo.

Rank by the ratio and the order inverts

Rank a firm's candidate workflows by this ratio instead of by hours saved, and the ordering can invert. The unglamorous processes — intake, reconciliation, document assembly, scheduling — rise to the top, because they're both real cost centers and cheap to verify. The workflows that generate the most enthusiasm in a planning meeting — anything requiring judgment a reasonable expert could contest — sink toward the bottom, not because they're unimportant, but because automating them first means shipping a system nobody can cheaply confirm is working.

Building that ranking in practice means scoring every candidate workflow on two axes at once — verification cost class and the risk class of getting it wrong — and plotting the resulting portfolio rather than reading down a single list. A V0 workflow with real financial exposure if it fails still deserves a real gate, even though checking it is nearly free; a V3 workflow with no downside beyond an internal record — an early draft nobody sees unedited — can absorb more risk than its verification cost alone would suggest. The two axes interact. What the plot produces isn't a single up-or-down verdict per workflow, but a specific claim about how much oversight each one needs and what kind: sampled review for the cheap-to-check items, exception-gated review for the moderate ones, and full pre-execution review — the system drafts, a person owns the decision, no exceptions — for anything landing in the expensive-to-verify, expensive-to-get-wrong corner. That corner is small on most portfolios. It is also, reliably, the corner every planning meeting wants to start in.

The kill list matters as much as the ranking. A portfolio review that only ever produces green lights isn't screening anything — it's a formality dressed as analysis. Marking a workflow "not yet, and here's specifically what would change that" is a harder sentence to write than "let's automate it," and it's the sentence that keeps the eventual rollout from becoming the cautionary case study everyone else learns from. The suitability-memo drafting from the example above isn't off the list forever; it's off the list until someone builds a cheaper way to check a strategic judgment than re-deriving it — a structured second-opinion protocol, a narrower sub-task that is itself V0 or V1, a compliance rubric detailed enough to turn part of the review mechanical. That is Wei's front-loading, applied to a suitability file instead of a coding problem: a real, buildable precondition, not a permanent no. Verification asymmetry doesn't argue against ambition. It argues for sequencing ambition behind the unglamorous problem of making checking cheap first.

That reordering is the actual deliverable. Not a longer list of things AI can technically attempt — every list is that list now — but a shorter one of things an organization can afford to be wrong about cheaply enough to find out. The firms that build durable automation programs aren't the ones with the most capable models. They're the ones that stopped asking what's expensive to do, and started asking what's cheap to check — and then had the discipline to build in that order, even when the boring workflow won't make anyone's quarterly update.

The observation this started from: No ringback — eighteen months inside a system that couldn't confirm whether its own work was happening.

Sources

• Jason Wei, "Asymmetry of verification and verifier's rule", July 15, 2025. Primary source read directly; not coverage of it.