Safety & operations¶
Solution
An incident review, a regulator visit, or a permit renewal all ask the same question in different words: what was the safety state on a specific date, and can you prove it. Search retrieves text; Telha resolves state, so "which risks were open on that date" and "was the permit valid then" are answerable from the graph, not from someone's memory of the spreadsheet.
The state questions safety & operations needs to answer¶
- Which safety risks were open on the date of an incident, before the corrective action that later closed them?
- Which permits were valid on a given date, and who signed them?
- What corrective actions were committed after an inspection, and are they still open or were they closed later?
- What did the inspection report say before a correction was filed against it, and what does the corrected version say now?
- Which incident records have an undated or ambiguous field still pending confirmation?
- Who had access to a sensitive incident record, and did that access follow the same permission floor as the source system?
Why generic RAG breaks here
A vector index over incident reports and permits retrieves the most similar text, not the record that was actually valid on the date being investigated, and it has no native concept of "open" vs. "closed" as of a point in time. Incident reconstruction is inherently a question about state at a moment; Telha answers it directly instead of asking a human to reconcile timestamps by hand.
What to connect¶
| Source | Ingestion path | Shipped connector | Notes |
|---|---|---|---|
| Incident and inspection forms (structured logs, spreadsheets) | csv/xlsx (tabular worker) | SharePoint/OneDrive | Row-level facts, one version per re-upload. |
| Inspection and investigation reports (PDF/DOCX) | pdf/docx (docling worker) | SharePoint/OneDrive | Provenance to the exact finding or corrective-action text. |
| Permit documents and renewals | pdf (docling worker) | SharePoint/OneDrive | Effective and expiry dates become valid-time facts. |
| Site correspondence (safety notices, escalations, sign-offs) | email (email worker) | Exchange | Sign-off threads become provenance for closures and approvals. |
Example queries¶
{
"find": "RISK",
"where": {
"severity": { "$gte": 6 },
"status": { "$eq": "open" }
},
"limit": 100
}
{
"find": "RISK",
"where": { "site": { "$eq": "plant-4" } },
"atValidTime": "2026-03-14T00:00:00Z"
}
plant-4 on March 14, 2026, the date the incident occurred, regardless of when each risk was later closed or reopened. {
"find": "PERMIT",
"where": { "permitType": { "$eq": "confined-space" }, "site": { "$eq": "plant-4" } },
"atValidTime": "2026-03-14T00:00:00Z",
"atTxTime": "2026-03-10T00:00:00Z"
}
{
"find": "CORRECTIVE_ACTION",
"where": {
"$or": [
{ "status": { "$eq": "open" } },
{ "status": { "$eq": "overdue" } }
]
},
"expand": [{ "type": "OWNED_BY", "direction": "out", "depth": 1 }],
"limit": 200
}
A verified answer in practice¶
Q: Were there any open safety risks at Plant 4 on March 14, and was the confined-space permit valid that day?
{
"question": "Were there any open safety risks at Plant 4 on March 14, and was the confined-space permit valid that day?",
"query": {
"find": "RISK",
"where": { "site": { "$eq": "plant-4" } },
"atValidTime": "2026-03-14T00:00:00Z"
},
"semanticModel": "text-embedding-3-small",
"expandDepth": 1
}
Telha: On March 14, Plant 4 had one open risk on record, a ventilation fault flagged as severity 7 on March 9 and not yet closed [S1]. The confined-space permit for that area was valid through March 20, signed by the site safety officer on February 28 [S2]. A renewal extending it to September was recorded, but not until March 10, after the incident date [S3].
[S1]
plant4-risk-log.xlsx, row 112 [S2]permit-confined-space-plant4.pdf, signature block [S3]permit-renewal-notice@2026-03-10.eml
Each claim, the open risk, the permit's original validity window, the later renewal date, is checked against its own cited span; a claim that quietly substituted the renewed expiry date for the one in force on March 14 would be scored unsupported. See Verified answers.
Ambiguous or undated records
Incident forms filled out by hand often carry a relative date ("effective next shift") or no date at all. Telha applies a best-guess interpretation at reduced confidence and opens a clarification, routed to the report's author or the site owner from the graph, rather than guessing silently. Any answer touching that record carries a caveat until it's confirmed.
Evidence and permissions¶
- Provenance to the exact finding. Every citation in an incident answer resolves to the byte span of the actual form field or report paragraph it came from, not "this report" in general. See Provenance to the span.
- RBAC for sensitive incident data. Incident records often carry personal and medical details; access follows deny-by-default RBAC from your identity provider's groups, so a role with no explicit mapping sees nothing. See Tenancy & security.
- Field-level encryption. Personal details inside an incident record (names of injured parties, medical specifics) can be declared classified fields and are encrypted in the app layer before core ever stores them; core holds only opaque ciphertext.
- Clarifications respect the same permission floor. Before a clarification question is sent to anyone, Telha checks that the recipient has the same read authorization they'd need to query the underlying span directly; a candidate who fails that check is skipped, not shown a redacted version of sensitive content by accident. See Clarifications.