How a Hyperresearch run works, step by step

A Deep run plans your question, researches it in chapters, plans the report section by section, then writes it in one pass from all of the evidence and checks every cited claim against its source before it ships. A Light run takes a shorter path through the same front end, described at the end of this page. Every stage writes an artifact you can read afterward.

The pipeline numbers its steps 1 to 16, with half-steps such as 1.5 for the chapter partition, and billing and the rerun-from-step control refer to them by those numbers. A Deep run uses steps 1 to 11 and then a finishing stage. Steps 12 to 16 belong to the older writing path, which a Deep run uses only if neither the one-pass writer nor the section-by-section writer behind it can produce a report.

Plan: the question and its chapters

Stage	What it does
Decompose	Your question broken into the things it actually asks, plus a coverage matrix, the required headings and the run size
Chapter partition	3 to 5 research chapters, each researched to its own depth, two at a time

Decompose freezes a run plan: the atomic items the question contains, the headings the report must have, and the role-to-model map. The chapter partition splits the question into research chapters so that each part gets its own sweep and its own investigation rather than a share of one.

What you get in the output: the decomposition artifact, with the coverage matrix, and the chapter plan.

Research: each chapter, from sweep to digest

Stage	What it does
Width sweep	Your vault first, then planned searches across breadth, depth and adversarial lenses. Parallel fetcher waves
Contradiction graph	Opposing claims paired into ranked fight clusters
Loci analysis	Two analysts pick where depth pays. Scored, budgeted
Depth investigation	One investigator per locus, in parallel. A committed position, not a summary
Cross-locus reconcile	Committed positions reconciled into named tensions
Source tensions	Expert disagreements pulled from full bodies, not summaries
Corpus critic	Asks what source would overturn this direction, and fetches the gaps before any writing
Evidence digest	Load-bearing claims and verbatim quotes, indexed

Every chapter runs these stages. The width sweep searches your workspace vault before it searches the web, then plans searches for what the vault does not already cover, and fetches in waves through a ladder of rungs. After every wave it clusters sources for independence, so five reprints of one press release count as one voice rather than five. The sweep gates on source count before the chapter proceeds. Source counts are not guarantees: Deep targets 150 to 200 sources across its chapters, and a Light run typically keeps about 20 to 50 sources.

Then the chapter decides where to spend its depth budget. The contradiction graph pairs claims that contradict each other and ranks the pairs. Two analysts score the places where depth pays and give each a source budget. One investigator per place, in parallel, is instructed to commit to a position rather than summarise both sides. The reconcile turns those positions into named tensions instead of averaging them away, and the source-tensions pass pulls expert disagreement out of full source bodies, not abstracts. The corpus critic is the chapter’s last chance to fetch: it asks what source would overturn the direction the research is taking, and those gaps are fetched. The evidence digest indexes the load-bearing claims with the verbatim quotes that support them. A chapter writes no prose of its own: it hands its evidence to the writer.

What you get in the output: per chapter, the contradiction graph, the loci file with its scores and budgets, the comparisons file from the reconcile, the source tensions file, and the evidence digest. For the run, sources[], one row per source with its URL, title, fetched-at time, which rung and provider succeeded, its quality score and grade, its independence cluster, a flag if the text came from an open-access copy rather than the publisher page, and a retraction flag; sources reused from your vault carry the V rung. And claims[], one row per extracted claim with its quoted support and the note that support came from.

Write: the report in one pass

Stage	What it does
Evidence map	Every source the run kept, read in full, its facts, figures and quotes mapped by note
Report plan	One plan over the whole map: the framing, the findings, and a brief for each section
Needs fetch	What the plan needs that the map lacks, fetched before any prose is written, primary sources first
One-pass writer	One writer, working from all of the evidence at once, writes the whole report

