# CLAUDE.md — Intraday Market Fragility Research Program

# 0. Role, mission, and non-negotiable standard

You are the lead research engineer, empirical asset-pricing researcher, market-microstructure specialist, econometrician, data auditor, and academic writer for a high-frequency finance project intended to reach the submission standard of The Journal of Finance (JF).

Your mission is to design, execute, document, and write a complete, reproducible research paper based primarily on the Hugging Face dataset:

• Dataset identifier: mito0o852/OHLCV-1m
• Claimed content: U.S. equity OHLCV bars at one-minute frequency
• Claimed coverage: 1992–2026
• Claimed storage: monthly Parquet files
• Claimed original source: Finnhub

The provisional paper title is:

Faster, Wider, More Fragile? The Evolution of Intraday Shock Propagation in U.S. Equity Markets

The central research question is:

How have the speed, breadth, persistence, and asymmetry of intraday shock propagation across U.S. equities evolved over the past three decades, and under which market conditions does an initially idiosyncratic shock become sectoral or market-wide?

The central economic hypothesis is:

Modern markets may absorb ordinary shocks more efficiently while transmitting extreme shocks more rapidly and discontinuously.

This is not a generic machine-learning forecasting project. The paper must make a clear contribution to finance by documenting new economic facts, proposing transparent measures of intraday contagion and fragility, testing economic mechanisms, distinguishing common information from genuine propagation, and establishing robustness through credible empirical designs.

The final output must be:

1. fully reproducible;
2. empirically honest;
3. economically motivated;
4. methodologically rigorous;
5. written in polished academic English;
6. formatted as a complete LaTeX submission package;
7. accompanied by a detailed Internet Appendix;
8. accompanied by code, logs, manifests, tables, figures, and machine-readable results;
9. prepared to the standard expected in a top finance journal;
10. explicit about every limitation imposed by OHLCV data.

Never fabricate data, results, citations, institutional details, variable definitions, statistical significance, sample sizes, or conclusions. Never write a result in the paper before it has been generated and verified from a saved machine-readable output.

# 1. Research philosophy

# 1.1 The paper must answer an economic question

The main contribution cannot be “a large model predicts one-minute returns.” Prediction may support the analysis, but the paper must answer:

• When does a local shock spread?
• How rapidly does it spread?
• How broadly does it spread?
• How persistent is the propagation?
• Is propagation asymmetric for negative and positive shocks?
• Has propagation changed over time?
• Is the change gradual, nonlinear, or concentrated around market-structure transitions?
• Which securities become transmitters, bridges, absorbers, or amplifiers?
• Is the observed comovement genuine propagation or simultaneous exposure to common news?
• Does market efficiency in normal periods coexist with fragility in the tails?

# 1.2 Distinguish observed liquidity from liquidity proxies

The dataset contains OHLCV bars, not necessarily:

• quotes;
• bid-ask spreads;
• order-book depth;
• order imbalance;
• trades and quotes;
• market-order direction;
• hidden liquidity;
• venue-level fragmentation;
• execution costs.

Therefore:

• Do not claim to observe liquidity directly.
• Use terms such as “OHLCV-based liquidity proxy,” “trading-activity shock,” “price-discontinuity proxy,” or “latent market fragility.”
• Treat the high-low range, zero-return frequency, volume shocks, price impact proxies, and realized volatility as imperfect proxies.
• Include a dedicated limitations section.
• If quote or trade data are later added, treat that as an extension, not as information already present.

# 1.3 Prediction is not identification

Every analysis must distinguish:

1. contemporaneous co-movement;
2. predictive lead-lag;
3. propagation conditional on observed information;
4. causal propagation;
5. structural counterfactual simulation.

Do not use causal language unless the design supports it. Use “association,” “predictive propagation,” or “network response” for observational results. Reserve “causal” for clearly defended event-based or quasi-experimental designs.

# 2. Project organization

Create the following project structure at the repository root:

intraday-fragility/
├── CLAUDE.md
├── README.md
├── LICENSE
├── CITATION.cff
├── pyproject.toml
├── uv.lock
├── environment.yml
├── .env.example
├── .gitignore
├── Makefile
├── config/
│   ├── base.yaml
│   ├── paths.yaml
│   ├── sample_filters.yaml
│   ├── shock_definitions.yaml
│   ├── models.yaml
│   ├── figures.yaml
│   └── tables.yaml
├── data/
│   ├── raw/
│   ├── manifests/
│   ├── interim/
│   ├── processed/
│   ├── external/
│   └── metadata/
├── logs/
│   ├── download/
│   ├── audit/
│   ├── preprocessing/
│   ├── estimation/
│   └── paper/
├── notebooks/
│   ├── 00_dataset_discovery.ipynb
│   ├── 01_small_sample_audit.ipynb
│   ├── 02_intraday_patterns.ipynb
│   └── 03_prototype_results.ipynb
├── src/
│   └── intraday_fragility/
│       ├── __init__.py
│       ├── cli.py
│       ├── paths.py
│       ├── logging_utils.py
│       ├── download.py
│       ├── manifest.py
│       ├── schema.py
│       ├── calendars.py
│       ├── corporate_actions.py
│       ├── identifiers.py
│       ├── universe.py
│       ├── cleaning.py
│       ├── features.py
│       ├── shocks.py
│       ├── networks.py
│       ├── contagion.py
│       ├── econometrics.py
│       ├── inference.py
│       ├── robustness.py
│       ├── simulations.py
│       ├── figures.py
│       ├── tables.py
│       ├── latex.py
│       └── validation.py
├── scripts/
│   ├── 00_probe_hf_dataset.py
│   ├── 01_download_hf_data.py
│   ├── 02_build_raw_manifest.py
│   ├── 03_audit_schema.py
│   ├── 04_audit_market_calendar.py
│   ├── 05_audit_prices_and_volume.py
│   ├── 06_detect_corporate_actions.py
│   ├── 07_construct_security_master.py
│   ├── 08_build_clean_minute_panel.py
│   ├── 09_build_daily_metadata.py
│   ├── 10_construct_features.py
│   ├── 11_detect_shocks.py
│   ├── 12_estimate_networks.py
│   ├── 13_measure_propagation.py
│   ├── 14_run_baseline_regressions.py
│   ├── 15_run_event_studies.py
│   ├── 16_run_robustness.py
│   ├── 17_run_placebos.py
│   ├── 18_build_figures.py
│   ├── 19_build_tables.py
│   ├── 20_compile_paper.py
│   └── 21_validate_release.py
├── tests/
│   ├── test_schema.py
│   ├── test_calendars.py
│   ├── test_cleaning.py
│   ├── test_features.py
│   ├── test_shocks.py
│   ├── test_networks.py
│   ├── test_econometrics.py
│   └── test_tables.py
├── outputs/
│   ├── diagnostics/
│   ├── estimates/
│   ├── figures/
│   ├── tables/
│   ├── models/
│   └── release/
├── paper/
│   ├── main.tex
│   ├── preamble.tex
│   ├── title_page.tex
│   ├── abstract.tex
│   ├── sections/
│   │   ├── 01_introduction.tex
│   │   ├── 02_literature.tex
│   │   ├── 03_data.tex
│   │   ├── 04_measurement.tex
│   │   ├── 05_empirical_design.tex
│   │   ├── 06_results.tex
│   │   ├── 07_mechanisms.tex
│   │   ├── 08_robustness.tex
│   │   └── 09_conclusion.tex
│   ├── tables/
│   ├── figures/
│   ├── bibliography/
│   │   └── references.bib
│   └── styles/
├── appendix/
│   ├── internet_appendix.tex
│   ├── sections/
│   ├── tables/
│   └── figures/
└── docs/
    ├── DATA_DICTIONARY.md
    ├── DATA_AUDIT.md
    ├── EMPIRICAL_DESIGN.md
    ├── LITERATURE_MAP.md
    ├── REPRODUCIBILITY.md
    ├── COMPUTE_LOG.md
    ├── DECISION_LOG.md
    └── LIMITATIONS.md

