Laya — a decision architecture built for choosing

Laya is a System One architecture designed around one idea: the set of things the model is allowed to answer is part of the model, not part of the prompt.

Laya is an evolving open architecture. The details below describe how it is used on this registry today; treat specific numbers as illustrative rather than as a benchmark claim.

The constrained head

Most classification setups fix the label set at training time. Laya's choice head takes the candidate set as an input, so the same trained model can decide between three queues today and five tomorrow without retraining.

from systemone import load

model = load("acme/laya-base")

decision = model.decide(
    "I can't connect to the API after rotating my key.",
    options=["technical_support", "billing", "general"],
)

decision.choice  # "technical_support"
decision.confidence  # 0.91
decision.probabilities  # {"technical_support": 0.91, "billing": 0.06, ...}

Two consequences follow, and both matter more than they sound.

The model cannot return an option that was not offered. Not "is unlikely to" — cannot. The probability mass is normalised over the candidate set, so the invalid-action failure mode disappears by construction rather than by careful prompting.

And because the head is trained to produce a distribution rather than a single argmax, the confidence is a quantity you can threshold. That is the whole basis for routing low-confidence cases to a human.

Why calibration gets its own metric

An uncalibrated model that reports 0.95 on cases it gets right 70% of the time is actively dangerous: every threshold you set from it is wrong. Laya models on this registry publish calibration_error beside decision_accuracy for exactly this reason, and you can sort the registry by it.

A concrete way to read the two together: accuracy tells you how often the model is right; calibration error tells you whether you can believe it when it says it is sure.

Fine-tuning

Laya fine-tunes are usually small and fast, because you are adapting a decision boundary rather than teaching a model language. The typical recipe:

1. Start from a base model — acme/laya-base or another published backbone.
2. Collect examples as (input, options, chosen) triples. A few thousand is often enough; you are not teaching vocabulary.
3. Train locally. Most Laya fine-tunes fit comfortably on a laptop GPU, and many on CPU.
4. Evaluate accuracy and calibration on a held-out set.
5. Publish, declaring the base model so the lineage is recorded.

For the training loop itself, Laya Studio is an open-source project that handles configuration, training and evaluation, and produces a manifest you can publish straight to this registry.

Declaring it

A Laya fine-tune's systemone.yaml records where it came from:

spec_version: "0.1"
model: support-router
namespace: biplov
category: system-one
architecture: laya
base_model: acme/laya-base
license: apache-2.0
capabilities:
  - choice
  - route
runtime:
  framework: pytorch
  hardware: cpu
evaluation:
  decision_accuracy: 0.943
  calibration_error: 0.031
  median_latency_ms: 4.7

That base_model line is what builds the lineage graph — the registry links the fine-tune to its parent and lists it on the parent's page, so anyone who finds the backbone can see what has been built on it.

Read the full manifest specification, or browse Laya models on the registry.