Rewriting only the paragraphs a Turnitin report flagged

I build HumanPen, which does the thing I am about to describe, so this is not a neutral survey. The mechanism is worth writing up anyway, including if you would rather do it by hand.

A rewrite-all tool is cheap to run and expensive to check.

The cost that actually lands on you is verification, and verification scales with what changed, not with what was wrong. Anywhere a rewrite landed, you now have to confirm the numbers survived, the terminology stayed consistent with the section before it, the in-text citation is still attached to the claim it supports, "see Table 2" still points at Table 2, and a hedge did not get upgraded. "Association" coming back as "causation" is the one that scares me, because the sentence still reads perfectly well on the page.

On a paragraph nobody touched, you check nothing.

Take the example we use in our comparison write-up: a 10,000-word paper with 2,800 words flagged. Rewrite all of it and you re-read 10,000 words for the same underlying fix. The other 7,200 are the ones you had no reason to doubt.

A second cost shows up later. Once a rewrite-all pass has changed the paragraphs that were already clean, the next report is no longer comparable to the first one. If something new gets flagged, you cannot tell whether it was flagged before, because the text underneath it is not the text the first report looked at. Selective rewriting keeps the unflagged text as a control.

Turnitin's documentation is direct about it: the AI writing indicator and the similarity score are independent of each other, and AI writing highlights do not appear in the Similarity Report at all (Using the AI Writing Report). A Similarity Report highlights overlap with existing sources. Feed that into a report-guided workflow and you go to work on passages nobody classified as AI writing. HumanPen will not read a Similarity Report as an AI Writing Report.

Two more things that change how you read the report:

• Below 20%, there is no number. Turnitin displays an asterisk instead of a percentage for scores in the 1 to 19 range, and attributes that to a higher false positive rate in that band. So the percentage is not always something you have. The highlights are.
• The percentage is not a share of the whole document. Turnitin only analyzes what it calls qualifying text, meaning long-form prose in standard grammatical sentences. Lists, bullets and other non-sentence structures are outside the analysis. Turnitin's own wording for what follows from that is "a document containing several different writing types would result in a disparity between the percentage and the highlights". So the highlighting and the percentage do not always line up, and how far apart they drift depends on how much of your document is not prose.

The highlighted spans, not the number, are the part of the report you can act on.

The rewriting is the easy half.

1. Get the highlights out of a document that was never meant to be parsed. In Turnitin, only instructors and administrators see the AI writing indicators. Instructors can download a PDF of the report to share with the student, so what reaches an author is typically a PDF, not a data feed. And a PDF report is a rendering. Its text layer is positioned glyph runs laid out in lines, and the highlight is a colored shape drawn over that layout. Nothing in the file says "these characters are flagged". Recovering that means intersecting the geometry of the highlights with the geometry of the text layer and reading off which glyphs fall inside.
2. Normalize what comes out, because it is not the text you wrote. Words break across lines with hyphens that were never in the source. Ligatures come back as one glyph where you typed two letters. Straight apostrophes come back curled. Running heads, page numbers and footers interleave into the extracted stream, so a paragraph can arrive with the journal name sitting inside it. Each of these defeats exact string matching, and the only symptom is a matcher that quietly returns nothing.
3. Match back to the source file with the same normalization on both sides. You are comparing a lossy rendering of a paragraph against the paragraph, so this is a fuzzy match by construction, and a fuzzy match is one you have to show someone.
4. Expand the match to the whole paragraph. Highlights are not obliged to line up with paragraphs, and the case that decides the design is the one where they do not: the span starts somewhere inside the paragraph and stops mid-clause. If you rewrite exactly the highlighted characters, half the paragraph comes back in a different register from the other half, and sentences are left leaning on pronouns and defined terms that were introduced in the part nobody touched. That is why the paragraph is the smallest rewrite unit. A partial highlight is expanded to the complete paragraph, and that expanded list is what the author is shown and asked to confirm.
5. Rewrite in place, inside the file. Not extract, rewrite, paste back. Each rewritten paragraph goes back where it came from, and a protected set is left alone on the way through: citation markers, reference entries, formulas, code, captions, figure numbering, footnotes, table cells, cross-reference fields and the table of contents.

Step 3 is heuristic, and heuristics are wrong sometimes.

A highlighted sentence that appears twice in the document, as happens with methods boilerplate, can match the wrong instance. A paragraph you edited after generating the report may not match at all. A caption or a table cell can look like body prose. If the tool acts on a bad match silently, it rewrites a paragraph the report never flagged and you never learn that it did, which is the exact thing this approach exists to avoid.

So the matched paragraphs are shown before the job starts. You add to the list, cut from it, and anything you have not confirmed stays out of scope. Scope is also price, since billing follows the words actually rewritten, so that screen is the estimate too.

Report-guided only makes sense when you actually have a report. Without one, whole-document processing or picking the passages yourself is the honest answer, and ours does both of those too.

The output needs a human read. Automated rewriting produces details that need correcting, and refusing to inject deliberate grammar or spelling errors does not make the result submission-ready on its own.

Matching runs against the file you upload, so if you have edited heavily since the report was generated, expect fewer matches and a shorter proposed scope. If the scope you are shown looks thinner than the highlighting in your report, that is usually the reason.

There is no detection-score comparison anywhere in this piece, on purpose. Turnitin says plainly that it will not publish the names of the paraphrasing and bypass tools its detector covers, because a public list would help people evade it (AI writing detection FAQs). Which means nobody outside Turnitin can check a "we beat detector X" claim, so I am not going to make one. Turnitin also says its indicator should not be the sole basis for action against a student, which is worth holding on to when a number comes back higher than you expected.

If a new report still flags passages, eligible results can continue lowering AI for free. This is support, not a promise about where the number ends up.

Is there a tool that rewrites only the paragraphs flagged in a Turnitin report? Yes. HumanPen imports a Turnitin or iThenticate AI Writing Report, matches the highlighted passages back to your source document, shows you the matched paragraphs, and rewrites only the ones you confirm. The file comes back in the format it went in as.

Can I just do this by hand? Yes, and for five or six flagged paragraphs it is completely reasonable. Open the report next to the document, find each highlight, rewrite that paragraph yourself, leave the rest alone. You get the same scoping win. What a tool buys you is the matching across a long PDF and not having to reassemble the file afterwards.

Does this work with iThenticate as well as Turnitin? Yes. Both produce an AI Writing Report and both are supported. What is not interchangeable is the Similarity Report, which measures something else entirely.

How would I test whether a tool really does this? Find a highlight in your report that starts in the middle of a sentence. Feed the report to the tool and look at the scope it proposes. It should contain that entire paragraph, and it should not contain the paragraph before or after unless those were flagged too. A tool that proposes the exact highlighted fragment is going to hand you back a paragraph written by two people, and a tool that proposes the whole section is not really working from the report.