DEV Community: Nylah Reynard

The shortcut everyone tells you to press is scoped to fields, not citations

Nylah Reynard — Thu, 03 Sep 2026 12:46:33 +0000

Elsevier tells you to select the whole document with Ctrl+A and press Ctrl+Shift+F9 to strip your reference manager's hidden codes before submitting.

Microsoft documents that shortcut as: "Unlink a field."

Not "unlink a citation". A field. And Microsoft's own field-code reference lists TOC, SEQ and REF as fields — your table of contents, your automatic numbering, your cross-references.

So the published instruction, applied to a whole-document selection, has no citation-only boundary anywhere in it. Nothing in the documentation gives you a reason to expect it to leave those other objects alone.

I went looking at this because a lot of people run that command in a hurry, near a deadline, on the file they are about to submit — and because the thing everyone thinks they are solving by running it is not actually a problem.

Let me get that part out of the way first, since it is the usual reason people start down this road.

A reference list is machine-generated, identically formatted and structurally repetitive, so people assume it is dragging their AI percentage up. It is not, on either side. Turnitin's AI writing report analyses only what it calls qualifying text — prose in standard grammatical sentences — and a release note dated 9 August 2023 separately says bibliographies are excluded when the report is processed.

If a bibliography is coloured in a report you are holding, the first thing to check is whether you are looking at the Similarity Report rather than the AI writing report. Matching reference entries are what a shared citation style is designed to produce.

So the expensive step is not the bibliography. The expensive step is the irreversible command someone told you to run.

Here is what I found comparing the vendors' own pages. Three reference managers, four add-ins, four different commands — and they do not behave the same way.

Zotero documents Unlink Citations, and calls the removal irreversible.

EndNote documents Convert Citations and Bibliography → Convert to Plain Text, and explicitly says the command creates a new copy for you. Clarivate's wording on going back is worth quoting, because "irreversible" tends to get read as marketing caution:

"Field code removal is a one-way process. Once you've removed EndNote™ field codes, you will need to reinsert the citations or revert to a backup of the document that still has the field codes in it."

Mendeley ships two different add-ins, and this is where it gets interesting. The older Citation Plugin used fields and had an Export command. Mendeley Cite, the newer one, uses different object language entirely: it calls a citation or bibliography a content control, and tells you to right-click the object and choose Remove Content Control.

That difference matters, because Microsoft's field-shortcut page says nothing about what Ctrl+Shift+F9 does to a content control. If your citations are content controls, the shortcut everyone recommends is documented against a different object type than the one in your document.

Zotero adds one more axis: its Document Preferences let you store citations as Fields or Bookmarks, advising that unless you need to collaborate with LibreOffice users, "you should always choose Fields". So even within one manager, the object in your file is a setting.

Fields, bookmarks, or content controls. Three possibilities, three different removal paths, and one keyboard shortcut that people apply to all of them.

There is a free, instant, completely reversible way to find out what is actually in your file before you run anything irreversible. Same Microsoft page:

"Switch between all field codes and their results. Alt+F9"

Press it. Word toggles between field codes and their displayed results. A table of contents exposes a TOC instruction; numbering exposes SEQ; a cross-reference exposes REF. If your citations also show up as field codes, fields are involved. If they don't, that tells you something too — and you should go read your add-in's own page rather than assume.

It costs one keystroke and it is the only step here you can undo by pressing the same keystroke again.

One more thing, for anyone whose plan is to reword bibliography entries until they stop matching.

Set aside whether that is a good idea. Just look at what the software does with the edit. Zotero's page is blunt:

"Manual edits made to the bibliography in Word will be overwritten the next time Zotero refreshes the document."

And for in-text citations, on the same page: manual modifications prevent Zotero from automatically updating that citation.

So in a document with live fields there are exactly two outcomes, and neither is the one you wanted. Either the next refresh silently reverts your edit, or the edit sticks and that one citation is now disconnected from the library — meaning the next style change updates every entry except that one.

The order of operations that keeps this cheap:

Keep a working master. Name the delivery copy separately before removing anything. EndNote makes a copy for you; the others do not say they do.
Finish all citation work first — style changes, added sources, page numbers, prefixes. After flattening, none of it can be done by the manager any more.
Refresh once before flattening, so what gets frozen is current output rather than something stale.
Identify the object, then follow that product's own path. Zotero: Unlink Citations. EndNote: Convert to Plain Text. Mendeley Cite: Remove Content Control. Not one generic shortcut for all three.
Press Alt+F9 first, and again on anything that comes back to you from any other tool, to confirm your fields are still fields.

And the honest boundary on all of the above: I read the vendors' documentation, I did not run a Word-version test matrix. What I can say is what the pages say — and what they say is that the command is scoped to fields, that at least one major add-in does not use fields, and that going back is not offered.

Originally published at HumanPen: https://humanpen.net/blog/zotero-endnote-citations-and-ai-flags?utm_source=devto&utm_medium=article&utm_campaign=D214

I compiled one .tex file and three PDF extractors gave me three different papers

Nylah Reynard — Thu, 03 Sep 2026 09:25:05 +0000

I compiled one .tex file, read the resulting PDF with three different extractors, and got three different papers back.

Not wildly different. mutool 1.25.6 and PyMuPDF 1.26.0 each returned 694 whitespace-delimited words. pypdf 6.4.0 returned 692. Same file, same machine, same moment.

A two-word gap sounds like nothing. It is enough to kill the assumption most of us are quietly running on: that the text layer in a PDF is a fixed object, and that whatever reads it sees what you wrote.

The fixture, so you can argue with it: standard article class, twocolumn, 10pt. Abstract, four numbered sections, inline and display maths, an itemize list, an algorithm environment with numbered pseudocode, a table float, a figure float whose caption is a full sentence, and one footnote long enough to wrap. Compiled with pdfTeX 3.141592653-2.6-1.40.26, TeX Live 2024.

First surprise: the thing everyone warns you about did not happen.

The standard advice about two-column PDFs is that extractors read straight across both columns and turn your paper into interleaved nonsense. It didn't. The last sentence of the abstract, at the foot of column one, arrived immediately before the first sentence of the Introduction, at the head of column two. Broad section order held in all three streams.

One layout, one class, three extractors, one machine — that is the size of that claim. But it held.

Something else broke instead, and I have seen almost nobody mention it.

Here is a verbatim run from the PyMuPDF stream, whitespace normalised, nothing removed between the endpoints:

"…justification for treating a visually correct page as a reliable 1This footnote is deliberately long enough to wrap onto a second line so that its position in the extracted stream can be observed and compared with nearby prose. 1 Table 1: Primary o…"

In the source, reliable text stream is one phrase. In the extraction, a footnote, a bare page number, a table caption and its cells all land between the two words. The bare 1 is the page number — nobody reading the PDF sees it as part of either passage.

Nothing is visibly wrong with that page. It renders perfectly. But "the sentence before" and "the sentence after" are not stable concepts until you know which extractor is reading.

Then the layout switch, which is the result I found most useful.

LaTeX hyphenates at line breaks, and a narrow column creates more chances to do it. In the two-column build, PyMuPDF found 22 split tokens. Six of them:

ex- poses · differ- ences · specifica- tions · observa- tions · justifica- tion · partici- pants

I then compiled the identical source as a single column, changing only the class option. PyMuPDF returned 678 words and five splits: or- dinary, extrac- tion, jus- tification, partici- pants, par- ticular.

Same source. One option. A different set of words has stopped being words.

And then the compiler itself. I compiled the same source a third time with XeLaTeX — same two-column layout, same words on the page.