Use relative paths. No user-specific absolute path may appear in committed code.

# 3. Execution protocol

# 3.1 Work in stages

Execute the project in the following order:

# Stage A — Dataset discovery and minimal probe

Do not download the entire dataset immediately. First:

1. inspect the Hugging Face repository metadata;
2. list all files, sizes, hashes if available, and last-modified information;
3. inspect the dataset card and revision history;
4. download only one early, one middle, and one recent monthly file;
5. infer the physical schema;
6. inspect timestamps, symbols, row counts, missingness, duplicates, price and volume units;
7. estimate total storage requirements after download, decompression, cleaning, features, and outputs;
8. write docs/DATA_AUDIT.md with preliminary findings;
9. stop if the schema is unusable or if legal/access restrictions prevent research use.

# Stage B — Full download with manifest and resumability

Only after Stage A passes:

1. download all target files;
2. use resumable transfers;
3. pin the exact dataset revision or commit hash;
4. save every file with checksum, byte size, row count, schema, and download timestamp;
5. never silently overwrite an existing file;
6. verify integrity before marking a file complete;
7. write a machine-readable manifest;
8. permit partial reruns and node-level parallelism.

# Stage C — Raw-data audit

Before constructing returns:

1. audit timestamp coverage;
2. map timestamps to the correct exchange timezone;
3. identify pre-market, regular, and after-hours observations;
4. inspect daylight-saving transitions;
5. compare observed minutes with the official U.S. exchange calendar;
6. identify half-days and exceptional closures;
7. detect duplicate symbol–timestamp observations;
8. detect non-monotonic timestamps;
9. detect impossible OHLC relationships;
10. inspect zeros, negative values, stale prices, and extreme volume;
11. identify possible split-related jumps;
12. inspect symbol reuse and ticker changes;
13. determine whether delisted securities are present;
14. quantify survivorship and look-ahead risks;
15. identify ETFs, ADRs, preferred shares, warrants, funds, and non-common-equity instruments where possible;
16. document uncertainty rather than guessing.

# Stage D — Clean panel and metadata

Construct:

• a regular-hours baseline panel;
• an extended-hours robustness panel;
• a broad universe;
• a conservative common-stock universe;
• a high-liquidity universe;
• a balanced-panel subsample only for diagnostics, never as the sole main sample.

# Stage E — Descriptive evidence

Document:

• sample coverage over time;
• number of securities;
• number of observations;
• missing minute patterns;
• intraday seasonality;
• cross-sectional distributions;
• volume concentration;
• volatility concentration;
• extreme-return frequency;
• changes over decades.

# Stage F — Shock measurement and propagation

Implement the full empirical design described below.

# Stage G — Tables, figures, and paper

All tables and figures must be generated from saved results. Never manually type numerical results into LaTeX.

# 4. Data acquisition requirements

# 4.1 Hugging Face access

Use official Hugging Face tooling when practical:

• huggingface_hub
• hf_hub_download
• repository file listing APIs
• revision pinning
• authenticated access only if required

The downloader must support:

• dry-run mode;
• file-range filters;
• year and month filters;
• retry with exponential backoff;
• resumability;
• maximum concurrent downloads;
• checksum verification;
• per-file logs;
• node-aware sharding;
• safe interruption;
• disk-space checks;
• idempotence.

Create CLI commands such as:

python -m intraday_fragility.cli probe-data
python -m intraday_fragility.cli download --start 1992-01 --end 2026-12
python -m intraday_fragility.cli verify-download
python -m intraday_fragility.cli audit-raw

# 4.2 Manifest

Create data/manifests/raw_files.parquet and data/manifests/raw_files.csv with at least:

• dataset_id;
• dataset_revision;
• remote_path;
• local_path;
• year;
• month;
• expected_bytes;
• downloaded_bytes;
• sha256;
• status;
• download_started_at;
• download_completed_at;
• row_count;
• column_names;
• column_types;
• min_timestamp;
• max_timestamp;
• unique_symbol_count;
• duplicate_key_count;
• null_count_by_column;
• audit_version;
• code_commit.

# 4.3 Never infer undocumented semantics

For each field, determine and document:

• exact name;
• data type;
• units;
• timezone;
• adjustment status;
• whether price is raw or split-adjusted;
• whether volume is raw or adjusted;
• whether timestamps denote bar open or bar close;
• whether bars with no trades are omitted or filled;
• whether symbols are point-in-time;
• whether source corrections are incorporated.

If a property cannot be established, label it “unknown” and design robustness checks around that uncertainty.

# 5. Data-quality audit

# 5.1 Schema validation

For every file and every batch, verify:

[ \text{Low}{i,t} \leq \min(\text{Open}{i,t},\text{Close}_{i,t}) ]

and

[ \text{High}{i,t} \geq \max(\text{Open}{i,t},\text{Close}_{i,t}) ]

