Education & Access

Proof Trace - Prove your writing history

Turn your Google Doc’s revision history into shareable proof of authorship, so students can defend their work with evidence, not unreliable AI detectors.

Live demo

Proof Trace - Prove your writing history cover

Demo video

What it does

ProofTrace turns a student's existing Google Doc into a shareable record of how their work developed. The flow is intentionally simple: • Sign in with Google. • Select the Google Doc you already wrote. • ProofTrace imports and analyzes the document's writing history. • Review the document timeline, editing activity, writing statistics, and notable changes. • Generate a private shareable report. • Send that report to a lecturer or teacher for review. The goal is not to declare that a student is innocent or guilty. ProofTrace provides evidence, not verdicts. A teacher can inspect how a document evolved instead of relying solely on the final text or an opaque AI-detection score.

Inspiration

A student can write an entire essay themselves and still end up in an uncomfortable situation: an AI detector flags the work, a teacher suspects misconduct, and suddenly the student has to prove something that was never recorded in the first place. While researching the problem, we found story after story from students who said they had been falsely accused of using AI. The common problem was not a lack of arguments — it was a lack of evidence showing how the document was actually written. That led to the idea behind ProofTrace: Don't detect authorship. Document it. Instead of trying to build another classifier that guesses whether text looks human or AI-generated, ProofTrace focuses on the writing process itself.

How we built it

We built ProofTrace as a web application centered around Google Docs. The frontend uses Next.js, React, TypeScript, and Tailwind CSS. Google authentication and the Google Drive picker let users select a document without changing their normal writing workflow. Once a document is imported, ProofTrace creates a private analysis record and presents the writing process through a document report. The report combines the document snapshot with chronological editing information, writing metrics, analysis findings, and a timeline designed to make revision patterns understandable at a glance. We also built a sharing flow around the report. Students can generate a link with controlled access and send the same evidence they see to a lecturer without exporting screenshots or trying to explain a complicated revision history manually. A major part of the project was the interface itself. We wanted the product to feel less like an AI detector and more like an evidence workspace: calm, readable, and focused on the document rather than a single suspicious-looking percentage.

Challenges we ran into

Turning raw history into something understandable A long-lived Google Doc can contain a huge amount of editing activity. Simply exposing revision data would overwhelm both students and lecturers. We had to decide which information actually helps someone understand how a document developed, then turn it into a concise timeline and report. Integrating with Google without changing the student's workflow We did not want students to install an extension, remember to start a recording, or write inside a custom editor. The experience had to begin with something students already use: their Google Doc. That meant designing the product around Google authentication, document selection, permissions, and document-history data. Evidence without overclaiming This was one of the most important design challenges. Writing history can provide useful context, but it should not become another automated system making absolute accusations. A perfectly normal document can still contain unusual editing patterns, and the absence of a particular pattern does not prove misconduct. We therefore designed ProofTrace around the principle: Available records do not prove authorship — they provide evidence for review. That distinction influenced both our analysis and our interface. Making the report useful to two different users The student wants reassurance and a simple way to share their work. The lecturer wants something concise enough to review quickly but detailed enough to investigate when necessary. Designing one report that works for both required us to prioritize information hierarchy, progressive disclosure, and a clear path from a high-level summary to the underlying document evidence. What we learned The biggest lesson was that this problem is not really about detecting AI. It is about provenance. The final essay contains very little information about the process that produced it. Once we started treating the writing process itself as data, we could ask much more useful questions: • Did the document develop gradually? • When did the major writing sessions happen? • Where did large changes occur? • What was added, removed, or rewritten? • What evidence can a human reviewer inspect for themselves? We also learned that evidence products need to communicate uncertainty carefully. Presenting more data is not automatically better; the interface has to distinguish observations from conclusions.

What's next

We want ProofTrace to become a richer writing-provenance layer for students and educators. Future work includes deeper revision-history visualization, better identification of writing sessions and significant changes, clearer citation/source analysis, richer professor-facing reports, and exports that can accompany academic integrity reviews. Our longer-term goal is simple: When a student is asked, “How do we know you wrote this?”, they should have something better to show than an AI-detector score.