Reproducibility & Data Policy (agsy-reproducibility-and-data-policy)
AgSy is a modelling journal, so reproducibility is not just about data — it is about whether someone else could re-run or re-implement your model. Elsevier's research-data policy explicitly counts software, code, models, algorithms, protocols, and methods as research data. Build the package as you go so submission and revision do not stall. (Verify the exact current policy strength — mandatory vs. encouraged — on the journal page; see 待核实.)
When to trigger
- Building the data + code + model materials for submission
- Writing the data-availability statement
- Data, code, or the model cannot be fully shared (licence, privacy, proprietary model) and you need the exemption path
- Preparing model documentation so reviewers can assess reproducibility
What AgSy / Elsevier expects (verify current wording)
- Deposit research data in a repository. Use a recognized repository (Mendeley Data, Zenodo, OSF, or a domain repository), cite and link the dataset in the article. Not a personal website.
- Code and models count as data. Deposit run scripts, parameter files, and — where licensing allows — the model code or a pointer to the exact model version. A black-box model with no access path weakens the paper.
- Data-availability statement. State where the data, code, and model are, or explain why they cannot be shared (third-party licence, privacy, proprietary model) and how others could obtain equivalent access.
- Model description. Document model version, structure/equations, parameter sources, calibration vs. evaluation data, and driving inputs. For agent-based models, follow the ODD protocol so the model can be re-implemented.
When data/code/model cannot be shared (exemption path)
- Explain why (proprietary model, licensed input data, privacy/legal restrictions).
- Give a README describing exactly how others can obtain access (provider, licence, version).
- Where possible, share synthetic inputs or a reduced example so the workflow can be exercised.
Build-as-you-go checklist
- One master workflow regenerates every table/figure from inputs + model runs
- Data + code + model/run scripts deposited in a repository with a DOI/permanent link
- README documents data provenance, model version, calibration/evaluation split, and how to reproduce each exhibit
- Seeds set and reported for every stochastic step (Monte Carlo, ABM, weather/price generators)
- Software/model versions pinned (
renv.lock/requirements.txt/ environment file) - Exhibit numbers in the manuscript match the package output exactly
- Restricted materials: exemption note + access instructions + synthetic example where feasible
- Data-availability statement drafted for the manuscript
Anti-patterns
- Treating the package as a post-acceptance afterthought
- Depositing data but not the code or model (Elsevier counts them as research data)
- A black-box model with no version, parameters, or access path
- A personal URL instead of a citable repository with a permanent identifier
- Undocumented, un-seeded, unpinned runs that "work on my machine"
Output format
【Repository】data + code + model deposited with DOI/link? [Y/N] 【Reproduces tables/figures?】master workflow verified locally? [Y/N] 【Model documented】version + parameters + calibration/eval split (+ODD if ABM)? [Y/N] 【Restricted?】exemption note + access path + synthetic example? 【Data-availability statement】drafted? [Y/N] 【Next】agsy-review-process
Supplementary resources
../../resources/external_tools.md— repositories, version-pinning, and model-description standards (ODD)../../resources/official-source-map.md— Elsevier research-data policy (data, code, models)
