Authorship guide
AI writing provenance: a practical record of what came from where
Writing provenance is a record of origin and revision. In an AI-assisted manuscript, it answers concrete questions: which passage was generated, what request produced it, what context the tool used, and what the author changed afterward. It is evidence about process, not a guess based on prose style.
01
Start with provenance, not detection
A detector examines finished text and estimates whether it resembles text associated with a model. Provenance records an event when it happens. The first is an inference; the second is process history. They answer different questions and should not be treated as substitutes.
A useful provenance record does not try to measure creativity or ownership. It records observable steps so the author can review the manuscript honestly and explain the workflow if needed.
- Origin: whether text was typed, imported, pasted, or generated.
- Request: the instruction or tool action that produced generated text.
- Context: the manuscript and reference material supplied to the request.
- Output: the exact text returned before acceptance or revision.
- Disposition: whether the author kept, changed, moved, or discarded it.
02
Capture the record when generation happens
The strongest time to record provenance is when a tool inserts or proposes text. Retrofitting a history from memory is slower and less reliable. Store the generated output before it is blended into surrounding prose, then attach the record to the passage or revision that received it.
Keep enough information to identify the event without collecting unrelated personal data. A timestamp, model identifier, tool name, request purpose, and local passage reference are usually more useful than a screenshot.
- Assign a stable generation or revision identifier.
- Record the provider and model identifier shown at request time.
- Preserve the prompt or tool instruction and relevant context references.
- Store the returned text separately from the author’s later edits.
- Link the event to its document, chapter, and location.
- Record failures and discarded outputs only when they matter to the audit trail you need.
03
Keep generated text visible during review
Provenance is most useful when it changes what the author can do next. Mark an inserted passage while it is still untouched, and make acceptance a deliberate action. A history hidden in a settings screen does little to support a sentence-by-sentence final pass.
Use a state model that reflects real editing. “Generated” can mean untouched model output; “revised” can mean the author changed the words; “discarded” can mean the suggestion never entered the manuscript. Define the states clearly and avoid implying that a tiny edit settles every authorship question.
- Show untouched generated passages in the manuscript itself.
- Offer an explicit keep or discard decision before silent blending.
- Preserve the original output after the visible passage changes.
- Let authors review provenance by chapter and across the whole book.
- Keep moves, splits, and merges linked to the same underlying event where possible.
04
Record the context the model actually received
A prompt alone is not the full request. Writing tools may also send nearby prose, character notes, a synopsis, style guidance, continuity facts, or previous messages. When that context affects an output, the provenance record should identify it.
Prefer references and snapshots over vague labels. “Used story bible” is less informative than a list of the specific entries supplied and the version or content captured at that moment.
- Separate author instructions from automatically assembled context.
- Name the chapters, notes, or records included in the request.
- Record truncation when a tool could not send all selected context.
- Keep the model response associated with the context version it saw.
- Do not imply that the model read material the request did not contain.
05
Keep provider and usage history explicit
Model names, routing, availability, and pricing can change. Record the provider and model reported for the request rather than relying on a current settings screen to explain an older generation. If cost matters, keep the actual charge when available and label estimates as estimates.
Local and hosted tools may use different credentials or billing arrangements. Provenance should describe the path that actually ran, not the option the author usually prefers.
- Provider and model identifier used for the completed request.
- Local, subscription-backed, or metered execution path when known.
- Token or usage counts reported by the provider.
- Actual cost, estimated cost, or unavailable cost as distinct states.
- Fallback routing when a different model answered than the one first selected.
06
Use provenance to plan the final human pass
Before export, walk every passage still marked as untouched model output. Read it in chapter context and against the book’s voice, facts, and intent. Keep, rewrite, or remove it deliberately. The aim is not to make a percentage disappear; it is to make sure no passage escapes author review.
Then inspect the history at book level. Repeated reliance on one prompt or one kind of context can reveal a revision risk, such as several scenes shaped from an outdated character note.
- Review untouched output in reading order, not only in generation order.
- Check factual claims and continuity independently of the prose quality.
- Rework language that does not match the surrounding narrative voice.
- Resolve or explain every remaining provenance marker before the chosen final state.
- Export a process record only when it is useful and appropriate for the recipient.