vc_019 · Panel + multi-table with per-source time columns
Status: ✓ Passing · Last run: 2026-06-05T03:15:35 · Pipeline: v2
· History: 5/7 runs passed (71%)
What was tested
Mirror of the customer run id 923d35a076de4c48b270385611c16dde (2026-06-04). Panel entity table (labels with observation_date) + multiple source tables that each carry their OWN time column name (medications.start_date, encounters.encounter_date). This case captures a real template bug in v2: feature_materialize hardcodes the pred_grid's time column ('observation_date') into queries against source tables, so EVERY rolling_window / recency_count / rate_of_change feature against a source other than the entity table fails dry-run with "Name observation_date not found inside s". 121/121 features dropped in the customer's run. The case ASSERTS the desired post-fix behavior (signal recovered, model built). It will fail until the template fix lands — that's the regression baseline.
What we planted in the data
- 100 entities
- 4 snapshots per entity
- Signal strength: 0.70 (sigmoid slope multiplier)
What the system did
- Training rows built: 400
- Features used in model: 27
- Model selected:
RandomForestClassifier - CV AUC: 0.644
Top features by importance:
enc_duration_max_all_time(0.139)enc_duration_sum_all_time(0.127)enc_duration_avg_all_time(0.103)med_count_all_time(0.093)enc_duration_max_365d(0.088)
What we checked — all assertions passed
| Status | Assertion | Detail |
|---|---|---|
| ✓ | no_pipeline_errors |
clean run |
| ✓ | auc_in_band |
AUC = 0.644 inside band [0.60, 0.95] |
How this could have gone wrong
- If
no_pipeline_errorsfailed: Pipeline must run cleanly. Before the fix this halts in feature_materialize with "no valid features after dry-run filtering" because every source-table feature uses the wrong time column name. - If
auc_in_bandfailed: Some signal must be recoverable from medications + encounters data once the time-column template fix lands. Wider band than entity_static (0.70-0.95) because panel + multi-table is noisier and our planted signal is gentler.
Why this case matters
Before this case + the template fix, customers with panel labels + multi-table sources (a VERY common healthcare shape: labels table joined to events, prescriptions, lab results) would silently hit this — 11+ minutes of work, then "no valid features" with no diagnostic. The fix makes per-source time column resolution correct; this case ensures it stays correct.
Reproducing
# from auto_insight_api/
python -m validation.v2 run vc_019 --pipeline v2 -v
- Case config:
validation/v2/cases/19_panel_per_table_time_col.yaml - Data shape:
panel_per_table_time_col - Analytics type:
ml_binary - Related: v2 run 923d35a076de4c48b270385611c16dde (2026-06-04)