How to Track Who Verified Each Claim in a Team Project

A claim tracker answers one question fast: for every factual sentence in the draft, who checked it, against what source, and when. The practical way to build one is to treat verification as a small, repeatable workflow rather than a memory exercise. You need a claim register, a source record, a named verifier, a status field, and a short set of rules for when a claim is allowed to move from "unchecked" to "verified."

This guide walks through that workflow for a course paper, thesis chapter, or first manuscript. It uses a winter-break cleanup and January project-start example, gives you a reusable table, and ends with one concrete next action.

Before building anything, look at the draft and ask three questions.

1. Can you point to the exact sentence that makes a factual claim? If claims are buried in long paragraphs, split them out first. A claim is a single assertion that could be checked against a source.
2. Does each claim already have a source attached? If citations exist but no one has confirmed that the cited work actually supports the sentence, you have citations, not verification.
3. Does anyone know who checked what? If the answer is "we think so," you have a tracking gap, not a knowledge gap.

Most teams discover they have a mix: some claims are cited and checked, some are cited but unchecked, and some are asserted with no source at all. The tracker's job is to make that mix visible.

Not every sentence needs a row. Track sentences that assert a fact, a number, a comparison, a causal statement, or a finding attributed to someone else. Skip transitions, definitions you introduce yourself, and statements about your own method.

A useful test: if a reader asked "says who?", would you need to answer with a source? If yes, it belongs in the register.

A claim register is a table with one row per claim. Keep it in a shared document so the whole team edits the same version. The columns below are the minimum that makes verification auditable.

Two columns do most of the work. Source location forces the verifier to point at the passage, not just the paper. Notes records whether the source supports the claim as written or only a weaker version of it.

Verification stalls when everyone assumes someone else is checking. Assign roles explicitly.

• Claim owner: the person who wrote the sentence and is responsible for finding a candidate source.
• Verifier: a different person who opens the source and confirms the claim. Keeping owner and verifier separate catches errors the author is blind to.
• Section lead: reviews the register for a section and confirms all rows are Verified or Flagged before the section is considered done.

For a small team, one person can hold the section lead role for several sections, but the verifier should not be the claim owner for the same row.

When a claim has no source yet, the owner searches for one. Use scholarly search tools to locate candidate papers, then record the identifier so the verifier can reach the same work.

A DOI resolves through doi.org to the destination registered for that identifier, which helps you locate a work. Resolution alone does not confirm that the paper supports your sentence, so the verifier still has to open the source and read the relevant passage. WisPaper's scholarly search interface is one place to find candidate papers; once you have a candidate, record its DOI or other identifier in the Source column so the next person can reach the same record.

If you are working from a BibTeX file, run the references through TrueCite, which checks BibTeX against real academic databases to flag hallucinated references. That step catches references that do not exist; it does not tell you whether an existing paper supports your claim, so the verifier still reads the source.

The verifier's job is narrow: open the source, find the passage, and decide whether the claim as written is supported.

Use three outcomes:

• Verified: the source says what the claim says, and the source location is recorded.
• Flagged — weaken: the source supports a narrower version. Rewrite the claim and re-verify.
• Flagged — replace: the source does not support the claim. The owner finds a different source or removes the claim.

Record what the source actually says in the Notes column. This is the single most useful habit in the whole workflow, because it lets a section lead audit the decision without re-reading every paper.

A three-person team is starting a January project on urban heat and public health. During winter break they cleaned up a draft chapter inherited from a previous term. Here is how three claims moved through the register.

C-003. Draft sentence: "Green roofs reduce urban surface temperatures across all climate zones." The owner finds a candidate paper and records the DOI. The verifier opens it and finds the study covers temperate cities only. Status: Flagged — weaken. The sentence is rewritten to name the climate zone studied, and the verifier confirms the narrower version. Status: Verified.

C-007. Draft sentence cites a paper that the team cannot locate. The owner runs the reference list through TrueCite, which flags the entry as not matching a real database record. Status: Flagged — replace. The owner finds a real paper on the same point, records it, and the verifier confirms support. Status: Verified.

C-011. Draft sentence: "Heat alerts reduce emergency admissions." The owner finds a paper, but the verifier cannot find the specific figure in it. Status: Flagged — replace. The claim is cut from the chapter rather than left unsupported.

At the end of the session, the section lead checks the register: every row is Verified or Flagged, no row is Unchecked, and every Verified row has a named verifier, a date, and a source location.

A register is only useful if the sources behind it are easy to reach. Save the papers you rely on in one place so verifiers are not hunting through email threads.

WisPaper's My Library lets you save or upload papers and organize them, which gives the team a shared set of sources to check against. When a verifier needs to ask a question about a paper already in the library, Library QA supports asking questions based on papers uploaded to My Library or added from search results. Use it to orient quickly, then confirm the exact passage yourself before marking a row Verified.

For a longer literature review that feeds many claims at once, Scholar Agent fits longer research tasks with literature review use cases. Treat its output as candidate material: each claim it surfaces still needs its own register row, source location, and named verifier.

A tracker without checkpoints drifts. Put three checkpoints on the calendar.

Checkpoint 1 — Register complete. Every factual sentence in the draft has a row. Stop here if any section has unregistered claims; do not start verification until the register is complete for that section.

Checkpoint 2 — Section verified. Every row in a section is Verified or Flagged, with a named verifier and date. Stop and escalate to the section lead if a row has been In review for more than a week with no note.

Checkpoint 3 — Pre-submission audit. The section lead samples Verified rows and confirms the source location matches the Notes. Stop the submission if any Verified row lacks a source location.

Escalation rules keep disagreements from stalling the team:

• If owner and verifier disagree on whether a source supports a claim, the section lead reads the passage and decides.
• If no source can be found for a claim after a reasonable search, the claim is cut or explicitly marked as the team's own argument.
• If a reference cannot be matched to a real record, it is replaced before the section can pass Checkpoint 2.

The tracker is ready when a reader who was not on the team can open it and answer, for any claim in the draft: who verified it, when, against which source, and where in that source. If any of those four answers is missing, the row is not done.

A quick readiness check:

• Every factual sentence has a row.
• No row is Unchecked.
• Every Verified row has a verifier name, a date, and a source location.
• Every Flagged row has a note explaining the decision.
• References have been screened so that entries match real records.
• The section lead has sampled Verified rows against their sources.

When all six boxes are checked, the register is a defensible record of who verified what.

Open your draft, create the claim register table with the nine columns above, and fill in the first ten rows for your introduction. Assign one verifier who is not the claim owner, and set Checkpoint 1 for the end of the week.