8 The SORTEE guidelines | The TADA-Wiki

8.1 The six stages

Table 2 of the paper (Pick et al. 2026) is reproduced below.

Stage	Guideline
1. Data must be archived and adhere to FAIR guiding principles
1.1 Data files are accessible and in an open repository	Data are open and freely available and are located in a permanent public repository with an associated globally unique persistent identifier, that is cited in the text and reference list of the manuscript.
1.2 Data are associated with a license	Data must be associated with a license.
1.3 Data files are present and complete	Authors must either provide: a) raw data, along with the processed data and/or code to prepare the data for analysis, or b) a sample of raw data alongside processed/filtered data when full raw data upload is not possible, or c) processed/filtered data with a detailed description of how to both obtain and process/filter the raw data.
1.4 Data files are in an interoperable format	Data files must be provided in an interoperable format.
1.5 Data metadata is present and adequate	Detailed metadata, including (but not limited to) a README file, must accompany the data.
2. Archived data corresponds with the data reported in the manuscript	The structure and contents of the archived data files must match the description in the manuscript.
3. Code must be archived and adhere to FAIR guiding principles
3.1 Code files are accessible and in an open repository	Code files are open and freely available and are located in a permanent public repository with an associated globally unique persistent identifier, preferably in the same archived project as the data files, and are cited in the text and the reference list of the manuscript.
3.2 Code is associated with a license	The code must be associated with a license.
3.3 Code files are present and complete	All code used for generating the results of the manuscript (including filtering, processing, graphing, and analysis) must be present either in one or more code files.
3.4 Code is in an interoperable format	Code files must be provided in an interoperable format.
3.5 Code metadata is present and adequate	A sufficiently detailed README must accompany the code. Code must also be broken into sections with clear annotation stating the purpose of the code with clear links to the relevant sections, figures, and tables in the manuscript.
4. Archived code corresponds with the workflow reported in the manuscript	The structure and content of the archived code must match the description of data filtering, processing, and analysis, and the presentation of results in the manuscript.
5. Archived code runs with the archived data	Code must be able to run without error using the archived data. With the exception of easy to fix file path errors, all errors should be addressed by the author.
6. Results can be computationally reproduced by running the archived code	Results reproduced by the data editor with the archived data and code must match those presented in the manuscript. A tolerance threshold can be given when there is not an exact match but the authors must state clearly in the code metadata why this mismatch might occur. If saved model outputs are instead provided, this must also be clearly stated in the metadata.

8.2 How TADA maps onto the stages

This mapping is ours, not from the SORTEE paper. TADA covers almost exactly the author-side work for Stages 1 and 3.

TADA	SORTEE stages
Transferable	1.4 and 3.4 (interoperable formats) and, in practice, 5 (code runs, since local file paths are the most common cause of failure)
Available	1.1 and 3.1 (open repository, PID, cited in the manuscript)
Documented	1.2, 1.5, 3.2 and 3.5 (licence and metadata)
Annotated	3.5 (sectioned code with clear annotation and signposting), and it is what makes Stage 4 assessable at all
(Not TADA: your responsibility as author)	1.3 and 3.3 (completeness), 2 (data matches manuscript), 6 (results reproduce)

8.3 Common failures at each stage

From the guidelines’ account of common problems (Pick et al. 2026).

Stage 5, code runs. The most frequent causes of failure are:

a package or module not installed or loaded within the code
a missing code chunk
variable names in the code not matching those in the data files
code referencing data files whose names do not match the archived files
local or absolute file paths, which the guidelines single out as one of the most common reasons code does not run

Data editors are told to be pragmatic about paths. An absolute path, or a way of specifying relative paths they do not know, should not be a reason to return the code if they can make it run with minor changes. It is logged as a minor error. Every other error is the author’s to fix, because it is not the data editor’s job to make your code run.

Stage 6, results reproduce. In most cases exact reproducibility is expected, so the code should give the same number as the manuscript. If a mismatch has one of the following legitimate causes, say so in the metadata:

Stochastic methods such as simulations and MCMC. Set a seed (set.seed() in R, random.seed() in Python) at the beginning of any code section that would be run independently, including for figure generation with jittering. Note that setting a seed does not always guarantee reproducibility.
Post-processing of figures in other software. The data in the figure are still expected to be the same, but the code may not reproduce the figure exactly.
Software version differences. If results are sensitive to the version used, flag it clearly and justify the version in the manuscript and metadata.

Computationally expensive or proprietary analyses. If code needs specialist hardware, takes a very long time or depends on proprietary software such as ASReml, full computational reproducibility cannot be assessed. In those cases:

Indicate it clearly in the metadata, alongside a saved output, for example large Bayesian model objects saved as .rds
Ideally provide example code demonstrating that the code will run, such as an analysis on a subset of the data, or a model run for a reduced duration
Where only part of the analysis needs proprietary software, say which parts a data editor can assess
Consider non-proprietary execution routes, such as GNU Octave for MATLAB code or MATLAB Compiler for standalone applications, but test compatibility and note any limitations in the metadata
Build systems such as targets (R; Landau 2021) or Snakemake (Köster & Rahmann 2012) can provide reproducibility signatures (hashes) for computationally intensive steps, along with intermediate data objects

8.4 Advice for authors

The guidelines’ suggestions (Pick et al. 2026):

1. Adhere to the guidelines from the beginning of the study. Making a project accessible and reproducible at the end is a lot of work. Create a clear directory structure and a README at the start, and update the metadata as new files are added. Annotate code as you write it. Working with reproducibility in mind also makes it far more likely that someone else can reuse the project and run the code, which matters if several people will work on the study over its lifetime.

2. Prepare data and code before submission to any journal. Having it ready minimises problems during submission and quality control, and makes it easy to move to another journal if the paper is rejected.

3. Perform a pre-submission code review. Send the project to a colleague or co-author before submitting. They can check that the code runs with the data in the structure provided, that the metadata are adequate, that data and code match the manuscript, and that results reproduce. Co-authors are also more likely to spot mistakes in the code, because they know the study and the data, while data editors do not check code reliability. See Code review.

4. Consider Markdown or Quarto. Presenting everything in one self-contained document is very helpful for data editors and future readers (Buckley et al. 2025), because it shows how code, data and outputs connect.

Say what was checked. If your journal does quality control, the guidelines suggest saying so in the data and code availability section, for example: “Data and code were checked from Stage 1–4 of the SORTEE guidelines for Data and Code Quality Control”. Say where a check could not be performed, whether because of proprietary software, sensitive data or computationally expensive analyses.