Auditing Assistance: A One-Page Template for Documenting LLM Use in Student Papers
Student-led papers in 2026 routinely involve large language models at some stage: screening literature, drafting code, cleaning data, or tightening prose. Many journals now require a disclosure statement. Too often, that statement reads like boilerplate: The authors used AI to improve the manuscript. Such a sentence tells a reader almost nothing about the work behind the paper. It does not say which tool was used, what task it performed, whether a human checked the output, or whether the assistance could affect a claim. For a lab that values reproducibility, that is a gap worth closing.
NI Lab treats AI disclosure as a methods habit rather than a confession. A useful disclosure should let another student understand where assistance entered the workflow and how the team verified it. With that goal in mind, we propose a one-page audit that can be attached to a submission, filed in the lab notebook, or included as supplementary material. It is deliberately short. The point is not to document every keystroke. The point is to document the assistance that matters.
Why a separate audit page
A single sentence in the acknowledgments is easy to write and easy to ignore. An audit page forces the team to answer a small set of concrete questions. Did the model screen abstracts? Did it draft analysis code? Did it suggest edits to the discussion? Who checked the output, and against what? If the tool changed a figure, a category, or an exclusion decision, the reader needs to know. If the tool only corrected grammar, the reader needs a brief note, not a second methods section.
The audit also protects student authors. A clear record shows that the team used assistance deliberately and reviewed it. It reduces the risk that a vague disclosure will later look evasive. Transparency here is not an ethical flourish added at the end. It is part of the reproducibility routine: version the tool, record the task, preserve the prompt where feasible, and state the human check.
The one-page template
Complete only the rows that apply. Mark the rest as not applicable. Attach the page to the manuscript file and to the lab notebook entry for the project.
| Field | Prompt to answer |
|---|---|
| Workflow stage | Literature search, data cleaning, coding, figures, drafting, editing, or other |
| Tool and version | Vendor or model family, version if known, access date |
| Task delegated | What the tool was asked to do, described in plain language |
| Human verification | Who checked the output, how it was checked, and whether the check was complete or sampled |
| Output retained | Where prompts and responses are archived, or why retention was not feasible |
| Effect on claims | None, cosmetic, methodological, or interpretive |
| Manuscript note | The one- to three-sentence disclosure that will appear in the paper |
A lab director can add this page to the submission checklist. A student can complete it at first draft and update it at submission. The audit should not become a bureaucratic burden. If a row does not apply, leave it blank and move on.
Vague versus specific statements
The difference between a weak disclosure and a useful one is usually specificity about task and verification. Consider two examples from literature screening.
Vague: The authors used AI to assist with the literature review.
Specific: We used a large language model on 12 March 2026 to screen 412 titles against the stated inclusion criteria. Two authors independently reviewed all titles recommended for exclusion and all borderline cases. The model did not make final inclusion decisions. Prompts and raw outputs are archived in the project repository. The tool did not generate interpretations or conclusions.
The second statement gives a reader enough information to judge the role of the tool. It names the stage, the scale, the human check, and the limits of the assistance. It also tells a replicator where to look.
A second pair, this time for code, follows the same logic. Vague: AI helped with coding. Specific: We used an LLM to draft unit tests for the preprocessing script. The first author reviewed every test, ran the full suite on the final dataset, and corrected two tests that relied on an outdated column name. The model did not set exclusion thresholds or generate results. The specific version is not longer for its own sake. It records the verification that made the assistance safe to use.
A short decision tree for interpretation
Not every use of an LLM needs a limitations paragraph. A decision tree can help authors decide when the assistance bears on interpretation.
- Did the tool shape a number, category, exclusion, figure, or model specification? If no, a brief methods note is usually enough.
- Could a reasonable reviewer change an interpretation if they knew about the assistance? If no, keep the disclosure concise.
- Was the output checked against an independent source or a second human coder? If not, flag the gap and do not rely on the output for a central claim.
- Does the assistance affect a core claim, a novelty statement, or a reported effect? If yes, describe the assistance in the methods and consider a sensitivity check.
- Would another team need the prompt, version, or output to repeat the step? If yes, archive them and say where.
If any answer routes to interpretive, the audit page and the manuscript should say so plainly. If the assistance was limited to wording or formatting, the disclosure can remain short. The goal is proportion, not performance.
Common failure modes
Three problems recur. The first is burying the disclosure in acknowledgments, where readers do not look for methods information. The second is naming a tool without naming the task; a model name alone does not tell a reader what happened. The third is treating disclosure as permission. A statement that AI was used does not substitute for human verification, especially when the output affects data handling or inference.
A fourth problem is version drift. A team may begin with one model and finish with another. The audit page should be updated when the workflow changes. A short revision note is enough: date, tool, task, and verification.
A modest adoption plan
Lab directors can add the audit page to the existing submission checklist and review one example at a group meeting. Journal clubs can use the vague-versus-specific examples as a ten-minute calibration exercise. Instructors can require the page with final papers and grade the specificity of the disclosure, not the presence of AI use. None of these steps requires a new policy regime. They require a habit of recording assistance where reproducibility already demands a record.
The audit is not a confession and not a seal of approval. It is a compact account of a workflow. In 2026, that account belongs alongside the protocol, the analysis script, and the data dictionary.