as well as:

[ \text{Low}{i,t} \leq \text{High}{i,t}. ]

Flag but do not automatically delete all violations. Report counts, rates, symbols, dates, and magnitudes.

# 5.2 Timestamp and calendar checks

Use a recognized exchange-calendar library and independently validate important dates.

Baseline regular session:

• 09:30 to 16:00 Eastern Time;
• respect historical calendar variation;
• handle early closes;
• handle daylight saving correctly;
• do not assume exactly 390 bars for every date.

Determine whether the source timestamps are UTC, local exchange time, or another convention by empirical checks.

# 5.3 Duplicate handling

The natural key is initially assumed to be:

(symbol, timestamp)

But this assumption must be verified.

For duplicate keys:

1. check whether rows are identical;
2. inspect whether duplicates arise from multiple venues or source revisions;
3. preserve raw copies;
4. create deterministic resolution rules;
5. report sensitivity to alternative rules.

# 5.4 Corporate actions

OHLCV-based research is highly vulnerable to splits and ticker changes.

Implement:

• detection of discontinuities near rational split ratios;
• cross-checking against external corporate-action sources if legally and technically feasible;
• split flags;
• exclusion windows around suspected splits;
• robustness using close-to-close versus open-to-close returns;
• separate treatment of extreme jumps plausibly caused by corporate actions.

Never winsorize away a possible split without logging it.

# 5.5 Security identity

A ticker is not a permanent security identifier.

Attempt to construct or merge a point-in-time security master containing:

• ticker;
• permanent identifier if available;
• issuer name;
• security type;
• exchange;
• listing and delisting dates;
• sector and industry;
• ETF indicator;
• ADR indicator;
• common-stock indicator;
• share class.

If permanent identifiers cannot be recovered for the full period:

• explicitly state this limitation;
• avoid interpreting long ticker histories as one unchanged security;
• create ticker-spell intervals;
• run conservative analyses within continuous ticker episodes.

# 5.6 Survivorship bias

Determine whether the data include delisted securities and whether historical files preserve the contemporaneous universe.

Produce:

• yearly entry counts;
• yearly exit counts;
• symbol survival curves;
• sample counts by vintage;
• comparisons of balanced and unbalanced panels;
• a formal discussion of possible survivorship bias.

# 5.7 Missingness

Measure missingness at:

• file level;
• day level;
• symbol-day level;
• minute-of-day level;
• decade level;
• market-state level.

Do not forward-fill prices in the main analysis unless the precise estimand requires a regular grid. If a regular grid is needed:

• distinguish “no recorded bar” from “zero return”;
• retain a missing-trade indicator;
• report results without imputation;
• use previous-tick interpolation only in explicitly labeled robustness analyses.

# 6. Sample construction

Create transparent sample filters in config/sample_filters.yaml.

# 6.1 Baseline universe

The baseline should target U.S.-listed common equities during regular trading hours, subject to defensible filters such as:

• valid OHLC;
• positive price;
• positive or nonnegative volume as appropriate;
• minimum number of valid bars per day;
• minimum trading history;
• exclusion of obvious corporate-action contamination;
• removal of duplicate records;
• no use of future information in inclusion rules.

# 6.2 Alternative universes

Construct at least:

1. all available instruments;
2. common stocks only;
3. stocks excluding ETFs and ADRs;
4. liquid stocks based on lagged information;
5. price above a lagged threshold;
6. top 500, 1,000, and 3,000 securities by lagged dollar volume;
7. continuous-history subsample;
8. pre-2001, 2001–2009, 2010–2019, and 2020 onward;
9. regular-hours only;
10. extended-hours included.

Any liquidity-based inclusion criterion must use lagged data to avoid look-ahead bias.

# 7. Variable construction

All features must be defined in docs/DATA_DICTIONARY.md with formula, timing, units, and availability.

# 7.1 Returns

Construct:

[ r_{i,t} = \log(P_{i,t})-\log(P_{i,t-1}). ]

Use alternative prices:

• close-to-close minute return;
• open-to-close bar return;
• midpoint proxy ((H+L)/2) only as robustness;
• previous valid close return;
• overnight return separately.

Never bridge overnight and intraday returns without an explicit definition.

# 7.2 Realized volatility

At stock-day level:

[ RV_{i,d} = \sum_{t \in d} r_{i,t}^{2}. ]

Construct:

• 5-minute RV;
• 15-minute RV;
• 30-minute RV;
• daily RV;
• upside and downside semivariance;
• bipower variation if data quality permits;
• jump proxies;
• realized quarticity.

# 7.3 Range-based measures

Examples:

[ Range_{i,t}=\log(H_{i,t})-\log(L_{i,t}) ]

and established range-based volatility estimators when their assumptions are defensible.

# 7.4 Trading activity

Construct:

• raw volume;
• log volume;
• dollar volume;
• turnover if shares outstanding become available;
• volume relative to the same minute of the day;
• volume z-score based only on lagged observations;
• fraction of daily volume occurring in each interval;
• market-wide and sector-wide volume concentration.

# 7.5 OHLCV-based illiquidity and price-impact proxies

Possible proxies include:

[ ILLIQ_{i,t} = \frac{|r_{i,t}|}{DollarVolume_{i,t}+\epsilon}. ]

Also consider:

• high-low range divided by dollar volume;
• absolute residual return per unit of volume;
• zero-return frequency;
• stale-price duration;
• Roll-type proxies only if valid at the available frequency;
• Corwin–Schultz estimates only at a frequency consistent with the estimator.

Use multiple proxies because no single OHLCV measure identifies true liquidity.

# 7.6 Intraday seasonality

For each variable, estimate minute-of-day seasonality using only historical information or a clearly defined full-sample descriptive normalization.

Main predictive and causal specifications must use lagged or training-period seasonality estimates.

Construct standardized variables:

# [ z_{i,t}^{x}

\frac{x_{i,t}-\widehat{\mu}{i,\tau(t)}}{\widehat{\sigma}{i,\tau(t)}}, ]

where (\tau(t)) is minute of day.

Use robust alternatives based on the median and MAD.

# 8. Defining idiosyncratic intraday shocks

A raw extreme return is not necessarily idiosyncratic. Construct several shock definitions.

# 8.1 Residual return model

Estimate rolling or recursively updated models such as:

# [ r_{i,t}

\alpha_{i,\tau} +\beta_{i,m,t}r_{m,t} +\beta_{i,s,t}r_{s(i),t} +\boldsymbol{\gamma}{i,t}'F_t +\varepsilon{i,t}, ]

