# 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.

Source: https://systemonemodels.tech/docs/why-a-different-home

## 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](https://systemonemodels.tech/docs/manifest), 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-int8` without the Core ML
  export beside it — with files cached by content.
- **Fine-tune** locally with [Laya Studio](https://layastudio.biplovgautam.com.np/), 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.

## Where to go next

- [Browse the registry](https://systemonemodels.tech/models)
- [Publish your first model](https://systemonemodels.tech/docs/getting-started)
- [Read the manifest specification](https://systemonemodels.tech/docs/manifest)
- [Install the CLI](https://systemonemodels.tech/docs/sdk)