Code provenance sheet with test evidence
Describe the role, not merely the presence of AI
Programming assistance may produce a regular expression, suggest an algorithm, explain an exception, design tests or refactor a module. These roles carry different implications for intellectual contribution and error. Replace “coded with AI” with the affected function and decision. Did the system select the statistical method, translate existing pseudocode, supply syntax, or change architecture?
Preserve the state before the proposal and the first output. Version control makes it possible to isolate the suggestion in a commit or reviewable diff. Then explain your choices: why did you replace a dependency, add boundary handling, or reject an apparent optimisation? A documented rejection is valuable evidence of scrutiny.
- Name files and functions, not only the language.
- Store prompts without secrets or identifiable research data.
- Verify claimed APIs in official documentation.
- Identify dependencies and licence notices.
- Explain substantive edits through a diff or decision note.
Evidence beyond “it runs”
A successful launch is not enough. Derive tests from the research purpose and foreseeable boundaries. Data-cleaning code should cover ordinary, missing, invalid and extreme values. Calculations need small cases whose answers can be checked independently. Randomised work requires environment, seed and tolerance information. Interfaces may require keyboard and error-state checks.
The sheet records the command or procedure, input, expected result, observed result and date. Do not erase failed runs: connect them to the correction and rerun. Tests suggested in the same AI exchange are useful candidates, but not independent validation. Add cases based on requirements, reference datasets, published definitions or manual calculations.
- State a domain invariant: what must always hold?
- Choose a transparent reference case.
- Derive boundaries from real input conditions.
- Repeat the run in a clean environment.
- Record output, versions and untested scope.
Worked example: normalising measurements
A generated function drops missing values and calculates z-scores. The researcher notices that silent deletion changes the sample. She separates missing-data policy from transformation, adds a guard for constant columns and reports excluded observations. She preserves the proposal, her diff and reference tests.
The methods chapter describes the actual missing-data rule and equation, not the conversation. The AI statement identifies programming assistance and validation. The provenance sheet reports successful tests for empty, constant and partially missing columns, while explicitly noting that memory behaviour on very large datasets was not examined. This boundary is more credible than an unlimited reliability claim.
Align code, appendix and declaration
The repository needs a README explaining execution, environment and data prerequisites. Link sheets to stable commits or releases. If the code cannot be public, an archived package inside the approved assessment environment can serve the same evidential purpose. Never include credentials, personal data or confidential prompts.
The AI declaration template supplies overall wording. See citing code and research software for the separate citation task. The AI transparency hub connects code, prompt and model records. The AI detection overview explains why final-code or prose signals cannot reconstruct a development trail.
Submission audit
Can you explain each central function without reopening the AI reply? Is the exact submitted code state identifiable? Do tests cover domain requirements and error states? Are known limits visible? Do thesis, README, repository and declaration agree? Are external libraries, data and snippets attributed correctly? A credible record emerges from these connected answers, not from a tool name alone.
Do not claim independent verification where the same unverified generated assumptions shaped code and tests. Where the result affects the thesis conclusion, compare against a second implementation, reference calculation, benchmark dataset or expert-reviewed method where feasible. Preserve discrepancies and their resolution.
Record negative tests
A provenance sheet is stronger when it contains deliberate failures: wrong data type, missing column, empty file, forbidden value or corrupt format. Record whether the program fails safely, silently changes data or reports misleading success. Link defects to the correcting commit and repeat affected tests after later changes. This shows that you defined expected behaviour and boundaries rather than demonstrating a single favourable example.