where:

• (r_{m,t}) is a broad market return;
• (r_{s(i),t}) is the sector return;
• (F_t) may contain principal components or other common factors;
• (\alpha_{i,\tau}) absorbs intraday seasonality.

Prevent mechanical contamination by excluding stock (i) from market and sector aggregates when feasible.

# 8.2 Shock threshold

Define a baseline shock as:

[ Shock_{i,t}=1\left( |\varepsilon_{i,t}| > q_{i,\tau,t}(p) \right), ]

where (q_{i,\tau,t}(p)) is a lagged conditional extreme quantile.

Use thresholds such as:

• 99th percentile;
• 99.5th percentile;
• 99.9th percentile;
• 4, 5, and 6 robust standard deviations;
• extreme-value-theory thresholds;
• jump-test thresholds.

Separate:

• positive shocks;
• negative shocks;
• return shocks;
• volatility shocks;
• volume shocks;
• combined return-volume shocks;
• range shocks;
• illiquidity-proxy shocks.

# 8.3 Shock isolation

To reduce common-news contamination, require one or more of:

• low contemporaneous market return;
• low contemporaneous sector return;
• large idiosyncratic residual;
• leave-one-out factor construction;
• no simultaneous extreme shock in a large fraction of the market;
• exclusion of scheduled macro announcement windows for the idiosyncratic baseline;
• separate common-shock sample.

Do not define isolation so strictly that only trivial events remain. Report the trade-off.

# 9. Measuring propagation

# 9.1 Outcome horizons

Use horizons:

[ h \in {1,2,5,10,15,30,60,120}\text{ minutes}. ]

Respect session boundaries. Do not mechanically carry an intraday horizon across the overnight period in the baseline.

# 9.2 Breadth

Define market-wide propagation breadth:

# [ Breadth_{i,t}(h)

\frac{1}{N_{t,h}-1} \sum_{j\neq i} 1\left(|AR_{j,t+h}|>q_{j,\tau,t}\right). ]

Also define:

• cumulative breadth through (h);
• sector breadth;
• connected-neighbor breadth;
• non-sector breadth;
• breadth weighted by lagged dollar volume;
• breadth weighted by network proximity.

# 9.3 Speed

Define:

• minutes until 1%, 5%, 10%, or 25% of eligible securities react;
• time to peak breadth;
• half-life of the response;
• propagation velocity over network distance;
• hazard of first response.

If a threshold is never reached, treat the observation as right-censored rather than assigning an arbitrary large value.

# 9.4 Intensity

Define:

# [ Intensity_{i,t}(h)

\frac{1}{N-1} \sum_{j\neq i}|AR_{j,t+h}|. ]

Construct signed and unsigned versions.

# 9.5 Amplification

Define the Intraday Shock Amplification Ratio:

# [ ISAR_{i,t}(h)

\frac{ \sum_{j\neq i}w_{ij,t}|AR_{j,t+h}| }{ |\varepsilon_{i,t}|+\epsilon }. ]

Explore alternative normalizations and show that results are not artifacts of a small denominator.

# 9.6 Persistence

Measure:

• cumulative response;
• response half-life;
• reversal after the initial response;
• permanent versus transitory components;
• integrated response over 5, 15, 30, 60, and 120 minutes.

# 9.7 Asymmetry

Estimate separate responses to:

• positive versus negative shocks;
• high versus low market volatility;
• opening, midday, and closing periods;
• high versus low aggregate correlation;
• high versus low market concentration;
• liquid versus illiquid source securities;
• large versus small shock magnitude.

# 10. Dynamic network construction

The network must be estimated using information available before the shock.

# 10.1 Candidate networks

Estimate several networks:

1. sector membership;
2. rolling return correlation;
3. partial correlation;
4. lead-lag predictive network;
5. volume-shock correlation;
6. volatility-spillover network;
7. sparse VAR;
8. graphical LASSO;
9. low-rank plus sparse network;
10. dynamic factor residual network;
11. Granger-style predictive network;
12. learned graph representation, used as an extension rather than the sole method.

# 10.2 Timing discipline

For a shock at time (t), network weights (W_{ij,t}) must be estimated only from data dated strictly before (t).

Use:

• rolling windows;
• expanding windows;
• annual network freezes;
• monthly network freezes;
• cross-fitted network estimation.

# 10.3 Centrality and roles

Compute lagged:

• out-strength;
• in-strength;
• eigenvector centrality;
• PageRank;
• betweenness;
• community bridge score;
• k-core;
• participation coefficient;
• transmitter and receiver scores.

Define economic roles:

• transmitter;
• receiver;
• amplifier;
• absorber;
• bridge;
• isolated security.

Do not infer economic importance from one centrality measure alone.

# 11. Baseline econometric designs

# 11.1 Local projections

Estimate horizon-specific responses:

# [ Y_{j,t+h}

\alpha_{j} +\delta_{\tau(t)} +\lambda_{d} +\beta_h Shock_{i,t} +\theta_h Shock_{i,t}W_{ij,t^-} +\Gamma_h'X_{i,j,t^-} +u_{i,j,t+h}. ]

Possible fixed effects:

• receiver security;
• source security;
• date;
• minute of day;
• source-by-year;
• receiver-by-year;
• sector-by-date;
• market-state bins.

Do not include fixed effects that absorb the variable of interest without recognizing it.

# 11.2 Cascade-level regressions

At the source-shock level:

# [ Cascade_{i,t}(h)

\alpha +\beta_1 Magnitude_{i,t} +\beta_2 Negative_{i,t} +\beta_3 Centrality_{i,t^-} +\beta_4 State_{t^-} +\beta_5 Magnitude_{i,t}\times State_{t^-} +\mu_i+\lambda_d+\delta_{\tau} +\varepsilon_{i,t,h}. ]

# 11.3 Long-run evolution

Estimate flexible time variation:

• year fixed effects interacted with shock magnitude;
• rolling coefficients;
• decade bins;
• splines;
• structural-break tests;
• distributional regressions;
• quantile regressions.

Do not impose a linear “algorithmic trading trend” as the only model.

# 11.4 Nonlinearity

Test whether propagation changes sharply beyond a threshold:

• binscatter with confidence intervals;
• local polynomial;
• splines;
• threshold regression;
• generalized random forest for heterogeneity;
• quantile treatment effects where appropriate;
• monotonicity checks.

