Core Concepts¶

Five ideas explain almost everything Telha does.

1. World state, not documents¶

Telha stores facts as versioned nodes and relationships in a graph, projected out of your documents and systems. A contract is not a PDF in Telha: it is a set of fact versions (parties, clauses, dates, amounts) each of which knows exactly which bytes of which source document it came from. Documents are evidence; state is the product.

2. Three time axes on every fact¶

Every query can pin any combination. This is what makes questions like "what did we believe about our exposure in March, before the amendment arrived" answerable at all. History is append-only: corrections create new versions, and the superseded belief remains reconstructable at its original transaction time forever. Deleting is a tombstone version, not a removal, so past snapshots stay whole.

3. Provenance to the span¶

Every ingested fact links to spans: exact byte ranges of the exact source version it was extracted from. Provenance survives corrections, powers the trace viewer's click-through from any claim to the underlying text, and gives every answer a deep link back into the source system (behind that system's own login).

4. Confidence, decay, and verified answers¶

Facts carry confidence; relationships weaken over graph distance by a reviewed decay model, and hybrid queries fuse semantic similarity with that decay. When Telha generates an answer (see AI Answers) it plans evidence under a token budget, generates from that plan only, then decomposes the draft into atomic claims and verifies each one against the planned spans. Verdicts are supported, partial, or unsupported, and unsupported claims are flagged or redacted by policy. The whole judgment persists as an immutable trace.

5. When Telha is not sure, it asks¶

Ingestion sometimes meets facts it cannot pin: "effective next quarter", two conflicting dates, an undated scan. Telha applies its best guess at reduced confidence, marks the fact pending, and opens a clarification:

• It derives who to ask from the graph itself (the author, the person named in the fact, the owner), never from a hand-maintained routing table.
• It checks that person may see the underlying text before sending, then delivers a one-tap card in Teams or Slack.
• Answers are recorded append-only as evidence with the responder's verified corporate identity (Entra ID, not a chat display name).
• High-stakes facts require two confirmations (quorum). Disagreements route to a steward; the steward's resolution is itself recorded, and all conflicting answers remain visible.
• Once the policy is satisfied, the fact is corrected bitemporally: the old belief remains queryable at its transaction time, the new interval takes over, and any answer that depended on the pending fact carried an explicit caveat until that moment.

The result: your world state gets more correct every week, with named accountability for every correction.

Tenancy and safety, briefly¶

Every storage key begins with the tenant and workspace prefix by construction: cross-tenant reads are not a policy, they are unrepresentable in the storage API. Classified fields (PII, financials, secrets) are encrypted in the application layer before Telha core ever sees them, bound to their exact record and field. Access is deny-by-default everywhere: roles come from your IdP groups, unmapped users get nothing, and chat identities can never bind evidence without a verified enterprise identity behind them.