Transparency & Data Policy (apsr-transparency-and-data-policy)

APSR does not just ask for data — it verifies that the deposited materials reproduce the manuscript's tables and figures before publication. Build the package as you go so conditional acceptance does not stall.

When to trigger

• Building the reproducibility/replication package
• A manuscript reached conditional acceptance and the editorial office requested materials
• Data cannot be fully shared (privacy, ethics, legal/provider restrictions) and you need the

exemption path

• A Replications and Reappraisals submission (materials expectations are central)

What APSR requires (verify current wording on the policy page)

1. Deposit to the APSR Dataverse. Authors of conditionally accepted manuscripts submit a

reproducibility package to the APSR Dataverse on Harvard Dataverse — the journal's dedicated repository with permanent identifiers and preservation. Not a personal website or generic cloud link.

1. Editorial verification. The office reviews the package to confirm it can **reproduce the

manuscript's tables and figures** and that the research process is documented well enough. Treat this as a real check, not a formality.

1. Quantitative materials. Data, code, and documentation sufficient to regenerate every reported

result. Master script + README + pinned versions + seeds.

1. Qualitative materials. Share the materials and data used, alongside literature citations, in a

form that supports the claims (e.g., evidence tables, annotated sources), with access controls where needed (QDR is an option for controlled access).

When data cannot be shared (exemption path)

• Explain why the relevant data are not available (ethical/privacy concerns or legal restrictions

by the data provider).

• Provide README instructions on exactly how others can obtain the data (access process,

application, provider contact).

• Where possible, provide synthetic data resembling the unavailable data so the code can be run.

Package skeleton (what the verifiers should find)

apsr-repro/
├── README.md            # provenance, environment, run instructions, exhibit map
├── run_all.{R,do,sh}    # one entry point → every table and figure
├── data/
│   ├── raw/             # as obtained (or access instructions if restricted)
│   └── constructed/     # built by scripts, never by hand
├── code/
│   ├── 01_build.*       # raw → analysis data
│   ├── 02_analysis.*    # estimates
│   └── 03_exhibits.*    # writes output/Table1.tex, output/Figure2.pdf, ...
└── output/              # regenerated exhibits, named to match the manuscript

The README's exhibit map — "Table 1 ← code/03_exhibits.* lines …; runtime ~N minutes" — is what lets the editorial office verify quickly instead of bouncing the package back.

Verification dry run (before conditional acceptance, not after)

1. Clone the package to a fresh directory or machine — not your working tree.
2. Run only what the README says. Any manual step you perform but did not write down is a defect.
3. Diff every regenerated exhibit against the manuscript: numbers, rounding, N's, note text.
4. Record total runtime in the README; flag any step needing > a few hours or special hardware.
5. Have a coauthor or colleague repeat steps 1–3 cold. If they ask you a single question, the

answer belongs in the README.

Preregistration discipline (APSR-specific)

Preregistration and pre-analysis plans are encouraged, not required — but if you reference one:

• Share it anonymized (as an appendix or via an anonymized OSF view) so double-anonymous review

survives; a PAP with your name on it defeats the anonymization you did everywhere else.

• Mark registered vs. unregistered analyses clearly in the text — this is the stated

expectation, and it converts "exploratory" from a weakness into a labeled category.

• Keep a deviations note: every departure from the plan, with the reason, in the appendix.

Build-as-you-go checklist

• [ ] One master script regenerates every table and figure from raw/constructed data
• [ ] README documents data provenance, construction steps, 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
• [ ] Restricted data: exemption note + access instructions + synthetic data where feasible
• [ ] Preregistration / pre-analysis plan linked (anonymized) where applicable

Anti-patterns

• Treating the deposit as a post-publication afterthought (it gates publication)
• Depositing code that does not actually reproduce the printed tables/figures
• A personal URL instead of the APSR Dataverse
• Claiming data are restricted without giving an access path or synthetic substitute
• Undocumented, un-seeded, unpinned code that "works on my machine"

Output format

【Repository】APSR Dataverse (Harvard) — package staged? [Y/N]
【Reproduces tables/figures?】master script verified locally? [Y/N]
【Documentation】README + provenance + seeds + pinned versions? [Y/N]
【Restricted data?】exemption note + access path + synthetic data?
【Qualitative transparency】evidence/sources documented? [Y/N/NA]
【Next】apsr-review-process

Supplementary resources

• ../../resources/external_tools.md — reproducibility tooling and qualitative-transparency options (QDR, ATI)
• ../../resources/official-source-map.md — APSR Research Transparency policy + APSR Dataverse