A reproducibility record you can use
Create one entry for a coherent task performed under one observable system state. Start another when the displayed model, date, access route, enabled tools or research purpose changes. The unit is not an entire dissertation and not necessarily an entire conversation. It is the smallest interaction whose conditions and influence you can describe accurately.
Add the interaction language, relevant software-library version and any tool calls you could see. Keep the card proportional. It should identify the conditions without exposing participant data, confidential manuscripts or restricted datasets in a public appendix.
A model label is evidence, not a complete specification
A consumer product may combine a language model with provider instructions, retrieval, safety layers and external tools. The name shown in the interface rarely documents that whole chain. A provider may alter the surrounding service while leaving a familiar product label in place. Therefore, a model record improves traceability but cannot promise bit-for-bit reproduction.
Say what was observable. A defensible methods sentence is: “The interface displayed model label X; underlying system instructions and service-side parameters were unavailable.” This wording keeps the evidence boundary clear. If you used an API, your record can be richer: endpoint, request parameters, client-library version and returned model field may all be available. Record only values you actually sent or received.
Capture details at the point of use
Retrospective documentation loses the very facts that change most easily. Open the card before sending the first substantive request. Read the visible model label, record the access route and note enabled search or analysis functions. When the response arrives, export or preserve the prompt and response together, then connect them to the academic decision they informed.
- Describe the intended task before the system contributes.
- Assign a record ID and copy visible service details exactly.
- Capture the timestamp with its time zone.
- List settings you controlled and tools shown as active.
- Preserve input and output in a stable, access-controlled file.
- Record whether suggestions were accepted, amended, verified or rejected.
- Link the record to a manuscript section, analysis file or code commit.
For a long project, maintain a lightweight index that points to detailed records. The index can contain ID, date, purpose, displayed model and storage location. Your readable disclosure is then built from evidence instead of recollection. The AI-use declaration guide shows how to turn interaction records into a concise account.
Worked case: one search task across two sessions
Suppose you ask for vocabulary to construct a database search on Monday. The interface displays Model A and web access is off. You save the conversation as AI-2026-014, then independently verify every suggested reference in a library catalogue. On Thursday you reopen the same conversation. It now displays Model B and an active search facility. That second session becomes AI-2026-015.
Your methods account distinguishes the two system states even though the browser presented one continuous thread. It also distinguishes discovery from evidence: the publications you read support scholarly statements, while the archived responses document how search terms were developed. The reference-verification workflow provides the checking route from generated lead to located original.
If Model B is withdrawn before examination, a reader can still inspect your timestamped record, settings and preserved output. They may not reproduce the wording exactly, but they can evaluate what you did and what limitations applied. That is useful reproducibility for a changing service.
Preserve raw responses and map their influence
Keep unedited output separate from annotated or revised material. A filename such as AI-2026-014_2026-09-04_raw.txt makes status visible. If you redact a record for sharing, retain the controlled original and mark the public copy as redacted. Never silently replace a raw response with a cleaned version.
The influence map answers a practical question: where did this interaction affect the work? Identify a chapter, paragraph, spreadsheet cell, analytical decision or commit. “No material retained” is also a valid outcome when accompanied by a short reason. If a factual proposition survives, add the original publication that supports it. The source-status decision tree explains why an archived response and a scholarly citation perform different jobs.
- Keep raw and edited files under different names.
- Check whether an export omits model labels or tool activity.
- Use a time zone rather than an ambiguous local time.
- For group projects, name the person who operated and reviewed the interaction.
- Apply project retention and access rules to the evidence files.
Choose the right level of disclosure
The methods chapter should explain why the tool was used, the class of tasks it performed and how human verification worked. A full interaction register may belong in an appendix or protected repository instead. Follow the assessment brief, institutional policy and supervisor instructions that govern your submission; requirements vary by context.
Neither extreme is helpful. Hundreds of unindexed screenshots bury the research trail, while “AI was used” conceals it. Present a chain from record ID to preserved interaction, academic decision and independent check. The AI transparency hub links related documentation methods. A probabilistic text assessment answers a different question and cannot recreate provenance; the AI scan explainer separates those purposes.