In the pdfLaTeX build, all three tools exposed zero ligature codepoints. In the XeLaTeX build, PyMuPDF and pypdf each exposed six — aﬀiliated, aﬀiliation, diﬀicult, eﬀiciency, insuﬀicient, oﬀice — while mutool exposed zero, because it normalised those glyphs back to ordinary letters.

The maths went the other way. In the pdfTeX file, mutool returned a Unicode replacement character for the summation sign; PyMuPDF and pypdf returned a capital X. In the XeLaTeX file, all three returned an actual ∑.

So: the compiler shapes the characters, and then the extractor shapes them again.

One more, and this one has practical consequences beyond curiosity.

\cite{smith2019,jones2020} arrived in the extraction as four characters: [1, 2]. \ref{sec:method} arrived as 2. \label left nothing at all. Section headings arrived as number and title separated, so 2 Method sits in the stream directly after the previous sentence.

Which means any plan you have that depends on citation formatting is acting on something that isn't there. There is no citation object in the extracted text. There are brackets and digits.

You do not need any of the tools I used to check your own paper. Open your compiled PDF in whatever viewer you have, select all, paste into a plain text editor. That is one more extraction path, not a proxy for anything official — but it shows you problems in the text layer you are actually shipping.

Read it for these four, in this order:

Split words. Search for a hyphen followed by a line break. Every hit is a word that has stopped being one word.
Where your floats landed. Find a table caption and read the two sentences around it. If the caption and cells have landed inside a paragraph, that is the reading order for that paragraph.
Your captions. If a caption is a full grammatical sentence, it reads as prose, because it is prose.
The maths. Read one display equation in the pasted text. Whatever you see is what an extractor got. Missing or wrong characters are a fact about your font embedding.

If your .tex lives in Git or Overleaf, do this once per major revision rather than once at the end.

The boundary on all of the above, stated plainly: this is one fixture, one class file, one machine, three named local extractors with pinned versions. It says nothing about what any particular service's private extraction chain sees, and I am not claiming it moves any number anywhere. The narrow, checkable claim is the one worth carrying: the text layer is a product of the compile, and different extractors expose different characters from the same PDF.

And if sentences have to change, the answer for a LaTeX paper is boring and correct — change the source, recompile, never edit the PDF. The sentence lives in the .tex. Everything else is a rendering of it.

Originally published at HumanPen: https://humanpen.net/blog/overleaf-latex-turnitin-ai-detection?utm_source=devto&utm_medium=article&utm_campaign=D211

Google has never used the word "paste" on any page about Docs version history

Nylah Reynard — Thu, 03 Sep 2026 08:22:09 +0000

I went looking for whether a large paste shows up in Google Docs version history. It turns out Google has never once used the word.

Not "paste". Not "clipboard". Not "keystroke". Zero hits across the four help pages that describe the record — version history, Drive file versions and activity, Office editing, and the page on creating, viewing and downloading a file — expanded so every collapsed section was open.

Before that reads as a broken search: the instrument works. Run the same counter over Google's own page about copying and pasting text and images and paste comes back 46 times. Run it over the Gemini in Docs page and Gemini comes back 24. The zeros are real absences.

This matters because of a conversation that happens a lot right now. Somebody points at a version history timeline and says either "you can see this was written" or "you can see this was pasted in", and both of them are assuming the tool has an opinion about it.

It doesn't. Or rather: Google has never published one.

And here is the part I did not expect, which is why I am writing this down.

The absence runs in both directions.

If you want to argue "look, no paste event, I typed this" — that is a claim about a feature Google does not describe, made to somebody who can open the same panel and check. It does not hold.

But if someone looks at your history and says a particular jump proves text was pasted in, that reading has exactly the same problem. It is an interpretation of a panel whose segmentation rules the vendor has never published. Nobody gets to read it confidently in either direction.

That symmetry is the useful thing to carry into a meeting, and it is the opposite of what most advice on this topic tells you.

It gets worse for the "you can see I typed it" argument, because Google documents that the record is lossy on purpose:

"The revisions for your file may occasionally be merged."

That sentence lives under a heading called "Unable to see a previous version of your file?", which tells you exactly what it is there to explain. Entries you expected to find are sometimes not separate entries.

Google's own remedy is naming, and it says so in the same breath: "You can create a named version to track your version history and make sure your versions aren't merged." Up to 40 named versions per document.

Three more things I found while counting, each of which will catch somebody.

Per-paragraph attribution is a paid feature. There is a right-click Show editors that answers the question a group project actually asks — not "when did this change" but "who wrote this paragraph". Read the line above it first:

"Important: This feature is available to only Google Workspace Business Standard, Business Plus, Enterprise Standard, Enterprise Plus, and Education Plus customers."

Education Plus is the only education entry on that list. If your institution is on a different edition, or you are in a personal account, that menu item does not exist for you. The version list still works; the per-passage attribution does not. Check the right-click menu on your own account today rather than the night before you need it.

There are two different records, and which one you are in depends on the file. Google flags this itself, in bold: "Version history for Google Docs, Sheets, and Slides is different than history for .pdf files, images, and other files stored in Drive."

The Drive one — the one for files you uploaded — has published limits, and they are exactly the numbers people wrongly attach to native Docs:

"A version might be permanently deleted after 30 days or if there are 100 newer versions."

So if your process was "write in Word, drop the .docx into Drive every few days as a backup", what you built is a Drive file-version stack with a rolling deletion rule on it, not a Google Docs history. There is a Keep forever in the Manage versions menu. Pin the earliest two or three now — it takes a minute per file, and it is the only thing in this whole area with a published expiry.

In Office editing mode, one route is closed. If you never converted, and you are editing the .docx directly in Docs, version history still exists — but Google lists this among the features that are not available:

Under "Version History," make a copy of an old version of the document

Making a copy of an old version is the standard way to get one dated state out of the panel and into an email attachment. On a .docx in Office editing mode, that is gone.

So, the four things actually worth doing, none of which take long:

Open the panel and scroll to the bottom. The date on the oldest entry that is actually there — not the date you started — is what your history covers.
Name a version at the end of each real work session. Date plus two words. It stops merging, and per Google's own description of the delete commands, a named version also survives Delete all versions, which "can remove all versions of your document that have not been explicitly named".
Check whether Show editors exists on your account. Select a paragraph, right-click, look.
If your drafts are uploaded files rather than native Docs, pin the early ones. Manage versions → Keep forever.

One last thing on offline work, because it produces the pattern people misread. Google says offline changes "will save to your device as you enter text, and will save to Drive once reconnected". What it does not document is what timestamp those versions end up carrying. So a long gap followed by a large arrival has at least one entirely ordinary explanation — and, like the paste question, it is not a pattern anyone can read confidently in either direction.

Everything above is either already true of your document or already false of it. There is nothing here you can switch on retroactively, which is the only real reason to read it before you need it.

Originally published at HumanPen: https://humanpen.net/blog/google-docs-version-history-ai-flag?utm_source=devto&utm_medium=article&utm_campaign=D209

Turnitin's policy on code is one sentence, filed under a question about handwriting

Nylah Reynard — Thu, 03 Sep 2026 06:44:54 +0000

I went looking for what Turnitin says about code, expecting to find nothing. What I found was one sentence, and it is filed in a place you would never look for it.

The sentence is: "we are not pursuing ChatGPT code detection at this time."

It is not in the code section, because there isn't one. It is the last line of the answer to a completely different question — "Why is AI detection not being added to Gradescope?" The rest of that answer is about handwriting. Someone appended the code policy to it and moved on.

That is a strange place for it, and worth knowing, because Gradescope is where a lot of programming coursework gets handed in. If your implementation goes to an autograder and your written report goes to a Turnitin assignment, those are two pipelines doing two jobs, and the AI writing percentage you eventually see was computed on the second one only.

