# Introduction

Jepela 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. Jepela 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  ──►  Jepela  ──►    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 Jepela 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 Jepela is made of

Jepela runs the Jepela engine, a decision engine with three checkpoints and a language router, on GPUs. 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. Around the engine Jepela has the memory (recall by the state, the subject's names and the question's words; pinned lines; exclusion rules that remove options in code), rules checked in code, the comparison of a decision with and without the memory and how far each line moved it, verified forgetting, warnings, matching for large choices, option orders and windows, quality and calibration from your labels, fine-tuning on your own cases, batches, tenant isolation, keys, metering and credit.

## Next steps

- Getting started and Quick start: a key, a request, a memory.
- Jepela versus Jev: what is the same and what is different.
- State, Primitives, Confidence, Request options, Warnings, Memory, Rules in memory.
- Quality, Fine-tuning and Batches: labels, calibration, golden sets, a model of your own, 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.