How verified citations work: the four verdicts

CiteDash AI's core promise is that no citation is ever invented and no claim reaches you unchecked. This guide explains the machinery behind that promise: what a citation actually is inside the product, what the Fact Checker examines when it verifies a sentence, why abstracts are never treated as evidence, and what each of the four verdicts (supported, partial, unsupported, unverified) is telling you to do next.

The reason to understand the machinery is practical. A verification verdict is only useful if you know what it does and does not guarantee. A green checkmark you read as "this sentence is true" will eventually mislead you; the same checkmark read correctly, as "this source's full text backs this sentence as written", is one of the strongest assurances an AI writing tool can give. By the end of this guide you should be able to read every verdict precisely, fix each one quickly, and explain the whole system to a supervisor or examiner in two minutes.

Citations are database objects, not free text

In most AI tools, a citation is a string the model wrote: an author, a year, a title, maybe a DOI, generated the same way as the sentence around it. That is why invented references happen, and why no prompt fully prevents them; the mechanism is covered in Why AI makes up citations, and the fix. In CiteDash, a citation is a row in a database that links your sentence to a real paper record. A generated citation that does not resolve to a real paper is rejected before display. There is no free-text reference anywhere in the product, so a fabricated reference has nowhere to exist.

This holds for everything that enters the system, not only AI drafts. Import a Zotero or Mendeley library through BibTeX and each entry becomes a paper record. Fetch a paper's details from a DOI and a record is created. Cite while you write and the citation binds your sentence to that record. The bibliography the Reference Manager formats, in any of its 12 citation styles, is generated from those records, which is why it cannot contain an entry that does not correspond to a real paper.

The object model is what makes verification possible at all. Because the system knows exactly which paper a sentence cites, it can fetch that paper's stored full text and ask a precise question: does this text support this sentence?

What the citation checker actually verifies

For every cited sentence, the Fact Checker retrieves the relevant passages from the cited paper's stored full text and judges whether they support the claim as written. Three details matter.

First, the unit is the sentence, not the paragraph. A paragraph can mix a supported claim with an unsupported flourish; checking sentence by sentence means the flourish cannot hide behind the citation next door. Second, the evidence is passages with sentence-level provenance: the system stores where in the document each passage sits, so a verdict can point you at the exact text it relied on rather than a page number. Third, the judgment is about the claim as written, including your qualifiers. "X improves Y" and "X was associated with improvements in Y" are different claims, and they can earn different verdicts against the same passage.

Two things the Fact Checker never does: it never uses the paper's abstract as evidence, and it never falls back on the model's memory of the paper. If the full text is not held, the honest answer is unverified, and that is what you get.

A fair question at this point: why not simply ask the model that wrote the sentence to double-check it? Because a model checking against its own memory has nothing new to consult; it would be grading its own homework with the same notes it used to write it. Verification only means something when the evidence is external, held, and inspectable: a stored document, retrieved passages, a recorded verdict. That is why checking runs as a separate step against stored full text, and why the result is a record you can show someone rather than a reassurance you have to repeat.

Why verification never grounds on abstracts

This rule surprises people, because abstracts are how most of us triage papers. Abstracts are fine for search and discovery, and that is exactly how CiteDash uses them: the Literature Finder matches your query against the record to surface candidates from its corpus and from OpenAlex, PubMed, Semantic Scholar and arXiv. But an abstract is a compressed advertisement for the paper, and compression loses the details a verdict turns on:

• Sample sizes, populations and settings usually live in the methods section, not the abstract.
• Effect qualifiers ("in the intervention group", "at 12 weeks", "after adjustment") are routinely dropped from abstracts.
• Limitations and null secondary outcomes rarely make the abstract at all.
• Abstract wording is often more confident than the results section it summarises.

The four citation verdicts explained

Grounding a verdict on an abstract would produce exactly the failure verification exists to prevent: a claim that looks checked but was only matched against a summary. Picture the concrete case: an abstract says "training improved outcomes" while the results section reports improvement on one of three measures, in a subsample. A verdict grounded on the abstract would wave through "training improves outcomes"; grounded on the full text, that claim earns partial at best. The gap between those two verdicts is exactly the gap an examiner will probe.

So the rule is strict. Search may use abstracts; evidence must be full text. When you see supported, it means the paper's body text backs the sentence, not that its abstract sounded similar. With that established, here is the whole verdict set. Every checked sentence carries exactly one of four:

• Supported: the source's full text backs the claim as written.
• Partial: the source supports part of the claim; usually a qualifier, a number or a generalisation you added goes beyond the text.
• Unsupported: the source does not back this claim. Rewrite it, cite a different source, or remove it.
• Unverified: the claim has not been checked yet, or the cited paper has no stored full text. Add the PDF and re-verify.

A worked example: one claim, four possible verdicts

The set is deliberately small and deliberately honest. There is no "probably fine". And unverified is the verdict that defines the system's character: where other tools would let the model guess from memory, CiteDash reports that it cannot check, which is the only honest thing a verifier can say without the source in hand.

Read the verdicts as instructions rather than grades. Supported means move on. Partial means look at your wording. Unsupported means stop and decide. Unverified means fetch the text. None of them is a judgment of you as a writer; overclaiming is what drafts do, human and AI alike, and the verdicts exist so the overclaims surface now, in your editor, rather than later, in your examiner's report.

To make the verdicts concrete, suppose you draft this sentence, with an invented example paper for illustration: "Mindfulness training reduces exam anxiety in undergraduates (Okafor et al., 2023)." Here is how each verdict could arise from that same sentence:

