Choose supporting files that help readers verify the manuscript

1. Decide what belongs in the article and what supports it

List the questions a reader must answer to interpret the main result. Keep the essential study design, outcome definition and central findings understandable in the article itself. Use a supplement to provide useful detail, such as a fuller method description or additional analysis, and give the reader a precise route to it.

For this proposed workflow, write one purpose sentence for every candidate file. “Explains how outcome categories were assigned” is specific; “extra material” is not. If two files answer the same question, decide whether both are needed and explain their difference. Do not move a limitation out of the main text merely to make the article sound more definitive.

2. Check the target journal’s handling rules

PLOS One describes supporting information as auxiliary material and publishes these files as supplied, without copyediting. Its instructions place captions at the end of the manuscript and encourage appropriate repositories for research data. These are PLOS instructions, not universal requirements for every journal’s naming, hosting or submission system.

Read the current instructions for the actual article type and separate the checks you must perform: accepted file format, size, labelling, accessibility, rights and data availability. A supporting appendix is not interchangeable with the underlying research dataset. Decide whether a repository, controlled-access arrangement or journal supplement fits the material and the applicable permissions.

Reference: PLOS One: supporting information

3. Classify five fictional candidates before uploading

The invented SM12 project proposes five items. Three may support the manuscript after their content and permissions are checked. The participant identifier file is restricted. The unsigned consent scan is not evidence of consent and is not a public supplement. Every row has an owner, version, purpose and a location in the manuscript or internal record.

“Public candidate” is deliberately provisional. It does not mean the file has been cleared for sharing, validated scientifically or opened successfully. The owners must resolve rights and confidentiality, match the current manuscript and verify the exact files before a real submission. A restricted classification does not by itself establish that the storage arrangement is compliant.

On small screens, scroll the table horizontally, or focus it and use the arrow keys.

4. Make labels resolve to the intended current file

In SM12, S1 Appendix names the methods detail and S1 Table names the sensitivity table. The label is a reader-facing identity; v02 and v03 are internal revision identities. A manuscript reference to S1 Table must point to the same table described in its caption, not whichever spreadsheet happens to be most recently uploaded.

Suppose the analyst corrects the fictional table from v02 to v03 after a coding review. Replace the selected file, record why it changed and check the associated text and caption. Keep v02 in the internal history if permitted, but do not expose two indistinguishable public files with the same label. A filename correction alone cannot show that the values were checked.

5. Treat confidentiality and rights as selection criteria

Inspect candidate files for direct identifiers, hidden sheets, comments, tracked changes and embedded material that the team has no authority to distribute. This is a proposed file-review checklist, not a guarantee that one scan detects everything. Assign the question to the person responsible for the data or rights rather than assuming that a supplementary label makes the file shareable.

Consent documentation and consent for public disclosure are different questions. In SM12, an unsigned scan proves neither. Do not attach it publicly to fill an administrative gap. If material must remain restricted, describe the available access route accurately under the applicable study and journal arrangements; do not promise open data that a reader cannot obtain.

6. Verify the final set and preserve the version that was checked

Before a real submission, have a colleague open each selected file using an appropriate viewer, navigate to the cited item and confirm that its label, units, headings and explanations are intelligible. Record the exact version and what was checked. “Uploaded” and “opens correctly” need separate evidence. A methods appendix can open perfectly while still contradicting the manuscript.

After publication, inspect the public article-to-file links and the repository record where one is used. Confirm that a public reader reaches the intended material, while restricted items remain outside the public set. Retain the submitted inventory and any later correction history. Five filenames alone never establish five useful, accurate or publicly accessible supplements.

Questions for a practical final check

• Give every file a concrete reader purpose.
• Keep the central report understandable in the article.
• Apply the target journal’s current file instructions.
• Record owner, version, rights, access and manuscript anchor.
• Exclude confidential or incomplete administrative records from public files.
• Open and reconcile the exact final set before submission.