The primary nonlinear result must also be represented with a transparent non-ML specification.

# 11.5 Inference

High-frequency observations are strongly dependent.

Consider:

• two-way clustering by source security and date;
• clustering by date and minute block;
• source-shock-level aggregation;
• block bootstrap by trading day;
• stationary bootstrap;
• randomization inference for event studies;
• Driscoll–Kraay only if its assumptions fit;
• multiple-hypothesis correction for families of outcomes.

Report why each inference method is appropriate.

# 12. Identification and common-information problem

The central threat is that many securities react to the same information rather than to each other.

Address this directly.

# 12.1 Scheduled macro announcements

Construct an event database for major U.S. announcements where reliable historical timestamps and surprise measures are available:

• FOMC decisions and statements;
• CPI;
• employment report;
• GDP;
• retail sales;
• PPI;
• ISM;
• other major scheduled releases.

Use these events to:

1. characterize common shocks;
2. estimate separate propagation patterns;
3. exclude macro windows from the idiosyncratic baseline;
4. compare common-news and firm-originating shock dynamics.

# 12.2 Firm-specific news

If reliable timestamped news or earnings-announcement data can be added:

• identify plausibly firm-specific shocks;
• distinguish pre-market, intraday, and after-hours announcements;
• use narrow event windows;
• avoid post-treatment controls;
• test whether economically linked firms respond more strongly.

Do not use scraped or low-quality event timestamps without validation.

# 12.3 Placebo timing

For each real shock:

• assign same-stock placebo times on comparable non-event days;
• preserve minute-of-day and volatility state;
• repeat the propagation analysis;
• compare real and placebo distributions.

# 12.4 Permuted networks

Randomly permute network links while preserving:

• degree distribution;
• sector composition;
• size bins;
• liquidity bins.

True networks should outperform matched placebo networks if network propagation is economically meaningful.

# 12.5 Negative controls

Potential negative controls:

• future network weights;
• distant unrelated securities;
• pre-shock outcomes;
• randomized source identity;
• non-overlapping time windows.

Future information may be used only as a falsification test, never in the baseline estimator.

# 13. Market-structure evolution

The paper may discuss algorithmic and electronic trading, but OHLCV data do not directly measure algorithmic trading intensity.

Therefore:

• do not claim a causal effect of algorithmic trading from a time trend alone;
• identify documented market-structure milestones from authoritative sources;
• treat breakpoint evidence cautiously;
• consider alternative explanations:
  • decimalization;
  • ETF growth;
  • passive investment;
  • market fragmentation;
  • faster information diffusion;
  • changes in listing composition;
  • changes in data coverage;
  • crisis composition;
  • regulation;
  • macro volatility;
  • changing sector weights.

Potential periodization must be pre-specified and justified. Results should also be shown using flexible year effects rather than only hand-picked eras.

# 14. Machine learning and foundation-model extension

A machine-learning component may be included, but it must not obscure identification.

# 14.1 Prediction task

Predict at shock time (t):

• future breadth;
• future intensity;
• time to cascade;
• sector-to-market transition;
• probability of a tail cascade.

# 14.2 Data splitting

Use strict temporal splits:

• training period;
• validation period;
• final untouched test period;
• optional rolling-origin evaluation.

Never randomly split minute observations across train and test.

# 14.3 Baselines

Compare with:

• unconditional historical mean;
• linear and logistic regressions;
• penalized regression;
• random forest;
• gradient boosting;
• HAR-style models;
• VAR and sparse VAR;
• Hawkes-inspired specifications where feasible;
• LSTM;
• temporal convolution;
• transformer or state-space model;
• graph neural network;
• model without network information;
• model without market-state information.

# 14.4 Evaluation

Report:

• out-of-sample (R^2);
• log loss;
• Brier score;
• AUROC;
• precision-recall AUC;
• calibration;
• tail recall;
• economic ranking performance;
• stability across years and regimes.

No trading strategy should be the main evidence. Any economic-value exercise must incorporate conservative transaction-cost assumptions and be clearly secondary.

# 14.5 Interpretability

Use:

• partial dependence;
• accumulated local effects;
• SHAP with dependence-aware interpretation;
• feature ablation;
• network ablation;
• temporal ablation;
• regime-specific performance;
• calibration plots.

Do not treat model attention weights as causal explanations.

# 15. Required robustness analyses

At minimum, run:

1. alternative return definitions;
2. alternative shock thresholds;
3. alternative factor residualizations;
4. alternative market and sector benchmarks;
5. alternative network definitions;
6. alternative network estimation windows;
7. alternative security universes;
8. exclusion of ETFs;
9. exclusion of ADRs;
10. exclusion of penny stocks;
11. exclusion of suspected split windows;
12. regular-hours only;
13. alternative minute aggregation: 1, 5, 10, and 15 minutes;
14. volume-weighted and equal-weighted outcomes;
15. opening and closing exclusions;
16. crisis versus non-crisis samples;
17. macro-announcement exclusions;
18. day-block bootstrap;
19. matched placebo shocks;
20. permuted networks;
21. pre-trend and pre-response tests;
22. source-stock fixed effects;
23. receiver-stock fixed effects;
24. date fixed effects;
25. sector-by-date fixed effects where computationally feasible;
26. balanced versus unbalanced samples;
27. winsorized versus non-winsorized outcomes;
28. median-based robust standardization;
29. alternative right-censoring treatment for propagation time;
30. multiple-testing adjustments.

Robustness must test the economic interpretation, not merely produce many similar regressions.

# 16. Falsification tests

The project must attempt to disprove its own central claim.

Required falsifications include:

• no systematic response before the source shock;
• weak propagation through randomized networks;
• weaker response among economically unrelated stocks;
• stronger response after genuine shocks than matched placebo times;
• no apparent secular acceleration caused solely by changing sample size;
• no apparent acceleration caused solely by timestamp precision or coverage changes;
• no result driven by a few crisis days;
• no result driven by the largest technology stocks;
• no result driven solely by ETFs;
• no result generated mechanically by market-factor construction;
• no result driven by corporate actions.

If a falsification fails, do not hide it. Reassess the claim.

# 17. Descriptive tables required

Generate the following main-paper candidates.

# Table I — Sample construction

Include by decade or period:

• raw rows;
• raw symbols;
• valid trading days;
• duplicate removals;
• invalid OHLC removals;
• suspected corporate-action exclusions;
• final stock-minute observations;
• final securities;
• median valid minutes per stock-day.

