OncoMate

How it’s built

Knowledge sources: Three sources: the organization’s own completed repairs, a curated treatment knowledge base of 3,067 entries, and an anonymized repair knowledge base shared across organizations.
Indexing unit: Each repair or treatment record is embedded whole, from a fixed template of equipment, fault codes, problem, resolution, and parts. Records are short and self-contained, so splitting them would separate a fault from its fix.
Embeddings and store: OpenAI text-embedding-3-small (1,536 dimensions) stored in Postgres with pgvector, using HNSW and IVFFlat cosine indexes.
Retrieval: Hybrid search combines vector similarity, Postgres full-text ranking, and exact fault-code matches in one weighted score. Results found by more than one method rank higher.
Agent: GPT-4o through the Vercel AI SDK, with 23 typed tools for search, asset history, PMI fault events, and parts inventory, and up to eight tool steps per answer.
Ingestion: Completing a repair embeds it immediately. A nightly pg_cron job sends new repairs to a Supabase Edge Function that extracts a structured, de-identified case and adds it to the shared knowledge base.
Access: The organization is resolved on the server and enforced by Postgres row-level security. The shared knowledge base is reachable only through one database function and holds no organization identifiers.

Troubleshooting workflow

Equipment teams troubleshoot across manuals, fault-code tables, preventive-maintenance records, inventory, and the memory of experienced technicians. An answer depends on the exact machine, its repair history, and the parts currently available.

OncoMate is in production at three organizations. A technician describes the problem in ordinary language. OncoMate identifies the equipment, retrieves relevant fault references and completed repairs, checks preventive-maintenance notes and parts availability, and proposes the next checks. The technician can review the records used to produce the answer.

Machine data

OncoMate parses PMI machine files (XML and WOX) into structured fault events, flow states, and board-temperature histories. These are exact, time-ordered records, so they are queried with SQL tools rather than embedded. Completed work orders flow back into the retrieval layer as soon as the work closes.

The agent combines both kinds of tools in one answer: SQL tools to narrow the machine and check its recent faults, maintenance, and parts stock, and search tools to find how similar faults were fixed before.

Retrieval design

Technicians describe faults in two ways: by symptom (“the beam stops after warm-up”) and by code (“fault 105023”). Vector search handles the first and misses the second, because a fault code has little semantic meaning. Full-text search has the opposite problem. OncoMate runs vector, full-text, and exact fault-code search together and merges them into one score, weighting semantic similarity highest. A result found by more than one method gets an extra boost. Fault codes are also extracted from the question automatically, so a pasted code always triggers an exact lookup.

The system prompt gives the agent a routing order: resolve the named machine first, then search by symptom or by code, then check the organization’s own repair history before the shared knowledge base. Answers cite cases as “Case 1” or “Case 2” instead of database IDs, and contact details are removed from tool results before they reach the model.

Building the shared knowledge base

Raw work orders are noisy. Many say only “done” or “fixed”, and some contain names and phone numbers. Each night, a pg_cron job sends new completed repairs to an Edge Function. For each one, gpt-4o-mini returns a strict JSON case with symptoms, root cause, resolution steps, a quality score, and a decision on whether the case is worth keeping, with personal details removed. Low-value and test records are dropped before any model call.

Accepted cases are embedded and stored with a content hash, so a reprocessed repair does not create a duplicate. The job’s progress marker advances only past repairs that were processed successfully. If the model call fails, the run stops and the same repairs are retried the next night.

Access and failure handling

Every request resolves the user’s organization on the server, and Postgres row-level security keeps each organization’s repair records separate. The shared knowledge base contains no organization identifiers and cannot be queried directly by users.

Each tool returns an error instead of failing the request. The agent is instructed to say what it could not retrieve and never to invent fault codes or procedures. The proposed plan remains decision support for the technician who performs the work.