Research should leave a usable record of the evidence and analyses behind its conclusions. NeuScience requires a Data Availability Statement for every research article and a Code Availability Statement when software or custom code is material to the findings. Restrictions must be disclosed at submission and resolved with the editor before acceptance.
What must be available
Provide the data necessary to evaluate the principal results, with the metadata, variable definitions, processing steps and provenance needed to understand them. Include numerical source measurements supporting key figures and tables where lawful. Distinguish raw observations, processed datasets and derived results, and describe how one becomes the other. Cite third-party data and identify the precise version used.
For custom analyses, provide scripts or notebooks that produce the main results, a readable explanation of their order, dependencies and versions, and representative inputs or instructions for lawful data access. A software name alone is not a reproducible computational method. Explain any unavailable component and how that limits independent evaluation.
Materials that are essential to replication must be identified and made available through a suitable custodian or collection where feasible. Describe access conditions, charges and transfer agreements at submission. Proprietary restrictions must not be discovered only after publication.
Repository selection and deposit
Use a recognised discipline-specific repository when one fits the data. Examples include GEO for appropriate functional-genomics datasets, the Sequence Read Archive for sequencing reads and the Protein Data Bank for applicable structures. General repositories such as Zenodo, Dryad or an appropriate institutional repository may be used for other outputs. These are examples, not NeuScience partnerships or assurances that every deposit is suitable.
Prefer durable access, versioning, persistent identifiers, clear licences and sufficient metadata. Deposit large datasets in a repository rather than embedding them in a document. A personal website or changeable cloud-sharing link should not be the only long-term access route. GitHub may support development, but archive the analysed release in a repository that supplies a persistent identifier where feasible.
Provide private reviewer access during assessment if the repository supports it. Remove author-identifying information from review-facing documentation where practical for double-anonymous review, while preserving correct provenance in the editorial record. Do not falsify deposit metadata to preserve anonymity. Discuss unavoidable identification with the handling editor.
Writing a Data Availability Statement
State what was generated, what was reused, where each output is held and the identifier or version. Say whether data are public, controlled, embargoed or unavailable and explain the reason. A generic sentence saying that data are available on reasonable request is insufficient when it omits the custodian and conditions.
For controlled access, describe who may apply, the application route, review criteria, any agreement required and foreseeable limitations. Provide a durable institutional contact rather than relying solely on one author's personal email. Do not promise access that the consent, ethics approval or data owner does not permit.
Example for public data: “The processed measurements and data dictionary are deposited in [repository] under [persistent identifier, version]. The source data for Figures 1–4 are included in that deposit.” Replace every bracketed field with actual information; do not submit the example as a declaration.
Example for restricted data: “Individual-level records cannot be released publicly because [specific restriction]. Eligible researchers may apply to [custodian and contact or URL] for [specified data], subject to [approval criteria and agreement]. The analysis code and non-identifying aggregate results are available at [identifier].”
Where no new data were generated, state this and identify any sources used for analysis. For a review, share extraction sheets and relevant analysis scripts where feasible. Embargoes must have a stated reason and release date and require editorial agreement.
Clinical-trial data sharing
For trial reports, specify whether de-identified participant data will be shared; which variables and documents are included; when access begins and ends; eligible users and analyses; and the access mechanism. Include the protocol and statistical analysis plan where available. Explain differences from the registered sharing plan. “Undecided” does not establish an access arrangement.
Public sharing of individual records is not required when it would breach consent or lawful obligations. The statement must distinguish public aggregate results from controlled participant data and provide the actual access process. A promise to share does not override participant protections.
Code and computational environments
Identify the archived release or commit, licence, language, package versions and execution instructions. Provide a README, describe required hardware or services and disclose costs or credentials needed to reproduce an analysis. Include seeds and relevant nondeterminism. Remove passwords, tokens and identifiable records from all deposits.
For models, describe how weights or an executable implementation can be obtained when sharing is permitted. If licensing prevents redistribution, identify the source and version and provide a lawful route to evaluation. Do not describe a model as open source merely because it has a public interface or downloadable weights.
Consent, privacy and third-party rights
Assess re-identification risks before sharing; removing names is not always sufficient. Protect dates, locations, rare diagnoses, genomic information and images that could identify individuals. Follow the consent, ethics approval, custodian rules and applicable law. Synthetic or aggregate examples must be labelled and must not be presented as the original observations.
Authors must have permission to use and redistribute third-party data, code and materials. Explain restrictions and cite the rights holder. The article's CC BY licence does not automatically apply to every dataset, software component or third-party image. State the applicable licence for each deposit.
Citation, preservation and corrections
Cite datasets and important software in the reference list using creator, title, repository or publisher, year, version and persistent identifier. Link the exact release analysed. Maintain deposited outputs after publication and correct broken access arrangements promptly.
If a deposit changes, retain earlier versions where possible and explain consequential corrections. Readers who cannot obtain promised evidence may contact editorial@neuscience.org with the article and access details. Editors may request remediation, consult custodians or consider a linked notice when the unavailable evidence affects evaluation of the published claims.
Research standards · Research integrity · Copyright and licensing · Corrections and appeals.