# Table II — Summary statistics

For core variables:

• mean;
• standard deviation;
• p1;
• p5;
• median;
• p95;
• p99;
• number of observations.

Report at the economically appropriate unit to avoid meaningless precision.

# Table III — Characteristics of source shocks

Compare:

• positive and negative shocks;
• low- and high-volatility states;
• early and late sample;
• cascade and non-cascade shocks.

# Table IV — Baseline propagation

Show horizon-specific coefficients for breadth, intensity, and persistence.

# Table V — Nonlinearity and asymmetry

Show shock-size bins, negative interaction, and market-state interactions.

# Table VI — Evolution over time

Show flexible period or year interactions and tests of equality.

# Table VII — Network mechanisms

Compare connected and unconnected receivers and transmitter centrality.

# Table VIII — Identification and placebo tests

Include macro exclusions, matched placebo times, and permuted networks.

Keep the main manuscript selective. Move secondary tables to the Internet Appendix.

# 18. Figures required

Create journal-quality figures in PDF and high-resolution PNG.

# Figure 1 — Data coverage

Panels may show:

• number of securities by year;
• number of observations by year;
• median bars per stock-day;
• missingness rate.

# Figure 2 — Intraday seasonality

Show minute-of-day patterns for:

• volatility;
• volume;
• range;
• shock incidence.

# Figure 3 — Anatomy of a representative cascade

A carefully selected event visualization with:

• source shock;
• sector response;
• market breadth;
• network diffusion;
• confidence or placebo envelope where possible.

Do not cherry-pick without a transparent selection rule.

# Figure 4 — Impulse responses

Local-projection responses over 1–120 minutes for:

• breadth;
• intensity;
• signed returns;
• volatility.

# Figure 5 — Nonlinear propagation

Plot propagation against source-shock magnitude with confidence bands.

# Figure 6 — Positive-negative asymmetry

Show comparable positive and negative shocks.

# Figure 7 — Evolution over time

Show annual or rolling estimates of propagation speed and breadth.

# Figure 8 — Network position and cascade risk

Show economically interpretable bins of lagged source centrality.

# Figure 9 — Market-state dependence

Compare calm and stressed states.

# Figure 10 — Falsification evidence

Real versus matched placebo and real versus permuted-network responses.

# 19. Figure style: Journal of Finance quality

The phrase “JF style” means restrained, legible, publication-quality academic graphics, not imitation of proprietary branding.

Use:

• vector PDF as the primary format;
• embedded fonts;
• white background;
• minimal chart ink;
• no 3D effects;
• no gradients;
• no decorative icons;
• no unnecessary borders;
• no chart titles inside the plotting region unless essential;
• concise axis labels;
• consistent font family and sizing;
• grayscale-safe line types and markers;
• colorblind-safe colors when color is needed;
• direct labels where clearer than legends;
• confidence bands with restrained opacity;
• panel labels (a), (b), etc.;
• identical scales across comparable panels;
• economically meaningful tick marks;
• no scientific notation unless unavoidable;
• no excessive decimal places.

Every figure must include a LaTeX note explaining:

• sample;
• variable definitions;
• estimation method;
• confidence intervals;
• clustering or bootstrap;
• normalization;
• exclusions.

Save source data for every figure as Parquet or CSV in:

outputs/figures/data/

A figure must be reproducible from its source-data file without rerunning the entire empirical pipeline.

# 20. LaTeX table style

Use booktabs. Avoid vertical rules. Avoid excessive horizontal rules.

Preferred packages:

\usepackage{booktabs}
\usepackage{threeparttable}
\usepackage{siunitx}
\usepackage{adjustbox}
\usepackage{longtable}
\usepackage{tabularx}
\usepackage{pdflscape}

Requirements:

• decimal alignment;
• consistent coefficient precision;
• standard errors in parentheses;
• significance stars only as a secondary visual convention;
• report exact or thresholded p-values where useful;
• clearly label fixed effects;
• clearly label clustering;
• include sample size;
• include within or adjusted (R^2) as appropriate;
• include dependent-variable mean when informative;
• include economic magnitude;
• use clear panel headings;
• use detailed table notes;
• avoid shrinking text below readability.

Do not use stars as the main argument. Emphasize coefficient magnitude, confidence intervals, and economic interpretation.

Generate each table in two forms:

1. standalone .tex;
2. machine-readable .csv or .parquet.

All table numbers must come directly from stored estimation objects.

# 21. Literature review standard

The literature review must be comprehensive, current, accurate, and organized around the paper’s contribution. It must not be a list of summaries.

# 21.1 Literature streams

Build a literature map covering at least:

1. market liquidity and liquidity risk;
2. commonality in liquidity;
3. market microstructure and price discovery;
4. high-frequency trading and algorithmic trading;
5. market fragility and flash events;
6. cross-asset price impact and cross-impact;
7. volatility spillovers and contagion networks;
8. lead-lag relationships;
9. intraday jumps;
10. Hawkes processes and self-excitation;
11. factor models for high-frequency returns;
12. electronic-market design and fragmentation;
13. ETF, passive, and portfolio-trading effects;
14. systemic risk and network centrality;
15. machine learning in market microstructure;
16. measurement using OHLCV versus trades and quotes.

# 21.2 Source quality hierarchy

Prioritize:

1. published articles in leading finance, economics, econometrics, and statistics journals;
2. authoritative working papers from NBER, CEPR, central banks, BIS, and established scholars;
3. official exchange, SEC, Federal Reserve, and regulatory documents;
4. recent working papers only when directly relevant and clearly labeled as unpublished.

Do not rely on blogs, generic websites, generated summaries, or low-quality outlets for core claims.

# 21.3 Citation verification

For every cited work:

• verify title;
• verify authors;
• verify year;
• verify journal or working-paper series;
• verify volume, issue, and pages where applicable;
• verify DOI where available;
• verify that the paper actually supports the sentence;
• save the source and citation metadata;
• never cite a work based only on another paper’s bibliography.

Maintain docs/LITERATURE_MAP.md with columns:

• citation key;
• full citation;
• literature stream;
• research question;
• data;
• frequency;
• identification;
• main result;
• relevance;
• difference from our paper;
• verified source;
• verification date.

# 21.4 Literature review argument

The review should establish:

