dce_004 · Deployment E2E: same recipe twice → identical section_outputs
Status: ✓ Passing · Last run: 2026-06-09T06:39:46 · Pipeline: deployment_e2e
· History: 1/1 runs passed (100%)
What was tested
Run execute_live_refresh against the same DeploymentSpec twice in a row, against the same source table and the same GCS model blob. Compare section_outputs[i].content_repr byte-for-byte. This is the "output-determinism check" the runtime's docstring mentions — without it, every refresh could silently produce a different HTML even though nothing changed.
What we planted in the data
- 500 entities
- Signal strength: 0.50 (sigmoid slope multiplier)
n_new_rows=50
What the system did
- Training rows built: 500
- Features used in model: 3
- Model selected:
DeploymentE2ERunner
What we checked — all assertions passed
| Status | Assertion | Detail |
|---|---|---|
| ✓ | e2e_section_completed_cleanly |
clean run (no pipeline or section errors) |
| ✓ | e2e_scored_row_count_eq |
scored 50 rows, expected 50 |
| ✓ | e2e_deterministic |
two refreshes produced identical section_outputs |
How this could have gone wrong
(no assertion descriptions provided)
Why this case matters
If two consecutive refreshes against the same data produce different section outputs, something nondeterministic snuck into the section code (random state, time-dependent feature, ordering bug). Users see this as "the dashboard keeps changing for no reason" and lose trust. The determinism check catches it.
Reproducing
# from auto_insight_api/
python -m validation.v2 run dce_004 --pipeline deployment_e2e -v
- Case config:
validation/v2/cases/dce_004_e2e_determinism.yaml - Data shape:
deployment_e2e_determinism - Analytics type:
deployment_e2e