Skip to content
Back to skills

Jhr Replication And Data Policy

ASecurity

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.

  • 3 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 12, 2026
ai-agentspythongogitbackenddocumentation

Security analysis

A100/100

Scanned September 12, 2026

npx -y skills add thedixitjain/the-mega-skill-library --skill jhr-replication-and-data-policy --agent claude-code

Installs 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 with every re-scan.

Security grade badge for Jhr Replication And Data Policy
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/thedixitjain-jhr-replication-and-data-policy/badge)](https://www.skillsdirectory.com/skills/thedixitjain-jhr-replication-and-data-policy)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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`

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.