# Laya: models, papers, benchmarks and practical guide

Independent guide by Coachix · September 23, 2026

## 01 · What Laya actually does {#overview}

Laya is an open-source **System 1 decision-model family** from Convai Innovations. Give it a business `state` and typed `questions`; it returns a choice, an ordinal score or a probability. It does not generate a reply token by token, write explanations or execute tools. “System 1” is a product metaphor for fast judgments, not evidence that the model reproduces human cognition.

A generative LLM can analyze a request and draft a response. Laya is closer to a dispatcher: which queue owns the request, whether it asks for a refund, how urgent it is. It can sit before an LLM as a router or after it as a checking component. Business rules, retrieval, a generative model or a person still complete the task. [S01][S02]

| Desired result | Fit | Reason |
|---|---|---|
| Choose billing, technical or sales | Fits the interface | A bounded answer space works with `choice` |
| Detect an explicit refund request | Fits the interface | `noul` returns the probability of a true proposition |
| Rate urgency from 0 to 3 | Worth evaluating | `score` supports ordered levels; published ordinal results are weaker |
| Write a refund explanation or justify a risk flag | Not directly supported | No free-text output or validated reasoning explanation |
| Extract arbitrary names, amounts and dates | Not general extraction | Fixed candidates can be selected; open fields need a parser, extractor or LLM |
| Browse, call a payment API or repair code | Outside the model | It returns judgments, not a complete agent runtime |
| Establish whether a news claim is true | Scores alone cannot establish truth | Trusted evidence is needed; the model can assess supplied material against a proposition |

**The practical assessment, as of September 23, 2026:** Laya is worth evaluating as a small, locally deployable decision component. Its usefulness depends on the task, language, option count, fine-tuning data and calibration. The “33 ms” headline does not settle those questions. Performance figures throughout this guide are attributed to their published experiments; they are not new Coachix inference measurements.

### Other projects called Laya

This guide covers `NandhaKishorM/laya` and `convaiinnovations/laya`. The `aayushch/laya` desktop notification assistant, the LAYA layer-attention paper at arXiv:2511.12723, and the EEG representation model at arXiv:2603.16281 are different projects. Their results do not belong to this decision model. [S36][S37][S38]

## 02 · Official links, versions and timeline {#identity}

