Skip to content

When Telha is not sure, it asks

Concept 6 of 8

Ingestion sometimes meets a fact it cannot pin down: "effective next quarter," a signature date and a countersignature date that disagree, a scan with no date at all. Telha does not silently guess and move on. It applies a best guess at reduced confidence, marks the fact pending, and opens a clarification, a routed, governed question to the human best placed to answer it.

Normative spec

This concept is defined by temporal-clarification ("Telha Asks Back"), approved with a responder-assertion condition, and by the Entra identity connector spec for how binding-grade identity is established.

Unpinnable facts get a best guess, marked pending

Ambiguity must never block ingestion. When a worker detects an ambiguous date (a relative phrase, conflicting candidates, an undated document, or a low-confidence extraction), the first candidate interpretation is applied to the fact immediately, at reduced confidence, and the fact version is marked pending clarification. The graph stays queryable the whole time; queries and generated answers that depend on the pending fact simply carry the caveat rather than either blocking or pretending to be certain.

sequenceDiagram
    autonumber
    participant Worker as Ingestion worker
    participant Core as Telha core
    participant Bot as Clarify bot (Teams/Slack)
    participant Person as Best-placed person

    Worker->>Core: ambiguity detected (kind, candidates, confidences)
    Core->>Core: apply best-guess candidate (reduced confidence, pending)
    Core->>Core: open CLARIFICATION node, derive who to ask from the graph
    Core->>Bot: enqueue routed job (ranked candidates)
    Bot->>Bot: RBAC check: may this person see the source span?
    Bot->>Person: one-tap card (dates, origin, "Something else...")
    Person->>Bot: answer
    Bot->>Core: POST /v1/clarifications/:id/answer (verified identity)
    Core->>Core: evaluate quorum, bind if satisfied
    Core->>Core: bitemporal correction (new fact version)

Who to ask comes from the graph, not a routing table

Telha derives the ranked list of people to ask from the graph itself: the source-span author, the person named in the fact, the source-record owner, in that order, with the workspace steward as the only configured fallback. There is no hand-maintained "who owns this kind of document" table to go stale. Because authority is derived live from whatever the graph currently knows (who authored this, who is mentioned in it, who owns it), routing updates automatically as your source systems change, instead of drifting the week after someone new joins.

A permission check happens before anything is sent

A clarification question can contain the actual source span text ("does this say 12 June or 12 July"), so before it is sent to anyone, Telha checks that the recipient has the same read authorization they would need to query that span directly. A candidate who fails that check is skipped, with a machine-readable reason recorded, and routing moves to the next candidate. If nobody in the ranked list passes, the steward gets a redacted question instead, a link to the document, no span text, rather than the question going unanswered or leaking content to someone unauthorized.

Delivery: a one-tap card in Teams or Slack

The clarify bot delivers a one-tap card as a direct message: a short question, buttons for each candidate interpretation labeled with its date and where it came from ("12 June (signature)"), and a free-text "Something else..." option. Free-form answers are normalized into a structured interval before they can bind; an answer that cannot be safely normalized is recorded only as a non-binding attestation, never silently coerced into a date it might not mean.

Answers are evidence, bound to a verified identity

Answering a card is a write, not a chat message. Every answer is recorded append-only as a response record on the clarification, carrying the responder's rights at the moment they answered. Critically, the identity behind that answer is the responder's verified corporate identity from Entra, resolved through the Entra connector, never just a Slack or Teams display name. A chat identity only carries binding authority once it has been matched, with evidence, to a verified enterprise identity; an unverified Slack profile can attach as a delivery alias but cannot bind anything on its own.

Answers only bind through the sanctioned path, too: the answer endpoint enforces that a caller may assert an identity other than their own only if they are the clarify bot's own service token, which has already verified the Teams or Slack callback. Any other caller, including a plain API key, can only answer as themselves, which closes off forging a clarification answer on someone else's behalf.

Quorum for high-stakes facts

Not every clarification binds on a single tap. Severity (low, normal, high, critical) is assigned by tenant policy from the kind of ambiguity detected, and it controls how urgently the question is delivered and how many confirmations it needs:

Severity Behavior
Low Stored pending; not asked.
Normal Asked, batched into a digest.
High Asked directly; the steward is notified.
Critical Asked directly; quorum (multiple confirmations) is required before binding.

A critical fact, a termination date or an obligation, cannot be rebound by one person's single tap. It requires the configured number of independent, binding-capable confirmations before the correction takes effect.

Steward resolution when answers disagree

If two authorized people answer differently, the clarification does not silently pick one, and it does not average them. It moves to a conflicted state and waits for a steward. The steward's resolution is itself recorded as an append-only response, and every conflicting answer that came before it remains visible in the record: nothing is quietly overwritten, and the reviewer that resolves the disagreement is accountable and traceable.

Bitemporal correction on resolve

Once the binding policy is satisfied (quorum met, or no quorum required and an editor-or-above answered), Telha writes a new fact version: the corrected validity interval, confidence restored, and provenance pointing back to the clarification that produced it. The old best-guess belief is not deleted, it remains reconstructable at its original transaction time, exactly the same append-only guarantee that governs every other correction in the tritemporal model. Any answer that depended on the fact while it was pending carried an explicit caveat right up until this moment; after it, answers use the corrected fact with restored confidence.

The result

Your world state gets more correct every week, and every correction carries named, verified accountability for who confirmed it and when.