---

name: ectj-replication-and-data-policy description: Use when preparing The Econometrics Journal replication files, README, software versions, data documentation, seeds, proprietary-data exemptions, and OUP Supporting Information package after conditional acceptance or before submission risk review.

EctJ Replication And Data Policy

Use this before submission for planning and after conditional acceptance for packaging. Reopen the RES replication policy before final delivery.

Package checklist

• Prepare a README that explains file contents, execution order, software, package versions, expected outputs, runtime, and system requirements.
• Include data or clear access instructions with complete variable documentation. If using proprietary formats, provide ASCII alternatives when required.
• Include all code needed to reproduce tables, figures, simulations, appendices, and supplementary results; set random seeds.
• Explain usage restrictions, confidential data, or exemption requests at first submission if current policy requires early disclosure.
• Expect accepted packages to appear as OUP Supporting Information when permitted.
• Treat non-compliance as publication risk; the RES policy says the board may refuse publication for non-compliance.

Methods-paper package pattern

For an EctJ methods paper, the replication package should let a referee rerun the claim hierarchy:

1. 00_setup records software versions, seeds, paths, and package checks.
2. 01_simulation recreates the minimal Monte Carlo tables used in the paper.
3. 02_application recreates the empirical illustration or diagnostic example.
4. 03_figures_tables exports exactly the exhibits in the manuscript and supplement.
5. README states expected runtime, hardware assumptions, and which files are slow or optional.

If the proof is symbolic rather than computational, still include any scripts used for figures, numerical examples, or robustness checks. Do not leave code that changes a published number outside the package.

Acceptance-risk audit

Run this audit before treating the package as ready:

• Match every numbered table, figure, simulation panel, and appendix exhibit to a producing script.
• Record the exact software stack, solver options, random seeds, BLAS or parallel settings, and any non-default package versions that can change Monte Carlo output.
• Separate slow exhaustive simulations from the short smoke run a referee can execute quickly; both should write comparable output names.
• For restricted data, provide the legal access path, synthetic or public-use substitute when possible, and the reason the substitute cannot reproduce confidential quantities exactly.
• Check that manuscript labels, supplement labels, file names, and README names agree after final revisions. A stale label is evidence that the package was not rerun.

For EctJ, the package should make the method credible, not merely archived. A referee should be able to see which computation supports the leading-case theory, which computation supports practical use, and which files are optional robustness material.

Monte Carlo determinism checks

Simulation-heavy EctJ papers fail reproduction for reasons pure-empirics packages never face. Verify each before delivery:

• One named seed per experiment, set inside the script rather than at the console; the RES policy explicitly expects seeds to be set for simulations.
• Parallel runs use a reproducible RNG-stream scheme (one substream per replication), because thread scheduling otherwise reorders draws and shifts the third digit of rejection rates.
• Record solver tolerances and optimizer starting values; a Monte Carlo that mostly converges must log which replications failed and how they were handled.
• Rerun the smoke version on a clean machine and diff against the shipped output; illustrative bar: simulated sizes should match to the digits printed in the paper.

Calibration: what a posted EctJ package looks like

Accepted packages appear alongside the article as OUP Supporting Information. Typical shape, hedged where journal practice varies: a top-level README, a master script per claim layer (simulation, application, exhibits), pinned software versions, and data or documented access instructions with ASCII fallbacks for proprietary formats. Exact file-format and size constraints on the OUP side can change; confirm against the journal's current author guidelines before the final upload.

Output format

[Replication status] ready / needs fixes / blocked
[Contents] <data/code/README/software/seeds>
[Restricted-data issue] <none, access path, or exemption request>
[Reproduction command] <master script or workflow>
[Publication risk] <low/medium/high and why>