The other sentence, the one in the FAQ where you would expect it, says the model "does not reliably detect AI-generated text in the form of non-prose, or code, nor does it detect short-form/unconventional writing such as bullet points (short non-sentence structures)."

Read one line further, though. That is where it stops being trivia:

"This means that a document containing several different writing types would result in a disparity between the percentage and the highlights."

A coursework report is a document containing several different writing types by construction. So that disparity is not a bug you have hit. It is the normal state for this genre.

Here is what that means in practice, and it took me a while to see it properly.

Your report is two documents stapled together. One of them is listings, pseudocode, terminal transcripts, config, tables. The other is the prose between them: the design rationale, the algorithm walk-through, the complexity analysis, the evaluation discussion.

Only the second one is being measured. Turnitin defines it as "individual sentences contained in paragraphs that make up a longer piece of written work, such as an essay, a dissertation, or an article, etc." Your listings are not in the denominator. The FAQ says so directly: "This percentage is not necessarily the percentage of the entire submission."

So the number is a statement about a slice of your file, not your file. If your report is listing-heavy, that slice can be small. There is even a floor — a submission needs at least 300 words of prose in long-form format before a report is generated at all, which a page-heavy but prose-light report can sit under while looking perfectly substantial.

And now the part that actually bothered me.

The prose that is measured is the most uniform prose in the document. Turnitin publishes what its false positives tend to have in common: "content without a lot of structural variation, text that literally repeats itself, or text that has been paraphrased without developing new ideas."

Read that against a well-written technical document. Structural variation is the thing a reference section deliberately removes. Every function gets the same frame — name, parameters, return value, failure modes — so a reader who learns the frame once can skim the rest. Saying it the same way twice is how you tell a reader that two components behave the same way. A style guide telling you to vary the shape of each entry would be a bad style guide.

The algorithm walk-through has the same shape for a different reason: it restates in English what the listing above it already says, and restating something has nowhere to go stylistically. Every step opens with the step. Every sentence has the same subject. The paragraph is a transcript of control flow.

Two honest limits on that. Turnitin gives no frequency for those properties — only a list of what false positives "can include" — so nobody can tell you how much of the effect this accounts for. And you cannot reason backwards from the model, because the FAQ also says it "is not explicitly programmed to evaluate specific signals such as 'burstiness,' 'perplexity,' or other individual metrics sometimes referenced in public discussions."

But the reason I am writing this is the asymmetry, which gets much less attention than the percentage does.

The half of your report that is excluded from the measurement is not inert background. It is the half where one changed character makes the document wrong. And a revision pass — yours, a co-author's, a tool's — reads it whether or not anyone is scoring it.

getUser quietly becoming get_user means your prose now names a function your code does not define. A command with a flag reworded is a command that no longer runs. A log line inside quotation marks is a quotation, and rewording it makes it a fabrication. None of this is visible on a read-through, because it all reads perfectly well.

There is a subtler one. A technical document gives one concept one name. If a pass leaves hash map in section 3 and dictionary in section 4 for the same object, or alternates worker and thread, the document has stopped telling the reader whether those are one thing or two — and a marker cannot resolve it without reading your code. No score enters into that in either direction. It is just damage.

It cuts against a habit that serves you everywhere else. In most writing a defined term is a word choice. In this genre it is closer to an identifier.

So the checking pass I would actually run, in this order:

Copy every command out of the document and run it in a scratch directory. Setup instructions rot first and get reread last.
List the identifiers your code defines and grep the document for each one. Anything in the code and missing from the prose is a rename that happened without you.
Pick your five load-bearing concept terms and search each. One name per concept, everywhere.
Read every complexity claim against the function it describes. O(n log n) and "efficient" are not interchangeable, and only one of them is markable.
Diff anything inside quotation marks against a real run. Log lines and error messages are quotations.

One last thing, and it is Turnitin's sentence rather than mine: the model "may not always be accurate (it may misidentify human-written, AI-generated, and AI-paraphrased text), so it should not be used as the sole basis for adverse actions against a student."

And separately from all of the above: what your department permits you to generate is set by its academic integrity policy, not by what a detector measures. Those are two different documents, and answering one does not answer the other.

Originally published at HumanPen: https://humanpen.net/blog/computer-science-report-ai-detection?utm_source=devto&utm_medium=article&utm_campaign=D206

Does editGPT Preserve Citations and Track Changes? A DOCX Test You Can Run

Nylah Reynard — Sun, 30 Aug 2026 17:42:22 +0000

Does editGPT Preserve Citations and Track Changes? A DOCX Test You Can Run

Does editGPT preserve citations? Its public Word workflow says you can import a Word document, edit it with AI, and export a DOCX with Track Changes. That means the output can show a trail of edits. It does not, by itself, prove that citations, numbers, tables, formatting, or revisions already present in the file were preserved. Those need a before-and-after DOCX test.

That distinction matters most for academic writing. Track Changes can tell you that a sentence was replaced. It cannot tell you that a citation still supports the same claim, that 0.48 kept its role as a coefficient rather than becoming a sample proportion, or that an old supervisor deletion remained separate from a new AI edit.

The same page names bold and italics as examples of formatting support. It does not turn the phrase that follows, and more, into a specification for every Word object. A returned .docx and an intact academic document are two different acceptance gates.

I would test them separately.

Start with a disposable copy of a real document that you are authorized to upload. Do not use a clean paragraph. Give the file the same kinds of fragile objects that your actual submission contains.

Put these six things in the sample:

One real citation attached to one specific claim, plus its reference-list entry.
Two numbers with different jobs, such as a sample size and a measured result with a sign, decimal, unit, and date.
A small table with a known row and column count and two cells you can identify by coordinates.
One pending Word insertion and one pending deletion created before the import.
One bold span and one italic span, each applied to a distinctive phrase.
A plain sentence outside the intended edit area, so you can tell whether the request changed more than expected.

Keep the original untouched. Record the filename, file size, Word version, and whether the document opens without a repair warning. Open the Reviewing pane and take a screenshot of the two existing revisions. This is your baseline, not busywork. Without it, a returned file can look fine while quietly changing the history underneath.

The citation needs more than a string check. Record the final six words of the claim it supports and the citation immediately following that claim. After the round trip, verify the author, year, locator, punctuation, and reference entry. Then check the attachment: does the citation still follow the same claim?

A citation can survive character for character and still fail if it moves to the next sentence.

Do the same for numbers. Write down each value, its unit, and its sentence role. 128 participants and 12.8 percent share digits but make different claims. A fluent rewrite that swaps their roles is not preserved just because both numbers remain somewhere in the file.

For the table, record its dimensions and two sentinel cells, for example row 2, column 1 and row 3, column 3. After export, count the rows and columns again. Check the two cells by position, not by searching for their text elsewhere in the document. If the table contains a subtotal, recalculate it from the returned cells.

Use one bounded edit request. Do not change the mode, prompt, and file at the same time. If the interface offers settings, record them before you start. Export the result as DOCX, then inspect the file in Word rather than relying on a browser preview.

Here is the ledger I would use:

Check	Baseline to record	Pass condition in the returned DOCX
Citation attachment	Exact citation, supported claim ending, and reference entry	Citation is unchanged and still belongs to the same claim
Numeric roles	Value, sign, decimal, unit, date, and sentence role	Every token and its meaning remain attached
Table geometry	Row count, column count, two coordinate-addressed cells, and any subtotal	Shape and cell positions match; subtotal still recalculates
Bold and italics	Exact styled phrases	Each style remains on the same words
Existing Track Changes	One old insertion and one old deletion, with anchor text and author label	Both remain pending and distinguishable from new edits
Returned file state	DOCX suffix, clean open, editable state, and original file size	File opens without repair and can still be edited, saved, closed, and reopened
Scope sentinel	Exact sentence outside the requested edit	Sentence remains unchanged

