Io transparency and data policy
Journal-specific Claude Code/Codex skill packs covering mainstream journals — AER, QJE, Nature, Cell, 管理世界, 经济研究 & 200+ more — your fast track to getting published. | 覆盖主流期刊的 Claude Code/Codex 期刊技能包,从选题、识别策略到表格规范与审稿回复全流程,助你快速发论文。
npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill io-transparency-and-data-policyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
Use when preparing the replication/transparency materials for an International Organization (IO) manuscript. IO's signature requirement is verification BEFORE final acceptance — the editorial staff request data and code at conditional acceptance, IO staff re-run quantitative results and check proofs of formal models, and editors withhold final acceptance until all reported results are confirmed; materials then deposit to the IO Dataverse with a DOI and a Data Availability Statement. Prepares the package; it does not waive requirements.
SKILL.md
5.3 KB, as published. Nobody here has run it
Transparency & Data Policy (io-transparency-and-data-policy)
IO does not just ask for data — its editorial staff re-run your quantitative results and verify the proofs of your formal models, and editors will not issue final acceptance until all reported analyses are confirmed. This pre-publication verification is IO's signature. Build the package as you analyze so conditional acceptance does not stall.
When to trigger
- Building the reproducibility/replication package (start during analysis, not at acceptance)
- A manuscript reached conditional acceptance and the editorial staff requested data and code
- You have a formal model whose proofs IO staff will verify
- Data cannot be fully shared (privacy, ethics, legal/provider restrictions) and you need the path
- Writing the Data Availability Statement
What IO requires (verify current wording on the policy page — 待核实 on verbatim text)
- No data at initial submission. Authors do not provide data or command files when first submitting (consistent with double-blind review).
- Data requested at conditional acceptance. The editorial staff request the data and command files at the time of conditional acceptance.
- Verification before final acceptance. For papers using quantitative data, IO staff re-run the code to confirm the reported results; for formal papers, IO staff verify the proofs. Editors do not issue final acceptance until all results of all reported analyses are confirmed. Treat this as a real check, not a formality.
- Deposit to the IO Dataverse. On final acceptance, upload quantitative datasets and supporting files to the IO Dataverse on Harvard Dataverse; the entry mints a DOI to be cited in the published article. Not a personal website or generic cloud link.
- Data Availability Statement. A DAS is required for quantitative articles (encouraged for qualitative), appearing before the reference list.
- Qualitative materials. Authors are strongly encouraged to deposit qualitative data at the Qualitative Data Repository (QDR) at Syracuse, with access controls where needed.
When data cannot be shared (exemption path)
- Explain why the relevant data are not available (ethical/privacy concerns or legal restrictions by the provider).
- Provide README instructions on exactly how others can obtain the data (access process, application, provider contact).
- Where possible, provide synthetic or simulated data so the code runs end-to-end. (Confirm the current exemption procedure on the live policy page — 待核实.)
Build-as-you-go checklist
- One master script regenerates every table and figure from raw/constructed data
- README documents data provenance, construction steps, software, and how to reproduce each exhibit
- Seeds set and reported for every stochastic step
- Software/package versions pinned (
renv.lock/requirements.txt/ recorded installs) - Exhibit numbers in the manuscript match the package output exactly (IO staff re-run them)
- Formal models: a complete, checkable proof appendix for IO staff to verify
- Data Availability Statement drafted (before the reference list)
- Restricted data: exemption note + access instructions + synthetic data where feasible
- Qualitative data: QDR deposit considered; sources documented for the claims
Anti-patterns
- Treating the deposit as a post-publication afterthought (it gates final acceptance)
- Depositing code that does not actually reproduce the printed tables/figures (IO re-runs it)
- A formal model with hand-waved or incomplete proofs (IO verifies proofs)
- A personal URL instead of the IO Dataverse; no DOI cited in the article
- Claiming data are restricted without giving an access path or synthetic substitute
- Forgetting the Data Availability Statement
Output format
【Stage】initial (no data) / conditional acceptance (data requested) / pre-final (verification)
【Quantitative reproduces?】master script re-runs all tables/figures locally? [Y/N]
【Formal proofs】complete, checkable proof appendix? [Y/N/NA]
【Repository】IO Dataverse (Harvard) staged + DOI plan? [Y/N]
【Data Availability Statement】drafted before references? [Y/N]
【Restricted data?】exemption note + access path + synthetic data?
【Qualitative】QDR deposit + sources documented? [Y/N/NA]
【Next】io-review-process
Supplementary resources
../../resources/external_tools.md— reproducibility tooling, formal-proof workflow, and QDR for qualitative IR../../resources/official-source-map.md— IO Research Transparency policy + IO Dataverse