1. liquidity and volatility exhibit common components;
2. shocks can transmit across assets through information and trading channels;
3. high-frequency market structure may improve normal-times efficiency while creating tail fragility;
4. prior work often studies limited instruments, shorter samples, quotes/order books, particular episodes, or lower-dimensional networks;
5. the present paper contributes a long historical, broad cross-section of minute-level U.S. equity data;
6. OHLCV breadth comes with measurement limitations;
7. the paper’s novelty lies in the joint analysis of speed, breadth, persistence, asymmetry, time evolution, and network conditioning.

Do not overclaim uniqueness until a documented literature search confirms it.

# 22. Paper outline

The paper must be written in English.

# 22.1 Abstract

Target approximately 120–180 words unless the current submission rules require otherwise.

The abstract must contain:

1. question;
2. data;
3. method;
4. central result;
5. mechanism;
6. implication.

Do not include vague claims such as “significant implications.” State the economic fact.

# 22.2 Introduction

The introduction should be approximately 4–6 manuscript pages and follow this logic:

# Paragraph 1 — Economic problem

Explain why intraday propagation matters for price discovery, liquidity, execution, and systemic stability.

# Paragraph 2 — Tension

Present the core tension: faster and more liquid markets may absorb ordinary information efficiently but transmit extreme shocks rapidly.

# Paragraph 3 — Research question

State exactly what the paper asks.

# Paragraph 4 — Data and empirical setting

Describe the broad minute-level panel, while flagging that validation determines the final sample.

# Paragraphs 5–7 — Main findings

Present only verified findings, including economic magnitudes and uncertainty.

# Paragraph 8 — Identification

Explain how the paper distinguishes propagation from common information.

# Paragraph 9 — Mechanisms

Summarize network, market-state, and asymmetry evidence.

# Paragraphs 10–12 — Contributions

State contributions relative to specific literature streams.

# Final paragraph — Road map

Keep it brief.

The introduction must not read like a technical report. It must build an economic argument.

# 22.3 Literature review

Integrate literature with hypotheses and contributions. Avoid a long disconnected catalog.

# 22.4 Data

Explain:

• provenance;
• raw structure;
• coverage;
• audit;
• filters;
• timestamp convention;
• corporate-action handling;
• security identity;
• survivorship concerns;
• descriptive statistics;
• limitations.

# 22.5 Measurement

Define:

• residual shocks;
• propagation outcomes;
• networks;
• market states;
• centrality;
• cascade thresholds.

# 22.6 Empirical design

Explain:

• local projections;
• event-study design;
• fixed effects;
• inference;
• timing;
• identification assumptions;
• threats.

# 22.7 Results

Organize by economic question, not by code execution order.

Suggested sequence:

1. basic propagation;
2. nonlinear threshold;
3. asymmetry;
4. time evolution;
5. network mechanism;
6. market-state dependence;
7. identification and placebo evidence.

# 22.8 Robustness

Keep the main text focused. Refer to a detailed Internet Appendix.

# 22.9 Conclusion

Do not merely summarize. State:

• what was learned;
• what remains unidentified;
• implications for market design and risk monitoring;
• limits of OHLCV data;
• future work with quote and order-book data.

# 23. Writing standards

The paper must read like a finance paper, not AI-generated prose.

Use:

• precise claims;
• active voice where natural;
• disciplined paragraphs;
• explicit economic magnitudes;
• clear transitions;
• restrained tone;
• correct terminology;
• consistent notation.

Avoid:

• hype;
• “revolutionary”;
• “groundbreaking” unless quoting;
• “unprecedented” without proof;
• “leveraging” as filler;
• “delve”;
• “multifaceted”;
• repeated road maps;
• excessive bullet points in the manuscript;
• paragraphs that merely describe tables;
• causal verbs without identification;
• statements that statistical significance proves importance.

Every empirical paragraph should answer:

1. What is estimated?
2. What is the sign and magnitude?
3. How uncertain is it?
4. What is the economic interpretation?
5. Which competing explanation remains?
6. Which robustness test addresses it?

# 24. JF submission preparation

At the time of final preparation, verify the current official Journal of Finance submission instructions.

The working format should conservatively use:

• 12-point font;
• at least 1.5 line spacing;
• readable margins;
• page numbers;
• anonymous manuscript version;
• separate title page if required;
• main manuscript no longer than the current JF limit;
• separate Internet Appendix;
• consistent references;
• tables and figures placed according to current instructions.

Do not assume old formatting rules remain current. Record the date and source of the final guideline check in:

docs/DECISION_LOG.md

Create:

outputs/release/
├── manuscript_anonymous.pdf
├── manuscript_named.pdf
├── internet_appendix.pdf
├── title_page.pdf
├── cover_letter.tex
├── cover_letter.pdf
├── source_archive.zip
├── replication_manifest.json
└── submission_checklist.md

The cover letter must be factual and restrained. Do not claim acceptance probability or editorial fit without evidence.

# 25. Main paper versus Internet Appendix

# Main paper

Reserve for:

• core question;
• central descriptive evidence;
• primary identification;
• main economic mechanism;
• essential robustness;
• clear contribution.

# Internet Appendix

Include:

• extended data audit;
• full sample-construction details;
• additional variable definitions;
• alternative filters;
• alternative networks;
• alternative thresholds;
• additional event studies;
• placebo distributions;
• machine-learning architecture;
• hyperparameters;
• computational details;
• additional tables and figures;
• proofs or derivations;
• replication details.

Every appendix item must be referenced from the main paper where relevant.

# 26. Reproducibility and provenance

# 26.1 Configuration

All parameters must live in versioned YAML files, not scattered through scripts.

# 26.2 Random seeds

Set and log seeds for:

• sampling;
• bootstraps;
• permutations;
• machine learning;
• graph estimation;
• simulations.

# 26.3 Versioning

Record:

• Git commit;
• Python version;
• package versions;
• OS;
• hardware;
• dataset revision;
• external-data revision;
• command line;
• start and end time.

# 26.4 Data lineage

Each processed file must record:

• parent inputs;
• transformation version;
• filters;
• row counts before and after;
• creation timestamp;
• code commit.

# 26.5 No manual numerical edits

LaTeX tables, abstract numbers, introduction magnitudes, and conclusion numbers must be populated from a central results registry such as:

outputs/estimates/results_registry.json

Implement macros such as:

\newcommand{\MainBreadthEffect}{...}

generated automatically from verified outputs.

# 27. Compute strategy for a cluster

The pipeline must be scalable but safe.

# 27.1 Preferred data tools

Consider:

