# E72-A/B — Baseline, the E70 worker-hour discrepancy, and adaptive scheduling

## Inherited

The branch started from `16d8d1673` (E71 replication) and inherited a concurrent E72 commit
`1c928a4ca..99d5f5972` (resource scheduling, five real-source missions, memory evaluation, one scheduling
experiment). The inherited E68/E69/E70/E71 suites all pass (`artifacts/e72/baseline.json`).

Historical references verified from evidence: E68 1,018.29 h / 1,000 workers; E70 1,000 workers, 163.46 h,
10.89 s failover; E71 3 models / 18 calls / 5 missions / 1,000,000 logical identities / 6.65 h.

## The E70 worker-hour discrepancy (forensic)

| Definition | Hours | Source |
|---|---:|---|
| E70 original: workers still alive at measurement, created→stop | **163.4645** | `artifacts/e70/endurance-latest.json` |
| E71 audit: every worker row, created→stop | **163.8940** | recomputed from the raw `coord.db` |
| Observed process lifetime: each row to its `ended_at` | **163.6772** | recomputed from the raw `coord.db` |
| Actual verified EXECUTE+VERIFY intervals (union per worker) | **2.0293** | recomputed from raw task rows |
| E70's own "verified productive" (EXECUTE only) | 1.0210 | E70 record |

The reported delta **0.4295 h** (163.8940 − 163.4645) is the population difference: E70 excluded the **3 workers
killed and replaced mid-run**; E71 summed all 1,000 rows. The recomputation at ISO-second resolution gives
163.3935 vs 163.8940 (0.5005 h) because the summary stores whole seconds; the uncertainty is explicit (≤0.1 h).
**Both original figures are preserved; nothing was silently merged.** The larger finding is that neither
"worker-hour" figure measures productive work: the verified productive interval union was **2.03 h**, not 163 h and
not 1.02 h (E70 counted only EXECUTE, excluding verification).

## Scheduling (E72-B)

`AdaptiveResourceController` estimates cost per operation, caps concurrency from CPU and RAM, sizes leases from the
estimate, and refuses work whose estimate cannot fit inside the task timeout. It never grants authority; a refused
task stays `READY`.

Measured (`artifacts/e72/scheduling.json`):

| Workers | Controller max busy | Verified | Lease expiries | p95 task |
|---:|---:|---:|---:|---:|
| 2 | 2 | 24/24 | 0 | 0.356 s |
| 4 | 4 | 24/24 | 0 | 0.434 s |
| 8 | 5 | 40/40 | 0 | 0.410 s |
| 16 | 6 | 40/40 | 0 | 0.452 s |
| 32 | 8 | 56/56 | 0 | 0.544 s |
| 64 | 8 | 56/56 | 0 | 0.449 s |
| 32, no controller | **32** | 56/56 | 0 | **3.478 s** |
| 16, no controller, 1 s lease | 12 | 0/12 | **36** | mission **FAILED** |

This reproduces the E71 oversubscription failure and fixes it. Interpretation: the controller trades raw throughput
for bounded latency and lease survival. It is not "faster" in every regime; the naive 32-worker run completed more
tasks/minute while making each task ~6× slower and, under a 1 s lease, failing the mission. A refused impossible
task is recorded as `ESTIMATE_EXCEEDS_LEASE`; refusing is the correct outcome, not a completion.