Keep a software citation tied to the release your work used
Check software-citation metadata against the release your work actually used.
About 5 min read · Allow extra time for the practical checks
Identify the software release used for the work before importing or formatting its reference. Check the project’s citation instructions and the metadata associated with that release. A citation exported from the current repository page can describe a different version from the one that produced your output.
Follow the destination’s requirements for software references and methods reporting. This guide concerns checking an attribution record; it does not decide whether every tool in a project needs the same kind of citation, establish a licence permission or verify the correctness of an analysis.
Separate the software used from the page found later
Record the software’s name, the version or other release identifier established by your work record and where its citation information can be inspected. Keep those details connected to the task the software performed. A browser history entry for the project homepage is not, by itself, a record of which release was used.
The Turing Way’s software-citation guidance, checked on 2 November 2026, explains how a CITATION.cff file supplies human- and machine-readable citation metadata. It describes information such as creators, software title, version, release date and identifiers, and ways to obtain formatted references. Use those facilities as a starting point for checking the actual release and required style, rather than treating an export as verification of your workflow.
If the work record does not establish a release, investigate the retained environment information or other appropriate records. Do not select the newest number merely because it is easy to find. Keep an unresolved version question visible until the responsible team can establish what happened.
Work through an original fictional citation check
The software, versions and work record below are invented teaching material. They describe no actual program execution, research finding, creator or persistent identifier.
Imagine a fictional methods draft says that Creek Label Tool was used to group category labels. The team’s fictional work record identifies release 1.2. When preparing the bibliography later, a writer opens the default repository page, which now describes release 2.0, and imports its displayed citation.
| Fictional evidence | What it establishes | Citation task |
|---|---|---|
| Retained work record identifies release 1.2 | The release identified for this exercise | Locate and check the metadata relevant to 1.2 |
| Current repository page describes 2.0 | A newer public state is available | Do not silently replace the used version with this number |
| Imported reference includes 2.0 | The export describes the newer state | Recheck the source of the imported entry |
| A project paper is linked | A related publication exists in the fictional record | Read the citation instructions before deciding its role |
The immediate repair is not simply to change “2.0” to “1.2” in an otherwise unchecked reference. Other fields may also describe the newer release. Check the relevant creator information, title, release details and identifier against the record that supports them.
A useful provisional source note could say:
The work record identifies Creek Label Tool 1.2. The imported citation currently describes 2.0. Metadata for the used release still needs to be checked before the reference is finalised.
That note states a remaining task, not a complete citation. The example deliberately supplies no authors, date or DOI to copy into a real manuscript. If the project recommends citing an associated paper, follow those instructions together with the destination’s requirements while retaining the information needed to identify the software actually used. Do not assume that a related article and a particular software release are interchangeable objects.
Check the imported reference field by field
Inspect the underlying citation information rather than judging an entry by its polished appearance. Confirm what the identifier resolves to: a particular release, a collection of releases or a related work. Keep any supplied descriptions of those identifiers in your working record so that their different roles are not lost during editing.
The Turing Way describes conversion and repository-interface options for obtaining references. Those routes can save transcription work, but the resulting fields still need checking. Resolve omissions or conflicts with the relevant project information rather than filling a gap with a plausible creator, year or identifier.
Apply the citation style required for your document after establishing the source details. Do not force a software reference into another source type solely because a reference manager offers a convenient template. Check whether the exported record retained the release information the reader needs.
Connect the reference with the methods account
The bibliography identifies a source; it does not explain everything the software did in the project. Keep the methods description consistent with the actual task and release. Distinguish using software to process supplied data from reading a result reported in a paper about that software.
The dataset-and-statistic citation guide addresses a parallel source-role check for data. The reference-record guide helps inspect an imported entry. Finish by comparing the work record, the prose and the reference so that a tidy citation does not point readers to a release that the work never used.
