You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: validator/PLANS.md
+8-5Lines changed: 8 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -22,6 +22,7 @@
22
22
* Most recent date seen in source data is not older than most recent date seen in reference data
23
23
* Similar number of obs per day as recent API data (static threshold)
24
24
* Similar average value as API data (static threshold)
25
+
* Outliers in cases and deaths signals using [this method](https://github.com/cmu-delphi/covidcast-forecast/tree/dev/corrections/data_corrections)
25
26
* Source data for specified date range is empty
26
27
* API data for specified date range is empty
27
28
@@ -44,6 +45,9 @@
44
45
45
46
### Larger issues
46
47
48
+
* Set up validator to use Sir-complains-a-lot alerting functionality on a signal-by-signal basis (should send alert output as a slack message and "@" a set person), as a stop-gap before the logging server is ready
49
+
* This is [how Sir-CAL works](https://github.com/benjaminysmith/covidcast-indicators/blob/main/sir_complainsalot/delphi_sir_complainsalot/run.py)
* Expand framework to support nchs_mortality, which is provided on a weekly basis and has some differences from the daily data. E.g. filenames use a different format ("weekly_YYYYWW_geotype_signalname.csv")
48
52
* Make backtesting framework so new checks can be run individually on historical indicator data to tune false positives, output verbosity, understand frequency of error raising, etc. Should pull data from API the first time and save locally in `cache` dir.
49
53
* Add DETAILS.md doc with detailed descriptions of what each check does and how. Will be especially important for statistical/anomaly detection checks.
@@ -52,20 +56,18 @@
52
56
* Easier suppression of many errors at once
53
57
* Maybe store errors as dict of dicts. Keys could be check strings (e.g. "check_bad_se"), then next layer geo type, etc
54
58
* Nicer formatting for error “report”.
59
+
* Potentially set `__print__()` method in ValidationError class
55
60
* E.g. if a single type of error is raised for many different datasets, summarize all error messages into a single message? But it still has to be clear how to suppress each individually
56
61
* Check for erratic data sources that wrongly report all zeroes
57
62
* E.g. the error with the Wisconsin data for the 10/26 forecasts
58
63
* Wary of a purely static check for this
59
64
* Are there any geo regions where this might cause false positives? E.g. small counties or MSAs, certain signals (deaths, since it's << cases)
60
65
* This test is partially captured by checking avgs in source vs reference data, unless erroneous zeroes continue for more than a week
61
-
* Also partially captured by outlier checking. If zeroes aren't outliers, then it's hard to say that they're erroneous at all.
62
-
* Outlier detection (in progress)
63
-
* Current approach is tuned to daily cases and daily deaths; use just on those signals?
64
-
* prophet (package) detection is flexible, but needs 2-3 months historical data to fit on. May make sense to use if other statistical checks also need that much data.
66
+
* Also partially captured by outlier checking, depending on `size_cut` setting. If zeroes aren't outliers, then it's hard to say that they're erroneous at all.
65
67
* Use known erroneous/anomalous days of source data to tune static thresholds and test behavior
66
68
* If can't get data from API, do we want to use substitute data for the comparative checks instead?
67
-
* E.g. most recent successful API pull -- might end up being a couple weeks older
68
69
* Currently, any API fetch problems just doesn't do comparative checks at all.
70
+
* E.g. most recent successful API pull -- might end up being a couple weeks older
69
71
* Improve performance and reduce runtime (no particular goal, just avoid being painfully slow!)
70
72
* Profiling (iterate)
71
73
* Save intermediate files?
@@ -87,3 +89,4 @@
87
89
* Raise errors when one p-value (per geo region, e.g.) is significant OR when a bunch of p-values for that same type of test (different geo regions, e.g.) are "close" to significant
88
90
* Correct p-values for multiple testing
89
91
* Bonferroni would be easy but is sensitive to choice of "family" of tests; Benjamimi-Hochberg is a bit more involved but is less sensitive to choice of "family"; [comparison of the two](https://delphi-org.slack.com/archives/D01A9KNTPKL/p1603294915000500)
92
+
* Use prophet package? Would require 2-3 months of API data.
0 commit comments