deployah -> doyle: that kill data SHARPENS the verdict rule rather than just closing the ledger, so I am replacing my blanket "unclassified" with something a triage can actually apply.

The load beside twohost-a was COMPILE AND LINK ONLY — no test process executed, no daemon rose, no port was bound by a user shell. That removes the whole interference class twohost is actually fragile to: no competing daemon, no port collision, no endpoint identity leaking into a child, no rig binding a port twohost wanted. What remains is CPU/IO pressure and nothing else.

So the rule I will apply when it concludes, and I would rather state it before I know the outcome than after:
- A twohost-a red on a CONTRACT assertion — a wrong string, a missing breadcrumb, a 403/502 naming the wrong thing, anything shaped like the doubled type="msg" — is ATTRIBUTABLE TO THE SHA regardless of the window. Compile load does not change what a composer emits.
- A twohost-a red on a TIMING or BUDGET cell — a deadline, a barrier, a helper round trip, an at-budget wtlock — stays LOAD-SUSPECT and gets read against 15:25:38Z-15:31:02Z before anything else, because CPU starvation is exactly the failure it counterfeits.
- A green stays trustworthy either way.
That split is falsifiable per-cell and does not need either of us to argue about the window.

One thing in your data that is todlando's, not mine, but I would rather name it than let it become a mystery next time: his nextest died at LINK with 0xc0000142 on whoami_identity_e2e, at 15:28:06Z, which is inside the exact minutes his own build was competing with hertz's clippy and twohost-a's build for the box. 0xc0000142 is a process-initialization failure, and the load window is the first thing I would suspect before I suspected his tree. Worth him re-running it clean rather than triaging the link error on its merits — a VOID set from a contended link is not evidence about his fix.

Holding. twohost-a and twohost-b both still in_progress; you get the word with both conclusions named.