Menu
CPI/GDP/retail sales date awareness and VIX regime scaling for calendar features
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | macro-calendar-modulation |
| description | CPI/GDP/retail sales date awareness and VIX regime scaling for calendar features |
| author | Claude Code |
| date | "2026-02-24T00:00:00.000Z" |
| version | 4.4.0 |
| Item | Details |
|---|---|
| Date | 2026-02-24 |
| Goal | Add CPI/GDP/retail sales awareness and VIX regime scaling to calendar features without changing obs_dim |
| Environment | Python 3.11+, OpenBB FRED provider |
| Status | Success |
Calendar features only knew FOMC + employment first Friday. No VIX level, no CPI/GDP dates. Earnings cause 5-10% average moves; CPI/GDP releases move markets significantly.
Design constraint: NUM_FEATURES must stay at 7 (no obs_dim change). Solution: modulate existing hour_weight value.
CPI_RELEASE_DATES = [datetime(2024,1,11), datetime(2024,2,13), ...] # 2024-2026
GDP_RELEASE_DATES = [datetime(2024,1,25), datetime(2024,2,28), ...] # 2024-2026
RETAIL_SALES_DATES = [datetime(2024,1,17), datetime(2024,2,15), ...] # 2024-2026
ALL_MACRO_EVENT_DATES = sorted(set(CPI + GDP + RETAIL))
CalendarFeatureCalculator(enable_macro_modulation=True)
# In _hour_weight():
base_weight = ... # existing market hours logic (0.1 - 1.0)
if enable_macro_modulation:
# +20% on CPI/GDP/retail sales days
if ts_date in self._macro_event_dates:
base_weight *= 1.20
# VIX regime scale (cached 4h via OpenBB FRED)
vix_scale = _get_vix_regime_scale() # 0.9x to 1.3x
base_weight *= vix_scale
| VIX Level | Scale | Rationale |
|---|---|---|
| < 15 | 1.0x | Normal volatility |
| 15-25 | 0.95x | Slightly reduce weight (elevated but manageable) |
| 25-35 | 1.1x | Higher volatility = more signal in price moves |
| > 35 | 1.3x | Panic = high weight (big moves, high importance) |
_macro_data_cache dict (not instance-level)_fetch_vix_level() using OpenBB FRED_macro_event_dates pre-built as set in __init__ for O(1) lookup| Attempt | Why it Failed | Lesson Learned |
|---|---|---|
| Adding new feature (earnings_proximity) | Changes obs_dim from 5900 to 6000, breaks all existing models | Modulate existing features instead |
| Instance-level VIX cache | Multiple CalendarFeatureCalculator instances waste API calls | Module-level cache shared across instances |
MACRO_EVENT_BOOST = 1.20 # +20% on macro release days
VIX_REGIME_SCALES = {
'normal': 1.0, # VIX < 15
'elevated': 0.95, # VIX 15-25
'high': 1.1, # VIX 25-35
'panic': 1.3, # VIX > 35
}
VIX_CACHE_TTL = 14400 # 4 hours
| File | Change |
|---|---|
alpaca_trading/features/calendar_features.py | Added date lists, _fetch_vix_level(), _is_macro_event_day(), _get_vix_regime_scale(), modulated _hour_weight() |
tests/test_openbb_integration.py | 6 tests for macro modulation |
Normalize long-form CODEX cycle folders to short form before notebooks run. Trigger: cyc001_reg001_*, hard-coded cyc paths breaking, staged CODEX raw data failing in Notebooks 1/2.
v5.6.0 joint multi-TF model: single model per symbol with broadcast 1Hour context replaces dual 15Min/1Hour models. Trigger: (1) replacing weighted-voting model aggregation, (2) adding broadcast features to vectorized env, (3) limited training data + worried about overfitting from doubling obs_dim, (4) backtest builder mismatch with newer feature counts.
DEPRECATED in v5.6.0 — see joint-multi-tf-v560 skill. Documents the v5.2.0 dual-model approach (train separate 15Min/1Hour models, combine via weighted voting). Still relevant for: (1) loading legacy v5.5.0 dual models, (2) understanding the historical aggregation layer, (3) resampling pattern via origin='start'.
Surface a shipped-but-undocumented CLI feature in user-facing docs. Trigger: user reports a known feature missing from README/readthedocs even though the CLI command exists.
KINTSUGI Snakefile + CLI changes that route SLURM jobs around accounts saturated by OTHER users on the same QOS pool. Trigger: QOSGrpMemLimit, jobs stuck pending despite available GPU slots in config, noisy neighbor on shared QOS, multi-user investment pool exhaustion, _build_cycle_assignment static-vs-live.
KINTSUGI SLURM batch processing: Maximize throughput using multi-account resource calculation with GPU+CPU pools per account. Trigger: SLURM job submission, batch processing, resource maximization, GPU+CPU concurrent, headless processing, resource pool.