MemberJunction / MemberJunction/MJ
Predictive Studio: non-numeric feature columns silently become dead constant-0 features (G7)
- Dominant language
- TSQL
- Stars
- 29
- Forks
- 6
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 323
Description
From live testing (see plans/predictive-studio-guardrails.md, G7 — found during PR #3089 field work).
Adding a datetime column (`CheckInTime`) to a pipeline's select step produces a silently dead feature: `normalizeValue` emits `Date → toISOString()` but every select column is declared `Kind: 'numeric'` in the feature schema, so the sidecar coerces the ISO strings to nothing and the whole column collapses to a constant — importance exactly 0, no warning at Validate time, no error at train time.
**Proposed fix:** at Validate (and/or assembly) time, check each select column's `EntityFieldInfo.TSType` — datetimes should be rejected with an actionable message ("datetime columns need a derived numeric feature, e.g. days-since") or auto-converted to epoch days; non-value-list strings same treatment. A post-train zero-variance warning ("feature X was constant across all rows") would also surface this class of problem immediately.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Contributor guide
Research direction
Read plans/predictive-studio-guardrails.md at G7, then trace Validate or assembly handling for select columns and EntityFieldInfo.TSType. Reproduce the issue with the datetime column CheckInTime and inspect how normalizeValue output reaches the feature schema and sidecar. Done should prevent silently constant features through actionable validation or conversion, with the proposed zero-variance warning addressed if included in scope.
Written by the indexing model from the issue text.
Assessment
- Domain
- machine-learning
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100