| Resource | What to use it for |
|---|---|
| [Official project website](https://laya.convaiinnovations.com/) | The author's positioning, research history and model family |
| [Official GitHub repository](https://github.com/NandhaKishorM/laya) | SDK, Router, presets, license and changes |
| [Hugging Face model hub](https://huggingface.co/convaiinnovations/laya) | Model cards, weights and configuration; the root and two subfolders contain three checkpoints |
| [Interactive demo](https://huggingface.co/spaces/convaiinnovations/laya-demo) | Try the interface; shared-demo cold starts are not warm inference latency |
| [PyPI package](https://pypi.org/project/laya/) | Install the official Python library; old search snippets may show older versions |
| [Author's DEV article](https://dev.to/nandakishor_m_6cc0adfde9f/i-built-non-autoregressive-decision-models-a-year-ago-then-a-frontier-lab-called-it-a-18me) | Early technical explanation, read alongside current code |

The observed PyPI release is **0.3.6**, requiring **Python ≥3.10**, uploaded on September 22, 2026 at 20:43 UTC (September 23 at 04:43 in Beijing). Dependencies include PyTorch, Transformers, safetensors, huggingface_hub and NumPy. Code-level explanations use GitHub commit `c7527708f9f5220c669d8aa385077cd28d04708a`. A Git commit and a package version are different identifiers; they are not assumed to contain identical code. [S08][S09]

| Date | Event | Relationship to today's model |
|---|---|---|
| December 18, 2024 | ModernBERT paper submitted | Background for the English and typed-decisions backbones |
| March 30, 2025 | SalesRLAgent preprint submitted | Earlier sales-conversion research, not the current Laya model report |
| September 8, 2025 | mmBERT paper submitted | Background for the multilingual backbone |
| September 23, 2025 | Confidence-Aware Routing preprint submitted | Earlier reliability-routing research, different from the current SDK Router |
| September 18, 2026 | PyPI 0.1.0 and DEV article | Early Laya release; some material still uses “RL Agent” |
| September 19, 2026 | PyPI 0.2 and 0.3 series | Rapid package changes make tutorial versions matter |
| September 21, 2026 | Independent sysone-bench v2 | Same-input comparison with Jev; routed Laya added afterward |
| September 23, 2026, Beijing | PyPI 0.3.6 observed | Version reference for this guide |

The website links the author's earlier research to Jev. That is the author's account of provenance and priority. Public material does not establish that Jev borrowed this project's code, weights or methods. Similar terminology is not proof of derivation. [S01][S10][S22]

## 03 · Choosing among the three checkpoints {#models}

| Checkpoint | Encoder | Total parameters, per model card | SDK length configuration | Starting point |
|---|---|---:|---:|---|
| `convaiinnovations/laya` | ModernBERT-large | 421M | 512 tokens | English classification, email and routing |
| `convaiinnovations/laya-multilingual` | mmBERT-base | 322M | 1024 tokens | Chinese, other non-English text and multilingual traffic |
| `convaiinnovations/laya-typed-decisions` | ModernBERT-large | 421M | 1024 tokens | A specialist fine-tuned on four typed-decisions workflows |

The same checkpoints can be loaded from the main hub's root, `multilingual` and `typed-decisions` subfolders. Downloading one model does not load all three into memory. The model card's approximately 808 MB / 647 MB weight-size figures are **not runtime memory promises**. FP32, activations, intermediate tensors and request batches add memory use. [S03][S04][S05]

### The context-length trap

A backbone's longer positional range does not mean Laya feeds an entire 8192-token document into its default model. The actual `max_len` values are 512 or 1024. Instructions, options and state share that budget. The corresponding `head_max_len` values are 192 / 256 / 256. The sequence constructor calculates remaining space from the actual question-head length; “about 320 / 768 tokens for state” is only an estimate. Special tokens and the question length change the remaining space. [S11][S14][S15][S16]

By default, an overlong state keeps its beginning and loses its tail. A customer's final correction—“I already resolved this” or “the previous description was wrong”—may disappear. Raising the configured length requires fresh memory, latency and accuracy measurements. The backbone's maximum length is not a guarantee of useful performance.

### An English specialist is still an English specialist

The typed-decisions checkpoint still uses English ModernBERT. Its English workflow advantage does not establish an advantage on Chinese tickets or alerts. Start a Chinese baseline with multilingual, compare it with suitable Chinese models, and evaluate any domain fine-tuning on samples in the target language.

## 04 · Inside a single decision {#architecture}

The interactive pipeline follows six stages: state → question → bidirectional encoder → decision head → temperature/softmax → typed output. The numbered explanation below preserves every stage.

Each question gets its own input sequence, approximately:

```text
[CLS] question type + instructions [SEP]
[MASK] option A [MASK] option B … [SEP]
business state [SEP]
```

1. **Serialize the state.** Text, JSON objects and conversation lists become textual representations. JSON describes the situation; it is not a database transaction and triggers no tool automatically.
2. **Render the question and options.** The three question types have token budgets. The SDK handles literal `[MASK]` text to prevent interference with option markers.
3. **Encode in both directions.** Tokens provide context to one another. The encoder does not repeat a next-token decoding loop.
4. **Apply type and decision heads.** A question-type embedding is added to the encoded representation, followed by a two-layer Transformer decision head. A scorer reads each option marker's representation and produces its logit.
5. **Apply temperature and softmax.** Temperature is selected by question type and option count, then logits are scaled and normalized into probabilities.
6. **Return typed values.** `choice` selects the highest-probability option, `score` calculates an expected ordinal level, and `noul` returns the probability of truth. A separate act/escalate auxiliary head does not execute an action. [S11][S12]

### One forward pass still has a batch cost

`Agent.system_one()` builds one state-containing sequence per question, batches those sequences, then calls the model once. It avoids token-by-token generation, but repeats the state across question sequences. Work still depends on question count, length and padding. The official T4 measurements distinguish one question from fifty.

This also explains why `usage.input_tokens` can exceed the original state's token count: it counts valid input tokens across the batch. `output_tokens = 0` means there is no generative output. Many questions or long text still require batch limits, request limits and memory monitoring.

### Dynamic options versus a conventional classifier

A conventional classifier usually has a fixed label head established during training. Laya includes the option text in the input, so a request defines its answer space. This is flexible, but it does not make every new task accurate without training. New label meanings, industry vocabulary, rare events and fine distinctions can still exceed the model's ability.

## 05 · Choice, score and noul {#primitives}

| Type | Input definition | Main output | Interpretation |
|---|---|---|---|
| `choice` | A `criteria` dictionary of label keys and descriptions; label lists are also accepted | `choice` and option `probabilities` | Distribution across mutually exclusive options, usually summing to approximately one |
| `score` | An ordered `criteria` list, low to high | `score`, `legend` and level probabilities | Expected zero-based level; not necessarily an integer |
| `noul` | A proposition that can be true or false | `noul` | P(true), a number from zero to one, not a Boolean |

For levels `[Routine, Time-sensitive, Urgent]` with probabilities `[0.1, 0.3, 0.6]`, `score = 0×0.1 + 1×0.3 + 2×0.6 = 1.5`. The text does not literally belong to “level 1.5”; the number compresses an ordinal distribution. If an application needs an integer, choose and evaluate argmax, a ceiling rule or separate thresholds. Rounding is not automatically the correct policy.

A mutually exclusive `choice` loses information when a request is both a refund request and a complaint. Two `noul` questions can preserve those flags; alternatively, route the main intent and identify risk flags separately. Ambiguous questions, overlapping labels and an incomplete “other” category can force a confident but misleading choice.

### Confidence is not always the largest probability

In the inspected implementation:

- For `choice` and `score`, `confidence = 1 − H(p) / log(K)`: normalized concentration of the distribution.
- For `noul`, `confidence = max(P(true), 1 − P(true))`.
- `action.act_probability` comes from a separate auxiliary head. It is neither the selected option probability nor permission to act. [S11][S12]

For `[0.8, 0.2]`, the maximum probability is 0.8, but normalized-entropy confidence is approximately 0.278. A `noul` question with the same truth probability has confidence 0.8. Copying a “confidence ≥0.85 means automate” rule across types therefore creates very different behavior. Different types and option counts should not share an unevaluated threshold.

Returned probabilities are commonly rounded to four decimal places, so small sum errors are possible. Account for this precision in calibration calculations and logs. Do not take the logarithm of a rounded zero without an explicit numerical policy.

## 06 · RLCD, the training objective and data {#training}

RLCD means Reinforcement Learning for Calibrated Decisions. Laya's explanation describes a model reporting a probability distribution, exploring with noise on its logits, and receiving rewards from proper scoring rules rather than only from whether the winning class is correct. [S03][S10]

In `proper_reward()`, targets may be one-hot labels or soft distributions. The reward combines log and spherical scores; ordinal `score` questions also subtract a Ranked Probability Score based on cumulative distributions. Omitting masks:

```text
log score       = Σ targetᵢ · log(qᵢ)
spherical score = Σ targetᵢ · qᵢ / ||q||₂
RPS             = Σ (CDF(q)ᵢ − CDF(target)ᵢ)² / (K−1)
reward          = log score + wₛ · spherical score − wᵣ · RPS (ordinal)
```

Proper scoring rules provide an incentive in expectation: under their mathematical assumptions, reporting the true conditional probabilities is optimal. **Finite data, incorrect labels, distribution shift, optimization error and implementation clipping break the shortcut from that theory to guaranteed calibration.** The code also floors the log score for numerical stability. Every individual output is not thereby mathematically guaranteed to be calibrated. [S11][S27]

### What the public fine-tuning notebook actually does

The 2×T4 notebook synchronizes gradients with DDP. It adds zero-mean-projected Gaussian noise to logits to produce groups of candidate distributions, uses the group's mean reward as a baseline, standardizes advantages and computes a policy-gradient term. It also adds soft cross-entropy with weight 1.0: `loss_rl + 1.0 * loss_ce`. The executable recipe is not an RL-only loss. [S17]

This detail explains more than the word “reinforcement”: label distributions provide supervision while sampling and rewards shape probability behavior. The notebook is a domain fine-tuning route. It is not automatically a complete, step-by-step reproduction of all three released models from initialization onward.

### Keep the generations of data claims separate

| Material | What it describes | What that establishes |
|---|---|---|
| SalesRLAgent 2025 paper | GPT-4o-generated sales dialogues and Azure OpenAI embeddings | An earlier project's data and representations, not today's Laya |
| Laya author's announcement | A claimed corpus of 25,000+ human-annotated examples [S50] | An author statement; independent reproduction needs source, version and split records |
| LocalLLaMA/typed-decisions card | Synthetic states and soft labels from repeated teacher-endpoint sampling | Later specialization/evaluation data, not entirely human gold labels |
| Public fine-tuning notebook | Samples constructed from the typed-decisions training split, followed by test evaluation | A specialization procedure, not general zero-shot ability |

A dataset's presence in a training mixture does not prove test-instance leakage. Different splits do not rule out every form of contamination either. Separate source overlap, duplicate examples, template overlap and learning a teacher's style. [S17][S18][S23]

## 07 · Can the probabilities support a decision? {#calibration}

Temperature illustration: fixed logits [2, 1, 0], levels [0, 1, 2], T from 0.5 to 5. Probabilities use softmax(z/T); entropy confidence uses 1 − H(p)/ln(3); score is p(B) + 2p(C). These are illustrative calculations, not Laya predictions.

If a model reports 90% confidence on one hundred questions but gets only sixty right, it is overconfident. Accuracy measures selection correctness; calibration concerns the relationship between reported probabilities and long-run frequencies. Low ECE can also accompany uninformative probabilities, so inspect accuracy, Brier score, log loss and coverage together. [S26]

| Metric | What it measures | Common trap |
|---|---|---|
| Accuracy / Macro-F1 | Correct classifications and balanced class performance | A large majority class can hide minority failures |
| Brier score | Squared error between probabilities and labels | Sums, means and soft-label definitions are not interchangeable |
| Log loss / NLL | Probability assigned to the correct outcome | Zero probability is heavily penalized; implementations often use a floor |
| ECE | Binned confidence versus correctness | Binning, confidence definition and sample size change the value |
| Coverage / selective risk | How much is automated and how often those decisions fail | Post-threshold accuracy can hide a large rejected fraction |
| Score MAE | Distance between ordinal values | Different level scales cannot be compared directly |

### Temperature scaling and its limits

Temperature scaling computes `p = softmax(z/T)`. A positive scalar T for one question preserves the largest logit's identity; it changes the distribution's sharpness. T above one generally flattens it; T below one sharpens it. It cannot restore truncated evidence or repair a misunderstood label.

Upstream reports English ECE falling from 0.466 to 0.081 and multilingual ECE from 0.314 to 0.106 after fitting temperatures in a particular experiment. These are experiment-specific recalibration results, not promises for unseen production traffic. [S06]

The English configuration still contains an approximately 0.10058 temperature for `choice:11+`. The inspected SDK clamps temperatures to `[0.5, 5.0]` and warns about out-of-range values. **Identical weights can therefore yield different probability behavior with different SDK code.** Record package version, source commit and calibration file together. [S11][S12][S14]

### A reproducibility detail that matters

The notebook fits temperature using `all_items[::15][:400]`, where `all_items` contains training-process data. It does not read a fully independent calibration split for that step. For deployment, split training, calibration and final testing explicitly; do not treat the tutorial's sampling method as independent calibration evidence. [S17]

Plot threshold against coverage and error rate on the target distribution, choose thresholds from the cost of mistakes, and retain an abstention path. A threshold such as 0.85 is an example, not an industry standard.

## 08 · How the Router chooses a model {#router}

`Router` is a Python dispatcher, not another trained large model. The inspected priority is: explicit `model` → explicit `task` → opt-in workflow detection → explicit `lang` → script/language detection → default checkpoint. [S13]

**Version-sensitive detail:** `auto_task_detection=False` by default. Business-looking JSON does not automatically select typed-decisions. Use `model="typed-decisions"` or `task="typed_decisions"` explicitly. When automatic workflow detection is enabled, it matches known sets of question IDs; it does not understand which checkpoint is best for an arbitrary new business.

```python
from laya import Router

router = Router()
router.preload(["english", "multilingual"])
# Inspect routing without running the neural network.
print(router.route({"body": "Please investigate a duplicate charge."}).reason)
# If the input language is already known, declare it explicitly.
result = router.predict(state, questions, lang="zh")
```

The default lazy-loading mode, `max_loaded=1`, limits resident memory. Alternating English and Chinese traffic can trigger eviction and rebuilding. Upstream measured median reloads around 7.4 seconds on CPU and 10.3 seconds on T4 in some scenarios. Preloading reduces this variability but uses more memory. Loading time and warm inference time are separate measurements. [S02][S13][S21]

Language detection can fail on short abbreviations, numbers, code, or English JSON keys mixed with Chinese values. Use `lang` when the language is known, and log the actual selection and reason from `routing` metadata. High confidence does not prove the language route was correct.

## 09 · Official benchmarks, with their conditions {#benchmarks}

The following results come from `BENCHMARKS.md` and associated public result files. The project states that Laya checkpoints within one experiment are comparable, while quoted Jev numbers come from external runs with different samples and prompts. [S06][S19][S20]

### Three checkpoints on typed-decisions

This test contains 400 cases and 2,000 decisions. Values below follow `BENCHMARKS.md`; small README differences such as 0.361/0.362 or 0.061/0.062 are not averaged together.

| Model or baseline | Accuracy | Soft accuracy | Brier | ECE | Score MAE |
|---|---:|---:|---:|---:|---:|
| Laya typed-decisions | 0.766 | 0.471 | 0.061 | 0.213 | 0.242 |
| Laya English | 0.361 | 0.332 | 0.316 | 0.175 | 0.694 |
| Laya multilingual | 0.342 | 0.326 | 0.439 | 0.285 | 0.687 |
| Jev 1.13.0, externally quoted | 0.727 | 0.580 | 0.148 | 0.144 | 0.391 |
| Test-split majority baseline | 0.461 | — | — | — | — |
| Random baseline | 0.318 | — | — | — | — |

The specialist's workflow accuracies are approximately 0.804 for invoices, 0.766 for security incidents, 0.764 for customer service and 0.730 for agent traces. The base English and multilingual checkpoints fall below this test's majority baseline. That matters when choosing a checkpoint.

### Teacher agreement is not a truth ceiling

The dataset card describes labels as the mean of three distribution samples from a teacher endpoint of roughly 4B-class capability. Scores measure agreement with that teacher. Its 0.735 self-agreement is a reference statistic, not a mathematical accuracy ceiling. Learning the teacher's preferences can exceed that number without proving better real-world decisions. The majority baseline of 0.520 over all 1,600 cases also differs from the 0.461 baseline of the 400-case test split. [S18]

### Application tasks

| Task | English | Multilingual | Typed-decisions | Relationship to training |
|---|---:|---:|---:|---|
| Spam | 0.993 | 0.993 | 0.958 | Source included in training mixture |
| Phishing | 0.980 | 0.993 | 0.940 | Source included in training mixture |
| Jailbreak / guardrails | 0.708 | 0.755 | 0.762 | Held-out source |
| Toxicity moderation | 0.530 | 0.525 | 0.530 | Held-out source |
| RAG passage relevance | 0.625 | 0.657 | 0.625 | Source included in training mixture |
| Support routing, 10 classes | 0.502 | 0.522 | 0.505 | Source included in training mixture |
| Model-routing domain classification | 0.639 | 0.123 | 0.659 | Held-out source |

Strong email results do not establish reliable general content safety. Toxicity accuracy is about 0.53 and Macro-F1 about 0.40, which does not support using the model as the sole safety layer. Domain classification also does not directly identify the cheapest sufficiently capable LLM for any request.

### Speed needs a device and a timing boundary

| Questions per call | English / T4 | Multilingual / T4 | Interpretation |
|---|---:|---:|---|
| 1 | 39.5 ms | 32.8 ms | One warm question |
| 5 | 84.5 ms | 40.1 ms | Total batch latency |
| 10 | 158.6 ms | 72.3 ms | Multilingual averages about 7.2 ms/question; the whole batch is not 7.2 ms |
| 50 | 771.3 ms | 337.4 ms | More total latency, better per-question throughput |

These are Tesla T4 measurements, not a universal “33 ms” for every CPU, phone or server. A local process and a remote API include different network, queue, sequence-length and batching overhead. Speed ratios are scenario-dependent.

### Large option sets and option order

The official Banking77 application experiment reports 0.425 for English, 0.425 for multilingual and 0.492 for typed-decisions. Many options share a small question-head token budget, shortening label descriptions and removing distinguishing information. The SDK does not have a hard 20-option interface limit; “roughly twenty or fewer” is practical advice for current defaults.

Possible approaches include a larger head/total budget, coarse-to-fine classification, or candidate retrieval. `predict_shortlist` uses caller-supplied embeddings to retrieve top-k candidates before deciding. That adds retrieval error and computation; it is no longer an all-options, end-to-end single forward pass. Test shuffled option order too: the official 20-option MASSIVE English experiment reports answer-flip rates of 0.15 / 0.23. [S24]

## 10 · Independent comparisons using the same inputs {#independent}

`instax-dutta/sysone-bench` fixes states, questions, seeds and model versions, checking question SHA values for matching inputs. Its September 21, 2026 README v2 table covers 751 states across nine suites. Laya uses the English checkpoint on a local M2 CPU; Jev uses the remote `jev-1.13.0` API. [S34]

| Suite | n, as reported in that table | Laya | Jev |
|---|---:|---:|---:|
| Hand-curated support triage | 160 | 0.800 | 0.888 |
| Hand-curated guardrails | 60 | 0.883 | 0.967 |
| Hand-curated moderation | 90 | 0.833 | 0.989 |
| AG News, four labels | 100 | 0.940 | 0.910 |
| Emotion, six labels | 100 | 0.540 | 0.550 |
| Banking77, twelve-intent subset | 96 | 0.802 | 0.906 |
| MNLI, three classes | 60 | 0.983 | 0.867 |
| SST-5, five ordinal levels | 60 | 0.367 | 0.617 |
| Multilingual intent, five languages | 25 | 0.360 | 1.000 |

In the repository's v3 update, using the then-current Router raised Laya's multilingual intent score to 0.840. That test has only 25 samples. It suggests a direction; neither 0.840 nor 1.000 establishes broad language quality. Those English/Router runs also predate the code revision inspected here.

The results support neither “Laya beats Jev everywhere” nor “Laya has no value.” Laya performs strongly on AG News and MNLI, and its deployment and cost structure differ. The repository's `REPORT.md` still describes an earlier three-suite run with different figures. This guide keeps the named v2 table separate from that earlier report. [S35]

### Reading a cross-vendor comparison

Control inputs, label counts, prompt lengths, calibration procedures, domain fine-tuning and model versions. Separate hardware execution from remote API latency: identical inputs improve accuracy comparisons but do not remove network or hardware differences. Small public tests still need a target-domain evaluation. The [Coachix Jev guide](/llm/jev/) covers the other model's interface and published limits.

## 11 · Chinese and multilingual performance {#chinese}

“100+ languages” describes product and backbone coverage. The detailed public MASSIVE sweep covers **51 languages**. “45 usable languages” means exceeding three times random accuracy: with twenty choices, random is 0.05 and three times that is only 0.15. This experimental threshold is not a production-quality standard. [S04][S06]

| Language in the 51-language CPU sweep | English accuracy | Multilingual accuracy | Multilingual ECE |
|---|---:|---:|---:|
| Simplified Chinese, zh-CN | 0.620 | 0.630 | 0.212 |
| Traditional Chinese, zh-TW | 0.460 | 0.540 | 0.327 |
| Japanese | 0.530 | 0.640 | 0.228 |
| Korean | 0.110 | 0.450 | 0.329 |
| Arabic | 0.110 | 0.400 | 0.341 |
| English | 0.820 | 0.680 | 0.209 |
| Macro average over 51 languages | 0.2269 | 0.3661 | 0.3869 |

This table and the fourteen-language T4 experiment are different sweeps. Combining their best per-language values would misrepresent the experiments. Above-random English-checkpoint performance on some Chinese examples does not make it the more reliable starting point; the model card recommends multilingual outside English.

For Chinese deployment, start with five sample groups: mixed simplified/traditional script, Chinese with English product names, colloquial support language and typos, domain abbreviations/numbers, and corrections at the end of long messages. Evaluate the language combination of state and instructions/criteria. Chinese state with English questions is not automatically equivalent to Chinese throughout. Preserve original text: translation can alter sentiment, negation and technical terms.

## 12 · Papers: direct history, backbones and theory {#papers}

As of September 23, 2026, official resources chiefly point to two earlier author preprints, current code, model cards and blogs. **No clearly identified standalone technical paper fully documenting the training and evaluation of all three current Laya checkpoints was located in those materials.** This is a boundary on the identifiable public material, not proof that no later paper exists.

### A. SalesRLAgent: the earlier sales direction

**SalesRLAgent: A Reinforcement Learning Approach for Real-Time Sales Conversion Prediction and Optimization.** Nandakishor M, March 30, 2025, arXiv:2503.23303. [Abstract](https://arxiv.org/abs/2503.23303) · [Full text](https://arxiv.org/html/2503.23303v1) · [PDF](https://arxiv.org/pdf/2503.23303).

The paper treats sales dialogue as a sequence for conversion prediction. It describes about 1.2 million synthetic conversations and 3072-dimensional Azure OpenAI embeddings, and reports results on that sales task. It helps explain the author's interest in probability trajectories and real-time decisions. It does not validate today's ModernBERT-plus-dynamic-option-head architecture. Its reported accuracy or conversion lift must not be relabeled as Laya performance. This interpretation uses the full text; preprint status does not establish peer review. [S23]

### B. Confidence-Aware Routing: the earlier reliability direction

**Confidence-Aware Routing for Large Language Model Reliability Enhancement: A Multi-Signal Approach to Pre-Generation Hallucination Mitigation.** Nandakishor M, September 23, 2025, arXiv:2510.01237. [Abstract](https://arxiv.org/abs/2510.01237) · [Full text](https://arxiv.org/html/2510.01237v1) · [PDF](https://arxiv.org/pdf/2510.01237).

This paper combines semantic alignment, layer convergence and learned confidence estimates to route requests toward local generation, RAG, a larger model or human review. That is a different design layer from choosing a Laya checkpoint by language. Its place in the author's research history does not make it a full training report for current RLCD models. Metrics belong to that paper's own experiments, not an independent reproduction in this guide. This interpretation uses the full text. [S25]

### C. ModernBERT: the English backbone

**Smarter, Better, Faster, Longer: A Modern Bidirectional Encoder for Fast, Memory Efficient, and Long Context Finetuning and Inference.** Benjamin Warner and colleagues, 2024, arXiv:2412.13663. [Paper](https://arxiv.org/abs/2412.13663).

The encoder-only model targets classification and retrieval, reporting 2T pretraining tokens and native 8192-token sequences. It explains why a classifier need not use a large decoder and the speed/memory choices of modern bidirectional encoders. Laya adds its own head and length constraints; backbone results are not Laya results. This account uses the abstract and official model material. [S28]

### D. mmBERT: the multilingual backbone

**mmBERT: A Modern Multilingual Encoder with Annealed Language Learning.** September 8, 2025, arXiv:2509.06888. [Paper](https://arxiv.org/abs/2509.06888) · [Model card](https://huggingface.co/jhu-clsp/mmBERT-base).

The paper studies multilingual encoders and language-learning schedules. Its abstract describes 3T tokens and pretraining coverage exceeding 1,800 languages. That is a corpus-coverage statement, not evidence that Laya passed business evaluations in 1,800 languages. Laya multilingual uses mmBERT-base with additional decision components. This account uses the abstract and model card. [S29][S49]

### E. Calibration and reward theory

| Paper | Why read it | Boundary for Laya |
|---|---|---|
| Gneiting & Raftery, 2007, *Strictly Proper Scoring Rules, Prediction, and Estimation* | Why probability forecasts need proper scoring rules | Mathematical properties do not guarantee every finite-data neural prediction is calibrated [S27] |
| Guo and colleagues, 2017, *On Calibration of Modern Neural Networks* | Temperature scaling and modern-network overconfidence | Fit on independent calibration data; scaling cannot repair semantic blind spots [S26] |
| Schulman and colleagues, 2017, *Proximal Policy Optimization Algorithms* | PPO background for the earlier sales-RL account | The current notebook's policy-gradient procedure should not automatically be called a complete PPO implementation [S31] |
| Devlin and colleagues, 2018, *BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding* | Bidirectional encoding and masked language modeling | Laya reads option positions marked by `[MASK]`; it is not filling in an entire article during inference [S30] |

Also read MASSIVE (arXiv:2204.08582) and XNLI (EMNLP 2018) to understand what intent classification and cross-lingual inference measure. These are benchmark-background papers, not papers authored for Laya. [S32][S33]

## 13 · Reading the blogs and announcements {#blogs}

The **official project website** brings the checkpoints, performance, routing and deployment motivation together. It contains promotional claims and cannot replace the experimental methods or data. The **author's DEV article** provides more detail on the early architecture and reward function, but some naming still says “RL Agent.” Use current source code for API and probability-field semantics. [S01][S10]

The article describes ordinary cross-entropy training as prone to overconfidence. That is a practical concern, but “cross-entropy cannot learn calibrated probabilities” is not a general mathematical result: the log score is itself proper. RLCD is this project's training design, not proof that it must be better calibrated than every supervised classifier. [S27]

**TypeSafe's Jev launch post** explains the industry context around choice, score, noul, System One and RLCD. Separate interface concepts, implementation and empirical comparison. Shared vocabulary does not establish identical internals. [S22]

The **author's Hugging Face announcement** helps identify the model and demo. Dataset sizes and training hardware described in release material and the Reddit post remain author statements, not independent verification. [S44][S50]

**Community runtime READMEs** can be more useful than reposted summaries. MLX describes its timing boundary, C++ describes GPU backends, and Node documents ONNX weights and memory. The Chinese translation repository is an additional reading aid; resolve conflicts against the corresponding upstream revision. [S39][S40][S41][S43]

## 14 · A complete Python starting example {#sdk}

This example follows the public SDK interface for a local experiment. It prints actual returned values rather than supplying an invented prediction. Installation, weight downloads and inference were not run to produce the figures in this guide.

```bash
python3 -m venv .venv
source .venv/bin/activate
python -m pip install 'laya==0.3.6'
USE_TF=0 python demo.py
```

`USE_TF=0` is an upstream compatibility recommendation. In some environments with TensorFlow installed, Transformers' framework detection can interfere with model construction. It is not an acceleration algorithm or a required fix on every machine.

```python
# demo.py
import json
import laya

agent = laya.load("convaiinnovations/laya", subfolder="multilingual")
state = {
    "subject": "Duplicate charge",
    "body": "The same order was charged twice. Please investigate. "
            "I have not requested a refund yet."
}
questions = {
    "department": {
        "type": "choice",
        "instructions": "Which team should handle this message?",
        "criteria": {
            "billing": "Charges, invoices and payment issues",
            "technical": "Application failures and bugs",
            "other": "Requests unrelated to billing or technical support"
        }
    },
    "refund_requested": {
        "type": "noul",
        "instructions": "Does the user explicitly request a refund now?"
    },
    "urgency": {
        "type": "score",
        "instructions": "How urgent is the request based only on stated facts?",
        "criteria": [
            "Routine", "Time-sensitive",
            "Blocking or explicit immediate deadline"
        ]
    }
}
result = agent.predict(state, questions)
print(json.dumps(result, ensure_ascii=False, indent=2))
print("actual_device:", agent.device)
```

The example deliberately contains negation: “I have not requested a refund yet.” Check whether the model incorrectly turns a duplicate charge into an explicit refund request. All example text is in English here; to evaluate Chinese, replace the state with original Chinese customer text and compare the instruction-language combinations described above. The example only prints results. It issues no refund, sends no email and changes no account. The first run normally downloads weights; a downloaded local model directory can be used afterward.

### Consuming the result

For `choice`, read `answer["choice"]` and the matching `probabilities[label]`; for `noul`, read `answer["noul"]`. Read `confidence` separately when using distribution concentration for routing. Provide explicit handling for missing state, unknown labels, unreliable predictions and exceptions.

Built-in `router_questions()`, `guard_questions()`, `moderation_questions()` and `triage_questions()` are reusable schemas. They simplify integration but do not establish task quality in your language or data. [S48]

### A similar interface is not an OpenAI chat API

Python `predict` and `system_one` are library calls, not Chat Completions or Responses API endpoints. Some community servers expose a Jev-style `/v1/systemone`; deployment and behavior follow that implementation's documentation. The official Python package is not a ready-made OpenAI-compatible chat service.

## 15 · Deployment, hardware, cost and privacy {#deployment}

| Runtime | What it offers | What to check |
|---|---|---|
| Official PyTorch SDK | CPU and available CUDA / MPS devices; closest to upstream | Actual device, precision, length, switching and memory |
| Community MLX | Local Apple Silicon inference | Numerical parity with a named upstream version, device and question length |
| Community C++ / ggml | Native inference and CUDA/Vulkan paths | Converted weights, quantization, checkpoint and backend support |
| Node / TypeScript ONNX | Integration without Python | Export version, sequence limit, batches and memory |
| AXERA NPU package | Compiled graphs and examples for specified hardware | Fixed graph shapes; not general support for every desktop NPU |

The official SDK prefers available devices and can fall back to CPU when CUDA/MPS is unavailable or in some memory-error cases. The inspected version uses FP32 on CPU/MPS; CUDA precision also depends on device capabilities. Log the actual device: a `cuda` startup argument does not prove every request ran on a GPU. [S12]

CPU support does not mean every throughput requirement suits a CPU. Under concurrency, batching, queue latency, maximum text length and timeouts often matter more than a 33 ms example. Load the intended weights and warm the service before declaring it ready. A running process is not yet a model reliably serving requests.

### Free weights do not mean zero total cost

Apache-2.0 code and weights reduce per-call API fees, but hardware, power, memory, operations, monitoring and evaluation remain costs. Compare deployment options using a task-specific estimate:

```text
Monthly total ≈ compute + storage/network + operations time
                + labeling/evaluation + mistakes and human handoffs
Cost per useful decision = monthly total / decisions meeting the quality target
```

Low traffic and expensive GPU maintenance may favor an API. High volume, internal-only data or existing idle hardware may favor self-hosting. These are deployment trade-offs, not current price promises for a commercial service.

### Local inference and network boundaries

Local inference can keep business inputs away from a model-cloud API. Initial weight downloads still use the network, and application logs, monitoring, error reports or subsequent LLM calls may send data elsewhere. An offline environment needs weights, dependencies and tokenizer prepared ahead of time, followed by observation of actual network behavior. Open source alone does not make the whole application offline.

## 16 · Fine-tuning and designing your own evaluation {#finetuning}

The official 2×T4 Kaggle notebook specializes the English model on typed-decisions. It includes mixed precision, gradient accumulation, gradient checkpointing, different encoder/head learning rates, distributed training and post-training temperature fitting. The website's approximately four-hour estimate belongs to a particular setup; it guarantees neither free GPU availability nor completion time for every account. [S17]

1. Define a specific question, such as whether a ticket explicitly requests a refund, rather than “understand the customer.”
2. Fix label descriptions and an abstention path. Handle multiple intents, missing evidence and contradictory state.
3. Build representative samples. Split by user, time or incident so paraphrases of one event do not cross training and testing.
4. Compare simple rules, a conventional classifier, base Laya and an appropriate generative model using the same inputs.
5. Fine-tune only if needed, checking whether gains extend beyond the training source.
6. Fit temperature and operational thresholds on an independent calibration split. Report final results on a frozen test set.
7. Initially log recommendations beside human outcomes. Observe drift and failure types before expanding automation.

| Slice | Why inspect it separately? |
|---|---|
| Language, script variants and mixed-language text | Routing and tokenizer capabilities differ |
| Option count and description length | The head budget changes effective input |
| State length and location of key evidence | Truncation can remove the decisive information |
| Negation, quotations, reported speech and history | “Requested last time” is different from “requests now” |
| Minority classes and risky events | Overall accuracy can hide misses |
| Contradictions across questions | Individual accuracy does not guarantee a consistent overall decision |
| New businesses, products and time drift | The original calibration curve may stop applying |

The four typed-decisions workflows each have 300 training and 100 test cases: 1,200 / 400 total, with five questions per case. Two thousand decisions are not two thousand independent user events. Questions sharing a state are correlated. [S18]

## 17 · Useful application patterns—and poor fits {#applications}

**Support triage.** Supply the message, relevant order state and allowed queues; identify the main intent and urgency before a person or LLM writes a response. Invoice and charge facts should come from the business database. A classification probability is not an accounting lookup.

**RAG.** Provide a query and candidate passage to judge whether the passage supports a proposition. Evaluate the complete retrieval/reranking system. If a long passage is truncated, “irrelevant” may mean the model never saw the evidence near its end.

**Model routing.** Classify into bounded categories such as coding, translation and ordinary questions, then use predefined handling paths. Selecting by quality and cost requires task-specific outcome and pricing data; identifying the subject alone is insufficient.

**Agent traces.** Provide organized tool results and state to flag review needs or stalled work. Aggregate long traces deterministically and locate evidence before inference, instead of burying critical errors at the end of the context.

**Security-alert assistance.** Prioritize queues or suggest review to analysts alongside deterministic rules, dedicated detectors and human action. Published guardrail/moderation figures do not establish a comprehensive autonomous safety system.

**Documents and invoices.** A fixed approve/hold/reject recommendation can be one component. OCR, amount calculations, field matching and permission checks still need separate handling. A model score does not authorize a payment.

**Poor direct replacements:** complex multi-step planning, free writing, open-ended factual question answering, detailed legal interpretation of long documents, live-market fact checking, tool execution and cross-system transactions. Wrapping these jobs in several `choice` questions does not supply the missing reasoning or execution system.

## 18 · Community runtimes and projects {#ecosystem}

These are third-party implementations, not official performance guarantees. Their original READMEs explain platform constraints, setup, licenses and numerical compatibility.

| Project | Direction | Details worth checking |
|---|---|---|
| [mizorewww/laya-mlx](https://github.com/mizorewww/laya-mlx) | Native MLX on Apple Silicon | Reports short-question M3 Max P50 of 13.42 ms English / 7.39 ms multilingual; inspect timing boundaries and small-sample parity, not a promise for every Mac [S39] |
| [lkarlslund/laya.cpp](https://github.com/lkarlslund/laya.cpp) | Native ggml C++, CUDA/Vulkan | Its own tokenizer, computation and JSON output; several similarly named ports exist, so check the owner [S40] |
| [receptron/laya](https://github.com/receptron/laya) | Node.js / TypeScript, ONNX Runtime | Node ≥20; approximately 1.7 GB FP32 weights plus runtime memory, not the same as an instant browser demo [S41] |
| [AXERA-TECH/Laya](https://huggingface.co/AXERA-TECH/Laya) | AX650 / AX8850 NPU3 | Fixed batch 1, sequence 256 and up to four options; different from the general SDK's 512/1024 configuration [S42] |
| [yangshun2005/laya-cn](https://github.com/yangshun2005/laya-cn) | Chinese translation | Follow the upstream revision the translation corresponds to [S43] |
| [instax-dutta/sysone-bench](https://github.com/instax-dutta/sysone-bench) | Independent same-input evaluation | Read questions, versions, raw results and statistical definitions, not just the ranking [S34] |

For a port, check both selected-label agreement and probability-distribution agreement. FP16, quantization, tokenizer differences and temperature handling can alter confidence-based routing even when most argmax labels stay the same. Interface compatibility is not identical behavior.

## 19 · Misconceptions and remaining unknowns {#limits}

| Claim | More accurate interpretation |
|---|---|
| It does not generate text, so it cannot be wrong | It avoids invented free-text passages but can misclassify, mis-score and be overconfident |
| 33 ms is a fixed response time | A specific warm T4 multilingual single-question measurement; service loading, network and queue time remain |
| High accuracy was verified in 100+ languages | Coverage claims differ from the 51-language experiment, whose “usable” threshold is not a production standard |
| 76.6% is the out-of-box default | It belongs to a specialized fine-tuned checkpoint; base checkpoints score much lower on that task |
| Dynamic options let it solve any task | An open schema does not guarantee domain generalization; option count and text budgets still matter |
| RLCD guarantees trustworthy probabilities mathematically | Ideal scoring-rule properties differ from actual training and calibration performance |
| Confidence 0.9 means a 90% chance of being right | Choice/score confidence is normalized entropy; noul uses another definition |
| Router automatically chooses the best model for every task | Current defaults mainly route language; typed-workflow detection is opt-in |
| Free weights mean free deployment | Compute, operations, labeling and error handling still cost resources |
| The author's two papers are today's Laya technical report | They describe research history with different tasks and implementations |

Three documentation boundaries deserve attention. First, `BENCHMARKS.md` references `research/results/app_benchmark.json`, which was missing from the inspected main tree and returned 404. The application table is traceable to the summary and script, not a claimed re-computation of every raw result. Second, the historical sales model and dataset are under DeepMostInnovations. Their model-card training-size descriptions differ from the 2025 paper; read each version separately rather than merging them into current Laya facts. Third, rapid repository updates mean old scoreboards do not automatically cover today's temperature clamps, routing and compatibility fixes. [S06][S20]

Open questions include the complete base-training data inventory and splits, independent cross-domain calibration, real Chinese business evaluations, long-context and large-label stability, probability parity across ports, and a full training report for the current family. Missing public information should remain an open question.

## 20 · Questions and reading paths {#faq}

### Is Laya an LLM?

It uses pretrained language encoders and belongs to the language-model ecosystem. “Chat-style generative large language model” does not accurately describe its interface. A non-autoregressive typed-decision model is more precise.

### Can it replace Jev directly?

Some input/output concepts overlap, and compatible community services exist. Behavior, option budgets, latency, deployment and support differ. Replay the same states/questions through both and compare correctness, probability quality and total cost before deciding to migrate.

### Does it run on a Mac?

The official code includes MPS/CPU paths, and an MLX port exists. Check the device actually loaded and measure your samples. This guide does not present a benchmark of the reader's or author's computer.

### Does it browse, remember or call tools?

Those are application functions. The surrounding system supplies state, retrieval and execution. Laya contributes a judgment within that workflow.

### Can it read long chat histories?

Default total budgets are 512/1024 tokens, shared with the question head. Define the relevant time window and evidence, or design chunking and aggregation. Pasting an entire log does not mean every line was processed.

### Where should I start reading?

**Concept path:** sections 1, 3, 5 and 19 → official website → model cards. Learn the input/output contract and the conditions behind the promises.

**Engineering path:** sections 4, 7, 8, 14 and 15 → `agent.py`, `common.py`, `router.py` → a small integration → your evaluation.

**Research path:** sections 6, 9, 10, 12 and 16 → the two earlier author papers → ModernBERT/mmBERT → calibration and proper scoring → raw official T4 results and independent sysone-bench.

All three paths lead to one practical question: is Laya better suited than your current system under your labels, languages, latency budget and cost of mistakes? For the larger assistant design, continue with [Coachix's model-selection module](/llm/), [knowledge layer](/knowledge/) and [tool connections](/mcp/). [Open the Coachix console](/console/) to work on your assistant; the console link is not a hosted Laya inference endpoint.

## 21 · Glossary {#glossary}

| Term | Meaning in this guide |
|---|---|
| Checkpoint | A saved weight version; one SDK can load checkpoints with different abilities |
| Encoder-only | An architecture focused on input representations, useful for classification and retrieval |
| Non-autoregressive | No repeated decoding in output-token order; still involves computation and errors |
| Logit | An unnormalized option score before softmax, not yet a probability |
| Calibration | Agreement between probabilities and long-run correctness frequencies |
| Confidence | An SDK-defined output field whose exact formula matters |
| Temperature | A logit-scaling parameter that changes distribution concentration |
| Proper scoring rule | A scoring criterion that incentivizes reporting the true probability distribution |
| RLCD | Reinforcement-learning training framed around probabilistic decisions and calibration |
| Zero-shot | Applying a model without additional task-specific training |
| Held-out | Data excluded from a particular training process; specify whether instances or sources were held out |
| Teacher soft labels | Probability-distribution labels from a teacher, potentially including the teacher's biases |
| Argmax | The largest-probability option; distinct from the quality of the whole distribution |
| Preload / cold start | Keeping a model resident ahead of time / the first loading and construction cost |
| Shortlist | Retrieving a small candidate set first, adding a candidate-recall stage |

## 22 · Sources and further reading {#sources}

The fifty references below distinguish official material, implementation, papers, independent experiments and community ports. Each entry explains its relevance and reading scope. Citation numbers in the article jump to the matching entry. Ten papers provide research history or technical background; two other same-name papers are included only for disambiguation.

### S01 · Official Laya website

[Open reference](https://laya.convaiinnovations.com/)

Official · Full text

Project positioning, checkpoint family and deployment motivation. Read performance claims with the experimental conditions.

### S02 · Official Laya GitHub repository

[Open reference](https://github.com/NandhaKishorM/laya)

Official · Full text

SDK, routing, presets, license and limits. The main branch changes over time.

### S03 · Laya English and family model card

[Open reference](https://huggingface.co/convaiinnovations/laya)

Models and data · Full text

Three checkpoints, weights, architecture, training summary and limitations.

### S04 · Laya Multilingual model card

[Open reference](https://huggingface.co/convaiinnovations/laya-multilingual)

Models and data · Full text

mmBERT-based checkpoint, language sweep and configuration.

### S05 · Laya Typed Decisions model card

[Open reference](https://huggingface.co/convaiinnovations/laya-typed-decisions)

Models and data · Full text

Domain specialization; its scores must not be attributed to the base checkpoint.

### S06 · Official BENCHMARKS.md

[Open reference](https://github.com/NandhaKishorM/laya/blob/c7527708f9f5220c669d8aa385077cd28d04708a/BENCHMARKS.md)

Benchmarks · Full text

Language, application, latency, calibration and limitation tables from several experiments.

### S07 · Laya demo Space

[Open reference](https://huggingface.co/spaces/convaiinnovations/laya-demo)

Official · Entry and metadata

Online interface; shared-resource waits and cold starts differ from warm inference.

### S08 · PyPI laya

[Open reference](https://pypi.org/project/laya/)

Official · Package metadata

Official package; observed release 0.3.6 and Python requirement of at least 3.10.

### S09 · PyPI release and dependency JSON

[Open reference](https://pypi.org/pypi/laya/json)

Code and configuration · Full text

Upload times, Python compatibility, dependencies and release history.

### S10 · Author's DEV article: I Built Non-Autoregressive Decision Models…

[Open reference](https://dev.to/nandakishor_m_6cc0adfde9f/i-built-non-autoregressive-decision-models-a-year-ago-then-a-frontier-lab-called-it-a-18me)

Blogs and discussion · Full text

September 18, 2026 article on the early architecture and RLCD. Compare naming and marketing claims with current code.

### S11 · common.py: sequences, decision heads, rewards and confidence

[Open reference](https://github.com/NandhaKishorM/laya/blob/c7527708f9f5220c669d8aa385077cd28d04708a/laya/common.py)

Code and configuration · Full text

Computation path, truncation, entropy confidence and temperature limits.

### S12 · agent.py: loading and typed output

[Open reference](https://github.com/NandhaKishorM/laya/blob/c7527708f9f5220c669d8aa385077cd28d04708a/laya/agent.py)

Code and configuration · Full text

Device fallback, batching, choice/score/noul fields and usage accounting.

### S13 · router.py: selection priority

[Open reference](https://github.com/NandhaKishorM/laya/blob/c7527708f9f5220c669d8aa385077cd28d04708a/laya/router.py)

Code and configuration · Full text

Workflow detection is disabled by default; language routing, preloading and eviction.

### S14 · English rl_agent_config.json

[Open reference](https://huggingface.co/convaiinnovations/laya/blob/main/rl_agent_config.json)

Code and configuration · Full text

512/192 token budgets and temperatures, interpreted with the SDK's current clamps.

### S15 · Multilingual rl_agent_config.json

[Open reference](https://huggingface.co/convaiinnovations/laya/blob/main/multilingual/rl_agent_config.json)

Code and configuration · Full text

1024/256 budgets; type temperatures initially one, without fitted option-count buckets.

### S16 · Typed-decisions rl_agent_config.json

[Open reference](https://huggingface.co/convaiinnovations/laya/blob/main/typed-decisions/rl_agent_config.json)

Code and configuration · Full text

Specialist length limits, temperature and training metadata.

### S17 · 2×T4 Kaggle fine-tuning notebook

[Open reference](https://github.com/NandhaKishorM/laya/blob/c7527708f9f5220c669d8aa385077cd28d04708a/notebooks/laya_finetune_typed_decisions_2xT4_kaggle.ipynb)

Code and configuration · Full text

DDP, noisy policy gradients, soft cross-entropy, calibration and testing. Code was read, not executed for this guide.

### S18 · LocalLLaMA/typed-decisions dataset card

[Open reference](https://huggingface.co/datasets/LocalLLaMA/typed-decisions)

Models and data · Full text

Four workflows, splits, soft teacher labels, baselines and metric definitions.

### S19 · Official raw T4 results

[Open reference](https://github.com/NandhaKishorM/laya/blob/c7527708f9f5220c669d8aa385077cd28d04708a/research/results/t4_colab_benchmark.json)

Benchmarks · Full text

JSON for the 17,416-question experiment, including samples and metrics.

### S20 · bench_apps.py: application benchmark

[Open reference](https://github.com/NandhaKishorM/laya/blob/c7527708f9f5220c669d8aa385077cd28d04708a/research/scripts/bench_apps.py)

Benchmarks · Full text

Dataset sources and task construction. The cited app_benchmark.json was missing from the inspected tree.

### S21 · bench_latency.py: latency and loading

[Open reference](https://github.com/NandhaKishorM/laya/blob/c7527708f9f5220c669d8aa385077cd28d04708a/research/scripts/bench_latency.py)

Benchmarks · Full text

Separates language detection, warm calls, cold switching and model residency.

### S22 · TypeSafe: Introducing System One Models and Jev

[Open reference](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

Blogs and discussion · Full text

First-party explanation of a related product, not evidence of Laya implementation or priority.

### S23 · SalesRLAgent, 2025

[Open reference](https://arxiv.org/abs/2503.23303)

Papers · Full paper

Earlier sales-conversion RL work; the full HTML was read. Not the current Laya technical report.

### S24 · shortlist.py: candidate retrieval

[Open reference](https://github.com/NandhaKishorM/laya/blob/c7527708f9f5220c669d8aa385077cd28d04708a/laya/shortlist.py)

Code and configuration · Full text

Caller-provided embeddings narrow candidates before classification; consider recall loss and added computation.

### S25 · Confidence-Aware Routing, 2025

[Open reference](https://arxiv.org/abs/2510.01237)

Papers · Full paper

Earlier multi-signal reliability routing; different from today's language-checkpoint Router.

### S26 · Guo et al.: On Calibration of Modern Neural Networks

[Open reference](https://proceedings.mlr.press/v70/guo17a.html)

Papers · Abstract and method overview

ICML 2017 background on temperature scaling, calibration and overconfidence.

### S27 · Gneiting and Raftery: Strictly Proper Scoring Rules

[Open reference](https://doi.org/10.1198/016214506000001437)

Papers · Abstract and definitions

JASA 2007 mathematical foundations for probabilistic prediction and proper scores.

### S28 · ModernBERT: Smarter, Better, Faster, Longer

[Open reference](https://arxiv.org/abs/2412.13663)

Papers · Abstract and model material

English backbone paper; encoder context length is not Laya's default total length.

### S29 · mmBERT: A Modern Multilingual Encoder with Annealed Language Learning

[Open reference](https://arxiv.org/abs/2509.06888)

Papers · Abstract and model material

Multilingual backbone; pretraining language counts are not business-task coverage.

### S30 · BERT: Pre-training of Deep Bidirectional Transformers

[Open reference](https://arxiv.org/abs/1810.04805)

Papers · Abstract

Bidirectional encoding and MLM background; option-marker inference is described in Laya code.

### S31 · Proximal Policy Optimization Algorithms

[Open reference](https://arxiv.org/abs/1707.06347)

Papers · Abstract

PPO background; do not equate the current notebook's entire training recipe with PPO.

### S32 · MASSIVE: A 1M-Example Multilingual NLU Dataset

[Open reference](https://arxiv.org/abs/2204.08582)

Papers · Abstract

Background for the 51-language intent task and its evaluation scope.

### S33 · XNLI: Evaluating Cross-lingual Sentence Representations

[Open reference](https://aclanthology.org/D18-1269/)

Papers · Abstract

Cross-lingual natural-language inference, not open-ended question answering.

### S34 · sysone-bench README: independent same-input comparison

[Open reference](https://github.com/instax-dutta/sysone-bench)

Benchmarks · Full text

Nine-suite v2 table and v3 Router update; local and API latency still include different overhead.

### S35 · sysone-bench REPORT: earlier three-suite run

[Open reference](https://github.com/instax-dutta/sysone-bench/blob/master/REPORT.md)

Benchmarks · Full text

An older run than README v2; preserve its sample and uncertainty boundaries.

### S36 · The other Laya desktop assistant

[Open reference](https://laya.aay.sh/docs.html)

Name disambiguation · Project description

Notification management and action cards, not the decision model covered here.

### S37 · LAYA: Layer-wise Attention Aggregation

[Open reference](https://arxiv.org/abs/2511.12723)

Name disambiguation · Abstract

Gennaro Vessio's output-head aggregation research; a different model identity.

### S38 · Laya: A LeJEPA Approach to EEG

[Open reference](https://arxiv.org/abs/2603.16281)

Name disambiguation · Abstract

An EEG representation model with different authors and tasks.

### S39 · mizorewww/laya-mlx

[Open reference](https://github.com/mizorewww/laya-mlx)

Community runtimes · Full text

Apple Silicon runtime; inspect M3 Max setup, timing boundaries, versions and probability parity.

### S40 · lkarlslund/laya.cpp

[Open reference](https://github.com/lkarlslund/laya.cpp)

Community runtimes · Full text

Native ggml inference with CUDA/Vulkan; distinguish this repository from similarly named ports.

### S41 · receptron/laya

[Open reference](https://github.com/receptron/laya)

Community runtimes · Full text

Node/TypeScript ONNX implementation with its own weight and memory requirements.

### S42 · AXERA-TECH/Laya

[Open reference](https://huggingface.co/AXERA-TECH/Laya)

Community runtimes · Full text

NPU3 package: batch one, sequence 256, up to four options and dedicated hardware.

### S43 · yangshun2005/laya-cn

[Open reference](https://github.com/yangshun2005/laya-cn)

Community runtimes · Entry and description

Chinese reading aid; its revision can lag upstream.

### S44 · Author's Hugging Face Laya announcement

[Open reference](https://huggingface.co/spaces/multimodalart/jev-decision-index/discussions/1)

Blogs and discussion · Announcement

First-party model description and demo links; training-size claims remain author statements.

### S45 · Historical SalesRLAgent model card

[Open reference](https://huggingface.co/DeepMostInnovations/sales-conversion-model-reinf-learning)

Models and data · Full text

DeepMostInnovations' earlier PPO sales model has different interfaces, licensing and data claims.

### S46 · Historical SaaS sales-conversations dataset

[Open reference](https://huggingface.co/datasets/DeepMostInnovations/saas-sales-conversations)

Models and data · Dataset card

Earlier project data, not a complete training inventory for today's three checkpoints.

### S47 · Laya research README

[Open reference](https://github.com/NandhaKishorM/laya/blob/c7527708f9f5220c669d8aa385077cd28d04708a/research/README.md)

Benchmarks · Full text

Experiment scripts, raw results and explicit limits of non-simultaneous Jev comparisons.

### S48 · presets.py: built-in question sets

[Open reference](https://github.com/NandhaKishorM/laya/blob/c7527708f9f5220c669d8aa385077cd28d04708a/laya/presets.py)

Code and configuration · Full text

Model routing, guardrail, moderation and triage schemas; presets do not guarantee task quality.

### S49 · jhu-clsp/mmBERT-base model card

[Open reference](https://huggingface.co/jhu-clsp/mmBERT-base)

Models and data · Full text

Multilingual backbone configuration, pretraining background and usage.

### S50 · Author's r/LocalLLaMA Laya announcement

[Open reference](https://www.reddit.com/r/LocalLLaMA/comments/1wjieap/made_the_horizontal_opensource_model_for_jev_with/)

Blogs and discussion · Announcement and retrieved post

Author statement of 25,000+ human-annotated examples, not independent verification of complete training data. The original research used the announcement excerpt; the post was reopened for this English edition.