Doc review — fact-check in the browser

Upload a Word or PDF document, check every claim against an agent's knowledge base, walk the findings, accept or reject each one, export the verdict trail.

Doc review is the in-browser companion to the Word add-in's Verify document skill. It runs the same fact-check pipeline — claim extraction, KB-grounded verdict, suggested rephrasal — but you don't need to install anything. Drop a .docx or .pdf, pick a knowledge base, get back a reviewable findings list.

Doc review lives in the sidebar — click the shield icon labelled Doc review. Every run also shows up here, including runs you (or teammates) triggered from the Word add-in. This is the single queue your team triages.

When to use Doc review

You want to fact-check a PDF. The Word add-in only handles .docx files. Doc review accepts PDFs, including scanned ones (OCR is automatic). This is the most common reason to use it.
You don't have the Word add-in installed — Mac, Chromebook, locked-down desktop, no Office at all. Doc review needs nothing beyond a browser.
You want to triage findings from a Word run. Whoever ran Verify in Word sees their findings as inline comments. The team lead opens Doc review here and walks the same findings as accept / reject / ignore — leaving a per-claim note, exporting the result to .xlsx for the auditor.
You want a persistent audit trail. Every run lands in the database with creator, agent, source SHA, per-claim reviewer status, and reviewer notes.

Run a check

Sidebar → Doc review → + Verify a document.
Pick the agent to check against. The agent's project scope is the corpus — pick the same one you'd use in Search to look up a related claim. (No agents yet? See Agents — every field explained.)
Drop the .docx or .pdf file into the upload zone. Scanned PDFs are OCR'd page-by-page — runs over scans are flagged with · OCR (N of M pages) in the run list so reviewers know verdict reliability differs.
Click Verify. The pipeline runs in the foreground — typically 10–60 seconds for a short doc, longer for a 50-page PDF. Keep the tab open until it finishes; you'll land on the run detail page automatically.

OCR is best-effort. Scanned PDFs with good resolution and clean text read fine. Low-quality scans, handwriting, multi-column layouts and dense tables can come back garbled — the verdict only sees what tesseract extracted. Spot-check OCR runs against the original before signing off.

What you get back

The detail page shows one card per problematic claim. Each card has:

The paragraph (for Word) or page (for PDFs) the claim came from.
A verdict — one of supported, contradicted, not_in_kb, partial.
The claim text as the model extracted it.
The evidence from the knowledge base that supports / contradicts the claim, plus the source document and page number.
A suggested rewording that is supported, when one is possible.

Claims that came back fully supported don't generate cards — silence is good news. The list is intentionally a problem queue, not a complete dump.

The reviewer loop

On every card, four buttons drive the per-claim decision:

Button	What it means	When to use it
Accept	The model is right — there's a real issue here.	Edit the source document to use the suggested rephrasal (or another fix you write yourself).
Reject	The model is wrong — the claim is fine as written.	Add a reviewer note explaining why (helps the next person hitting the same false positive).
Ignore	The claim is out of scope for this run.	E.g. the claim is true but the KB simply doesn't cover it; you have other evidence.
(none)	Default `pending` until a reviewer touches it.	The list view shows the pending count so the team lead knows how much triage is left.

Notes are optional but recommended for rejected and ignored claims — they're what makes the review queue useful for the next person.

Export for auditors

On a run's detail page, click ↓ Excel. You get one row per flagged claim with every column an auditor or procurement reviewer wants: paragraph or page, verdict, severity, confidence, claim text, evidence quote, source document and page, suggested wording, reviewer status, reviewer note, who reviewed, when. This is the deliverable that closes the loop on a third-party audit fieldwork request or a vendor security review.

Doc review vs the Word add-in's Verify skill

Question	Doc review (browser)	Verify skill (Word add-in)
Inputs	.docx and .pdf (PDF gets OCR fallback)	.docx only — the document open in Word
Installs needed	None	Office 365 desktop or web + add-in
Where findings appear	Cards on this page	Inline Word comments anchored to paragraphs
Triage UX	Click Accept/Reject/Ignore + reviewer note on each card	Resolve/edit each Word comment
Persisted history	Yes — every run stays in this list	Yes — same database; runs also show up here
Best for	PDF inputs, team review, audit deliverables	Single author editing inline while fact-checking

Both surfaces hit the same agent — the model, prompt, project scope and budget are identical regardless of which UI started the run.

Troubleshooting

"No verifications yet" but I ran one from Word

The Word add-in's Verify skill only persists runs when it can reach the database (the standard path). Runs from a Word session signed in as a different agent key will appear under that key. Switch agent in the add-in's Connections tab and re-check.

"Could not extract any text from this PDF"

Three usual suspects: the PDF is password-protected (Knowledge can't read locked files), the file is a scan and tesseract isn't installed on the server (see Troubleshooting for the OCR install steps), or the file is corrupted. Open /diagnose.php to confirm which binaries are available.

The model said "not in KB" but the answer is in our docs

Either the agent's project scope doesn't include the relevant document, or the chunk wasn't retrieved in the top-K. Open the agent settings and (a) confirm the right project is ticked, (b) bump top_k from the default 5 to 8 or 10. If you can find the chunk in Search but verify still says "not in KB", it's almost certainly a top-K issue.