The revision-history row deserves its own pass. In Word's Reviewing pane, separate edits that existed before upload from edits introduced during the editGPT round trip. Confirm that the old insertion and deletion are still pending, still attached to the same text, and still usable. Then accept or reject one new edit, save the document under a new name, close Word, and reopen it.

That last reopen catches a different failure class. A file may display correctly once but lose editability or ask Word to repair its contents after saving. The deliverable is not finished until it survives that cycle.

Do not collapse the ledger into one score. Six clean rows do not cancel a moved citation. The failed object is the result. It tells you whether this workflow fits the document you actually need to submit.

This test also has limits. One passing DOCX supports one file shape, one request, one set of options, and one product state. It does not prove that every reference manager, field, footnote, equation, comment, or complex table will behave the same way. Add those objects when they matter to your own document.

Use non-sensitive material unless your rules allow the upload. editGPT's Privacy Policy says submitted text and files are used to provide the service. It separately says documents, files, and submitted text are not used for training. Its deletion statement is narrower: when a user deletes a document or file, that document or file is permanently removed from the servers. Those are the vendor's policy statements, not an independent security or deletion audit. Your course, client, publisher, or institution may impose a stricter rule.

I did not upload a file to editGPT, run its editor, or test an export for this article. There is no preservation result or detector result to report. The public claim is specific enough to design a fair test. Only the returned file can answer whether your citation, table, revisions, and editable document state survived it.

Track Changes helps you review what changed. The ledger tells you whether the document still means and behaves the way it did before.

Originally published at HumanPen: https://humanpen.net/blog/editgpt-ai-rewriter-review?utm_source=devto&utm_medium=article&utm_campaign=d166

GPTHuman's Own Scores Cannot Verify Facts or Citations. Here's a Deterministic Test

Nylah Reynard — Sun, 30 Aug 2026 09:37:12 +0000

GPTHuman's Own Scores Cannot Verify Facts or Citations. Here's a Deterministic Test

This week I opened GPTHuman's output-quality page to find out what its three scores were supposed to settle. I copied Human Score, Similarity Score, and Readability Score into my notes, then tried to add a fourth column: did the evidence survive?

That column stayed blank.

GPTHuman's own output-quality guide says the three numbers describe different features of the result and that none is a complete quality measure. It also says they do not independently verify factual accuracy, quotations, citations, plagiarism, policy compliance, authorship, or the verdict of an outside detector.

That is a useful limitation, not a footnote to skip. It tells you what kind of test to build.

The Human Score concerns patterns that GPTHuman's system associates with human-like writing. Similarity concerns how closely the result resembles the source. Readability uses the Flesch-Kincaid method to estimate how easy the text is to read. A result can look strong on all three and still change not to nothing, move a citation to the wrong claim, or reverse a threshold.

So I would not use any of those scores as the acceptance criterion. I would give the tool a source with facts that have only one correct answer, then mark each answer pass or fail.

Here is the source. It is 83 whitespace-delimited tokens. The name, event, and figures are invented, so no real paper or private data needs to enter the test.

Rivera (2025, p. 12) wrote, "Batch A stayed below 4.75 ms." The audit covered 128 records on 12 March 2025. Batch A contained 64 records and 9 exceptions; Batch B contained 64 records and 8 exceptions. The combined exception rate was 13.28% (17/128). The rate applies only when room temperature is at or below 21.5 C. Because the sensor failed after record 96, records 97-128 were excluded from the latency average but remained in the exception count. The conclusion is preliminary, not final.

Put this table directly under it:

Cohort	Records	Exceptions	Rate
Batch A	64	9	14.06%
Batch B	64	8	12.50%
All	128	17	13.28%

The paragraph is short on purpose. GPTHuman's meaning-preservation guide warns that exact preservation cannot be assumed in every passage. It specifically tells users to check names, dates, numbers, units, quotations, citations, conditions, exceptions, and qualifications. This fixture puts most of those failure points into a space you can inspect in a few minutes.

Here is the ledger I would use:

Check	Fixed baseline	Pass condition
Citation	`Rivera (2025, p. 12)` belongs to the sentence that follows	Author, year, locator, and attachment stay unchanged
Quotation	`"Batch A stayed below 4.75 ms."`	Quotation marks and every word inside them stay unchanged
Dates	`2025` and `12 March 2025`	Both dates keep their value and role
Units	`4.75 ms` and `21.5 C`	Values remain attached to the same units
Arithmetic	9/64 = 14.06%, 8/64 = 12.50%, 17/128 = 13.28%	All three rates still recalculate after rounding to two decimals
Condition	The rate applies only at or below 21.5 C	`only`, the downward direction, and the inclusive 21.5 C boundary all remain
Exclusion	Records 97-128 leave the latency average but stay in the exception count	The two populations are not merged, swapped, or shortened
Qualification	The conclusion is preliminary, not final	Uncertainty is not promoted into certainty
Table	Four headers, three rows, twelve body cells, fixed row order	Every label, value, and position survives

This is intentionally unforgiving. If the output changes 13.28% to 13.3%, that may be acceptable for some jobs, but it fails this fixture because the baseline asked for two decimal places. If at or below becomes below, the new sentence excludes exactly 21.5 C. That fails too. Fluent prose does not get to overrule the source.

Do not merge the nine rows into a single percentage. A pass rate of eight out of nine hides whether the failed row was a table label or the word not. Keep the failure attached to the thing that changed.

The setup around the run matters as much as the text. Save an untouched copy first. Record the language, mode, plan, date, and whether the source was pasted or imported. Change one setting at a time. Save each result under a new filename.

Then compare exact tokens before judging style. Recalculate the three rates. Read the condition, exclusion, and qualification as logic, not as approximate meaning. Count the table cells after copying the result out of the browser.

GPTHuman's testing guidance makes the same separation at a broader level. It says meaning preservation, factual consistency, readability, language quality, originality, and named-detector results answer different questions. The page does not publish a universal independently verified bypass rate, and it says a defensible detector report needs a defined sample set, settings, detector versions, date, threshold, and complete outcomes.

I did not run GPTHuman or a detector for this article. There is no pass rate to report. The point is to define the test before seeing the output, so a pleasant result cannot quietly move the goalposts.

One successful run would still support only a narrow claim: this fixture passed under this language, mode, input route, plan, and date. It would not establish that every citation survives, every subject behaves the same way, or a future detector will agree.

GPTHuman's responsible-use page also tells users to verify facts, calculations, quotations, and citations and to follow the rules that apply to the work. That last part stays outside the ledger. A technically preserved result can still be disallowed by a course, employer, publisher, or client.

The three scores can help you inspect an output. They cannot approve it. For evidence-heavy writing, the boring little ledger is the more useful result.

Originally published at HumanPen: https://humanpen.net/blog/gpthuman-ai-humanizer-review?utm_source=devto&utm_medium=article&utm_campaign=d163

I put three Turnitin update pages side by side. They were tracking different things

Nylah Reynard — Sun, 30 Aug 2026 07:27:41 +0000

I put three Turnitin update pages side by side. They were tracking different things

I put Turnitin's three update pages side by side and searched each one for the same 2026 dates.

The page titled AI writing detection model had February 12 and May 5. It had no July architecture statement, no August 4 category merge, and no August 18 Arabic launch. Those two August entries were in Turnitin release notes. The Turnitin product updates page carried them too, with rollout details that the shorter release entries did not include.

That was the point where "the release notes say" stopped being a usable source label.

The phrase sounds precise, but it can point to three pages doing three different jobs. The model log records dated changes to detection behavior. The general release page mixes AI Writing Report changes with releases for other Turnitin products. The product updates page adds scope and the vendor's reason for a change, but it is not a complete model history.

