# Introduction

Jers is a decision API with memory. Send a state and typed questions; get typed answers with probabilities and confidence that your code can branch on. Name a subject, and the answer also uses what that subject's memory knows, without you packing it into every request.

Large language models write text for people. When your code needs a judgment it can act on, you end up asking a text generator for JSON and parsing it back. Jers does not generate text. A decision engine reads the state together with each question and answers every question in the request, each as a typed value: a choice with a probability per option, a score on ordered levels, or the probability that a statement is true.

```
one request                          one response
state + questions  ──►  Jers  ──►    typed answers + probabilities + confidence
      + subject          │              + what the memory contributed
                         │              + warnings about known traps
                 the subject's memory (RAM)
                 facts, rules checked in code
```

## The three primitives

| Question type | Goal | Returns |
|---|---|---|
| Choice | pick one option from a list | `choice`, `probabilities`, `confidence` |
| Score | place the state on ordered levels | `score`, `probabilities`, `legend`, `confidence` |
| Noul | is this statement true | `noul`, a probability from 0 to 1, and `confidence` |

All three can be mixed in one request. Each question is evaluated on its own against the same state, so adding questions does not change the other answers.

## The fourth thing: memory

Every Jers tenant has as many subject memories as it likes. A subject is whatever you decide about: a customer, a user, a player, a device, a case, a project. A memory holds lines (facts about the subject, in words) and rules (a condition checked in code, and what to do when it holds). `POST /v1/memory/remember` writes a line to RAM in about 0.1 ms (median, measured on the development Mac); a decision that names the subject recalls the lines that touch the state, adds the rules whose condition holds, places them before the state, and tells you which lines it used and how many the engine read. `forget` removes a concept and verifies it is gone. Two tenants never see each other's memories, whatever names they use.

## What Jers is made of

Jers is built on an open decision engine with three checkpoints and a language router. Its calibration was measured here on one constructed set of 60 support messages, and it can be fitted to each tenant's own labels (Quality); the numbers in these pages are measured and say where. Jers adds the memory, rules checked in code, the comparison of a decision with and without the memory when you ask for it, verified forgetting, warnings, two rounds for large choices, option orders and windows, quality and calibration from your labels, batches, tenant isolation, keys, metering and credit.

## Next steps

- Getting started and Quick start: a key, a request, a memory.
- Jers versus Jev: what is the same and what is different.
- State, Primitives, Confidence, Request options, Warnings, Memory, Rules in memory.
- Quality and Batches: labels, calibration, golden sets, many requests at once.
- Patterns and Cookbooks: how to build with it, with measured results.
- API reference, Pricing, Models, Python SDK, JavaScript and TypeScript, Claude and MCP, Agent skill, Jaggedness.