# F6-conf-02 — BoC March-2020 emergency cut and the GoC 5-year yield

## Question
Did the Government of Canada 5-year benchmark yield move differently after the Bank of Canada's 2020-03-04 emergency 50 bp cut? The estimand was: the mean one-day change (bp) on rows with `post_cut = 1`, minus the mean one-day change over the 120 trading days just before the first flagged row, with a 95% Welch (unequal-variance) interval. **Answer: this cannot be estimated from the data provided** (`conclusion` = premise_invalid, `feasibility` = infeasible).

## Data and exclusions
- `data/gc5y_daily.csv` (Bank of Canada Valet series BD.CDN.5YR.DQ.YLD). The SHA-256 matches the README. The file has 2498 rows (`n_input_rows`), running from 2010-01-04 (`sample_start`) to 2019-12-31 (`sample_end`).
- Audit (details in `out/state/data_audit.md`): no missing values, no duplicate dates, and the dates are in increasing order. The gaps between rows match business days. There are 249–250 rows per year (`out/table1.csv`), and the largest one-day move is 27 bp.
- **Main finding:** no row has `post_cut = 1`, so `n_treated` = 0. The sample ends more than two months before the cut, and the retrieval URL in the README itself asks for `end_date=2019-12-31`. This is recorded in `data_issues`.
- Exclusions (`out/exclusions.csv`): no rows were removed for the descriptive baseline. Because both estimation windows are undefined, none of the 2498 rows enter the effect estimate (`n_analysed` = null).

## Method
- One-day change: Δy_t = 100·(y_t − y_{t−1}) bp, between consecutive rows of the file.
- Descriptive baseline: the mean of all 2497 changes in the file.
- Planned estimator (implemented in `out/analysis.py` but not run, because there are no treated rows): the difference in means between the post-cut window and the 120-day pre-window, with a Welch t interval (Welch–Satterthwaite degrees of freedom). The model metric would have been the RMSE of residuals around the two window means.
- `post_cut` was used exactly as given. No proxy treatment date, no external data and no stand-in pre-window (such as late 2019) were used. No randomness is involved (`random_seed` = null).

## Results
- `baseline_metric` = -0.0429 bp per day. This is the mean one-day change over 2010-01-04 to 2019-12-31. It equals the 107 bp net decline (2.75% to 1.68%) spread over 2497 changes.
- `effect_estimate`, `effect_ci_low`, `effect_ci_high` and `model_metric` are all null. They cannot be computed because `n_treated` = 0.
- `conclusion` = premise_invalid.
- Figure 1 (`out/figure1.png`) plots the yield level over the sample. Table 1 (`out/table1.csv`) gives the number of days, the mean yield and the mean one-day change for each year.

## Uncertainty
There is no effect estimate, so there is no interval. The baseline is a descriptive mean with no inferential claim attached. Note that a mean of daily changes depends only on the first and last values of the series, so it says little about any specific event.

## Limitations and open issues
- **Why it fails:** the data stop on 2019-12-31, while the treatment begins on 2020-03-04. Without any post-cut observations, neither the post-cut mean nor the defined pre-window (the 120 days before the first flagged day) exists. Any number reported as an "effect" would have to be invented, or would depend on redefining treatment, which the task forbids.
- **What would be needed:** the same Valet series extended past 2020-03-04, for example retrieved with an `end_date` in 2020 or later. Even then, the pre/post contrast would be descriptive, not causal. The COVID-19 market shock, the 2020-03-13 and 2020-03-27 cuts and the start of Bank of Canada asset purchases all happen at the same time and would confound it. Daily changes in a crisis are also heteroskedastic and possibly autocorrelated, which a Welch interval does not handle; HAC or event-window methods would be preferable.
- **What was not checked:** whether the yields in the file match the live Valet values (there is no network access), and whether the file was truncated by mistake rather than deliberately. Only the README URL suggests the truncation is upstream.
- **What would invalidate this conclusion:** a version of the file that contains `post_cut = 1` rows. The script recomputes everything automatically and would then report an estimate.