dc_006 · Deployment: late-arriving rows (idempotency)
Status: ✓ Passing · Last run: 2026-06-09T06:21:26 · Pipeline: deployment
· History: 1/1 runs passed (100%)
What was tested
Some entity_ids that appear in this fire's new_data ALSO appear in the prior_predictions table — they were marked as late upstream and re-emitted. Deployment runs and writes its 100 new predictions; the prior_predictions table should be byte-identical afterward (deployment does NOT mutate history). The semantics here are "deployment doesn't dedupe — that's an upstream concern" but it MUST be idempotent about the prior table.
What we planted in the data
- 1,000 entities
- Signal strength: 0.50 (sigmoid slope multiplier)
n_new_rows=100n_prior=500
What the system did
- Training rows built: 1,000
- Features used in model: 3
- Model selected:
DeploymentScoringRunner
What we checked — all assertions passed
| Status | Assertion | Detail |
|---|---|---|
| ✓ | deployment_completed_cleanly |
clean run |
| ✓ | scored_row_count_eq |
scored 100 rows, expected 100 |
| ✓ | prior_predictions_unchanged |
prior predictions row count unchanged (500) |
How this could have gone wrong
(no assertion descriptions provided)
Why this case matters
Idempotency bugs are the worst class of deployment failure: they silently corrupt history. Catching them in test prevents weeks of "wait, did the model predict this last Tuesday or did we rewrite history?" investigations.
Reproducing
# from auto_insight_api/
python -m validation.v2 run dc_006 --pipeline deployment -v
- Case config:
validation/v2/cases/dc_006_late_rows.yaml - Data shape:
deployment_late_rows - Analytics type:
deployment