Jpube replication and data policy

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

• Data-availability statement drafted and consistent with the data used
• Open data deposited, cited, and linked; restricted data explained with access path
• Restricted-data access path, agency, and sharing limits documented
• All cleaning + estimation programs supplied (even if microdata are restricted)
• Disclosure / cell-suppression compliance documented for shared outputs
• run_all master script regenerates all exhibits; versions and seeds pinned
• README maps exhibits -> scripts
• Current JPubE/Elsevier data fields checked in Editorial Manager before upload

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