Inside the eval gate: how a checkpoint earns promotion
The gate is the only stage of the Neptune factory that produces no weights. It produces decisions — and the signed record that makes them checkable.
AINFERA RESEARCH·SIGNED AUDIT LOG · EVENT #000212Every stage of the line — SFT, DPO, GRPO, MTP, QUANT — ends the same way: a candidate checkpoint arrives at the gate. The gate runs the eval suites registered for that stage, writes the scores, and makes exactly one of two calls. Pass, and the checkpoint promotes to the next stage. Fail, and the run stops where it stands.1
The important property is that nothing else can make that call. There is no override flag, no "promote anyway" path in the orchestrator. A stage that wants to run can only consume checkpoints the gate has passed, the same way a build system can only link objects that compiled.
checkpoint → run(suites[stage]) → scores
scores → sign() → audit_log.append(event#)
verdict ∈ { PROMOTE, STOP } · no third value
Each verdict is appended to a signed audit log with an event #. The entry records the checkpoint hash, the suite versions, the scores, and the verdict. Eval certificates — the documents that ship with Neptune models — are rendered from these entries, which is why a certificate always cites its event #.2
This is also why we publish no roadmap dates. A date is a promise about the future; the gate only issues records about the past. When a model is listed as proof-gated, that is the whole claim: it ships when its evals clear, and you will be able to read the entry that says so.
1 "Stops" means stops: the artifact is retained for diagnosis, but nothing downstream may reference it.
2 Certificates are rendered from these entries and published with each release on Hugging Face.