A fourth tab supplied the entry none of those three pages carried. Turnitin's AI writing detection capabilities FAQ contains a July 2026 architecture statement. It says Turnitin replaced an ensemble of multiple models with one model. There is no day attached to it, and the statement does not appear in the model log.

One supposed changelog had become a reconstruction from four pages.

Once the sources were separated, the 2026 sequence made more sense.

On February 12, Turnitin said it updated the AI writing detection model to improve recall while keeping its false-positive rate low. The settings and report highlighting did not change. Previously generated reports were not recalculated, so an existing file had to be resubmitted to use the updated model.

On May 5, the Spanish-language model was updated to detect content from newer GPT and Gemini model families. This was limited to Spanish submissions. Again, the report interface stayed the same and old reports did not change unless the file was resubmitted.

The July FAQ entry concerns architecture. It does not provide a version number or a before-and-after score table. It also does not turn the separate English, Spanish, Japanese, and Arabic detectors into one multilingual model. The August Arabic release still describes those language models as separate.

Then the visible report changed. On August 4, the English AI Writing Report combined its blue and purple categories into one blue category. Turnitin said detection of text that may have been AI-generated and then processed by a paraphraser or bypasser remained in place. The display changed. The documented capability did not disappear. Older reports keep the old colors until the file is resubmitted.

On August 18, Modern Standard Arabic joined English, Spanish, and Japanese as a supported language. Turnitin described the Arabic detector as a separate model. The institution still needs the AI writing detection feature licensed and enabled, and the rollout also covers enabled iThenticate 2.0 customers.

These entries cannot be compressed into "Turnitin released a new model." February and May concern existing detection behavior. July concerns architecture. August 4 changes how an English report is read. August 18 changes which languages can be processed.

That distinction matters when two reports show different numbers. A later score does not identify its cause. The file may have changed. The same file may have been resubmitted after a model update. The submission may have gone through a different language detector. More than one of those things may be true.

The generation date on the report is more useful than the date someone downloaded it. The exact report name matters too. An AI Writing Report and a Clarity Writing Report are not interchangeable just because both appear under the Turnitin name.

The older entries had the same source-reading trap.

Turnitin's December 15, 2023 model-log entry mentions scores for submissions under 300 words. Read alone, that sentence can sound like a current warning about short papers. The heading and preceding paragraphs give it a much narrower meaning: a bug introduced on December 6 had allowed files below the minimum requirement to be processed, reports from December 6 through 15 were affected, and the issue was resolved.

Today, Turnitin only generates the report when a file contains 300 or more words that qualify as long-form prose. The old sentence describes a closed bug window. It gives us no basis for judging a paper submitted today at either 300 or 500 words.

The general release page creates another easy mistake because several products share one long screen. The product label beside each entry is part of the claim. The August 4 category merge belongs to the English AI Writing Report under named Originality configurations. A nearby Clarity release cannot expand that scope.

I did not run a document through the detector for this check. This was a documentation audit. The pages establish what Turnitin says changed and when. They do not show whether one paper's score would rise or fall, and they do not support an accuracy comparison.

The audit notes now keep the exact page title, the date as published, the product and language scope, and whether an old report needs resubmission. If a day is missing, it stays missing. If the source only describes a display change, the note does not call it a model change.

A date without its page and scope is only half a changelog entry. Keep those pieces attached and the record becomes useful. Collapse everything into "Turnitin's release notes," and the citation has already lost the fact it was supposed to prove.

Originally published at HumanPen: https://humanpen.net/blog/turnitin-detection-model-changelog?utm_source=devto&utm_medium=article&utm_campaign=d147

I finished the paper. Then the AI score gave me another assignment

Nylah Reynard — Fri, 28 Aug 2026 15:21:21 +0000

The paper was finished until the AI score arrived.

I had done the work and could explain every section. The citations were checked. The weak parts had already been revised. Then the number turned a finished paper into work I was expected to do again.

The new task had nothing to do with finding a better source or fixing a bad argument. It was a loop built around the report. Locate a highlighted passage. Change words that already say what I mean. Make sure the edit did not disturb a quotation or citation. Hand the revision back for another check.

There is no credit for this task. There is no marking rubric either. I am trying to satisfy a classifier without being told what finish line would count.

That extra work is a detector time tax. It is paid in the part of the deadline that could have gone toward reading, checking evidence, asking for feedback, or getting some sleep. The paper does not become more thoughtful because its sentences have been moved around for a number.

The score also collapses questions that should stay separate. Authorship is about who did the intellectual work. Course policy decides which kinds of assistance were allowed. The detector supplies a signal about the text. One answer cannot stand in for the other two.

A student can write the paper and still violate a rule about editing tools. A student can also follow the tool policy and receive an AI flag. Treating the score as a verdict skips both of those facts.

Turnitin's own report guidance says its model may misidentify human-written, AI-generated, and AI-paraphrased text. It says adverse action needs further scrutiny, institutional policy, and human judgment. The company's FAQ says instructors should not use the percentage as a definitive grading measure.

That is the vendor drawing a boundary around its own output. The report can start a closer look. It cannot reconstruct who chose the argument, found the sources, or made the decisions inside the paper.

Still, telling a student to ignore the number is easy advice from the side that does not carry the grade. If an instructor or submission process wants the score lowered, a refusal can be principled and expensive at the same time. Students comply because the risk belongs to them.

An authorship concern should lead to a human conversation. Ask me to explain the thesis. Ask why I used a source or how a section changed between drafts. Apply the course policy to evidence from the writing process.

If the paper has already been submitted and an investigation has begun, preserve the original file. Rewriting an existing submission would change the evidence when the dispute is about how that evidence was produced.

Before final submission, or during a revision the student has been explicitly allowed to make, the situation is different. The work still has to be mine. The course or assignment rules must expressly permit this kind of AI-assisted or third-party rewriting at that stage. Any disclosure, approval, and submission requirements still apply.

To save my valuable time, I used HumanPen for this part.

For an English DOCX, PPTX, or TXT file, the tool can use a Turnitin or iThenticate report to locate the flagged passages inside the document. That removes the manual search and the trip through a paste box for every passage. Eligible results can continue lowering AI for free.

It cannot decide whether the use was allowed. It cannot prove authorship, cancel a disclosure duty, or promise a score. Every changed paragraph still needs to be read. The meaning and citations still need to be checked. I keep the original and remain responsible for the file I submit.

That division of labor makes sense to me. I do the thinking. A tool can take some of the mechanical work out of a loop I did not ask for. The final review remains mine.

The score should be a reason for a person to examine the evidence, not a hidden style guide that students must reverse-engineer. The first approach asks whether the work is honest. The second teaches students that pleasing a classifier matters more than writing well.

I wrote the paper. I should not also have to write a second version for the machine.

Build a six-slide failure file before you trust a PowerPoint humanizer

Nylah Reynard — Wed, 26 Aug 2026 07:33:42 +0000

Do not judge a PowerPoint humanizer from its feature page alone. Build a failure file first.

The pages I reviewed this week kept describing inputs. One had a paste box. Another listed .pptx in an upload control. A third talked about presentations without saying what the download would be.

None of that tells you whether a returned deck will still work.

An upload control can show that a page offers a file type. It does not prove that the backend accepts and processes the upload. Even a successful upload answers only half the question. You still need to know whether the result is an editable PowerPoint file and whether the objects inside it survived.

Build a six-slide acceptance fixture with invented text and deliberately awkward objects. Make it safe to throw away, and give every slide one job.

