Introducing the Standalone AI Text Detector
How we built a detector workflow that prioritizes actionable feedback over a single aggregate score
The problem with one number
Imagine finishing a draft and seeing "62% AI likelihood" in the corner of your editor. Now what? You know something is flagged. You do not know which paragraphs triggered it, whether the opening or the conclusion is the culprit, or whether the revision you just made actually helped. You copy the draft somewhere else, re-paste it, and hope the number moves.
That was the in-document detection experience before this release. A single aggregate score, embedded in editor chrome, tied to a live document that kept changing. Grades were ephemeral. Risk was unlocalizable. Comparing "before tutoring session" to "after" meant keeping notes in a separate tab.
We needed to make the grade itself a first-class artifact, not a sidebar number.
What a better workflow looks like
The naive shape:
Four things break with this shape. There is no map from score to paragraph, so edits are guesswork. Output disappears on refresh, so users cannot compare revisions. Typing and grading run in parallel, so users mistrust numbers that move while they are still in the middle of a sentence. And when a scan fails, the UI shows nothing or shows zero, which looks identical to a clean draft.
The standalone detector workspace fixes all four. Editable source sits in the left pane. Grading output and snapshot history sit in the right. Three explicit actions control the cycle: Create, Re-grade, Clear. Nothing rescores silently while you type.
How the workspace is structured
The key insight was to treat a grade the way a CI system treats a build artifact: addressable, numbered, and restorable. Every snapshot freezes the exact string that was scored along with its per-section map. "What did this draft look like when it scored 62% AI?" is always answerable, even three revisions later.
Section scoring versus whole-document scoring
For longer drafts, we split content into paragraph-level units and score eligible sections independently. The right pane maps scores into graded visual states (green, amber, red) so users scroll to heat instead of re-reading blindly. The cost is more API calls and more UI state to manage. The gain is diagnostic precision: a user can see that the first and third paragraphs are fine and the second one is the problem, then focus the edit there.
For shorter inputs, whole-document mode yields a single top-level score within a bounded text window. Large documents intentionally do not pretend to be fully scored in one cheap pass.
How snapshots work
Each successful scan materializes a graded snapshot with four parts:
Frozen source text. The full draft string exactly as scored, not a live view that drifts while you type.
Section map. Character-range offsets and scores for each section, so the right pane can render TipTap-style highlights against the frozen text.
Content hash. A hash of the segmented payload lets us deduplicate identical rescans. Same text produces the same snapshot rather than stacking duplicates.
Serial label. Snapshots are numbered #1, #2, and so on. Deleting one snapshot does not renumber the remaining ones mid-session. Serials reset when history is cleared entirely.
The chip row at the top of the history strip shows one chip per snapshot. Selecting a chip loads that snapshot's highlights and displays a length-weighted document AI percentage across its sections. A mode tag (SB for section-based, WD for whole-document) stamps how the run was scored, so "why does this snapshot look different?" stays answerable.
Insert to text replaces the live left-pane draft with the selected snapshot's frozen text. That is the explicit restore path: pull an older graded revision into the editor, edit it, then Re-grade to append a new snapshot.
When the live draft diverges from the selected snapshot's frozen text, an inline note appears: edits are not reflected in the grade until Re-grade is clicked. Scores stay bound to the frozen snapshot, not to whatever is in the editor now.
Snapshot history and draft text survive tab switches and full page refreshes via local storage in the same browser profile, not server-synced. That keeps iteration cheap and avoids new backend scope for v1. The tradeoff is that a new device or a cleared browser profile starts with empty history. We cap history at 18 snapshots in the shipped client so storage stays predictable under heavy iteration.
Reliability decisions
Two choices drove the trust model.
No implicit rescoring on edit. Draft changes do not move scores until the user requests a new run. This avoids "haunted" numbers that are technically scores but are tied to text no longer in the editor.
Clear failure signaling. Configuration, eligibility, or quota failures return a direct error state with a readable message. There is no silent downgrade to zero or an empty panel. For an integrity tool, a quiet failure is worse than a visible one.
Operational reality
A few things that shaped the product decisions:
Scores are probabilistic signals, not forensic verdicts. Copy and UI language must not imply certainty. The output tells you where to look, not whether the text is AI-generated.
Detector workloads are bursty around submission deadlines. Rate limits should surface as actionable messages ("try again in a moment" or "upgrade your plan"), not as generic errors.
Section mode increases the surface area for partial failures. A per-section error state is better than one opaque "whole document failed" message, because it lets users see which sections scored and which did not.
Before and after
| Dimension | Embedded single-score | Standalone with snapshots |
|---|---|---|
| Localization | Aggregate only | Section heatmaps |
| Iteration | Informal copy/paste | Numbered snapshot strip with per-snapshot delete and Clear |
| Restore / compare | Manual undo | Insert to text loads a frozen graded draft into the editor |
| Continuity | Lost on refresh | Local persistence of draft and history in the same browser |
| Staleness | Easy to confuse | Explicit re-grade; live draft can diverge visibly from frozen snapshot |
| Trust on failure | Opaque | Visible error states |
The qualitative shift: users spend less time hunting where the problem is and more time editing with a clear before/after grading trail.