Status & versioning

Every model, in every series, carries exactly one status and one version. Status says where the current version is in its lifecycle; version identifies the weights. Deployment state is not a model property: whether a hosted endpoint exists is stated in each model's Runtime & deployment chapter, not in the badge.

Status vocabulary #

Five words, defined here and used with no other meaning anywhere on the site.

• Released — the weights for this version are final, evaluation is recorded, and the version is being served: through the Falcon API, behind the model's own service contract, or in-process inside the host application.
• Trained — the weights for this version are final and evaluation is recorded, but no hosted deployment of this version exists yet. The model's Runtime & deployment chapter says, verbatim: “A hosted endpoint for this version is not yet available.”
• Training — a training job for this version is in progress. No weights are published, and the Evaluation chapter reads “Evaluation results have not been published for this version.”
• Planned — the model or version is part of the series plan and no training job has run. It is documented with its intended contract only.
• Deprecated — a newer version or a sibling supersedes it. The documentation stays; the endpoint may be withdrawn after the notice period recorded on the changelog, and new integrations should pick the successor named on the page.

Beside each badge a short status note carries timing — “Serving since 2026-09-03”, “Weights final; hosted endpoint for this version not yet available” — so that the badge itself never has to carry a date.

What “hosted endpoint not yet available” means #

A Trained model is complete as a model: its weights are final, its metrics are published, and its request and response contract is documented in full. What it lacks is a running deployment of this version. In practice:

• The documented route or service contract is the one the model will answer on; nothing about the request shape changes when the endpoint appears.
• Until then, a public route whose model has not been deployed answers 503 with a model-specific unavailable code (for example lim3d_unavailable), and a service that is still loading its weights answers 503 with a loading message. The reference client retries once after 2.5 s. Which services load on demand is a deployment fact stated on each page: the Falcon API and, since 2026-09-16, the Express Voice service are kept warm with one minimum instance each; Express Cue scales to zero after a quiet period, and the GPU service shared by Waymark and Waymark Extra, and Cognitio, scale to zero and pay a cold start of one to two minutes.
• Weights are not distributed during the private preview, so a Trained model cannot be run by an integrator ahead of its endpoint.
• The change from Trained to Released is a status change recorded on the changelog. The weights do not change, so at most the patch number moves.

Versioning #

Versions follow semantic versioning applied to weights.

• Major — the input or output contract changes: a new required field, a renamed or added label, a different label set, a different frame. Integrations must be revisited.
• Minor — a retrain with the same contract: new data, a new recipe, different numbers, the same request and response shape. A drop-in replacement.
• Patch — metadata or runtime only: a corrected metric source, a changed resident footprint, a new deployment. The weights are byte-identical.

Pre-release versions carry a suffix, for example 0.1.0-pre, and are never Released. Chips show v1.0.0; tables show 1.0.0.

Every model is at version 1.0.0 today: the first documented version of each. A Planned or Training model carries a pre-release version such as 0.1.0-pre until its first weights are final. The number says nothing about maturity — ELIM at 1.0.0 has been serving since 2026-09-03, while Waymark Extra at 1.0.0 was released on 2026-09-13.

Lineage is separate from versioning. A warm-started model records the slug of its parent as lineage; the two are different models with their own version lines, not two versions of one model. A retired preview of a model, such as the 124M Waymark Extra preview that the released 355M model superseded, is a note in the Versions chapter, not a version.

What the Versions chapter records #

Each model's Versions chapter lists every documented version with its date, status and a short note, newest first, and closes with a compatibility paragraph and the current weights identifier — the checkpoint or bundle the deployed version was built from. Site-wide, the changelog merges every model's version history with site-level entries; the same list is published as changelog.json.