[Tracking] MLSys 2027: neocloud fleet admission — readiness

Readiness index for the MLSys 2027 neocloud fleet-admission paper.

Gap analysis: fable-review/06-mlsys-readiness.md, verified against Vx source 2026-08-02.

Bottom line from that analysis: the type-system substrate is ready. The gaps are one small dtype addition, three pieces of tooling plumbing, and the evaluation assets themselves — roughly 3–4 focused weeks of Vx work.

Everything in this set carries the mlsys label, including the pre-existing issues listed below: gh issue list --label mlsys.

Already there — verified, no work needed

P0 — paper-blocking

• hiraditya/Vx.1#280 — fp8 element types (f8e4m3 / f8e5m2) · 1–2d
• hiraditya/Vx.1#281 — --machine <file.vx> · 2–4d
• hiraditya/Vx.1#282 — --diagnostics-json · 2–3d
• hiraditya/Vx.1#283 — fleet library + reference admission program · ~1wk · needs hiraditya/Vx.1#280, hiraditya/Vx.1#281
• hiraditya/Vx.1#284 — multi-GPU modeling rule + constant-index check · 2–3d
• hiraditya/Vx.1#285 — vLLM bridge emitter · 3–5d · needs hiraditya/Vx.1#282
• hiraditya/Vx.1#286 — resident-set modeling rule (docs only) · ~0.5d

P1 — strengtheners, if the campaign goes smoothly

• hiraditya/Vx.1#287 — overcommit / PagedAttention story
• hiraditya/Vx.1#288 — negative suite as bug taxonomy · needs hiraditya/Vx.1#283
• hiraditya/Vx.1#245 — bounded shapes (context <= 8192 as a QF_LIA-checked bound), upgrading W1029 from "skipped" to a proof. V1 works without it via static max-context, which is how operators plan capacity anyway.

Critical path, not Vx work

• hiraditya/Vx#289 — ground-truth rental campaign. The long pole.

The gate

#280, hiraditya/Vx.1#281, hiraditya/Vx.1#282, hiraditya/Vx.1#283 must be done by mid-September or hiraditya/Vx#289 cannot start — and hiraditya/Vx#289 is the long pole. Everything else has slack; these four do not.

Calendar

Aug (w/ CGO):  hiraditya/Vx.1#280 fp8 -> hiraditya/Vx.1#281 machine flag -> hiraditya/Vx.1#282 JSON -> hiraditya/Vx.1#283 fleet library + fixes
early Sep:     hiraditya/Vx.1#284 indexed check, hiraditya/Vx.1#285 vLLM emitter; dry-run the matrix locally
mid-Sep-Oct:   hiraditya/Vx#289 rental campaign (P0 done) - P1 items as slack allows
mid-Oct:       write; Oct 30 submit

Calendar risk, stated plainly: this plan runs P0 alongside the CGO push (deadline 2026-09-10), and the readiness analysis was written as though CGO's remaining work were zero. It is not — there is an unfinished sweep and an outstanding experiment there. Two papers are sharing these five weeks.

Explicitly out of scope — resist

on_overflow / MoE capacity policy (#255 — future-work section), seam obligations across inter-node links, per-instance memory accounting, first-class TP/PP annotations, any GPU codegen, async transfer tokens (#244), mlir! (#250), plugin work.

Note on the source document

06-mlsys-readiness.md cites hiraditya/Vx.1#17, hiraditya/Vx.1#20 and hiraditya/Vx.1#21 for multi-hop staging, bounded shapes and on_overflow. Those numbers are wrong — they point at the old hardware-plugin epic. The real issues are #245 (bounded shapes) and #255 (MoE / on_overflow); multi-hop staging has no tracking issue and needs none, being already verified by emission.

Start with fable-review/06-mlsys-readiness.md and compare its issue references with the linked #280–#289 work items. Use gh issue list --label mlsys to inspect the tracked implementation and evaluation tasks; this tracking issue is complete when the stated P0 gate and supporting readiness work are resolved.