A citation should let you check the claim beside it. If an answer says a library supports Python 3.12, the linked documentation needs to support that version claim. A link to the library’s homepage leaves you to find the evidence yourself.
We use the same standard for API limits, prices, policy terms, and commands. Find the relevant passage, preserve its qualifiers, and check that it applies to the version or date in the answer.
Check the claim against the passage
A material claim changes what someone decides or builds. A supported version, a request parameter, or a data-retention policy qualifies. A sentence connecting two sections usually does not need a citation.
Start with the exact claim. Open its cited page and find the passage that supports it. Check the passage’s scope before using the claim: an enterprise-only feature does not apply to every plan, and a release note describes the version it names.
One sentence can contain several claims. Separate them when they need different evidence.
Review one sentence from a Research answer
The Python Research example includes a recorded fast-mode run that asked:
What are the current ways to add web search to an Ollama-based application, and what output does each approach return?
The saved report contains this sentence:
The Ollama Web Search API, released on September 24, 2025, requires an API key and performs a POST request to https://ollama.com/api/web_search with a query and optional max_results (default 5, maximum 10) [1][2][3].
The source record maps those markers to these entries:
| Marker | Returned URL | Page |
|---|---|---|
[1] |
https://docs.ollama.com/capabilities/web-search.md |
Ollama’s Web Search documentation |
[2] |
http://docs.ollama.com/capabilities/web-search |
The same documentation page |
[3] |
https://ollama.com/blog/web-search |
Ollama’s announcement |
Entries [1] and [2] point to the same documentation page. The sentence cites two distinct pages, both published by Ollama. Count the pages separately from the citation markers.
The documentation states that the API requires a key, accepts a POST request at the named endpoint, and takes a required query. It also defines max_results as optional, with a default of 5 and a maximum of 10.
That supports the request details. The documentation does not establish the release date, so leave the date out until you verify it against a dated source.
Here is the revised sentence:
Ollama’s Web Search API requires an API key and accepts a POST request to
https://ollama.com/api/web_searchwith a requiredqueryand an optionalmax_results, which defaults to 5 and has a maximum of 10 [1].
We retained the supported details and attached their source. We removed the date rather than carrying an unchecked claim into the revision.
The report’s opening sentence lists four approaches without attaching citations. That creates a different review task: locate the evidence for each approach. A missing citation tells you the answer has not shown its support; it does not establish that the claim is false.
Check support, scope, and freshness
For each material claim, answer these questions:
| Check | Question | Example failure |
|---|---|---|
| Resolution | Can you open the cited page and find the relevant passage? | A documentation homepage links to the parameter’s actual page but does not describe it. |
| Support | Does the passage support the claim? | The answer names a feature the cited page never describes. |
| Scope | Did the answer preserve the source’s qualifiers? | The answer describes a paid-plan feature as available on every plan. |
| Time | Does the source apply to the date or version in the question? | An older release note supports behavior that has since changed. |
These checks catch different errors. An accessible page can describe the wrong version. A current page can support part of a sentence while leaving another part unchecked.
If current primary sources disagree, identify the conflicting statements and check their versions and scope. Narrow the answer to what the evidence establishes, or leave the disputed point unresolved.
Check whether the answer covers the question
Claim support and answer coverage require separate checks.
The Ollama question asks for both the available approaches and the output each approach returns. An answer that names the approaches but omits their outputs remains incomplete, even if every named approach has a valid citation.
Write down the required answer elements before reviewing the output. Then mark each element as answered, partially answered, or missing. This keeps a polished paragraph from hiding an unanswered part of the question.
Keep a review record
Record one row per material claim. Split a sentence into multiple rows when its clauses need different sources or decisions.
| Field | What to record |
|---|---|
claim_id |
A stable identifier for the claim. |
answer_text |
The exact sentence or clause, including its qualifiers. |
citation_ids |
The attached citation markers; leave empty when none exist. |
source_url |
The page you inspected. |
passage |
A short supporting or contradicting excerpt. |
source_date_or_version |
The relevant date or version; record unknown when the page does not establish it. |
retrieved_at_utc |
When you opened the source. |
support |
2: supported at the stated scope; 1: partially supported or needs a qualifier; 0: unsupported or contradicted after inspection; U: not inspected or could not inspect. |
reason |
The specific evidence gap or reason for the decision. |
Keep citation problems separate from factual decisions. Flag missing markers and duplicate source entries without treating them as proof that a claim is wrong.
Report supported, partial, and unsupported claims over the claims you inspected. Report U separately. Measure coverage against the required answer elements, not the number of sentences. If you inspected no claims, report the support rate as unavailable.
Save the passage and retrieval time so the record shows what you checked if the page later changes. This example demonstrates a review method; it does not measure citation accuracy across Tabstack Research.
Use the source record from Tabstack Research
Tabstack Research handles source selection and synthesis inside one call, then returns a Markdown report and citation metadata on the complete event.
The source list uses citedPages in the wire format and cited_pages in the Python SDK. Treat a missing list as empty. In fast mode, each source’s claims array is empty; use the report’s numbered citation markers to trace statements to their source entries. Balanced mode populates the claim lists.
The traced Python example preserves source order so each citation number continues to point to the correct page. It generates a review sheet with the answer text, citation markers, and source URLs. You then add the supporting passages and review decisions.
Your application sets the acceptance rules. Check decision-driving claims before using them downstream, and choose an appropriate review process for lower-risk answers. Automated checks can flag missing markers, out-of-range references, inaccessible links, and matching URL patterns. A verifier still needs to assess whether the passage supports the claim.
Review one answer
Choose a public question your application answers today. List what a complete answer must contain, then check one material claim against its cited passage. Record the evidence and decision before moving to the next claim.
Use the traced Research example to prepare the review sheet and keep the source mapping intact.
