TL;DR
Hypothesis-Verification is a technique that rewires how analysis works: instead of “go dig up something on the topic,” you first spell out what exactly has to be true for each answer option to be correct. Only then do you go hunting for evidence.
The standard “wander through the topic and collect whatever you find” approach falls apart on hard problems: the first facts you stumble on send the reasoning down the wrong path, and every next step doubles down on the initial mistake. Worse, the model looks for what resembles an answer rather than what actually separates the right option from the wrong ones.
The method fixes this with four roles inside one task: Thinker rewrites each answer option as a testable hypothesis, Judge finds the minimal clue — the one piece of evidence that splits the hypotheses, Verifier checks that clue against the actual data, and Answer pulls it all together into a final conclusion with an explicit chain of reasoning.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
(All four steps can run in a single prompt)
STEP 1 — Thinker: for each answer option, formulates a hypothesis
"What has to be true for answer X to be correct?"
→ list of hypotheses H1, H2, H3...
STEP 2 — Judge: from the set of hypotheses, derives one discriminating clue
"What do we need to check to tell the hypotheses apart?"
→ one specific clue κ
STEP 3 — Verifier: checks the clue against the available data
→ status CONFIRMED / PARTIAL / NOT CONFIRMED + justification
STEP 4 — Answer: integrates the evidence and states the final answer
→ conclusion with an explicit chain of logic
If status is NOT CONFIRMED → refinement loop: hypotheses get sharpened
and the check repeats (usually 1-2 times)
Example in Action
Task: Paul opened a dumpling shop on Uber Eats four months ago. His average rating is 3.8 — not good. There are three theories: (A) bad food, (B) slow delivery, (C) a weak listing page. He needs to find the real cause without guessing.
Prompt:
Act as an analyst using the four-agent Hypothesis-Verification scheme.
Context: 3.8 rating on Uber Eats, 40 reviews over 4 months.
Reviews: [paste 10-15 reviews]
Possible causes: A) the food tastes bad, B) slow delivery, C) weak
listing/photos
THINKER — formulate a hypothesis for each option:
What specifically must be true in the reviews if the cause is A?
What must be true if the cause is B?
What must be true if the cause is C?
(key entities, actions, time patterns)
JUDGE — from the three hypotheses, derive one discriminating clue:
What minimal observation in the reviews would separate these three hypotheses?
What do we need to find to rule out two of the three?
VERIFIER — check the clue against the reviews:
Find direct evidence. Output a status:
CONFIRMED / PARTIAL / NOT CONFIRMED + timestamps / quotes
ANSWER — integrate the evidence:
Which theory got confirmed?
What is ruled out and why? Recommendation in one action.
Result: The model will first lay out three explicit hypotheses — not “bad delivery,” but “reviews mention a specific wait time over X minutes and tie it to the low score.” Then it derives a discriminating clue — one phrase or pattern that shows up only if one of the theories is true. Next it searches the reviews for that clue and reports what it found. The final answer points explicitly to the evidence — logic, not gut feeling.
Why It Works
A plain question like “why is my rating low?” triggers a search for things that look similar — and the model grabs the first confirming facts while ignoring the ones that point the other way. This is called confirmation bias: an LLM generates text by following the most likely pattern, and early reasoning drags everything after it along.
LLMs have another strength, though: they handle explicitly assigned roles and structured conditions really well. Ask not “what is true?” but “what would have to be true?” and the model switches from hunting for confirmation to writing out testable conditions.
The method exploits exactly that: Thinker forces the model to explicitly unpack the logic of each theory, and Judge finds the separating clue — what distinguishes the theories, not what they share. From there the search goes narrow instead of wide: not “collect everything about delivery,” but “find exactly this.”
Control knobs: - Number of hypotheses → more answer options = more hypotheses; you can cap it at the 2-3 most likely - Clue format → ask Judge to list the specific marker words to look for in the text - Verifier status → add a threshold: “count as CONFIRMED only if the clue appears in 3+ reviews” - Refinement loop → drop it for simple tasks to save time and tokens
Prompt Template
Work using the Hypothesis-Verification scheme. Task: {task description}.
Answer options: {A: ..., B: ..., C: ...}
Data to analyze: {text / reviews / facts}
THINKER:
For each option — what must be true in the data
if that option is the correct one? Name key entities, actions,
patterns. Drop clearly implausible options right away.
JUDGE:
From the set of hypotheses, derive one discriminating clue κ.
This is the minimal observation that separates the correct hypothesis
from the rest. What do we need to find — and what does it look like concretely?
VERIFIER:
Check clue κ against the data. Output a status:
CONFIRMED / PARTIAL / NOT CONFIRMED
+ concrete evidence (quotes, facts, timestamps)
If PARTIAL — specify what exactly is confirmed
and what still needs checking.
ANSWER:
Integrate the evidence. Which option is correct and why?
What is ruled out? Final conclusion: {output format}.
Placeholders:
- {task description} — what you are analyzing and why
- {A, B, C} — competing theories / options / hypotheses
- {text / reviews / facts} — the data you check against
- {output format} — e.g. “one action,” “ranking of options,” “yes/no with justification”
🚀 Quick start — paste into the chat:
Here is a Hypothesis-Verification template. Adapt it to my task: {your task}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask which competing theories you are weighing and what data you have — because without that, Thinker can't write hypotheses that actually differ. It will take the four-agent structure and tailor the roles to your task.
Limitations
⚠️ Open-ended questions: The method is built for choosing between competing options. For an open question with no answer options it is less effective: Judge can't come up with a discriminating clue when there is nothing to tell apart.
⚠️ Data quality: If the source data is thin or uniform, Verifier won't find the clue — the status will loop on PARTIAL. You need enough facts to compare.
⚠️ Task complexity: For simple questions with an obvious answer it's overkill. The structure pays off on genuinely competing hypotheses where gut instinct can be wrong.
⚠️ Refinement loop: If the task is poorly structured, the self-refinement loop can spin forever — the model keeps rephrasing hypotheses without real progress. Cap it at 2 iterations.
Resources
Title: Think, Then Verify: A Hypothesis-Verification Multi-Agent Framework for Long Video Understanding
Datasets and benchmarks: EgoSchema, NextQA, IntentQA, VideoMME-L
Authors: Zheng Wang, Haoran Chen, Haoxuan Qin, Zhipeng Wei, Tianwen Qian, Cong Bai
Institutions: Zhejiang University of Technology (China), UC Berkeley (USA), East China Normal University (China)
Code: https://github.com/Haorane/VideoHV-Agent