Concepts

Everything in Empress follows from treating behavior as a permanent record rather than a log stream. These are the five ideas; each is enforced by the architecture, not by policy.

1. The ledger is immutable

Statements are never rewritten and never deleted. Hygiene — excluding test traffic, filtering noise — happens at query time, by convention, on read. This means your audit trail is a physical property of the store: if a statement landed, it can always be produced again, exactly as it was.

2. Any verb is accepted

Ingestion validates structure (is this a well-formed xAPI statement?), never vocabulary (is “refactored” on our list?). Unknown verbs are stored and become queryable. The intelligence about what verbs mean lives in the analytics layer, where it can improve without ever having rejected data it didn’t yet understand.

3. Tenancy is machine-verified

Your API key scopes every read, export, and analytic to your tenant at the SQL level. This isn’t a promise — a repeatable production test proves isolation in both directions (a probe tenant sees only probe data; the production tenant sees zero probe leakage). That test once caught a real leak, which is exactly why it exists.

4. Derived truths are endpoints

Difficulty, trending, actor stats, percentiles, and rerank orderings are computed by Empress from statements — you read them from /analytics/*, you never rebuild them in your own code. One computation, one source of truth, every consumer sees the same number.

5. Belief is memory with honest decay

GET /belief/:actorId serves an FSRS-based memory model per actor and concept: what this actor knows, how confident the model is, and what’s due for review. It’s computed from real behavior in the ledger — a proficiency record with a paper trail, decaying the way memory actually decays.

---

Next: Tenant integration · API reference · Quickstart