This paper describes the mechanism. The evidence that detectors misfire on second-language English is set out separately in our research on AI-detection bias.
The question we are answering
An AI-writing detector answers: did a machine produce this text? It answers by inspecting the finished artifact — word variety, sentence shape, statistical smoothness. Those are also the properties that make second-language English distinctive, which is why the false-positive burden falls hardest on the writers who worked hardest.
There is a narrower question, and unlike the first one it has a factual answer: how was this text produced? Not who is honest, not what a model could have generated — what actually happened in the document, over time, on the record.
A detector infers backwards from an artifact. A provenance record is written forwards, while the work happens. That difference is the whole paper.
We do not claim to be first. Grammarly shipped Authorship in August 2024, tracking typed, pasted and AI-inserted text with an internal report. The concept is not ours alone, and any framing that said otherwise has been removed from our materials. What follows is what we think the mechanism must have to be usable as evidence by someone who has no reason to trust the vendor that issued it.
Three properties an evidence artifact needs
It must be checkable by someone with no account. An internal report shown inside the vendor's own product is a claim, not evidence. If a department has to log into our system to see whether a certificate is genuine, we have simply moved the trust, not established it.
It must state its own limits. A document that overclaims is worse than none: the first time it is examined by someone adversarial, everything it asserts is discarded together. Our certificates carry the limitation in the artifact itself — this documents observable editing process, it does not establish legal innocence, and it offers no warranty that any third party will accept it.
It must separate what is proven from what is asserted. This is the distinction we consider most important and the one most often missing. On every certificate, items are marked either Verified — backed by the signed editing record — or Attested — the author's own declaration, not cryptographically supported. “I wrote the thesis myself” is an attestation. “100% of this text was typed in-app” is verified. Presenting the two as one number is how process evidence becomes untrustworthy.
The same honesty applies to coverage. If recording began after 44 characters already existed in the document, the certificate says so, and those characters are excluded from what it claims.
The mechanism, in full
Nothing in this section is withheld. The scoring heuristics that resist gaming are deliberately not published — publishing them would be publishing the instructions for defeating them — but everything needed to verify a certificate is open by design.
The chain. Every edit emits an event. Each event is signed with ed25519 over the previous event's digest concatenated with the canonical payload, so the record is append-only: events are never mutated and never deleted within the retention window. The chain unifies edits across surfaces — web editor, browser extension, document add-on, mobile, desktop — into one record rather than one record per tool.
The certificate. A certificate is a signed statement about a document at a point in time: the editing period, process metrics, the checklist with its Verified/Attested marks, a SHA-256 of the document content, the issuing key's identifier, and the limitation text. Because the content hash is included, anyone can confirm that a given text is the text the certificate describes.
Key identity, publication and rotation. A signing key is identified by a fingerprint derived from the key itself, so it cannot be claimed independently of holding it. The public key is published as a bundle containing the active key and any previous keys still inside their validity window. A certificate signed while a key was live remains verifiable after that key is retired, because the verifier resolves the key the certificate names rather than assuming the current one.
Verification. A reference verifier resolves the key from the published bundle, checks the signature over the canonical payload, and reports the result. It runs in the browser, needs no account, and can be reimplemented by anyone from this description — ed25519 verification is standard cryptography, and we have no interest in being the only party able to perform it.
Revocation is live. A certificate can be revoked by its issuer; the verification page reflects current status, while a downloaded PDF necessarily reflects status at the moment it was downloaded. We state this on the artifact rather than letting a stale PDF imply currency.
Why giving verification away is the point
The instinct is to charge for verification, since institutions are the ones with budgets. That instinct destroys the thing being sold.
A certificate is worth exactly what the verifier accepts. If checking one requires a contract, a login, or a fee, then checking will not happen at scale, and a document nobody checks certifies nothing. Verification therefore stays free, public and accountless — permanently. The author's side is where a business can exist; the reader's side must be frictionless or the artifact has no meaning.
The precedent is not novel. The X.509 format is open, certificate validation is free and built into every browser, and certificate authorities are nonetheless real businesses. Openness on the verification side is not a concession made against the business model — it is the precondition for it.
For the same reason we intend the format to be interoperable rather than proprietary, framing our contribution as an assertion type within the C2PA content-provenance specification, so that verifiers built by other parties can read it.
What this does not do
It does not prove authorship. It documents a process; a determined person can produce a clean process for text they did not compose, and no amount of cryptography changes that. What it changes is the cost and the direction of the argument: the writer arrives with a record instead of a denial.
It does not overrule an institution. Acceptance is a policy decision that belongs to the department, and nothing in the artifact asserts otherwise.
It does not help with text written elsewhere. The record covers what was recorded, and the certificate says so plainly rather than implying coverage it does not have.
It is not a detector, and it is not an argument that detectors are useless. Our narrower claim, argued with sources elsewhere, is that on second-language English today's detectors are wrong often enough that their output should not be treated as proof — and that when a writer is asked to respond to such an output, a documented process is a better answer than a stronger denial.
What adopting it looks like
Nothing is installed. A department that wants to accept process evidence needs only to name it in a course policy and know where to check. Verification takes a certificate identifier or the submitted PDF and returns a verdict; no roster, no integration, no student records, and therefore none of the data-protection weight that an integration would carry.
That is deliberate. The first institution to accept this should be able to do so in an afternoon, and to stop just as easily.
This paper describes a mechanism we publish so that it can be checked, adopted, or improved by parties who do not work for us. It describes design intent and is not a guarantee about any third party's acceptance of any document.
