Why decision models need their own registry

Hugging Face can host a decision model. It is a file; the Hub stores files. So the honest case for a separate registry cannot be "they can't host it."

The case is that storing a model and making it findable and adoptable are different problems, and the second one is category-specific.

What generic metadata cannot express

Here is the metadata a general hub is built around, and what a decision model actually needs beside it:

Generic	Decision-native
Task, framework, language	Decision primitive: choice, score, rank, classify
Parameter count, architecture	Action space constraints and supported schemas
Evaluation score	Accuracy and calibration, confidence quality, latency
Model checkpoint	Base model → fine-tune → benchmark → runtime

You can put all of the right-hand column in a README. People do. But prose is not a filter. If calibration error lives in a paragraph, nobody can sort by it — and sorting by it is precisely what you want when you are choosing between four routing models.

The question you actually ask

Nobody browses a model hub asking "show me models." They ask something like:

A routing model I can put in a request path. Under 10ms on CPU. Calibrated well enough that I can auto-approve above 0.9. Permissively licensed.

On a general hub that is a search, then a dozen README skims, then a guess. On a registry where capability, latency, calibration and license are structured fields, it is four facets and a sort.

That is the whole product thesis. Not more models — a better answer to the question people are actually asking.

What a standard buys you

Structured fields only work if everyone fills them in the same way, which is why the registry is built around a small manifest rather than a form. systemone.yaml lives in the author's repository, next to the model, versioned with it. It is small enough that people actually write it, and closed where it needs to be — capabilities is an enum, not free text, because a field that accepts anything is a field nobody can filter on.

If the manifest gets adopted, the metadata standard is the moat, not the domain name.

Lineage compounds

A base model, a fine-tune of it, a benchmark of the fine-tune, a deployment of that. Each link is worth little alone. Together they answer questions no individual page can: what is the best starting point for my task, what has already been tried, did fine-tuning actually help.

The registry records base_model as a first-class relationship. Every fine-tune makes its parent more useful, which is the only kind of network effect that survives someone else copying your homepage.

What this is not

It is not a competitor to general ML infrastructure. Hugging Face and GitHub can sit underneath this registry: a version can point at files where they already live, or store them here, versioned and deduplicated. What the registry adds is the decision-native layer on top.

It is also deliberately not a dataset platform, not a Spaces equivalent, and not a GPU fleet. The first release proves one loop — discover, pull, fine-tune elsewhere, publish — and everything else waits until that loop has users.

Browse the registry, or read what makes a System One model different.