Skip to content

Solutions

Telha by function

Every function in the business asks the same underlying question in a different accent: what was true, when, and can you prove it. Finance asks it about exposure at quarter-end. Legal asks it about which clause was in force. Safety asks it about which risks were open. Telha answers all of them the same way: a tritemporal graph resolves state, provenance links every answer back to the exact source bytes, and generation is verified claim-by-claim before it reaches anyone.

Why by function

The engine underneath every page here is identical: one query DSL, one provenance model, one verification loop. What changes by function is the vocabulary (clauses vs. exposures vs. incidents), the sources you connect, and the temporal question that matters most. These pages exist to save you the translation work: concrete questions, concrete queries, and a worked example for the job you actually have.

New here?

If you have not read the core ideas yet, start with Concepts, especially the tritemporal model and provenance to the span. Everything below assumes both.

  • Finance & compliance

    Know what you reported as exposure at quarter-end, and what you knew when you reported it.

    Finance & compliance

  • Legal & contracts

    Ask which version of a clause was in force on a given date, with provenance to the exact text.

    Legal & contracts

  • Safety & operations

    Ask which risks were open, which permits were valid, and on what date, across incidents and inspections.

    Safety & operations

  • Sales

    Ground every deal answer in the CRM state and the emails and documents around it, not a stale export.

    Sales

  • Customer care

    Answer "what did we tell this customer, and when" with a citation, not a guess from a ticket summary.

    Customer care

  • Complaints

    Reconstruct exactly what was known at each step of a complaint, in the order it became known.

    Complaints

What every solution page gives you

  • The state questions the function needs to answer. Concrete, mostly temporal or permission-shaped, phrased the way a practitioner would ask them.
  • What to connect. The sources that feed the function, the shipped connector or ingestion format for each.
  • Example queries. Real query-DSL bodies against /v1/query, including at least one temporal query using atValidTime or atTxTime.
  • A verified answer in practice. A worked question and a grounded, cited answer from /v1/generate.
  • Evidence and permissions. How provenance, RBAC, and field encryption apply to that function's data.
  • Concepts, the seven ideas every solution page assumes.
  • Query language, the DSL used in every example query.
  • Connectors, setup runbooks for Entra ID, SharePoint/OneDrive, Exchange, Slack, and Salesforce.
  • Clarify bot, how Telha asks a person when a fact can't be pinned down.