FAQ

Questions we get asked about the design

Most of these are variations on one question: why store the relationships between claims instead of letting the model work them out each time it answers. Here is the reasoning, and where we haven't measured something we say so.

Last updated 2026-09-12
Source of truth docs/ONTOLOGY.md · technical docs

Why this design

Isn't this just RAG with extra steps?

Not quite, and the difference is specific.

Similarity search returns text that resembles your question. A correction rarely resembles the thing it corrects — it's shorter, worded differently, often a footnote on a later document. So the agreeing text outranks the disagreeing text, and a model reading only the top results never learns there was a disagreement. It doesn't fail at reasoning; the counter-evidence never arrived.

Tortoise keeps the source text and additionally indexes the one thing the text cannot contain: the relationships between pieces. “These two conflict.” “This replaced that.” That is a different retrieval signal, not an extra step on the same one.

Why not let the model work out contradictions at query time?

It can only judge what is in front of it. Deciding whether A contradicts B requires having both, and contradictions are the least likely pair to be retrieved together.

That is circular: you need to know the relationships to retrieve the right material, and you need the right material to discover the relationships. Recording a relationship when it is observable is what breaks the circle.

The model still makes every judgment call — what a conflict means, how much weight it deserves, and whether it matters for the question being asked. What it doesn't have to do is remember, on its own, that the conflict exists.

Do you replace my source text with extracted facts?

No, and this is the one we would most want you to hold us to. Your source stays, verbatim and authoritative. Extraction is a revisable index over unrewritten evidence — the source is never rewritten, and claims carry a quoted span of the text they came from. (That quote field is partially implemented today.)

An external study — Fidelity Before Structure: Verbatim Chunks Beat Lossy Artifact Extraction in Long-Conversation LLM Memory (Tao An, arXiv 2601.00821) — held the retriever, reranker, answerer and judge fixed and swapped only the stored representation: verbatim source won by 15.9 points on LoCoMo and 22.0 points on LongMemEval-S, and a one-hop semantic graph did not close the gap. The authors read the result as lossy distillation rather than structure as such: accuracy tracks how much source text survives in the store.

Read that study as the case for keeping the source layer, not as evidence that this graph works — it tested a one-hop semantic graph, not typed-relation propagation or contradiction surfacing. We keep both layers: verbatim source as the evidence layer, the graph as the reasoning layer over it.

What happens when the graph is wrong?

You correct it, and belief recomputes. Nothing is frozen.

If you disagree with a confidence score, you don't argue with the system. You add evidence, and it moves.

Does a contradiction delete the losing belief?

No. Both claims stay in the graph, with the tension recorded. That is the point of keeping a contradiction as a first-class relationship instead of overwriting one side.

A deleted belief leaves no trace of the disagreement, so a later reader sees a confident answer with no idea it was ever contested. A recorded contradiction stays visible, and keeps pulling on the confidence of the claims it connects — on both sides for a mutual contradiction, on the target only for a directed one — until it is genuinely resolved or superseded.

Is a graph slower than vector search?

Two different costs, and it depends on how often you read.

The expensive part of Tortoise is at write time: reading and judging incoming material to extract the relationships. That cost is linear in how much you ingest, and it does not get cheaper per item as you grow.

The read path is the opposite trade. Because the relationships are already recorded, working out a claim's belief needs only its neighbourhood, and the lookup itself is index-backed rather than a scan of the corpus. Retrieval runs in parallel across full-text, vector and structural strategies, against a pre-registered end-to-end target of 300 ms p95. That target has not yet been certified on production-class hardware — measured p95 on a development box has been 345–460 ms — so treat it as the bar we hold ourselves to, not a published result.

So: pay once at write, or re-derive on every read. Which is cheaper depends on how many questions you ask of the same material. Ingest a lot and ask twice, and the precomputation isn't worth it.

How does it scale?

Honestly: the retrieval path has a benchmark harness with scaling arms for larger corpora, but we have not published corpus-scaling curves, and belief propagation at production scale is open work. We'd rather say that than quote a number we haven't earned.

What we can tell you concretely today:

In progress. A published capacity page — graph sizes, memory footprint per tier, and measured scaling behaviour — is being prepared. Until then we are not going to state limits we haven't tested.

