# Evolution 72 — Final Audit Branch `evolution-72`, final HEAD `3fa6c6fb826e6a51fa74cb7af51caaaaefb6c7d3`. This audit is generated from measured artifacts. Prior E72 final audit (commit 1c928a4ca) is preserved at `docs/evolution-72/history/FINAL_AUDIT_1c928a4ca.md`. ## Answers ### What was inherited? E71 at 16d8d1673 plus a concurrent partial E72 commit set 1c928a4ca..99d5f5972; all inherited E68/E69/E70/E71 suites pass. The prior E72 docs/audit are preserved under docs/evolution-72/history and artifacts/e72/history. ### What was implemented? Adaptive scheduling, real task-completion model evaluation and routing, five real-source missions with independent proof, cross-host execution on two VMs, worker/DB/cold-restart recovery, a durable 1-hour long-horizon controller, held-out memory evaluation, two governed experiments, an external benchmark, measured economics, a local ClawX view, a 93-scenario security lab, a gate registry and a standalone offline verifier. ### Which models actually executed? 56 real local transformer calls across SmolLM2-135M, SmolLM2-360M and Qwen2.5-0.5B; 0 remote calls. Remote providers are BLOCKED (no credential/endpoint). ### Which genuine missions completed? All five: repository engineering, defensive security, arXiv research, Iris data analysis, host reliability. 5/5 accepted from artifacts and tests. ### What real deliverables were produced? A verified patch + independent regression test, a security report with before/after exploit evidence, a cited research brief, a validated data analysis, a host-reliability report, five signed v5 evidence bundles, a 1-hour mission journal and a signed E72 evidence bundle. ### How many workers actually executed? Scheduling tested 2..64 real processes (max busy 8 under the controller); economics ran 240 tasks at 4 and 8 workers; cross-host ran 4 workers on host A and 2 on host B; recovery killed one live worker. No million-agent claim. ### How many logical identities were tested? 1,000,000 from E71 are preserved as historical records, not processes. E72 did not re-run a logical-identity scale test. ### What was independently verified? Every mission EXECUTE was recomputed by a different worker (cross-field where set); five mission bundles and two recovery bundles pass the E68 offline verifier; cross-host evidence verifies on both hosts; the E72 bundle verifier rechecks signatures, digests and key arithmetic. ### What were verified productive worker-hours? Long-horizon: 0.0174 h verified productive vs 0.6078 h process-alive. Economics: 4 workers 1.24 h productive vs 1.53 h alive; 8 workers measured separately. E70's 2.03 h interval union is preserved in the reconciliation, replacing the misleading 163 h figure. ### What was utilization under each workload? Scheduling levels: 2w 0.8656, 4w 0.7438, 8w 0.376, 16w 0.236, 32w 0.0988, 64w 0.0605. Economics: 4w 0.8132 (peak PSS 25.6 MB), 8w 0.4614 (peak PSS 46.6 MB). Long-horizon is duty-cycled: 0.02863. ### What improvements were demonstrated against E71? Oversubscription/lease failure reproduced and fixed (naive 32 workers p95 3.478 s and 36 lease expiries at 1 s; controller p95 0.544 s and 0 lease expiries). Five real-source missions with stronger independent proof. Cross-host execution moved from BLOCKED to demonstrated. Recovery added DB-lock and cold-restart tests. A 1-hour durable mission replaced short demonstrations. ### Was cross-host execution demonstrated? Yes, twice. (1) SSH-tunnel/SQLite: two distinct VMs, 18 verified tasks on host A and 22 on host B, 0 duplicates. (2) PostgreSQL shared state: mission M1 completed with 12 tasks produced on one host and independently verified on the other; a 972-event chain verifies; 0 duplicates. Coordinator failover succeeded on a repeated run: host B became leader, fencing advanced 2->3, M2 completed with 0 duplicates. The first attempt failed (b_took_over=false) and is recorded. Network partition was not induced. ### Was actual host reboot recovery demonstrated? Yes, on the development replica B: boot_id changed (32cacb7c... -> e245c1ff...), uptime reset to 120 s, mission M4 resumed and completed 100/100 verified tasks, and 5 tasks holding a 12 s expired grant were refused after recovery. This is one reboot, not a soak test, and it is not a production disaster-recovery proof. ### Which long-running missions completed? One real 1-hour campaign, cycled every 20 s with a restart at the phase boundary: 172 cycles, 688 verified EXECUTE tasks, journal chain intact. 6/24/72/168-hour missions are BLOCKED. ### What happened during failure injection? Worker SIGKILL: retried (max attempt 2), mission completed, 0 duplicates. SQLite exclusive lock: independent write failed closed; integrity ok. Coordinator cold restart: prior mission preserved; new mission completed. Host B reboot: boot_id changed, mission M4 resumed 100/100, expired grants refused. Coordinator failover attempt: B did NOT take over; not claimed. Provider outage: classified BLOCKED. Naive scheduling with a 1 s lease: 36 expiries, mission FAILED. ### Did memory improve held-out task performance? Deterministic retrieval 0/20 -> 20/20 (retrieval availability); real local model 0/6 -> 4/6 with context. Memory authority violations 0; injection quarantined; supersession correct. ### Did governed self-improvement produce reproducible gains? Two measured gains: routing +0.25 and scheduling +0.667 on held-out criteria; history chain verifies; promotion is withheld pending owner approval. Guard tests refused a protected target, no-held-out, evaluator substitution and agent self-promotion. ### What were the actual costs and resource requirements? Model cost $0 (local, unbilled); remote cost BLOCKED. 4 workers: CPU 0.727 s/verified task, peak PSS 25.6 MB, 81.3% utilization. 8 workers: 0.715 s, 46.6 MB, 46.1%. Cross-host host B had 2 vCPU / ~1 GB available. All figures are measured from the process tree. ### What security weaknesses remain? The lab is same-project, not an audit. PostgreSQL is a single primary, not Byzantine fault tolerant, and network partition was not induced. No remote-provider path, hardware attestation, SOC 2, third-party audit or independent trust anchor. ClawX is local. The evidence key is self-generated. Heuristic detectors can miss novel defects. ### Which gates are PASS, PARTIAL, BLOCKED, or FAIL? {"BLOCKED": 3, "FAIL": 0, "PARTIAL": 4, "PASS": 21} ### Was the remote replica independently verified? Yes: commit 3fa6c6fb8 pushed to the established development replica, clean clone, 18 E72 tests and the standalone verifier passed; remote HEAD matched that commit. The final docs/evidence commit is one commit ahead and is pushed after this audit; see replication.json. ## Measured facts - model calls and classifications - mission acceptance from tests/artifacts - cross-host task counts - recovery outcomes - benchmark denominators - CPU seconds, PSS, utilization - journal head - gate statuses ## Engineering interpretations - the controller is more economical for CPU-bound work at the smallest capable width - routing P2 is better than P1 but not better than the fixed strongest model - the long-horizon campaign demonstrates persistence, not throughput ## Future targets (not achieved) - 6/24/72/168 h missions - 500/1,000/5,000/10,000 verified productive hours - network partition tolerance - repeated reboot/soak recovery - remote model providers - third-party audit ## Not claimed - production readiness - third-party audit - network partition tolerance - remote model capability - general intelligence - 10,000 productive hours - hardware attestation - multi-reboot soak ## Gate summary ```json { "BLOCKED": 3, "FAIL": 0, "PARTIAL": 4, "PASS": 21 } ``` Reproduce with `python3 scripts/evolution72/verify_e72_offline.py artifacts/e72/bundle --json`.