• Supported: the stored full text reports a randomised trial in undergraduates where the mindfulness group's exam anxiety fell relative to control, and the results state the effect plainly. The claim as written matches the text.
• Partial: the paper studied a mixed sample and reports reduced anxiety only in a subgroup, or reports an association rather than a causal effect. The direction is right, the strength is not; "reduces" overstates what the text supports.
• Unsupported: the paper is about mindfulness and sleep quality, and mentions exam anxiety only in the introduction as background. The citation resolves to a real paper, but the paper does not make your claim.
• Unverified: you cited the paper from its record after a DOI lookup, but no full-text PDF is held yet. Nothing has been checked, and the verdict says so instead of guessing.

How to fix each verdict: a decision guide

Notice that three of the four scenarios involve a perfectly real paper. Resolving to a real source is the floor, not the promise; the verdict is about the relationship between your sentence and that source's text. In the Thesis Editor, per-paragraph indicators show grounding at a glance and one click re-verifies the whole document. When a verdict needs work, here is the playbook:

• Supported: nothing to fix. Reread the sentence once anyway; supported means the source backs it, not that it is the best sentence for your argument.
• Partial: narrow the claim to what the text supports, split a sentence carrying two claims into two sentences with their own citations, or keep the stronger wording and find a source that actually supports it.
• Unsupported: first check whether you meant a different paper from your library. If not, rewrite the claim, replace the citation, or cut the sentence. Never leave it standing on a source that does not back it.
• Unverified: get the full text into the system. Upload the PDF, or fetch it if the paper is open access, then re-verify. If no full text can be held, treat the claim as effectively uncited and decide accordingly.

Overclaiming: where partial verdicts come from

Work the verdicts in passes rather than one by one. Fix a chapter's partials in a single sitting, because they usually share one cause (overclaiming) and yield to the same narrowing skill. Handle unverified in a batch, because fetching PDFs is mechanical. Save unsupported for a focused session, because each one is a genuine writing decision about what your argument needs.

The most common single fix is narrowing an overclaim: "X causes Y" often becomes supported as "X was associated with Y in two randomised trials". The second most common is promoting a held reference to full text so verification has something to read.

Most partial verdicts are not errors of fact; they are errors of strength. Academic sources hedge carefully, and drafts tend to strip the hedges. Four patterns account for most of them:

• Causal upgrades: "associated with" becoming "causes" or "reduces".
• Population stretch: a finding in one sample stated as a general truth.
• Number drift: "roughly a third" becoming a precise figure the paper never states.
• Consensus inflation: a single paper cited for "studies show".

Re-verifying claims after revision

The discipline the verdicts teach transfers beyond the tool. After a few weeks of seeing your own overclaims labelled partial, you start writing claims at the strength your sources actually support, which is precisely the skill examiners probe in a viva.

Verification is also not a one-time gate, because revision changes claims. Tighten a sentence, merge two paragraphs, or soften a conclusion at your supervisor's request, and a verdict earned last month may no longer describe the sentence on the page. Two habits keep the ledger honest: re-verify a chapter after any serious editing pass (one click in the Thesis Editor), and run the Proof Reader's revision audit before you circulate a draft, so a wording change that weakened a claim's grounding is caught rather than shipped.

This is also the argument for revising inside the system rather than exporting early to a word processor. Outside, your citations are inert text and no verdict can follow an edit; inside, a full re-check is always one click away.

Retractions: the check that never stops

A verdict describes the relationship between your sentence and a source. Retraction status describes the source itself, and it can change after you cite. CiteDash checks continuously: a retracted paper is badged in your Library and blocked from citation, and a paper retracted after you cited it is flagged in the Reference Manager and again at compile time, with the offending citation named.

You can check any paper's status without an account using the free retraction checker: paste a DOI and see where it stands. It is a small habit worth adopting for any source that carries real weight in your argument, whatever tool you write in.

Why so much machinery for a rare event? Because the cost is asymmetric. Retractions are uncommon, but a retracted paper load-bearing in your literature review is the kind of flaw an examiner remembers, and it is invisible to any check that only runs once. Continuous checking turns a catastrophic late discovery into a routine notification with a named citation to fix.

What a supported verdict does and does not mean

Precision about the guarantee matters, so here is the honest boundary. Supported means the cited source's full text backs the claim as written. It does not mean:

• The claim is true. A paper can be wrong, underpowered or superseded; verification checks fidelity to the source, not the state of the field.
• The source is good. A supported claim from a weak study is still a claim from a weak study; appraisal remains your job as the researcher.
• Your argument works. Ten supported sentences can still add up to a non sequitur; logic is not entailment.
• You have read the paper. The verdict points you at the exact passages; reading them remains the fastest way to own your material in a viva.

Citation verdicts at submission time

None of those boundaries diminish the verdicts. They locate them: verification eliminates the failure class that destroys theses, fabricated references and misattributed claims, so your attention can go to the judgments only you can make.

The verdicts you accumulate while writing become the record you submit with. At compile, the Thesis Assembler builds your bibliography with citeproc from the same citation records the verdicts attach to, so the document and the ledger cannot drift apart. Submission readiness checks report the state of your claims, the originality pre-check runs, and the audit trail of verifications generates the AI-use disclosure many institutions now require: a statement backed by a record rather than by memory.

A practical rhythm that makes all of this cheap: verify as you draft, so verdicts arrive while the source is still fresh in your mind; re-verify at the end of each chapter; and let the final compile be confirmation rather than discovery. A student who first meets their verdicts the night before a deadline has the same tools but none of the calm. The ledger rewards being consulted early and often.

That is the whole machine: citations that must resolve, claims checked against full text, four honest verdicts, and a trail you can hand to an examiner. For what the disclosure itself should say, read How to write an AI use disclosure statement for your thesis next.