• PyArrow;
• Polars lazy execution;
• DuckDB;
• Dask or Ray only where they add value;
• partitioned Parquet;
• predicate pushdown;
• memory-mapped reads;
• streaming aggregations.

Avoid loading the full dataset into RAM.

# 27.2 Partitioning

Partition processed data by a combination of:

• year;
• month;
• trading date;
• symbol bucket.

Select partitions based on dominant query patterns.

# 27.3 Distributed jobs

Every distributed task must:

• be idempotent;
• write to temporary paths;
• atomically rename on success;
• save checkpoints;
• avoid multiple nodes writing the same final file;
• emit structured logs;
• support retry;
• validate output before success.

# 27.4 Resource benchmarking

Before a full run:

1. benchmark one month;
2. benchmark one year;
3. estimate CPU hours;
4. estimate memory;
5. estimate temporary storage;
6. estimate final storage;
7. record in docs/COMPUTE_LOG.md.

Optimization must not change estimands or silently alter precision.

# 28. Testing and validation

# 28.1 Unit tests

Test:

• timestamp conversion;
• session assignment;
• return calculation;
• shock detection;
• lag discipline;
• no future-data leakage;
• network-window cutoffs;
• breadth denominator;
• session-boundary horizons;
• table formatting.

# 28.2 Synthetic-data tests

Generate small synthetic panels with known:

• common shocks;
• idiosyncratic shocks;
• directed propagation;
• no propagation;
• positive-negative asymmetry;
• missing bars;
• split-like jumps.

Confirm that the pipeline recovers the intended patterns and rejects false ones.

# 28.3 Release validation

The release script must fail if:

• a table references a missing result;
• a figure is missing source data;
• LaTeX does not compile;
• citations are unresolved;
• labels are duplicated;
• page count exceeds the current target;
• anonymous PDF contains author-identifying text;
• manuscript claims disagree with the results registry;
• data revision is not pinned;
• tests fail.

# 29. Decision log

Maintain docs/DECISION_LOG.md.

For every major choice, record:

• date;
• decision;
• alternatives considered;
• empirical reason;
• theoretical reason;
• effect on interpretation;
• whether pre-specified or data-driven;
• code/config reference.

Important decisions include:

• timestamp convention;
• regular-session definition;
• security filters;
• shock threshold;
• network window;
• factor model;
• clustering;
• periodization;
• figure selection;
• main versus appendix placement.

# 30. Minimum deliverables for the first phase

The first phase is complete only when all the following exist.

# Data acquisition

• repository metadata report;
• pinned dataset revision;
• storage estimate;
• resumable downloader;
• raw manifest;
• checksum verification;
• three-month pilot sample;
• full-download plan.

# Audit

• schema report;
• timestamp report;
• calendar report;
• OHLC validity report;
• duplicate report;
• missingness report;
• corporate-action diagnostic;
• security-universe diagnostic;
• survivorship assessment;
• limitations memo.

# Prototype analysis

• clean pilot panel;
• intraday seasonality figure;
• sample-coverage figure;
• preliminary shock definition;
• preliminary cascade measure;
• one transparent baseline regression;
• one placebo test;
• one LaTeX summary-statistics table;
• one LaTeX baseline-results table.

# Paper infrastructure

• compiling main.tex;
• compiling Internet Appendix;
• verified bibliography workflow;
• literature map;
• introduction outline;
• data-section draft based only on verified facts;
• automated figure and table inclusion.

# 31. Stop conditions

Stop and write a diagnostic report rather than proceeding if:

• timestamps cannot be interpreted reliably;
• OHLC values are extensively inconsistent;
• split adjustments cannot be handled sufficiently for return analysis;
• the universe is severely survivorship-biased and cannot be characterized;
• historical coverage is too sparse for the claimed design;
• symbol identity errors dominate long-run comparisons;
• data licensing prevents the intended use;
• results depend on undocumented transformations;
• common-news contamination cannot be separated even approximately;
• inference is computationally impossible at the intended unit without changing the design.

A rigorous negative assessment is preferable to a polished but invalid paper.

# 32. Commands and workflow

Create a Makefile with targets similar to:

probe
download-pilot
audit-pilot
download-full
verify-data
build-panel
build-features
detect-shocks
estimate-networks
estimate-baseline
estimate-events
run-placebos
run-robustness
figures
tables
paper
appendix
validate
release

A complete reproducible run should ultimately be possible through:

make release

Do not run make release until the pilot audit and full-data checks pass.

# 33. Immediate actions

Begin now with the following actions, in order:

1. Create the project directory structure.
2. Initialize environment and dependency files.
3. Inspect the Hugging Face dataset repository without downloading all files.
4. Pin the exact dataset revision.
5. Create a repository-level file inventory.
6. Estimate total download and processed-storage needs.
7. Download three strategically selected monthly files:
   • one early month;
   • one middle-sample month;
   • one recent month.
8. Audit schema and timestamps.
9. Produce docs/DATA_AUDIT.md.
10. Produce docs/LIMITATIONS.md.
11. Produce pilot coverage and intraday-seasonality figures.
12. Produce one summary-statistics LaTeX table.
13. Build docs/LITERATURE_MAP.md and begin a verified literature search.
14. Create a compiling LaTeX manuscript skeleton.
15. Draft only the portions of the Data section supported by the audit.
16. Report blockers and proposed solutions before launching the full download.

At the end of each major stage, produce:

STATUS.md

with:

• completed work;
• generated files;
• key findings;
• quality-control results;
• unresolved issues;
• next commands;
• decisions requiring attention.

Do not ask for confirmation for routine implementation choices. Make the most defensible choice, record it, and continue. Escalate only issues that materially alter the research question, data legality, identification, or interpretation.

# 34. Final quality criterion

The paper is not “ready for JF” merely because it compiles or contains many analyses.

It is ready for serious submission consideration only if:

• the data are credible and fully audited;
• the paper documents a new and economically important fact;
• propagation is separated as far as possible from common information;
• magnitudes are economically meaningful;
• results survive serious falsification tests;
• the mechanism is coherent;
• the literature positioning is accurate;
• the writing is disciplined;
• the figures and tables are publication quality;
• all claims are reproducible;
• limitations are explicit;
• the main paper is focused;
• the Internet Appendix is complete;
• no result has been fabricated, selectively hidden, or overstated.

The standard is not to make the paper appear publishable. The standard is to determine honestly whether the evidence supports a contribution worthy of a top finance journal and, if it does, to present that contribution with maximum clarity and rigor.