# Experiment 1 scale=5 — saturated rolling deploy at production maximum_capacity

**Purpose:** measure whether DEPLOYMENT_BLOCKED behavior changes when the
service has 5 tasks (`maximum_capacity` for prod `spatial_audio_validation`)
vs the 3 tasks tested in the original run.

**Run date/time (UTC):** 2026-04-17T17:31:54Z

**Setup:**
- desired_count = 5
- EXPIRES_MINUTES = 5 (current task def)
- WORK_DURATION_MS = 200, IDLE_MS = 50 (saturated)
- Trigger via `force_deploy.sh`

**Results:**
- Time from trigger to first `enable_failed`: **89.5 s**
- Time from trigger to last `enable_failed`: **89.8 s**
- Spread of 5 `enable_failed` events: **233 ms**
- Convergence: **181 s**
- All 5 old tasks exited via `DEPLOYMENT_BLOCKED` + `worker_exit` (clean)
- SIGTERM events: **0**

**Per-task offset from trigger:**

| # | Offset from first | Absolute offset from trigger |
|---|---|---|
| 1 | 0 ms | 89.516 s |
| 2 | 13.6 ms | 89.530 s |
| 3 | 69.7 ms | 89.586 s |
| 4 | 168.3 ms | 89.685 s |
| 5 | 232.8 ms | 89.749 s |

## Finding: latency is scheduler-tick driven, not task-count driven

The ~90 s latency holds at scale=5. Comparing to the other runs:

| Run | n tasks | Time to first enable_failed | Spread | Convergence |
|---|---|---|---|---|
| Original exp 1 | 3 | 84 s | 260 ms | 167 s |
| Repeat A | 3 | 94 s | 160 ms | 190 s |
| Repeat B | 3 | 92 s | 217 ms | 175 s |
| **Scale=5** | **5** | **89.5 s** | **233 ms** | **181 s** |

Mean across all 4 runs: 90 s to DEPLOYMENT_BLOCKED (~6% CV). Spread
consistently <300 ms regardless of task count. Convergence ~177 s mean.

**Implication:** production with `maximum_capacity = 5` should see the same
~90 s gate + ~180 s total convergence as at lower scales. The scheduler's
`protected_count > desired_count` check fires at its own tick rate
independent of how many tasks are involved.

## Raw data

- `worker-logs.jsonl` — via `filter-log-events`
- `service-state.jsonl`, `service-events.jsonl`, `task-state.jsonl`
- `trigger.txt`