Kairos

Kairos turns a plant's scattered maintenance records into cited answers, early warnings and pre-job briefs, so teams decide on evidence instead of memory.

Comment

Inspiration

A technician is assigned to a seal failure on a pump. The same pump has failed this way four times in eight years. The vendor changed the seal specification eighteen months ago. Six months ago, a colleague recorded a voice note about unusual vibration that nobody followed up. The technician knows none of this, because it sits in a maintenance system, a document archive, a vendor portal and one person's memory. So the wrong part gets fitted, and the pump fails a fifth time.

Nothing in that story is a technology failure. The plant already had every answer. It could not deliver any of them to the person doing the job, at the moment of the job.

The numbers behind that story are public:

  • People spend around 20% of the working week looking for internal information or for a colleague who has it (McKinsey Global Institute).
  • 69% of industrial businesses worldwide have an unplanned outage at least once a month, and in India it is 88% (ABB Value of Reliability survey, 2023).
  • An hour of unplanned downtime costs a typical industrial business about ₹1.03 crore globally, and about ₹70 lakh in India (same survey).
  • Two in three new energy-sector hires to 2035 will be needed just to replace people who retire (IEA, World Energy Employment 2025). What they never wrote down leaves with them.

Most "chat with your documents" tools make this worse in an industrial setting, because a confident wrong answer about a pressure limit or an isolation step can injure someone. We wanted to build the opposite: a system that turns a plant's own data into decisions, shows where every claim came from, and refuses when it does not know.

Who it is for

  • Field workers and operators, who need to know what matters before they start a job.
  • Maintenance and reliability engineers, who decide whether to repair, replace or investigate.
  • Compliance leads, who must show evidence for every clause that applies to every asset.
  • Plant managers, who need to see where the organisation's knowledge is thin before it costs them.

What it does

Kairos reads a plant's documents, maintenance history and live events into one governed body of knowledge, then delivers it as answers, briefs, warnings and evidence.

One work order, end to end

  1. The trigger. A work order is raised on a pump. Nobody searches for anything. Kairos sees the event and starts gathering what the person doing the job needs.
  2. What it finds. The failure history, the part number that changed, the open warning from a colleague.
  3. The check. Each fact is ranked by who said it. A regulation outranks a vendor manual, and a vendor manual outranks a local note. The vibration note was never verified, so it is labelled unverified, not mixed in with established fact.
  4. The delivery. One screen on a phone shows the history, the changed part, the warning and a link to every source document. The technician reads it before touching the pump.
  5. The refusal. If the technician asks a safety-critical question and no authoritative source supports an answer, Kairos refuses and hands over the documents instead.

The full set of capabilities

  • Expert copilot. Plain-language questions, answered with sources, an authority badge and a confidence level on every claim. It can answer as of a past date, because facts are stored with the period they were valid.
  • Proactive briefs. Written when a work order, alarm or permit arrives. Capped at six per operator per hour so people keep reading them, with safety permits always exempt. A permit-to-work brief needs two different people to sign it.
  • Cross-site pattern alerts. The same failure on the same class of equipment at more than one site, or recurring at one site while a sister site runs that equipment. Only counts and failure codes cross a site boundary, never names or free text.
  • Root-cause packs. Hypotheses ranked by how much evidence supports them, on a timeline, each traceable to its documents.
  • Compliance mapping. A clause-by-asset grid showing which required evidence is missing, with an audit pack assembled from the sources.
  • Knowledge coverage. Per asset: how many facts, how many from authoritative sources, how many verified by a human. It shows managers where the plant is blind.
  • Knowledge capture. Voice notes from the field, structured interviews with experts who are leaving, and form or checklist extraction. All of it lands in a review queue first.
  • Governance. Conflict detection between sources, management-of-change approval before a high-authority document can be replaced, and a full audit trail.
  • Works where the work is. An installable mobile app that keeps working offline and syncs when the connection returns, with a high-contrast mode for sunlight.

How we built it

Kairos is not a wrapper around a language model. The model is the last step of a pipeline whose job is to make sure it only speaks from governed evidence.

What happens to a document

  1. Ingestion. PDFs, scans, engineering drawings, spreadsheets, forms, voice recordings and live plant events enter through a durable Temporal workflow, so a failed step retries without losing the document.
  2. Reading. Scans go through an OCR model, drawings are read for their layout, tables in forms are parsed cell by cell, and audio is transcribed.
  3. Extraction. A vision-language model pulls out entities such as asset tags, people and organisations, and the relationships between them.
  4. The quarantine gate. Anything extracted with confidence below 0.7 is held for a human reviewer. Promotion is a human decision. There is no automatic promotion anywhere in the system.
  5. The knowledge graph. Accepted facts become edges in a Neo4j graph. Every edge carries six things: when it became true, when it stopped being true, its authority level, its source document, its confidence and its verification status. Nothing is ever deleted. A replaced fact is closed with an end date, which is what makes "what was true last March?" answerable.
  6. Indexing. The same content is embedded into Qdrant for meaning-based search and indexed in Elasticsearch for exact matches such as tag numbers.

