# F6-conf-01 — Does the day of the week carry predictive content for daily changes in the 10-year Treasury yield?

# Scientific question

Financial folklore attributes systematic "Monday" or "Friday" patterns to daily asset-price changes. Using twenty years of daily data (2000–2019) on the 10-year US Treasury constant-maturity yield, determine whether the day of the week has any predictive content for the one-day change in the yield. The estimands are: (i) the differences in the conditional mean of the one-day change Δy_t (basis points) across the five weekdays, tested jointly; (ii) the "Monday contrast", the mean change on Mondays minus the mean change on the other four weekdays, with a 95% interval; (iii) the out-of-sample predictive value of weekday-specific means relative to a zero-change (random-walk) baseline. This is a complete, bounded mini-project: question → data audit → baseline → justified method → results → uncertainty → failure discussion → one figure and one table → short report. Report what the data show, whatever that is.

# Inputs

data/DGS10.csv — observed data, FRED series DGS10 (Board of Governors, H.15), daily, percent; raw FRED CSV restricted to 2000-01-01 … 2019-12-31 (provenance, URL, retrieval date, terms and SHA-256 in data/README.md). Columns: observation_date (YYYY-MM-DD, every weekday is listed) and DGS10 (percent; the field is empty on days when no yield was published, i.e. US market holidays).
data/README.md — provenance.

# Information-availability rules

First drop the rows with an empty DGS10 field; then define the one-day change as Δy_t = 100·(y_t − y_{t−1}) in basis points between consecutive available observations. The change is dated t and attributed to the weekday of t (Monday … Friday). The first available observation has no change.
The estimation period is the set of changes dated on or before 2009-12-31; the evaluation period is the set of changes dated on or after 2010-01-01. Any weekday-specific quantity used to forecast an evaluation-period change must be estimated from the estimation period only.
The joint test is the classical one-way (equal-variance) analysis-of-variance F-test of equal weekday means over all changes (both periods together). The Monday contrast and its interval may use any valid two-sample method (Welch, pooled, or a regression on a Monday indicator with heteroskedasticity-robust SE); state the choice.
Use only the file listed above.

# Required outputs

out/results.json with the keys:

key	type	unit	meaning
`n_missing_rows`	integer	rows	rows of `DGS10.csv` with an empty `DGS10` field
`n_train`, `n_test`	integer	changes	number of daily changes in the estimation and evaluation periods
`anova_f_stat`	number	—	one-way ANOVA F statistic for equal weekday means (all changes)
`anova_p_value`	number	—	its p-value (F(4, n−5))
`effect_estimate`	number	basis points	Monday contrast: mean Monday change minus mean change on the other weekdays (all changes)
`effect_ci_low`, `effect_ci_high`	number	basis points	95% confidence interval for the Monday contrast
`baseline_metric`	number	basis points	RMSE of the zero-change forecast over the evaluation period
`model_metric`	number	basis points	RMSE over the evaluation period of the forecast that predicts each change by the estimation-period mean change of its weekday
`conclusion`	string	—	one of the codes below (decided by the ANOVA at the 5% level; if it rejects, the sign is given by the Monday-contrast interval)
`task_id`	string	copied from this file
`feasibility`	string	`complete` / `partial` / `infeasible`
`feasibility_reason`	string or null	why, if not complete
`data_issues`	array of {"issue","handling"}	every data problem detected and how it was handled (empty list allowed)
`n_input_rows`	object {file: integer}	rows read per input file (file name as key, header row excluded)
`n_analysed`	integer or null	observations actually used in the main estimate
`random_seed`	integer or null	seed used, if any

(n_analysed = number of daily changes used in the ANOVA.)

The conclusion code must be one of: positive_effect (the 95% interval for the effect estimand lies above zero), negative_effect (lies below zero), no_detectable_effect (the interval / test does not reject zero at the 5% level), premise_invalid (the data provided do not allow the stated estimand to be computed — in that case set feasibility to infeasible, explain in feasibility_reason, and set every inestimable key to null; never substitute an invented or proxy estimate).

out/figure1.png — mean change by weekday with 95% confidence bars (all changes), produced by out/analysis.py with matplotlib.
out/table1.csv — one row per weekday with columns weekday, n, mean_bp, se_bp (header + five data rows), produced by out/analysis.py.
out/report.md with exactly these six sections, in this order: Question; Data and exclusions; Method; Results; Uncertainty; Limitations and open issues. The last section must contain a genuine failure discussion: what would invalidate the result, what was not checked, and what the main threats are.
out/analysis.py — replication entry point: ~/wp29/venv/bin/python out/analysis.py, run from the workspace root, must regenerate out/results.json, out/figure1.png and out/table1.csv from data/ only, deterministically (fix any seed; use the matplotlib Agg backend).
out/claims.json — list of the central claims of the report: [{"id": "C1", "text": "...", "results_keys": ["..."], "status": "supported"|"unsupported"|"not_evaluated", "caveat": "..."}]. Every claim must reference existing keys of out/results.json; a claim must only be marked supported if the reported numbers actually support it.

# Constraints

No network access. Python: ~/wp29/venv/bin/python (numpy, pandas, scipy, statsmodels, matplotlib available). Do not modify data/.
Write all deliverables under out/. This task is designed to be completed in well under 20 minutes of work; prefer a short, correct chain over an elaborate one.

spb/wp29_uqo