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.

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