Trust & provenance
Every page carries a quiet trust strip under its title — a read-only line telling you how much to lean on what you're reading. tela never writes these signals into the page; it computes them from data it already keeps (edit history, the activity log, the semantic index) and shows them where you read.
What the signals mean
| Signal | Looks like | What it tells you |
|---|---|---|
| Freshness | Updated 3 months ago (amber when old) | Time since the last edit. Turns to a warning past ~4 months, or past a review cadence the page declares (below). |
| Provenance | by alice · Agent-written · Synced | Who or what last touched it — a person, an AI agent (via MCP), or a file sync. A human edit after an agent flips it back to human. |
| Dispute | 1 may dispute this (red) | Same-space pages that appear to contradict this one. Click it for the conflicting pages and why each was flagged — this is how stale or conflicting docs surface. |
A whole space's disputes are collected under its Health tab, which lists every disputed page alongside likely duplicates and unlinked pages as a maintenance worklist.
[!NOTE] A corroboration count used to sit in this strip. It was removed: the check reads each page's opening, and the openings of related pages tend to restate the same summary — so the number mostly measured "these two pages start alike" while reading as "this page has been verified". Corroboration is still computed and still reaches agents in the
epistemicblock; it is no longer shown as a badge.
Review cadence
To flag a page for review on a schedule, set a review_every_days property (page properties / frontmatter):
review_every_days: 90
Once the page is older than that many days since its last edit, freshness shows "review overdue" in amber. Unset, a page is only flagged at the general ~4-month (120-day) staleness mark.
How corroboration & disputes are computed
A background worker compares each page against its nearest pages in the same space (via the semantic index), one pair at a time, and asks the model whether the two make conflicting claims. The result is cached and read instantly — the analysis never runs while you're reading, and only same-space pages are ever named, so a dispute can't reveal a page you can't access.
A conflict is only raised when it can be checked. The model has to name the shared subject and quote the two conflicting values, and tela then verifies each value actually appears in the page it was quoted from, that the two aren't the same value written differently, that one isn't simply a more precise form of the other, that they're the same kind of thing measured the same way, and that the field isn't one every page carries its own version of (a project code, an object id — those aren't disagreements). Finally the pair is re-checked from the opposite direction and must come back the same. Anything that fails is treated as no conflict rather than shown, so the strip stays quiet unless there's something specific to look at.
It refreshes itself: editing a page re-runs its check, and a periodic sweep re-checks pages whose neighbours changed — so disputes can appear or clear on a page you didn't touch.
Agents get it too
The same trust read goes to agents over MCP: get_page includes an epistemic block — freshness, provenance, corroboration vs. dispute (with the disputing pages). So an agent reading tela gets not just the text but how much to trust it, and can prefer fresh, corroborated, human-reviewed pages over stale or disputed ones. That's what makes tela usable as memory you can trust. See [[Agents & MCP]].
[!IMPORTANT] Corroboration/dispute and the auto-summaries both rely on an LLM + the semantic index. On the managed cloud these are provided; self-hosting, they run once you've configured a chat model + embedder. To keep the per-page corroboration pass off without disabling your LLM, set
TELA_AGREEMENT=0.
Related: [[Search & ask your docs]] · [[Graph view]] · [[Agents & MCP]]