Caura's current approved LoCoMo and LongMemEval results, and the rules that keep stale or unsupported numbers out of public copy.
A benchmark result is more than a percentage. It is a denominator, dataset, answering model, judge, configuration, date, code commit, and a path to reproduce or inspect the run. Remove those fields and a precise-looking number becomes hard to evaluate and easy to repeat after it has gone stale.
Caura now publishes those fields in a machine-readable evidence registry. The site vendors that registry from the open-source repository at an immutable commit and derives every current benchmark constant from the vendored JSON.
The LoCoMo methodology and harness are currently in a private repository that requires access, and no full question-level result artifact is published. The registry records this limitation; the LoCoMo run is not currently publicly reproducible.
Caura scored 77.9% (1,199/1,540) under its documented LoCoMo semantic-judge protocol using the retrieval-augmented agentic-v1 pipeline.
Caura answered 461 of 500 LongMemEval_S questions correctly (92.2%) under the benchmark's GPT-4o reference judge.
The same 500 frozen LongMemEval_S answers scored 90.2% (451/500) under the secondary Gemini 3.5 Flash-Lite judge.
On LongMemEval_S, the median compact retrieved context was 22,410 tokens versus a 107,706-token full haystack: 79.2% context-only savings; counting every reader call yields 75.4%.
The wording is intentionally specific. The LoCoMo result is the Caura retrieval-augmented pipeline, not a full-context reader control. The two LongMemEval accuracy values apply different judges to the same frozen answers. The efficiency result names both accounting boundaries so the smaller context-only denominator is not mistaken for total reader usage.
LoCoMo and LongMemEval model one user, one agent, and a long conversation. They are useful tests of retrieval and answering, but they do not measure whether one agent's memory is correctly shared with another, whether tenant boundaries hold, whether a mandatory policy reaches every agent, or whether the audit trail explains a cross-scope read.
Those fleet-shaped properties need scope-correctness tests and workload-specific evaluation. We do not use a single-agent score as evidence for governance, production latency, or deployment scale. Operators should measure those properties in the environment where they matter.
Each claim has a lifecycle: active, withdrawn, or withheld. Only an active claim with approved wording can feed a public benchmark component. Withdrawn and withheld records stay in the full, status-marked JSON registry so history remains auditable. They are not approved for citation or promotional use and are excluded from promotional pages, metadata, structured data, Markdown mirrors, and narrative agent-readable corpora.
CI compares the vendored registry and schema byte-for-byte with the pinned upstream commit. It then scans source and static build output for unsupported claims. Updating a pin requires an explicit upstream commit, so a moving branch cannot silently change the evidence behind a page.
Read the human evidence index, download the JSON registry, or follow the pinned methodology and artifact links from each active record. If a result cannot meet that contract, the deterministic fallback is to withhold it.