| name | jpube-replication-and-data-policy |
| description | Use when assembling data and code for a Journal of Public Economics (JPubE) manuscript under Elsevier's Option C research-data framework — data-availability statements, repository deposit/citation/linking, restricted administrative data, and a reproducible package. It does not run the analysis. |
Replication & Data Policy (jpube-replication-and-data-policy)
When to trigger
- You are preparing a data-availability statement or research-data declaration
- Your results rest on restricted tax/health/register data and you must document access
- You want a reproducible package that pre-empts referee replication requests
- You need to choose between repository deposit and a restricted-data access statement
JPubE / Elsevier requirement
JPubE's Guide for Authors applies Elsevier Option C research-data instructions: deposit research
data in a relevant repository, cite and link the dataset in the article, or provide a statement
explaining why research data cannot be shared. For public-economics work using restricted tax, health,
or register microdata, the practical route is usually a data statement plus a code package and exact
access path rather than public release of protected rows.
Build the package around Option C
Public-economics referees frequently ask to see the elasticity/bunching/RD pipeline, so build a clean
package around the data route:
- Data-availability statement matching reality: open data -> link the repository; restricted
tax/health/register data -> state the access path, the agency, and why microdata cannot be shared.
- Dataset citation/linking. Cite open datasets in the reference list with repository, version, year,
persistent identifier, and the
[dataset] marker where applicable.
- Programs even when microdata are proprietary. Supply all cleaning and estimation code so the
workflow is auditable even if IRS/SSA/CMS or register microdata cannot leave the enclave.
- Disclosure compliance. Document cell-size suppression and output-clearance for restricted data;
never embed suppressed cells in shared outputs.
- One master script (
run_all) regenerating every table and figure from inputs; pin
software/package versions (renv.lock, requirements.txt, recorded ssc versions); set and report
seeds for bootstrap / randomization inference.
- README mapping each exhibit to the script that produces it.
Checklist
Anti-patterns
- Treating Option C as optional boilerplate rather than a repository link or a concrete reason data
cannot be shared
- A data-availability statement that does not match what was actually used
- Sharing restricted-data outputs without documented disclosure clearance
- A package with no master script, unpinned versions, or unreported seeds
Data-availability routing by source
Public-finance papers lean on restricted microdata more than most fields, so the availability statement
is rarely "open repository." Route by what you actually used.
| Data source | Availability statement says | What you still ship |
|---|
| Public tax/SOI tabulations, survey extracts | Link repository (Mendeley/openICPSR/Zenodo) and cite dataset | Data + all code |
| IRS/SSA/CMS enclave microdata | Access path + agency + why microdata cannot leave | All cleaning + estimation code |
| European whole-population registers | Application route, custodian, approval ID | Code + non-disclosive aggregates |
| Mixed (public + restricted) | Split the statement by component | Repository for the open part, access note otherwise |
Worked vignette: a register-DID package referees can trust
A social-insurance reform evaluated on a national register cannot share person-level rows. The package
still makes the DID pipeline auditable: run_all regenerates every exhibit from cleared aggregates; the
README maps Table 3 (the moral-hazard wedge) and Figure 2 (the event study) to their scripts;
renv.lock pins versions; the bootstrap seed is fixed so the SEs on the MVPF = 1.4 statistic
(illustrative) replicate. The availability statement names the custodian, the approval ID, and the
cell-suppression rule (min count 10), so a referee sees the workflow without touching protected
microdata.
Calibration anchors
- The reproducibility bar a JPubE referee imagines: could a second analyst, given the same authorized
access, rebuild every elasticity/MVPF/bunching number? Code completeness and exact access
documentation are what you control.
- Option C is about deposit/citation/linking or a sharing explanation; it is not the same as promising a
named AEA-style data-editor code run.
Output format
【Data type】open / restricted-administrative / register / mixed
【Availability statement】drafted + consistent? [Y/N]
【Restricted access】path + agency + limits documented? [Y/N]
【Programs supplied】all cleaning + estimation code? [Y/N]
【Reproducibility】run_all + pinned versions + seeds? [Y/N]
【Policy check】Option C route and Editorial Manager data fields checked? [Y/N]
【Next step】jpube-review-process
