Use when preparing Journal of Human Resources data and replication materials: archive plan footnote, public repository deposit, CC0 license, Data Availability Statement, read-me file, waiver requests, RCT pre-analysis-plan statements, and code package.
Scanned 9/12/2026
Install to Claude Code
npx -y skills add thedixitjain/the-mega-skill-library --skill jhr-replication-and-data-policy --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Jhr Replication And Data Policy?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/thedixitjain-jhr-replication-and-data-policy)More formats (shields.io, HTML) on the badges page.
---
name: jhr-replication-and-data-policy
description: "Use when preparing Journal of Human Resources data and replication materials: archive plan footnote, public repository deposit, CC0 license, Data Availability Statement, read-me file, waiver requests, RCT pre-analysis-plan statements, and code package."
category: backend-and-data
source_repo: brycewang-stanford/Awesome-Journal-Skills
source_path: "Journal-of-Human-Resources-Skills/skills/jhr-replication-and-data-policy/SKILL.md"
source_url: https://github.com/brycewang-stanford/Awesome-Journal-Skills/blob/HEAD/Journal-of-Human-Resources-Skills/skills/jhr-replication-and-data-policy/SKILL.md
---
# Replication & Data Policy (jhr-replication-and-data-policy)
## When to trigger
- The paper is being prepared for JHR submission or acceptance
- You need the archive-plan footnote, Data Availability Statement, or waiver
- Data are restricted, proprietary, administrative, or RCT-based
## JHR policy core
JHR's data policy is unusually concrete: accepted papers must preserve data and
post replication materials in a well-curated public repository where possible,
with a public-domain CC0 1.0 Universal license. At submission, include an archive
plan footnote with a persistent link if available, or request a waiver at initial
submission.
## Package contents
- Data files that can legally be shared
- Code and models needed to reproduce all tables and figures
- Read-me file explaining the sequence
- Data Availability Statement on the title page
- Restricted-data access instructions or waiver justification
- For RCTs: pre-analysis plan registration and deviations
## Acceptance-stage replication gate
Do not wait until conditional acceptance to discover that the archive cannot be
built. Run this gate before initial submission and again when the paper enters
revision.
| Gate | Pass condition | Blocker to surface early |
|---|---|---|
| Exhibit inventory | Every main-text and appendix table/figure maps to one script and one input dataset | Hand-built table, untracked spreadsheet edit, or private intermediate file |
| Data rights | Each dataset is classified public, restricted, proprietary, confidential, or author-generated | No redistribution right or unclear crosswalk ownership |
| Repository plan | Public repository path, DOI plan, CC0 posture, and embargo/waiver status recorded | Deposit location or license undecided |
| Code portability | A clean clone runs from raw/public inputs or approved restricted mount points | Absolute paths, local user directories, hidden credentials |
| Reviewer audit trail | Read-me explains what a referee can reproduce now and what requires restricted access | DAS promises more than the archive can deliver |
## Waiver logic
Request a waiver at initial submission when data cannot be publicly deposited.
State how other researchers can obtain the data and commit to provide reasonable
guidance.
## Waiver evidence test
A waiver is not a reason to ship a thin package. Before asking for one, prepare
evidence that the non-public data barrier is real and that the reproducibility
route remains usable.
| Question | Strong answer | Weak answer |
|---|---|---|
| Why can the data not be posted? | Contract, statute, IRB term, license, or agency rule named in plain language | "Confidential" without a source |
| How can another researcher apply? | Agency/vendor/contact path, application steps, and expected constraints | "Contact the authors" only |
| What can still be checked? | Code, dictionary, synthetic data, logs, exhibit map, and public-source rebuild scripts | PDF tables only |
| What does the DAS say? | Same access route and limits as the footnote and read-me | DAS, footnote, and read-me disagree |
## Restricted-data package
When the data cannot be public, still prepare:
- synthetic or public-use data that exercises every script path when possible;
- data dictionary with variable construction and source tables;
- access instructions, application links, and approval constraints;
- log showing which outputs require restricted data;
- archive-plan footnote explaining the waiver and reproducibility route.
## Deposit decisions by data source
| Data source | What can usually be deposited | Waiver posture |
|---|---|---|
| Public-use surveys (CPS, ACS, NLSY, PSID extracts) | Extraction code plus the analysis file, or code that rebuilds it from raw downloads | Rarely needed; check redistribution terms of each survey |
| State administrative records (UI wages, K-12, Medicaid) | Code, codebooks, aggregate exhibits; microdata stays with the agency | Waiver expected; document the access route precisely |
| Own RCT microdata | De-identified analysis files under CC0 where consent and IRB allow | Partial waiver for identifying fields; PAP registration stated |
| Proprietary/commercial data | Code, pseudo-data, purchase or license instructions | Waiver with a named acquisition path |
| Linked or matched files | Each source assessed separately; the crosswalk is often the binding constraint | Mixed: deposit what is public, waiver the link keys |
Repository choice and licensing details evolve — confirm against the journal's
current author guidelines before depositing.
## Exhibit-to-script map
The read-me should include a compact manifest. This is the fastest way to catch
irreproducible tables before upload.
| Exhibit | Output file | Producing script | Data requirement | Notes |
|---|---|---|---|---|
| Table 1 | `tables/table1_balance.tex` | `03_tables/table1_balance.do` | public-use extract | Rebuilds from raw survey download |
| Figure 2 | `figures/event_study.pdf` | `04_figures/event_study.R` | restricted admin file | Runs only on approved secure machine |
| Appendix Table A4 | `tables/a4_placebo.tex` | `05_appendix/placebo.py` | synthetic test + restricted file | Synthetic version verifies code path |
Use the actual filenames from the project. If an exhibit has no producing
script, treat that as a package defect, not a documentation detail.
## Worked waiver scenario: UI wage records
Illustrative case: earnings outcomes come from one state's unemployment-insurance
wage records under a data-use agreement that bars any microdata release.
1. Footnote at submission: names the agency, the agreement, and states that
code, codebooks, and a synthetic test file will be archived under CC0.
2. The read-me lists the application steps and typical approval constraints a
replicator faces, and which exhibits need the restricted extract.
3. Every script runs against the synthetic file end-to-end so reviewers can
verify logic without the data.
4. The Data Availability Statement mirrors the footnote — the two must not
drift apart between submission and acceptance.
## Read-me skeleton for the JHR archive
```text
README
1. Data sources & access (public files included; restricted: how to apply)
2. Software & versions (Stata/R/Python; packages pinned)
3. Run order: 00_master -> 01_clean -> 02_analysis -> 03_exhibits
4. Runtime & hardware notes; random seeds fixed where used
5. Exhibit map: each table/figure -> producing script -> data requirement
6. License: CC0 1.0 Universal (data and code deposited)
```
## Pre-acceptance dry run
- Clone the package to a clean directory and run it without manual edits.
- Confirm every main-text and appendix exhibit regenerates byte-stable or with
documented stochastic variation.
- Check that no intermediate file under a restrictive license leaks into the
deposit.
- Compare the archive footnote, Data Availability Statement, waiver request,
read-me, and repository landing page for identical access claims.
- Save the run log and unresolved exceptions in the project archive before
acceptance, so the team can fix blockers before production deadlines.
## Output format
```text
[Data status] public / restricted / proprietary / confidential / mixed
[Archive plan footnote] ...
[DAS] ...
[Waiver needed] yes/no + reason
[Replication gate] exhibit map / data rights / repository plan / code portability / audit trail
[Restricted-data route] public deposit / partial waiver / full waiver + access path
[Dry-run result] clean / stochastic differences documented / blocked
[RCT PAP status] ...
[Next step] jhr-submission
```
---
**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `Journal-of-Human-Resources-Skills/skills/jhr-replication-and-data-policy/SKILL.md`
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!