Slide one tests inheritance. Use a custom master, two associated layouts, a footer and a small logo placeholder. After the round trip, open Slide Master view and check the counts, layout assignments, footer and placeholder position.
Slide two tests overflow. Keep the title short, but make the body placeholder almost full. A rewrite can keep the box in the same position and still make the slide unusable by clipping a line, covering another object or shrinking the font too far.
Slide three tests non-obvious text surfaces. Add a table and a SmartArt graphic, each with a distinctive phrase. The result has to put the phrases in the right cell and shape, and both objects need to remain editable.
Slide four tests the chart. Give it a title, data labels and simple values that are easy to remember. A chart screenshot can look perfect after the underlying object has been flattened. Open the chart data and change a value.
Slide five tests time. Set three objects to enter in a known order. A still image cannot tell you whether that order survived, so inspect the Animation Pane and play the slide.
Slide six tests the notes boundary. Put PPTX-NOTE-CHECK-47 and one sentence of disposable copy in the Notes pane. The token should stay attached to slide six. The sentence should change only if speaker notes were part of the selected scope.

The point of the fixture is not realism. A real thesis defense deck may have dozens of layouts, linked charts and years of inherited formatting. That makes it a bad first test because a failure is hard to isolate. Six controlled slides show you where to look.

Before upload, record the baseline: slide count, master and layout count, chart type, animation order, notes token, and the exact text selected for rewriting. A screenshot or PDF catches visual drift. The original .pptx catches behavior a flat baseline cannot show.

Run the same readback sequence for every service.

First, duplicate the fixture. Keep the clean original untouched.

Second, choose the smallest rewrite scope the service offers. One or two text objects are enough. Record what you approved because "the deck changed" is useless unless you know what was allowed to change.

Third, upload the copy and download whatever the service returns. Write down every limit shown during the run and the unit attached to it. A file cap and a character cap describe different bottlenecks.

Fourth, open the result in desktop PowerPoint and make three small edits: one in ordinary slide copy, one inside SmartArt, and one in the chart's data sheet. Then save, close and reopen the file. This catches the friendly-looking output that falls apart at the next ordinary edit.

Fifth, leave Normal view. Inspect layout inheritance under View > Slide Master, open slide six's notes, and check motion order with the animation controls. Play the animated slide instead of assuming the sequence is intact.

Last, compare every untouched object. Check text, labels, numbers, notes and unselected slides one by one. Any difference needs an explanation tied to the scope you approved.

Keep the conclusion deliberately narrow. If the service passes the chart test, you can say the chart in this fixture remained editable. You cannot claim that every linked Excel chart in every corporate template will behave the same way. If the fixture did not include speaker notes, notes stay unverified. A simple deck does not certify a complicated one.

This is the distinction feature pages blur. "Supports PowerPoint" sounds like a product category. In practice, it is a set of observable file behaviors, and each one needs its own failure point.

A good paragraph can distract you from a broken deck. The fixture reverses that priority. The file has to survive before the prose gets a vote.

Originally published at HumanPen: https://humanpen.net/blog/ai-humanizer-for-powerpoint?utm_source=devto&utm_medium=article&utm_campaign=D91

The upload button was not the document test

Nylah Reynard — Wed, 26 Aug 2026 03:04:51 +0000

Two AI humanizer pages showed me an upload control this week. I still left the editable-return column blank.

On undetectable.com, the logged-out input area showed Paste Text, Upload Doc, and a 0 / 2,000 words counter. Grammarly's current AI Humanizer page had an Upload file control too.

Both observations show that the public pages offer a file-upload entry point. They do not prove that a selected file is accepted or what comes back.

That sounds fussy until the input is a DOCX with footnotes, fields, citations, and tables, or a PPTX where one extra line can overflow a text box. Upload is an intake event. A document round trip includes the output format, editability, document structure, and the parts that were supposed to stay untouched.

The checked undetectable.com page did not state that an uploaded document returns in the same editable format. The checked Grammarly page did not state that either. That is not a claim that either product lacks the feature. It means the two upload controls cannot carry that conclusion on their own.

I did not submit a document to either product during this research. So I do not have a format-retention result to report. What I have instead is the acceptance test I would run before trusting any humanizer with the real file.

Make the test disposable and small. It should still contain the structures that make the real document expensive to repair:

Save a clean copy and record the exact input extension.
Add a heading, a footnote, one in-text citation, a numbered list, and a small table to a DOCX. For a PPTX, add a text box close to its lower boundary and one slide with notes.
Mark one paragraph as the intended rewrite scope. Put a distinctive sentinel sentence in a paragraph that should stay outside that scope.
Run the public workflow on the exact tier you plan to use. Record the date, tier, displayed counting unit, and every file the product lets you download.
Open the result in Word or PowerPoint, not only in a browser preview. Record the extension, whether normal editing still works, and whether fields or linked elements remain live.
Compare the clean input with the result. Check the selected paragraph, the sentinel paragraph, citation text, footnote numbering, table cells, list numbering, slide overflow, and notes.
Keep both files and the checklist. A screenshot of the upload button is not evidence for any item after step four.

The protocol is deliberately boring. Every row has a result another person can inspect. DOCX in and DOCX out are observable. "Looks fine" is not. A field that still updates is observable. A familiar page layout in a screenshot is not.

It also keeps vendor claims in the right column. If a page promises same-format editable return, write that down as a public claim before the run. Then test it. If a page only shows an upload control, write down exactly that and leave the return field unresolved until the workflow produces evidence.

The same discipline applies to scope. A product may accept a full file yet rewrite more of it than you wanted. The sentinel paragraph makes that visible. If the selected paragraph changes and the sentinel does not, you learned something useful about this run. If both change, you caught the mismatch on a disposable file.

Our product is HumanPen. Its public pages list DOCX, PPTX, and TXT as accepted inputs and promise editable Word and PowerPoint returns. They also describe passage selection that leaves text outside the confirmed boundary unchanged. Those are vendor statements. HumanPen should go through the same acceptance protocol rather than receiving a free pass because we wrote the protocol. Eligible results can continue lowering AI for free.

None of this predicts what Turnitin will show afterward. The test answers a different question: can the document survive the workflow you are about to depend on?

An upload button is evidence that the page offers a file-upload entry point. Stop there, and successful intake remains unresolved. Follow the file all the way back into its native editor, and the marketing label turns into a testable contract.

Originally published at HumanPen: https://humanpen.net/blog/ai-humanizer-comparison-2026?utm_source=devto&utm_medium=article&utm_campaign=D96

Accused of using AI on your dissertation? What to bring to the meeting

Nylah Reynard — Sun, 23 Aug 2026 19:01:20 +0000

Four things to bring, and two of them were written by the company that makes the detector.

None of this is about arguing that the tool is broken. That argument loses, and it loses for a specific reason I go into below — the flaw most people reach for was fixed in 2023 and the fix is documented. This is about the difference between a meeting that is about a number and a meeting that is about a document.

The short answer

If you have been called in about a Turnitin AI score on your dissertation, you have four things to bring to that meeting, and none of them require you to claim the tool does not work. The first is a sentence from Turnitin's own documentation saying an AI score should not be used as the sole basis for adverse action. The second is the report itself, which you are entitled to see. The third is your version history. The fourth is another sentence from Turnitin, this one saying that if your text has certain features common in dissertations, the high score should be discounted.

That is the outline. The rest of this article explains where each card comes from, what it does, and what it does not do. None of it teaches you how to deny using AI. It teaches you how to make the meeting about evidence and procedure rather than about a single number.

The distinction matters because the number is the thing you cannot argue with on its own terms. You did not compute it. You cannot inspect the model. What you can do is ask the people who did compute it to follow their own guidance, and bring the material that only you have.

Card one: Turnitin says the score should not be the sole basis

Turnitin's AI writing report guide says:

