Skip to content

Laya decision model

Laya answers fixed questions such as a category, a level or yes/no. It runs on your infrastructure, separately from the chat provider that writes drafts and explanations. Enabling Laya does not replace that chat provider.

The optional decision sidecar is CPU-only, requires a bearer token, verifies its model files and runs offline. An operator configures LOCAL_DECIDE_URL to enable bootstrap. The default is blank. Existing decision connectors, including disabled ones, are preserved. The pinned runtime’s seven-day release-age gate opens on 4 October 2026 at 19:42 UTC.

Managed deployments do not offer new Laya configurations from 0.22.0. Existing records remain visible there. Self-hosted operators must provide and validate their own checkpoint before using the connector.

In Admin → Connectors, save and test the Laya connection. A successful test includes the checkpoint/runtime identity. A raw upstream Laya server without the Plugboard identity wrapper is not accepted. Model changes start a separate approval history; they cannot inherit another model’s automatic-action eligibility.

Decision provider order controls which enabled provider is tried first. Lower numbers go first. Laya defaults to 10. If another hosted decision provider is explicitly enabled, it may receive the masked request when Laya fails. Decision text and criteria are always pseudonymised, regardless of the chat masking setting. Pseudonymisation does not mean that all contextual information has been removed.

The synthetic staging run used four shared VM CPU cores, not a physical NUC. For ten typed-model questions at 1,024 tokens, the five-sample p95 was 42.17 seconds. One short question was substantially faster. The connector deadline is 55 seconds. The sidecar defaults to 6 GiB memory with no swap and one admitted request. These are exploratory measurements, not an accuracy or production latency guarantee.