What happens to a question

  1. Hybrid retrieval. Vector search, exact search and graph traversal run together and are fused into one ranking.
  2. Authority ordering. The most relevant evidence is kept, then ordered so a regulation comes before a site note.
  3. The safety gate, first pass. If the question is safety-critical, the evidence must be relevant, about the same asset, and either high-confidence or from an authoritative source. Otherwise the answer is a refusal.
  4. Synthesis. A large language model writes the answer strictly from the retrieved evidence, citing each source.
  5. The safety gate, second pass. The finished answer is checked again before anyone sees it.

The server always retrieves its own evidence and classifies the question itself. A client cannot hand it fake context to talk its way past the gate.

Where AI is used, and where it is deliberately not

Task Approach
Answer and brief writing NVIDIA Nemotron via NIM, with a cascade of fallback providers
Entity and relationship extraction Llama 3.2 Vision via NIM
Document OCR NVIDIA Nemotron OCR
Speech to text Whisper large-v3 via Groq
Semantic search Jina v3 embeddings in Qdrant
Cross-site patterns, compliance gaps, conflict detection No model. Deterministic logic over the graph, so the result is explainable and repeatable
Promotion of knowledge to trusted status No model. A human reviewer, always
Grading the benchmark No model. Deterministic checks, never one model judging another

The rest of the stack

FastAPI for the core API, Celery workers across six queues, a Go service for plant system connectors, Redis, Supabase for auth, storage and Postgres, Open Policy Agent for access control that fails closed, OpenTelemetry into Grafana for observability, and a Next.js and Tailwind front end. The backend runs on AWS EC2 and the front end on Vercel.

Challenges we ran into

  • A safety gate that could be fooled. An early version let any high-authority document clear the gate, even one about a different asset. We also found that filtering "the top results" did nothing, because the list was sorted by authority, not relevance. Now only relevant, same-asset evidence can clear the gate, ranked by relevance score.
  • Authority ranking buried the right answer. Sorting by authority before cutting the list pushed the single most useful document out of the window, and the copilot said "no failure history" for a pump with four recorded failures. The fix keeps the most relevant documents first and applies authority order afterwards. Retrieval stayed at 46 of 46 before and after.
  • What counts as a contradiction. Two documents that both mention the same person do not disagree. We had to separate edges that make a claim from edges that only record provenance, or the conflict queue filled with noise that would train reviewers to click through it.
  • Measuring without flattering ourselves. A refusal counts as correct, so a gate that refuses too much would quietly raise the score. We audited every refusal by hand. A run is also marked suspect if a fallback model answered more than a tenth of the questions, even when the score looks good.
  • A public demo that cannot touch real data. The one-click demo works a separate showcase plant that shares the same databases and is kept apart by markers. A registry test fails the build if any query forgets the boundary.
  • A model retired mid-project. The provider withdrew our synthesis model. We rebuilt the provider cascade around a new one and re-ran the whole benchmark before trusting it.

Accomplishments that we're proud of

  • Answer quality: 43 of 46 (93.5%) on a golden question set, graded deterministically. Six of those are correct refusals. The three misses are published with their question numbers.
  • Provenance: 46 of 46. Every answer that is not a refusal cites its sources.
  • Retrieval: 46 of 46. The correct source surfaces for every question.
  • Compliance gap detection: precision 1.000, recall 0.838. Zero false positives against an independently derived truth table.
  • Entity extraction: F1 0.805 on a labelled set.
  • Speed: a synthesised answer in a median of 5.5 seconds.
  • 969 backend tests that run with no network and no model call, and 374 front-end tests.
  • A live system, not a mock-up. Every screen shows real data, a loading state or an honest error. There are no fixtures to fall back on.
  • We publish what did not work too. One benchmark came back with a null result and is reported as one.

What we learned

  • In a high-stakes business, trust is the product. Showing sources and refusing well mattered more to usefulness than answering more questions.
  • Retrieval and governance decide quality far more than the choice of model. Our biggest gains came from fixing ranking and gating, not from changing models.
  • A human gate is a feature. People trust a system that visibly separates what has been verified from what has not.
  • Some problems should not be given to a model. Pattern detection across sites and compliance gaps are better as plain, explainable logic.
  • Too many alerts is the same as none. The six-per-hour cap on briefs came from how control rooms manage alarm overload.
  • Honest empty states beat impressive fake ones. A page that says "your account covers one site, so there is nothing to compare" earns more trust than an invented alert.

What's next for Kairos

  • Handwritten and scanned forms, read with a vision model, still routed through the review queue.
  • Live plant connections to a real historian and maintenance system. The connector service is built and waiting for an endpoint.
  • Failure forecasting on top of the pattern history, once there is enough verified data to do it honestly.
  • A pilot with a real maintenance team, measuring time saved per job and repeat failures avoided.
  • The same approach in other asset-heavy sectors, such as utilities, rail and hospitals, where the knowledge problem is the same.

Built With

Share this project:

Updates

Submission history