agsy-reproducibility-and-data-policy
GitHub为农业系统期刊稿件准备数据、代码和模型材料,确保符合Elsevier可重复性政策。涵盖数据仓储、可用性声明撰写及无法共享时的豁免路径,提供构建式检查清单以支持模型复现。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill agsy-reproducibility-and-data-policy -g -y
SKILL.md
Frontmatter
{
"name": "agsy-reproducibility-and-data-policy",
"description": "Use when preparing the data, code, and model materials for an Agricultural Systems (AgSy) manuscript. AgSy applies Elsevier's research-data policy, which treats software, code, and models as research data — deposit them in a repository and cite\/link them, or state why they cannot be shared. Covers model-description standards and exemptions. Prepares the materials; it does not waive requirements."
}
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. The 2026-06-20 Guide for Authors refresh says Agricultural Systems applies Option C: deposit research data, cite and link it, or state why sharing is not possible.
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
- 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 the availability of data at submission. If data, code, or the model cannot be shared, explain why (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"
Worked micro-example (illustrative)
An agent-based crop–livestock model with a licensed weather input is packaged. Elsevier treats more than tabular data as "research data," so each artifact maps to a sharing path:
- Model code is open → deposited on Zenodo with a tagged version and DOI; the commit is cited.
- Weather data is licensed → cannot be redeposited. The README names the provider, license, and version, and ships a synthetic series so a reader can exercise the workflow end-to-end.
- ABM documentation follows the ODD protocol so the model can be re-implemented, not just re-run;
seeds are fixed and
renv.lockpins the toolchain.
Outcome: a reviewer can reproduce every exhibit except the licensed input, for which a documented, exercisable substitute exists.
Referee pushback → the AgSy-specific fix
- "The model is a black box." → Deposit code (or pin the version) and document structure, parameters, and the calibration/evaluation split; add the ODD protocol for an ABM.
- "Data are on a personal website." → Move to a citable repository with a permanent identifier.
- "Only the data is shared." → Add run scripts, parameter files, and the model/version — Elsevier counts them as research data.
Calibration anchors
- Agricultural Systems currently uses Elsevier Option C research-data instructions: deposit, cite, and link research data, or explain why sharing is not possible.
- The ODD protocol is a community standard for agent-based models, not a journal format.
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)
Version History
- 1839142 Current 2026-07-05 12:16