"Our AI writing detection model may not always be accurate (it may misidentify human-written, AI-generated, and AI-paraphrased text), so it should not be used as the sole basis for adverse actions against a student."

The sentence immediately after it is the one that gets dropped every time this quote is used:

"It takes further scrutiny and human judgment in conjunction with an organization's application of its specific academic policies to determine whether academic misconduct has occurred."

Read both sentences together. The first says do not use this number alone. The second says what should happen instead: further scrutiny, human judgment, and the institution's own policies. That is not a student talking. That is the company that built the tool telling the person holding the number to do more work before drawing a conclusion.

The FAQ page says the same thing in its own words: "the percentage on the AI writing indicator should not be used as the sole basis for action or a definitive grading measure by instructors." And a release note from December 2023 repeats it: "an AI Writing score should not be used as the sole basis for adverse actions against a student." Three pages, same instruction.

There is also a separate page titled How should I review the AI Writing report? which puts it differently:

"It is not meant to provide definitive answers in isolation. More important than any tool is the educator who sees the score and makes decisions balancing this information with their personal knowledge of their students, their work, and institutional policy."

The next sentence completes it:

"When educators look at the AI writing score and utilize it as a single data point rather than a definitive response, then it is being used as intended."

That is the company calling its own score a single data point. Not a verdict. Not a definitive response. A single data point. If your meeting starts with a number and no further discussion, the person running it is using the tool in a way the manufacturer says it should not be used.

What this card does not do: it does not say the number is wrong. It says the number alone is not enough. That is a weaker claim and a sturdier one.

Card two: you have the right to see the report

Turnitin's FAQ states two things that matter to you right now:

"Please note, only instructors and administrators are able to see the indicator."

And on the same page:

"The AI writing detection indicator and report are not visible to students."

The second sentence is followed by one that changes it:

"However, with the PDF download feature, instructors can download and share the AI report with students."

Put those together: you cannot see the AI score yourself by logging in. Your supervisor can. And your supervisor can download the report as a PDF and hand it to you. If nobody has done that, you are sitting in a meeting about a number you have never seen on a page you have never opened.

So the first request is simple. Ask for the PDF of the AI writing report. Not a screenshot of the percentage. The full report, because the full report shows you where the highlights sit, how many words were analysed, and whether the score is a real number or an asterisk.

If the number is between 1% and 19%, Turnitin does not display a percentage at all. It shows an asterisk. A forwarded number in that range is not something the report itself commits to.

What this card does: it moves the conversation from a claim about a number to a discussion of a document you can both look at. What it does not do: it does not tell you what the number will be. You might see a high score. But at least you will know what it is attached to.

Card three: your version history is timeline evidence

If you wrote your dissertation in Word, Google Docs, or Overleaf, the platform kept a version history. That history is a timestamped record of when changes were made to the document over days, weeks, or months. An AI-generated draft pasted in one go looks different from a document that accumulated edits across dozens of sessions.

This is the one piece of evidence that only you have. The institution does not have your version history. Turnitin does not have it. Your supervisor might have seen drafts at various stages but probably does not have the full edit log. You do.

What to bring:

The version history itself, either exported or shown on a laptop.
The earliest draft you still have, even if it was rough.
Any drafts you shared with your supervisor by email or through a shared document, with the dates those were shared.
Notes, outlines, or annotated PDFs you produced while working on the dissertation. These are the residue of a writing process, and their dates trace a path that does not look like a single generation event.

The point is not to prove a negative. You cannot prove that no AI was involved at any stage. The point is to show that the document has a history consistent with being written by a person over time. That is evidence the score cannot address, because the score only looks at the final text.

What this card does not do: it does not disprove anything. A version history can show that editing happened, and editing is consistent with a document that was drafted by a person, revised with feedback, and polished before submission. It is also consistent with someone pasting an AI draft and then editing it. What makes it useful is that it shifts the question from "is this number right" to "what does the full picture look like," and the full picture is something only you can present.

Card four: Turnitin says some text types get inflated scores

This is the card most people do not know they have. Turnitin's FAQ page lists characteristics of text that tends to produce false positives:

"Sometimes false positives (incorrectly flagging human-written text as AI-generated), can include content without a lot of structural variation, text that literally repeats itself, or text that has been paraphrased without developing new ideas."

The next sentence is the one that matters in your meeting:

"If our indicator shows a higher amount of AI writing in such text, we advise you to take that into consideration when looking at the percentage indicated."

Read what that covers. Content without a lot of structural variation. Text that literally repeats itself. Text that has been paraphrased without developing new ideas. Those three describe a large share of dissertation writing, especially literature reviews and methodology sections. A literature review summarizes existing work, which is a paraphrasing task by nature. A methodology section follows a standard structure with repeated phrasing. Neither is supposed to introduce new ideas, because the new ideas belong in the analysis and discussion chapters.

So if your flagged sections are literature review or methodology, the company that made the tool is telling the person reading the score to discount it for exactly that reason. Not you. The company.

This is also where you should be careful. Turnitin also published a release note in May 2023 acknowledging that false positives had been concentrated in the first and last few sentences of documents:

"Since launch, we have observed a higher incidence of false positive detection in the first few or last few sentences of a document. Many times these sentences consist of introduction or conclusion content written in a generic way. As a result, we have changed our detection logic to help reduce these false positives."

The key phrase is the last one: "we have changed our detection logic to help reduce these false positives." This was a fix announced in 2023. It is not a current weakness you can point to. It is evidence that the tool changes over time, which means two things for your meeting. First, a report generated six months ago may have been produced under different logic than one generated today. Second, arguing that the tool is broken is arguing against a target that has moved. Your position is stronger when you say the tool is improving and your case deserves to be looked at on its own terms, not when you say the tool is useless.

What not to do

Three things will hurt you in this meeting, and all three are tempting.

Do not say Turnitin is inaccurate. The company itself says its model may not always be accurate, and it says the score should not be the sole basis for action. That is your lever. If you go further and claim the tool does not work, you are making a claim you cannot support, and you are picking a fight with the institution's chosen system. The person across the table will dig in. The right stance is that the tool has a documented marginal error rate and documented guidance on how to handle it, and you are asking them to follow that guidance.

Do not refuse to talk. Silence reads as guilt. You have evidence to present. If you walk out, the meeting happens without your version history, without your drafts, and without anyone hearing the sentence about text types. The only way the cards on this list work is if you show up and put them on the table.

Do not bring the old "first and last sentences" argument. As we said, that was a 2023 fix, not a current flaw. If you bring it as evidence that the tool is currently broken, the person across from you can look it up, find the fix, and you lose credibility on everything else you brought.

How to prepare

Before the meeting, gather these things:

The AI writing report as a PDF. Request it if you do not have it. You need to know what the number is, where the highlights sit, and whether it is a percentage or an asterisk.
Your version history. Export it or have it ready to show on a laptop. If you used Overleaf, the page history is there. If you used Google Docs, the version history is in File > Version history. If you used Word, it depends on whether you had OneDrive autosave on, but even without it, your drafts and their file modification dates tell a story.
Your writing process material. Notes, annotated PDFs, outline drafts, email threads with your supervisor, feedback on earlier drafts. Anything that shows the dissertation was not produced in a single sitting.
A list of specific questions you want answered. Not a script, not a speech. Questions. "Which sections were flagged?" "Was the report generated before or after the May 2023 logic change?" "Does the flagged text fall under the categories Turnitin says can produce false positives?" Questions like these keep the meeting in a space where you are participating in an investigation rather than defending against an accusation.

The meeting is not a trial. It is supposed to be a review, and Turnitin's own documentation says it should involve further scrutiny and human judgment. Your job is to bring the material that makes that review possible.

