vc_014 · Entity table with duplicate keys (fail-fast)

Status: ✓ Passing · Last run: 2026-06-04T23:42:11 · Pipeline: v2 · History: 3/3 runs passed (100%)

What was tested

Reproduces the failure mode of run_id 5331dea4c43c447dac1dcea45b078412: the entity table itself has duplicate entity-id rows (1000 total rows but only ~940 distinct entity_id values), causing the v2 pipeline's fans_out detector to flag the entity table as event-stream — at which point the feature_plan LLM has no good way to encode features and loops through 3 invalid plans before giving up with an unhelpful RuntimeError 14 minutes in. The fix in pipeline._validate_entity_table_grain catches this at intent_classification (~30s in) and halts with a customer-actionable error: "Your

has N rows but only M distinct values..." This case asserts that fix stays in place. This case pins ONE behavior: halt with a clear message. An earlier draft of this description also listed "auto-dedupe and proceed" as acceptable, but the assertions below never permitted it (they require an error and no model), so the prose and the assertions disagreed. Resolved in favour of the assertions, because dedupe is the wrong default HERE: these duplicates are dirt from an append-only loader, nothing declares them meaningful, and silently dropping 60 rows of a customer's data is worse than saying what is wrong. Note the boundary with vc_021. There, the source's DECLARED key (data_table_meta.pk_strategy) is strictly finer than the modeling grain, so its extra rows are claims to aggregate and the pipeline must proceed. Here there is no declared key to justify the extra rows, so it must halt. The discriminator is the declared key, not the row counts — the two cases look identical from a COUNT(DISTINCT) alone, which is why both exist. Failing behavior the case prevents: - 14-minute thrash through 3 feature_plan iterations - Pipeline producing a model trained on inflated rows

What we planted in the data

1,000 entities
Planted driver: usage_score
3 noise feature(s) (no relationship to outcome)
Target positive rate ≈ 30%
Signal strength: 0.70 (sigmoid slope multiplier)
n_duplicates = 60

What the system did

(no metrics available)

What we checked — all assertions passed

Status	Assertion	Detail
✓	`pipeline_halted_with`	halted with text containing 'entity': 'RuntimeError: Your `src_vc_014` table has 1060 rows but only 1000 distinct `entity_id` values (60 …
✓	`pipeline_halted_with`	halted with text containing 'entity': 'RuntimeError: Your `src_vc_014` table has 1060 rows but only 1000 distinct `entity_id` values (60 …
✓	`no_model_produced`	no model produced — pipeline correctly refused to train

How this could have gone wrong

If pipeline_halted_with failed: Pipeline must halt with a message containing "duplicate" — the key signal that the entity-grain validator caught the dirty data. Without this exact string the customer wouldn't know what to fix.
If pipeline_halted_with failed: The halt message must also reference "entity" — pinning the diagnosis at the entity table specifically, not some generic "validation failed" message.
If no_model_produced failed: No model should be trained on dirty entity data. If a model slips out despite the halt, the message would be a polite lie and the model would be on inflated rows (60 of 1000 entities double-counted in training).

Why this case matters

Patient-shaped datasets (each entity has demographics + some history) routinely arrive with dup entity rows from append-only loaders or re-imports. Before the fix this caused a 14-minute thrash with no customer-actionable error. This case is the floor that prevents the same UX regression — any future refactor of intent_classification that drops the dup-key check fails this case loudly.

Reproducing

# from auto_insight_api/
python -m validation.v2 run vc_014 --pipeline v2 -v

Case config: validation/v2/cases/14_entity_with_duplicates.yaml
Data shape: entity_with_duplicates
Analytics type: ml_binary
Related: v2 run 5331dea4c43c447dac1dcea45b078412 (2026-06-01)

← back to validation report