# Verification Is the Bottleneck Date: 2026-07-05 Status: Working paper v0.2, full draft Track: VKR AI Research ## Abstract The value of AI systems increasingly depends less on whether they can generate a plausible answer and more on whether that answer can be verified cheaply, quickly, and at the right standard of rigor. Generation is becoming abundant. Verification is not. This paper argues that the next frontier in AI automation is evaluability: the degree to which a task has observable success criteria, cheap feedback, and a repeatable path from output to acceptance. Tasks become automatable earlier when they can be checked. They remain resistant when success depends on ambiguous judgment, missing facts, long-horizon context, institutional constraints, social trust, or expensive expert review. We propose a taxonomy of verification modes, a six-factor evaluability score, and a first VKR Verification Matrix for mapping work categories by automation readiness. The claim is not that model capability does not matter. It is that the rate at which model capability becomes economic value is governed by the cost, latency, and reliability of verification. The first publishable artifact should be a task evaluability scorecard across software, finance, law, research, operations, and support. The scorecard should make explicit what can be checked automatically, what requires expert review, what depends on delayed outcomes, and what remains institutionally hard to verify. ## One-Sentence Thesis As generation gets cheaper, the scarce resource becomes knowing which outputs are correct enough to use. ## 1. Motivation AI systems can now produce fluent work across code, writing, analysis, research, customer operations, legal reasoning, and planning. The practical question is no longer only whether a model can generate candidate work. It is whether the work can be accepted. Acceptance requires verification. A code patch must pass tests and review. A data extraction must match the source. A research claim must be supported by the cited evidence. A legal argument must identify the right issue, rule, application, and conclusion. A medical recommendation must be safe in context. A strategy memo must survive contact with facts, constraints, and incentives. The verification burden is uneven. Some tasks expose correctness quickly. Others hide correctness behind domain expertise, long timelines, social coordination, or downstream outcomes. This unevenness explains why AI automation arrives first in some categories and stalls in others even when the model appears broadly capable. The bottleneck is not intelligence in the abstract. The bottleneck is the price, latency, and reliability of knowing whether an AI-generated artifact is acceptable. ## 2. Evidence From the Current Benchmark Landscape Mechanize describes its work as building environments and evals for frontier coding agents. In these environments, models carry out software engineering work and graders score performance for reinforcement learning and evaluation.[^mechanize] This is a direct statement of the verification thesis: work becomes trainable and measurable when an environment can produce feedback. micro1 frames part of its work around expert human data, real-world training environments, and contextual evaluations.[^micro1] Its Realm legal reasoning benchmark decomposes legal work into issue spotting, rule identification, factual application, and conclusion, and emphasizes that polished writing can hide weak reasoning.[^micro1-realm] That is the verification problem in a high-skill domain: the answer can sound professional while the reasoning path is wrong. SWE-bench evaluates whether systems resolve real-world software issues, and SWE-bench Verified is a human-filtered subset of 500 instances.[^swebench] Software engineering is not easy, but it is unusually verifiable: code can compile, tests can run, patches can be inspected, and failures often produce observable traces. METR's time-horizon work measures AI capability by the human-expert task duration at which an AI agent is predicted to succeed with a given level of reliability.[^metr-time] Its task suite is largely composed of software engineering, machine learning, and cybersecurity tasks that are self-contained and have clear success criteria. METR also warns that most real jobs are not composed only of well-specified, algorithmic tasks and that holistic scoring can reduce measured performance. NIST's AI Risk Management Framework gives the governance version of the same point. It emphasizes test, evaluation, verification, and validation across the AI lifecycle, and says objective, repeatable, or scalable TEVV processes should be in place, followed, and documented after measurement.[^nist-rmf] Stanford's HELM project likewise frames evaluation as holistic and multi-metric, emphasizing broad coverage, transparency, standardization, and the incompleteness of any one benchmark.[^helm] Stanford HAI's 2026 AI Index reports rapid progress but also highlights measurement gaps and jagged capabilities.[^stanford] Taken together, these efforts point toward a common conclusion: AI systems are not deployed into abstract intelligence tests. They are deployed into tasks with verification surfaces. Where the surface is cheap and observable, automation accelerates. Where the surface is expensive or ambiguous, automation slows. ## Measurement Gap Most current evaluation work asks whether a model can complete a task under a specified benchmark protocol. That is necessary, but it does not fully answer whether the task can become reliable economic work. The missing layer is verification accounting. A benchmark score usually compresses three separate objects: 1. the model's ability to generate a candidate output; 2. the evaluator's ability to detect whether the output is acceptable; 3. the real-world cost of running that evaluator at deployment scale. These objects should be separated. A task can have high model performance and high verification cost. It can have low model performance but cheap verification, making retries viable. It can have a strong benchmark score but weak deployment validity if the benchmark checks only the easiest-to-measure part of the work. The verification thesis is therefore not an argument against benchmarks. It is an argument for reporting the verification surface alongside the score: what was checked, how it was checked, what it cost, what it missed, and who has the authority to accept the output. ## 3. The Verification Thesis AI automation requires three things: 1. A system that can produce candidate work. 2. A task environment that reveals whether the work is good. 3. A feedback loop that can improve or select among candidates. Most public discussion focuses on the first. The second and third often determine economic value. If an AI writes code and tests fail, verification is cheap. If an AI extracts a number from a table and the source is available, verification is cheap. If an AI writes a medical recommendation and the harm appears weeks later, verification is slow, expensive, and ethically constrained. If an AI writes a strategy memo and the claim sounds plausible, verification requires source audit, domain judgment, and an understanding of what missing evidence would change the conclusion. The same model can be highly useful in one task family and unsafe or uneconomical in another. The difference is often not generation quality alone. It is whether the work can be checked. ## 4. Key Definitions ### 4.1 Verification Verification is the process of determining whether an output satisfies stated acceptance criteria. It can be automatic, human, expert, outcome-based, or institutional. ### 4.2 Validation Validation asks whether the task, metric, or system is appropriate for its intended use. A model output can be verified against a rubric while the rubric itself fails to validate the real-world objective. ### 4.3 Evaluability Evaluability is the degree to which a task has observable facts, stable criteria, cheap feedback, and a repeatable path from output to acceptance. ### 4.4 Acceptance Acceptance is a decision that the output is good enough to use under the task's standard. Acceptance does not imply perfection. It implies that the output passed the declared threshold for the declared use. ### 4.5 Verification Cost Verification cost includes model-judge calls, test execution, human review, expert review, source audit, legal or compliance review, and downstream remediation caused by mistaken acceptance. ## 5. A Taxonomy of Verification ### 5.1 Deterministic Verification The output can be checked by exact rules. Examples: - JSON schema validation; - arithmetic consistency; - SQL query returns expected rows; - file compiles; - unit tests pass. These tasks are easiest to automate because feedback is cheap, fast, and machine-readable. ### 5.2 Test-Based Verification The output is checked by a test suite, simulator, or environment that approximates success. Examples: - coding benchmarks such as SWE-bench Verified; - terminal tasks with expected file-system state; - browser automation tasks with expected state changes; - game or robotics simulators; - transaction-processing workflows with replay tests. These tasks are powerful for training and selection, but they are vulnerable to test overfitting, coverage gaps, brittle proxies, and hidden assumptions. ### 5.3 Rubric-Based Verification The output is evaluated against explicit criteria. Examples: - legal memo scoring by issue, rule, application, and conclusion; - analyst report scoring by claim support and limitations; - customer-support response scoring by correctness, tone, and resolution; - research synthesis scoring by citation support and uncertainty handling. Rubrics make ambiguous tasks more measurable, but they inherit the quality of the rubric and the judge. A bad rubric can reward polished wrongness. ### 5.4 Expert Verification The output requires a domain expert to review. Examples: - clinical recommendations; - legal filings; - investment memos; - security vulnerability triage; - scientific interpretation; - safety-critical engineering decisions. Expert verification is expensive and may dominate generation cost. ### 5.5 Outcome Verification The output is judged by downstream results. Examples: - trading strategy performance; - conversion lift; - reduced support escalations; - patient outcomes; - litigation outcomes; - hiring quality. Outcome verification is economically meaningful but slow, noisy, and confounded. ### 5.6 Social or Institutional Verification The output must be accepted by humans, organizations, regulators, markets, or other institutions. Examples: - board materials; - regulatory filings; - grant applications; - hiring recommendations; - public communications; - policy decisions. Here correctness is necessary but insufficient. Legibility, trust, incentives, accountability, and authority matter. ## 6. Evaluability Score VKR should score task families on six dimensions. Each dimension can be rated from 1 to 5, where 1 means verification is expensive or ambiguous and 5 means verification is cheap and reliable. | Dimension | Question | Low Score | High Score | | --- | --- | --- | --- | | Observability | Can we see the relevant facts? | Hidden or delayed | Directly observable | | Feedback speed | How quickly do we know if it worked? | Weeks/months | Seconds/minutes | | Feedback cost | How expensive is checking? | Expert-heavy | Automated | | Criterion stability | Does "good" remain stable? | Context-dependent | Rule-like | | Error severity | What happens if the answer is wrong? | High-stakes | Reversible | | Decomposability | Can the task be split into checkable parts? | Holistic | Modular | The total score is not a universal automation index. It is a diagnostic. It tells researchers what kind of verification problem the task presents. ### 6.1 Example Scoring | Task | Observability | Speed | Cost | Stability | Error Severity | Decomposability | Interpretation | | --- | ---: | ---: | ---: | ---: | ---: | ---: | --- | | JSON extraction from known source | 5 | 5 | 5 | 5 | 4 | 5 | Strong automation candidate. | | Unit-tested code patch | 4 | 4 | 4 | 4 | 3 | 4 | Strong but depends on test coverage. | | Citation-grounded research memo | 3 | 3 | 3 | 3 | 3 | 3 | Useful with audit workflow. | | Legal litigation memo | 3 | 2 | 1 | 2 | 1 | 3 | Expert verification dominates. | | Strategy recommendation | 2 | 1 | 2 | 1 | 2 | 2 | Ambiguous and outcome-dependent. | | Medical treatment recommendation | 3 | 1 | 1 | 2 | 1 | 2 | High-stakes expert/outcome verification. | The purpose is not to rank professions. It is to identify where AI work can be checked cheaply enough to scale. ## 7. Why Software Engineering Moved First Software engineering is not easy. It is unusually verifiable relative to much knowledge work. It has: - executable artifacts; - tests; - compilers and linters; - version control; - issue descriptions; - logs; - reproducible environments; - automated review hooks; - large public corpora; - clear failure signals. That makes it a natural wedge for agent training and evaluation. Mechanize's focus on software-engineering environments and evals is therefore not an accident. Software offers a rare combination: valuable work, abundant data, observable artifacts, and cheap-enough feedback. SWE-bench and METR's software-heavy task suites reflect the same structural advantage. They are not merely examples of AI capability. They are examples of tasks where verification infrastructure exists. The same pattern explains why many other domains lag. Finance, law, medicine, strategy, sales, operations, and management all contain valuable work, but their success criteria are less observable, more delayed, more institutionally mediated, or more dependent on expert judgment. ## 8. The Polished-Wrong Problem Modern AI systems are strong at fluency. Fluency can make errors harder to detect. micro1's Realm legal benchmark makes this concrete. Legal reasoning tasks are scored through issue spotting, rule identification, factual application, and conclusion. The report argues that polished writing can mask weak reasoning and finds that models perform better on issue spotting than on rule selection and factual application.[^micro1-realm] This is a general failure mode: - In law, a model may identify the legal area but miss the controlling rule. - In finance, a model may produce a clean memo but rely on stale or mismatched data. - In research, a model may cite relevant literature but overstate what it proves. - In operations, a model may propose a plausible process that violates an internal constraint. - In medicine, a model may sound reassuring while missing a contraindication. The output looks like work. Verification determines whether it is work. ## 9. Long-Horizon Verification Long-horizon tasks create a second problem: the system must preserve and update state over time. micro1's legal benchmark reports performance fading on later deliverables in multi-stage tasks, with models struggling to revise earlier conclusions when new facts or contrary evidence appear.[^micro1-long] METR's time-horizon work similarly argues that measuring task length offers a more meaningful lens for autonomous-agent capability than many static benchmark scores.[^metr-time] Long-horizon verification has to answer: - Did the model remember the relevant prior facts? - Did it revise its conclusion when new evidence arrived? - Did it distinguish changed facts from unchanged facts? - Did it preserve constraints across intermediate steps? - Did it notice when a prior assumption became invalid? - Did it leave an audit trail that lets a reviewer inspect the trajectory? This is where simple grading breaks. The evaluator must inspect not only the final answer, but the path. ## 10. Verification Cost and Automation Economics For a task to be economically automatable, the following must hold: ```text AI generation cost + AI orchestration cost + verification cost + error remediation cost < human baseline cost ``` Many tasks fail this test not because generation is too expensive, but because verification is too expensive. ### 10.1 Structured extraction If a field can be checked against source text, verification may be cheap. Automation is attractive. ### 10.2 Analyst memo If every cited claim needs source review and domain judgment, verification may dominate cost. Automation may still help, but not as a full replacement. ### 10.3 Legal reasoning If success requires identifying missing facts, procedural constraints, and jurisdiction-specific rules, verification needs expertise. The model may draft quickly, but a lawyer still has to audit the reasoning path. ### 10.4 Coding agent If tests are comprehensive and the task is isolated, verification is cheap. If the task requires product judgment, architecture tradeoffs, security review, or unfamiliar system context, tests may be insufficient. ## 11. Proposed VKR Verification Matrix VKR should publish a matrix that maps work categories by evaluability: | Work Type | Primary Verification Mode | Automation Readiness | Main Bottleneck | | --- | --- | --- | --- | | JSON extraction | deterministic | high | source ambiguity | | Code patch | test-based | high-medium | test coverage | | Data cleaning | deterministic + review | medium | edge cases | | Financial model QA | spreadsheet audit | medium | assumption quality | | Research synthesis | citation audit + rubric | medium | unsupported claims | | Legal memo | expert rubric | low-medium | rule/application errors | | Medical note | expert + outcome | low-medium | safety and liability | | Strategy memo | source audit + judgment | low | ambiguous success | | Managerial decision | institutional | low | incentives and context | The matrix should not be a vibes-based automation ranking. Each row should include the verification procedure required for acceptance. ## 12. First Publishable Study The first VKR artifact should be a task evaluability scorecard. ### 12.1 Study Design Scope: - 20 work tasks; - six domains: software, finance, law, research, operations, and support; - one-page task card per task; - scoring on the six evaluability dimensions; - short explanation of what verification would require; - examples of what an AI system might generate; - examples of what would still need human review. ### 12.2 Task Card Template ```text task_id: domain: task_description: input_artifacts: expected_output: primary_verification_mode: secondary_verification_mode: observability_score: feedback_speed_score: feedback_cost_score: criterion_stability_score: error_severity_score: decomposability_score: acceptance_criteria: human_review_required: expert_review_required: likely_failure_modes: automation_readiness: notes: ``` ### 12.3 Output Table | Task | Domain | Verification Mode | Score | Automation Readiness | Human Review Required | | --- | --- | --- | ---: | --- | --- | | Extract payment terms from contract | Legal/Ops | source audit | to be measured | medium | yes | | Fix failing unit test | Software | test-based | to be measured | high-medium | maybe | | Build market-size estimate | Research | source audit + judgment | to be measured | medium-low | yes | | Reconcile spreadsheet totals | Finance | deterministic | to be measured | high | spot review | | Draft compliance memo | Policy | expert rubric | to be measured | low-medium | yes | This would give VKR a clean first wedge: not another model leaderboard, but a map of where AI work becomes economically verifiable. ## 13. Design Principles for Verification Systems ### 13.1 Start with acceptance, not generation Before choosing a model, define what it means for the output to be accepted. The verification surface determines the deployment architecture. ### 13.2 Separate generation from checking Where possible, the system that generates candidate work should not be the only system that verifies it. NIST's AI RMF notes that actors carrying out verification and validation are ideally distinct from those performing testing and evaluation actions.[^nist-rmf] ### 13.3 Preserve audit trails Verification is harder when the system leaves no path. Logs, sources, tool calls, intermediate claims, and reviewer notes should be preserved. ### 13.4 Price human review explicitly Human review is often treated as free because it lives outside the API bill. It is not free. It is part of the system cost. ### 13.5 Treat judge models as instruments, not truth Judge models can reduce review cost, but they require calibration, adversarial testing, and periodic human audit. Otherwise the verifier becomes another generator with a different prompt. ## Measurement Validity A verification system can fail even when it is consistent. The central validity question is whether passing the verifier means the output is good enough for the intended use. VKR should separate four validity checks: | Validity Check | Question | Failure Example | | --- | --- | --- | | Construct validity | Does the verifier measure the intended quality? | Rubric rewards style instead of correctness. | | Coverage validity | Does the verifier cover the important cases? | Unit tests miss the production edge case. | | Context validity | Does the verifier reflect deployment conditions? | Benchmark task omits messy real-world context. | | Authority validity | Can the verifier actually accept the work? | Model judge approves work that still requires expert signoff. | This distinction matters because verification can become theater. A system can produce a clean score, a rubric can produce consistent labels, and a judge model can provide confident evaluations while the deployment still fails. The paper's claim is stronger if VKR treats verification systems as objects of measurement rather than assuming they are ground truth. ## 14. Implications ### 14.1 For labs Investing in environments, graders, and task distributions may produce more economic progress than another static benchmark score. The feedback loop is the product. ### 14.2 For enterprises AI deployment should begin with verification design, not model selection. The first question is: how will we know the output is acceptable? ### 14.3 For evaluators Benchmarks should reveal verification mode, cost, and coverage. A score without a statement of what was checked is incomplete. ### 14.4 For researchers The frontier question is not only "What can models generate?" It is "Which valuable tasks can be made observable enough to train, evaluate, and trust?" ## 15. What Would Change the Claim The verification bottleneck thesis would be weaker if highly capable AI systems could reliably self-check across domains without domain-specific environments, expert rubrics, test harnesses, or outcome data. It would also be weaker if users accepted AI outputs without requiring evidence, audit trails, or accountability. The current evidence points the other way. The most useful systems tend to be embedded in environments where success is observable: code can be tested, documents can be audited, rubrics can be scored, and downstream outcomes can eventually be measured. The research question is therefore not whether verification matters, but which forms of verification are cheap, reliable, and general enough to expand the surface area of automatable work. ## 16. Limitations This paper does not claim that verification is the only bottleneck. Data access, tool integration, model capability, incentives, liability, privacy, security, and user trust all matter. The evaluability score is also not objective without a task definition. A legal question can be low-evaluability as open-ended advice and higher-evaluability as constrained citation checking. The same domain can contain both automatable and non-automatable work. Finally, verification itself can be automated only partially. Judge models, unit tests, simulators, and rubrics can reduce cost, but they cannot remove the need for calibration and periodic review. ## 17. Research Agenda VKR should pursue four near-term questions: 1. Which high-value work tasks are blocked by generation quality and which are blocked by verification cost? 2. Which verification modes are cheap enough to support reliable automation? 3. How does model performance change when tasks are scored holistically rather than algorithmically? 4. When do judge models reduce total verification cost without lowering acceptance quality? These questions sit at the center of AI economics, evaluation, and deployment risk. They are not abstract safety theater and not product marketing. They are measurement problems. ## Appendix A: Example Evaluability Card ```text task_id: research_claim_audit_004 domain: research task_description: audit a five-claim AI market memo against supplied sources input_artifacts: memo, source packet, citation list expected_output: claim-level accept/reject table with notes primary_verification_mode: source audit secondary_verification_mode: rubric observability_score: 4 feedback_speed_score: 3 feedback_cost_score: 3 criterion_stability_score: 3 error_severity_score: 3 decomposability_score: 5 acceptance_criteria: - each claim maps to source evidence - unsupported or overstated claims are flagged - missing uncertainty is noted human_review_required: yes expert_review_required: no likely_failure_modes: - source supports weaker claim than memo states - citation points to related but insufficient evidence - model misses contradiction across sources automation_readiness: medium notes: good candidate for model-assisted review with human audit ``` ## Appendix B: Verification Failure Modes | Failure Mode | Description | Example | | --- | --- | --- | | False acceptance | Bad output passes verification. | Judge approves unsupported claim. | | False rejection | Good output fails verification. | Rubric penalizes valid alternate answer. | | Proxy failure | Metric rewards the wrong thing. | Test passes but product behavior is wrong. | | Coverage failure | Tests miss material cases. | Code handles sample inputs but fails edge cases. | | Context failure | Verifier lacks relevant information. | Reviewer misses hidden constraint. | | Authority failure | Verifier lacks standing to accept output. | AI produces legal answer but lawyer must sign. | | Drift failure | Criterion changes after deployment. | Policy or market condition shifts. | | Audit failure | No path exists to inspect reasoning. | Final answer has no sources or logs. | ## References [^mechanize]: Mechanize, Inc., ["Mechanize, Inc."](https://www.mechanize.work/), accessed July 5, 2026. [^micro1]: micro1, ["Data lab to train frontier models & evaluate agents"](https://www.micro1.ai/), accessed July 5, 2026. [^micro1-realm]: micro1, ["Realm: Legal reasoning benchmark"](https://www.micro1.ai/benchmark/realm-legal), updated July 2, 2026. [^micro1-long]: micro1, ["Realm: Legal reasoning benchmark"](https://www.micro1.ai/benchmark/realm-legal), section "Long-horizon reasoning: the fading tail," accessed July 5, 2026. [^swebench]: SWE-bench, ["Official Leaderboards"](https://www.swebench.com/), accessed July 5, 2026. [^metr-time]: METR, ["Task-Completion Time Horizons of Frontier AI Models"](https://metr.org/time-horizons/), last updated May 8, 2026. [^nist-rmf]: NIST, ["AI Risk Management Framework"](https://www.nist.gov/itl/ai-risk-management-framework), accessed July 5, 2026; NIST, ["Artificial Intelligence Risk Management Framework (AI RMF 1.0)"](https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf), January 2023. [^helm]: Stanford CRFM, ["Holistic Evaluation of Language Models (HELM)"](https://crfm.stanford.edu/helm/), accessed July 5, 2026. [^stanford]: Stanford HAI, ["The 2026 AI Index Report"](https://hai.stanford.edu/ai-index/2026-ai-index-report), accessed July 5, 2026.