Where we sit

HumanPen is a document rewriter. We are not going to tell you that running your dissertation through a rewriter will make an AI score disappear, because we do not make claims about future scores. What we can say is what the tool does: you upload the document with its AI writing report, and only the passages the report flagged are rewritten. The rest of the document stays verbatim. You review the output before it becomes anything final.

If you are in this situation because a report already came back high, and you want to revise the flagged sections before your meeting, that is one path. If you would rather go into the meeting with the original document and your version history and let the evidence speak, that is another path. Both are legitimate. The meeting comes first.

Frequently asked questions

Can I refuse to attend the meeting? You can, but it is the worst move you can make. The meeting is where you present your evidence. Without you there, the institution makes its decision based on the score alone, which is exactly the outcome Turnitin says should not happen.

What if the score is 100%? A score of 100% is not evidence that every sentence was generated by AI; it is a statistic over the qualifying prose the model was willing to read, on one date, under one model version. What matters in the meeting is the same: request the full report, bring your version history, and ask the specific questions.

Does version history prove I did not use AI? No. It shows that the document was edited over time in a pattern consistent with human writing. It cannot prove a negative. What it does is give the reviewer something to look at besides the score, and that is its value.

What if I did use AI for part of the dissertation? This article does not teach you how to deny using AI. If AI was used for some part of the work, the meeting is where that gets discussed alongside everything else. The documentation cited here, the version history, and the text-type guidance all apply regardless, because they are about how the score should be interpreted, not about whether AI was used.

Will running my paper through a rewriter fix the score? We do not make claims about future scores. What HumanPen does is rewrite the flagged passages you select. Whether the next report comes back lower is something we will not promise, because the model changes and the report is produced by Turnitin, not by us.

Bring the report, bring your history, bring your questions

If a Turnitin AI report has flagged your dissertation, the meeting is where you present your evidence. If you want to revise the flagged sections beforehand, upload the document with its report and only those passages get touched.

Originally published at HumanPen: https://humanpen.net/blog/accused-of-using-ai-on-dissertation?utm_source=devto&utm_medium=article&utm_campaign=d69

Does Turnitin Store Your Paper? What the FAQ Actually Says

Nylah Reynard — Sun, 23 Aug 2026 19:00:38 +0000

"Does Turnitin store my paper" is three questions wearing one coat, and the answers point in different directions.

There is no separate AI writing repository. Whether the paper itself enters the similarity repository is your institution's setting, not the vendor's. And the AI results — the percentage and the flagged segments — are retained regardless, inside the similarity report. All three come from the same FAQ answer, which is quoted below in full so you can see where the seams are.

The Short Answer

When students ask us whether Turnitin stores their paper, the honest answer is: it depends on what you mean by "store." Turnitin does not maintain a separate database dedicated to AI writing detection. However, that does not mean nothing is retained. AI detection results are saved as part of the similarity report, and your institution controls whether your paper itself goes into the similarity repository. The distinction matters, and we will walk through each piece.

No Separate Repository for AI Detection

The most direct statement on this topic comes from Turnitin's own FAQ. When asked whether submitted papers are added to a repository for AI writing detection, the answer is:

"No, it does not. There is no separate repository for AI writing detection, and customers retain the ability to choose whether to add their student papers into the repository or not."

The FAQ continues: "Our AI writing detection capabilities are part of our existing Similarity Report workflow."

What this tells us is that AI detection does not create a new, standalone database of your writing. The AI analysis runs on top of the similarity workflow that Turnitin already had in place. So when people worry about an "AI database" that collects AI-generated text for future matching, that is not how the system works. The AI detector evaluates text during the similarity check, but it does not file your paper into a separate AI-specific archive. What that similarity check compares you against is the repository, which is the subject of the next section.

Your Institution Controls Repository Submission

The same FAQ sentence contains an important clause that often gets overlooked: "customers retain the ability to choose whether to add their student papers into the repository or not." In Turnitin's terminology, "customers" means the institutions (universities, schools, districts) that license the service, not individual students.

This means your school decides whether your submitted paper is added to the similarity repository for future comparisons. Some institutions enable repository submission by default. Others do not. If you want to know whether your paper is being stored in the similarity database, the question to ask is not "does Turnitin store my paper" but rather "what repository settings has my institution chosen."

Turnitin itself does not force papers into the repository. The decision rests with the licensing institution, and settings can vary from one department to another. That same setting is what decides whether your own earlier draft will match your resubmission.

AI Detection Results Are Retained

Here is where the nuance becomes critical. While there is no separate AI repository, Turnitin does retain the results of the AI analysis. The FAQ states:

"Results regarding the percentage AI writing identified by the detector, along with the segments identified highly likely written by AI – are retained as part of the similarity report."

This means the AI writing detection percentage and the flagged text segments are saved within the similarity report for that submission. They are not stored in a separate AI database, but they are preserved as part of the report record.

The distinction we want to highlight is between "your paper is stored in an AI database" (which does not happen) and "your AI detection results are saved within a report" (which does happen). Both things are true at the same time, and confusing the two leads to misunderstandings about what Turnitin actually retains.

AI Score and Similarity Score Are Independent

One common source of confusion is whether the AI detection percentage affects the similarity score. Turnitin addresses this directly:

"The Similarity score and the AI writing detection percentage are completely independent and do not influence each other."

The FAQ explains: "The Similarity score indicates the percentage of matching-text found in the submitted document when compared to Turnitin's comprehensive collection of content for similarity checking."

The two scores measure different things. The similarity score compares your text against existing content in the repository. The AI score estimates the likelihood that portions of your text were AI-generated. They run in the same workflow, but they do not feed into each other. A high AI percentage does not raise your similarity score, and a high similarity score does not affect the AI percentage; reading the two scores as the same thing is the mistake this causes most often.

AI Detection Is Not Available in All Turnitin Tiers

Another factor that affects what happens to your paper is which Turnitin product your institution licenses. Not every Turnitin subscription includes AI writing detection. The FAQ states: "AI writing detection is only available to customers that license Turnitin Originality." For iThenticate 2.0 users, the FAQ notes: "iThenticate 2.0 customers can get access to this feature if they license AI writing capabilities as an add-on."

The FAQ adds: "If you are a Turnitin Similarity, Turnitin Feedback Studio (TFS) or Originality Check customer, please speak to your Turnitin account manager regarding access to AI writing detection."

This matters because if your institution has not licensed AI detection, then the AI analysis simply does not run on your submission. The question of whether your paper is stored for AI purposes becomes less relevant when the feature is not active. We mention this because the storage question is often inseparable from the licensing question: which Turnitin product is your school actually paying for?

What This Means for You

To summarize what we have covered:

There is no separate AI writing detection repository.
Your institution decides whether your paper enters the similarity repository.
AI detection results (the percentage and flagged segments) are retained as part of the similarity report.
The AI score and the similarity score are independent and do not influence each other.
AI detection is only available to institutions that license Turnitin Originality (or purchase it as an add-on for iThenticate 2.0).

The takeaway is that "does Turnitin store my paper" is not a yes-or-no question. The paper itself may or may not be in the similarity repository, depending on your institution's settings. The AI detection results, however, are retained within the similarity report regardless. Understanding this distinction can help you have a more informed conversation with your instructor or institution about what happens to your work after submission.

HumanPen Works With Your Drafts

HumanPen supports DOCX, PPTX, and TXT files. We charge by the word, so 1,000 words costs 100 credits, and only the words actually rewritten are billed. Upload your draft, select the passages you want adjusted, and get your file back in the same editable format.

Originally published at HumanPen: https://humanpen.net/blog/does-turnitin-store-your-paper?utm_source=devto&utm_medium=article&utm_campaign=d69