Confidence & decay¶

Concept 4 of 8

Facts in Telha carry confidence, and relationships weaken the further you travel from the fact you started at. A supplier two hops away through weak relationships should not rank the same as a supplier one direct edge away, and when a query fuses graph structure with semantic similarity, that weakening has to compose with similarity in a way that cannot be gamed by a single strong signal.

Confidence on a fact¶

A fact version can carry a confidence below full certainty for reasons rooted in how it was produced: a best-guess interpretation applied during a clarification while the clarification is still pending, or an extraction the ingesting worker itself was unsure about. Confidence is distinct from decay: confidence describes how sure Telha is about the fact itself; decay describes how much a relationship should count as you traverse away from it.

Decay weakens relationships over distance¶

When a query expands from a root node across the graph, each hop crosses an edge of some type (OWNED_BY, MEMBER_OF, MENTIONS), and each edge type carries a weight. Traveling further multiplies those weights together, so a fact reached through two weak relationships counts for much less than one reached directly. Three defaults matter conceptually, without the formulas:

• A default weight applies to edge types that have not been given a specific weight, so decay is well-defined everywhere without configuring every edge type by hand.
• Per-edge-type weights let you say, for example, that an OWNED_BY edge should carry relationships further than a loose MENTIONS edge, because ownership is a stronger signal of relevance than a passing mention.
• A floor stops expansion once a path's decayed weight becomes negligible, so the graph does not keep traversing into facts that are, for practical purposes, unrelated.

The root of any traversal is always fully weighted; decay only applies as you move away from it.

Hybrid queries fuse similarity with decay¶

A query that combines a semantic (vector) clause with graph expansion is asking two different questions at once: "how similar is this to what I searched for" and "how structurally close is this to where I started." Telha's ranking fuses both into a single score rather than letting either one dominate on its own. The fusion is intentionally built so that a semantically perfect match that is very graph-distant, or a structurally close match with no real semantic relevance, cannot fully compensate for the other factor's absence: both signals have to be present for a result to rank highly.

Two boundary cases are worth knowing conceptually:

• A query with no vector clause has nothing to fuse with, so ranking falls back to decay alone.
• A pure semantic search with no graph expansion has no decay to speak of, so ranking falls back to similarity alone.

Results returned with tracing enabled show both components of the score separately, so you (or an operator debugging a ranking) can see why something ranked where it did, rather than trusting a single opaque number.

flowchart LR
    ROOT["Root: RISK<br/>(weight = 1)"]
    A["1 hop via OWNED_BY<br/>(strong edge type)"]
    B["2 hops via MENTIONS -> MENTIONS<br/>(weak edge type, compounded)"]
    ROOT --> A
    ROOT --> B
    A --> RANK1["Ranks higher:<br/>close + on-topic"]
    B --> RANK2["Ranks lower:<br/>distant, even if similar"]

A reviewed model, not a tuning knob you should fight¶

The decay and fusion formulas are not something each query author reinvents. They went through a dedicated mathematical review before the corresponding code was allowed to land, specifically because getting this wrong in either direction is costly: too little decay and irrelevant, distantly-connected facts pollute every answer; too much and directly relevant facts a few hops away disappear from ranking entirely. The review also settled a boundary case in the fusion formula that would otherwise have quietly inflated weak matches on pure similarity searches.

The practical upshot is that the default weight, the floor, and the balance between similarity and decay are configuration you can tune per deployment or per edge type, but the shape of the formula itself, and the reasoning behind it, is a reviewed, versioned model rather than an implementation detail. When the formula itself changes, results carry a model version so that generated answers and traces from before the change are never silently re-scored under a different model.

Related¶

• World state, not documents - the nodes and edges decay traverses.
• Verified answers - how ranked, decayed evidence becomes a generation plan.
• Architecture › Confidence decay & fusion - the formulas, the floor, and the reviewed boundary conditions.
• Developers › Query language - the vector clause and expand that trigger decay and fusion.