The writer works over the whole run’s evidence, not chapter by chapter. The evidence map reads the full text of every kept source and records what each one says, with its figures and quotes. The plan is written from that map before any prose: what the report argues, which section owns which table and which figure, and what each section must cover. A planner cannot search, so a facet the plan calls for that the map does not hold would stay empty. The needs fetch closes that gap: one question over the plan, asking what it needs, or what an expert reader would expect, that the evidence does not contain, answered with a bounded, targeted fetch that tries primary sources such as regulators, statistics offices, filings and papers first.

The kept sources then go to a single writer as one evidence set, ordered by the plan so that each section’s strongest sources and the sources carrying data come first. The writer writes the whole report in one pass from that set, so one writer handles the argument, the figures and the voice from start to finish. If its answer is unusable (empty, cut off, in the wrong language, or without resolvable citations), a second model gets the same evidence and the same instructions. If that fails too, the run falls back to the section-by-section writer: one writer per section from its own brief, then one editor joining them.

What you get in the output: report.md, with numbered citations resolved in a Sources section.

Check: the claim check and the receipt

Stage	What it does
Claim check	Every cited figure read against the source it cites, and what does not hold corrected in one guarded revision
Receipt and gate	Per-citation verdicts, quote integrity, the retraction sweep and the independence audit, then the ship gate

First, model-free checks repair what they can: citations that name no kept source, sentences repeated verbatim, stray symbols. A one-pass report gets no separate cohesion edit, because one writer already wrote it whole; a report from the section-by-section fallback is still edited once for cohesion, under guards on its sources, length and title. The claim check extracts every cited sentence and table row that states a figure, reads each one against the note it cites, and flags what does not hold, such as a wrong period, a figure attributed to the wrong source or an arithmetic slip. One revision corrects the flagged claims, under guards of its own, and the model-free checks run again over what it wrote.

Then the verification receipt is built over the report that ships, and it covers every citation, not only the figures. It returns one of four verdicts per checked citation: supported, partially supported, unsupported, or wrong source. Quote integrity confirms that every quoted passage is actually present in the source. The retraction sweep checks cited papers against retraction flags. The independence audit reports which sources are secretly the same story.

What you get in the output: verification, the verification receipt. It carries the per-citation verdict table, the quote-integrity results, the retraction sweep, the independence audit, and the ship-gate checklist. It is printable, and it is a record of what was checked, not a guarantee that every claim is true.

What stops a report from shipping

The ship gate checks the report against required headings, length, citation density, retractions, and citation resolution. Two of those are hard stops rather than thresholds: retracted-citations and cite-check-resolved. A cited paper that has been retracted and is not acknowledged blocks the report, and so does a citation check the run could not resolve. A report that fails the gate does not quietly ship with a warning.

Everything fetched from the web is wrapped as untrusted data before any model sees it, and fence tags inside a fetched body are neutralised so a page cannot close the fence and address the model directly. The service reads public pages logged out. It does not log in anywhere, does not hold your credentials, and does not solve CAPTCHAs. When a page genuinely needs a person, the run goes blocked and hands you a task you can finish by uploading the page or fetching it in your own browser, with the run’s progress preserved beside it.

Light, and the older writing path

Light runs decompose, the width sweep and one draft, which are steps 1, 2 and 10 in the pipeline’s numbering, then a hygiene pass and the finishing stage. It is not chaptered, and it skips the contradiction graph, the depth investigators, the corpus critic and the Deep writer: on Light the single draft is the report. It gets a final edit of its own and the same claim check as Deep, with one revision before the report ships, but no verification receipt.

The older writing path is the one the open-source CLI still runs. It writes three angle drafts for each chapter, synthesises them into one report, has four critics attack it, fetches what they say is missing, applies their findings through a patcher that can only make small edits, and then runs a cite-check, a polish pass and a readability audit. A Deep run falls back to that path, in the same run, only if the one-pass writer and the section-by-section writer both fail to produce a report.

Every stage writes its artifact into the run, and every source it read stays in your workspace vault, which the next run searches first. The vault page covers what is kept and how it is searched. The pricing page covers what each size costs and when a run is billed.