This walks through publishing a decision model end to end. You will not upload any weights: the registry stores metadata and points at wherever your files already live.
1. Claim a namespace
Create an account. Your username becomes your namespace, so models you
publish live at username/model-name. It cannot be changed later — every
reference to your models depends on it.
Verify your email. Publishing is gated on it, which is what stops someone claiming an address they do not own.
2. Write the manifest
systemone.yaml is the file that makes your model comparable to every other
model on the registry. It is deliberately small enough to write by hand.
spec_version: "0.1"
model: support-router
namespace: biplov
category: system-one
architecture: laya
license: apache-2.0
summary: Routes inbound support tickets to the right queue.
capabilities:
- choice
- route
tags:
- routing
- support
runtime:
framework: pytorch
hardware: cpu
artifacts:
- kind: huggingface
uri: https://huggingface.co/biplov/support-router/resolve/main/model.safetensors
filename: model.safetensors
evaluation:
decision_accuracy: 0.943
calibration_error: 0.031
median_latency_ms: 4.7
Two fields do most of the work.
capabilities is a closed set — choice, score, rank, classify,
extract, route. It is closed on purpose: it is the field that makes the
registry filterable, and free text would make it useless within a month.
evaluation is where a decision model earns trust. Publishing
calibration_error beside decision_accuracy is what lets someone decide
whether they can threshold on your model's confidence. Leave it out and your
model is harder to adopt than it should be.
You can check the file before you publish, at the manifest validator or from the terminal once the CLI ships. Validation returns every problem at once rather than one per attempt.
3. Create the repository
Go to New model. Pick the owner, name it, paste the manifest. The editor validates as you type and will not let you create a repository whose manifest disagrees with its own URL.
Add a model card while you are there. The useful ones answer three questions: what does it decide, what was it trained on, and where does it fail. A table of good fits and poor fits is worth more than three paragraphs of prose.
4. Publish a version
Versions are immutable. Once 0.1.0 exists it always resolves to that manifest
and those artifacts, so a pull that worked last month still works.
Add artifact references — Hugging Face, GitHub, or a plain URL. The registry records where the file is and counts downloads; the bytes never pass through it.
5. Record the lineage
If your model is a fine-tune, say so:
base_model: acme/laya-base
The registry links it to the parent and lists your model on the parent's page. This is the part that compounds — the more lineage the registry records, the more useful it is for finding a starting point rather than starting over.
If the base model is not on the registry yet, that is fine. The reference stays in your manifest and resolves the moment that repository appears.
What is next
The same workflow runs from the terminal. pip install systemonemodels
installs the systemone command:
systemone login
systemone search routing
systemone pull acme/laya-base
systemone push ./support-router --repo you/support-router
login opens your browser once to approve the machine; after that, pushes and
pulls just work. The CLI guide has the rest, and the API
does everything the web app does — it is the same API the web app calls.