> ## Documentation Index
> Fetch the complete documentation index at: https://starforge.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Models

> The registry: a named version line across runs, and which version is in production.

A run id is a fact about an experiment. A model version is a decision — this is the one we are
willing to serve. This screen holds the second kind.

<Frame caption="The model registry: version lines, promotion and acceptance cards.">
  <img src="https://mintcdn.com/starforge/GatXR2rI5-_Vm4_H/images/console/models.png?fit=max&auto=format&n=GatXR2rI5-_Vm4_H&q=85&s=512a8de00f04df641c37de785a893567" alt="StarForge models page" width="2160" height="1350" data-path="images/console/models.png" />
</Frame>

## What you see

| Region              | What it shows                                                                 |
| ------------------- | ----------------------------------------------------------------------------- |
| **Version line**    | Every registered version of one model, newest first                           |
| **In production**   | Which version is promoted, or that none is                                    |
| **Acceptance card** | What the version shipped on, frozen at the moment it shipped                  |
| **Data flywheel**   | Where the version's data came from, what evaluated it, and what it is serving |

## The acceptance card

A card is either clean or it names what is missing. It records the evidence a version shipped on —
the evaluation verdict, the data sources, the run that produced it — at the moment of shipping, not
as a query run later.

That distinction is the point. Six months on, the run may have been reclaimed and the benchmark
suite may have moved, and a question like "what did we actually check before shipping v3" has no
answer unless somebody froze it.

<Info>
  A card marked with missing items is not a failure. It is an accurate statement that a version
  shipped without some piece of evidence — which is worth knowing precisely because it is easy to do
  by accident.
</Info>

## The data flywheel

| Stage                  | What it answers                                                                                               |
| ---------------------- | ------------------------------------------------------------------------------------------------------------- |
| **Data sources**       | Which platform datasets the run referenced. "No platform dataset" is itself informative                       |
| **Training**           | The run, or that the version was registered from outside with no training run                                 |
| **Evaluation verdict** | What scored it, or that nothing has                                                                           |
| **Serving**            | Whether it is deployed, and what traffic it takes                                                             |
| **Cost**               | Kept separate on purpose — whether search cost belongs to this version is a judgement, not an arithmetic fact |

A closed flywheel means production traffic can feed the next version through [Reflow](/en/guides/reflow).

## What you can do

* **Promote** a version to production. Deployments pointing at the model follow it.
* **Open the acceptance card** — it renders as a file a reviewer can read.
* **Archive** a version, taking it out of circulation without deleting its history.

From the CLI: `sf model register`, `sf model promote`, `sf model card`, `sf model archive`.