Model candidate field

The canonical candidate field is the structured record in content/candidates/*.yaml, rendered as the candidate board. Gate, date, reason and evidence belong in those records; this page deliberately does not duplicate a hand-maintained status table.

Standing rule

Nothing leaves the field on assumption. A candidate changes gate only after a recorded measurement or an explicit operational blocker, and rejected candidates keep the evidence and bounded interpretation that caused the transition. Vendor claims and community reports are hypotheses to test, not substitutes for local evidence.

Promotion follows the staged protocol: fit probe, four-item guard, short agentic smoke, then a powered arm only where a decision depends on it. Quantisation, backend, build, context and simulator must remain explicit; unmatched configurations are not silently ranked together.

Reconciliation — 2026-08-19

• DeepSeek-V4-Flash-0731 remains benched. The carried v0.6.4 Vulkan fork completed f16-KV cells through d262144 without device loss (clm-0084). This corrects the older stock-only backend conclusion while preserving the fork/build and capability limits.
• Gemma 4 26B-A4B is rejected. HG-001 stopped at its guard gate after needle retrieval failed at 2048 tokens (clm-0085). No smoke, throughput, Vulkan or energy result was produced, so the record does not support a runtime-crash or general-quality claim.
• Ling-3.0-flash remains benched, with plain decode recommended. HO-002 proved real MTP activation and nonzero acceptance, but n_max 1–3 all missed the 1.10x promotion threshold (clm-0086). The MTP activation hazard is resolved; a production speed benefit was not measured.

Earlier prose listed candidates as never acquired or awaiting promotion after their records had moved. Those duplicate lists have been removed. For the complete current field and every transition reason, use the generated candidate board and structured histories.