How belief works

Is a confidence score a fixed verdict, or does it move?

It moves. Confidence is derived: every claim's score is recomputed from the evidence attached to it, and the stored number is a cache of that computation rather than a ruling.

Add a supporting claim and it rises. Add a contradiction and it falls. Supersede the evidence it rested on and it recomputes without it. Nothing is stamped at write time and frozen.

What does the variance on a confidence score mean?

A confidence score is a distribution, not a single number — so it carries a spread as well as a centre.

A tight spread means the evidence has settled. A wide spread means it has not: either there is very little evidence, or the evidence points both ways. That distinction is why a claim can be flagged as contested rather than handing you a middling score and leaving you to guess which situation you are in.

Contested claims are often the interesting ones. A 0.5 that nobody disputes and a 0.5 that two strong sources are fighting over are different situations, and only one of them deserves your attention. The full treatment is on the docs page.

What is expectation propagation?

It is how the belief score is actually computed, and the reason a score can change after the claim was written. Support and contradiction propagate along the relationships connecting a claim, and its score settles at whatever the surrounding evidence supports.

Unlike a system that assigns each claim a number once, the score here is a distribution that is updated as evidence accumulates around it.

It also means a contradiction is a first-class force rather than a missing record. Silently replacing a contradicted claim looks identical to never having recorded the contradiction — until you need to know why the belief changed. For the mechanism itself, the docs page has the full account.

What happens if extraction misses something?

If a relationship is missed when it is observable, it is gone — no later search recovers it, because the relationship was never inside either document. That is a real loss and the main risk of this approach.

That is why the source text is kept verbatim and authoritative, and why the graph is positioned as an index over the evidence rather than a replacement for it. A missed relationship makes the graph incomplete; it does not make the underlying record wrong, and the raw material is still there to search directly.

How is this different from other memory systems?

One specific thing: propagated confidence — a belief score that moves when the evidence around it moves, rather than a static field written once. The category converged on graph retrieval some time ago, so the graph itself is not the differentiator.

Across the systems we have surveyed: most have some form of graph, two have partial contradiction handling, one has a formal revision theory, and no surveyed agent-memory product propagates credence — the single exception being an alpha, single-maintainer reimplementation that is not a competitor product. The honest reading is that our combination is unoccupied, but the unoccupied area is narrower than it was: one competitor has already taken contradiction plus temporal validity, another took formal revision over a graph, and the reimplementation showed that propagated credence is bolt-on-able rather than out of reach.

We keep a mechanism-named comparison in the public repo — what each system actually does, not what it claims — under an explicit rule that we make no win claims on benchmarks we haven't run. The capability survey behind those counts is product/competition/_analysis.md; the benchmark-by-benchmark numbers are in docs/benchmarks/comparison-systems.md.

Using Tortoise

What does it cost?

Pricing is stated on the product page — metered write operations, with reads free at every tier. Self-hosting is also a real option if you would rather run it yourself than pay per write (see self-hosted): the source is public and the licence is source-available rather than open source, with production use free for organisations at or below the $5M revenue threshold.

We are not going to restate a price here, because a copy of a price is exactly the kind of thing that goes stale without anyone noticing. The product page is the single place it is stated.

Can I export my graph, and what if I stop using it?

Yes, on both paths. Self-hosted, the CLI writes a versioned encrypted export artifact (tortoise export), and the graph lives in your own database anyway. On the hosted service, a team owner can export the graph — every point with its properties, every relationship, and entity nodes, plus the recent event log (the newest 5,000 events within the 30-day window) — as JSON; it is owner-only, rate-limited and audit-logged.

What happens to your data after you stop using the service — retention, deletion, termination — is governed by the Terms of Service and the DPA. Those documents govern that question; this page does not, and will not attempt to.

Who can read my data?

Only authorised personnel operating the service can reach production systems, and access to personal data is limited to what is necessary to operate and support the service — stated in full in the privacy policy, with the contractual terms in the DPA.

The technical controls behind that — encryption in transit and at rest, how API key credentials are stored, what control-plane activity is logged — are on the security page.

We do not restate those documents here, because a summary is precisely the artefact that drifts out of sync with what it summarises.