DOCUMENTATION
Why a different home
System One models decide instead of write. Why they need a registry of their own rather than a corner of a hub built for language models.
View as Markdown · for AI agents: llms.txt
Two kinds of model
Psychologists describe two modes of thinking. System 2 is slow and deliberate: it reasons, weighs options, explains itself. System 1 is fast and automatic: it sees the situation and acts.
Large language models are the System 2 of AI. Ask one which way a game agent
should move and it writes a paragraph weighing the options. A System One
model is the other half: given the same situation it returns one typed
decision — left, with a probability of 0.94 — in a millisecond or two, often
on a CPU or a phone.
Both are useful. They are not the same thing, and the tooling built for one fits the other badly.
What changes when a model decides
| A language model | A System One model | |
|---|---|---|
| Output | Free text | A typed decision with a probability for each option |
| Judged on | Fluency, helpfulness | Decision accuracy, calibration, valid-action rate |
| Latency | Seconds per answer | Milliseconds per decision |
| Runs on | GPUs | CPUs, edge devices, phones |
| Typical use | Explain, draft, converse | Route, score, rank, classify, act |
Calibration is the one that surprises people. A decision model's confidence is something your code branches on — escalate below 0.7, act above it — so a model that says 0.9 when it is right 60% of the time is broken even when its accuracy looks fine. A general hub has nowhere to put that number; here it is a field you can sort by.
What a general hub records, and what this one records
You can store a decision model on any model hub. It is a file. But storing a model and making it findable are different problems, and the second one depends on the category.
| A general hub records | A System One repository records |
|---|---|
| Task and language tags | What it decides: capabilities — choice, score, rank, classify, route |
| One evaluation score | Whether its confidence can be trusted: decision_accuracy, calibration_error, valid_action_rate |
| Parameter count | Whether it fits in a request path: median_latency_ms, p95_latency_ms |
| A checkpoint | Where it came from and what runs it: base_model, runtime, variants per folder |
Every right-hand entry is a field in systemone.yaml, so the registry can filter, sort and compare on it instead of leaving it in a README.
The whole lifecycle, native
A decision model's life is short and repetitive: pull a base model, fine-tune it on your own decisions, evaluate it, publish it, put it to work, and do it again when the data drifts. On a general hub every one of those steps is adapted from a workflow designed for something else.
Here each step is built for it:
- Discover by decision primitive, architecture, licence, accuracy or latency.
- Pull exactly the variant you need —
onnx-int8without the Core ML export beside it — with files cached by content. - Fine-tune locally with Laya Studio, which emits a manifest this registry accepts directly.
- Publish with lineage recorded: every fine-tune links to its base model, so the question "did fine-tuning help?" has an answer.
Who it is for
The developers who train and ship these models: game AI and reinforcement-learning agents, robotics controllers, ticket and request routers, risk and fraud scorers, rankers, and small classifiers that run on the device. If your model returns a choice, a score or an action rather than a paragraph, this is meant to feel like your own tooling.