Mykola Vorobiov

Case study · 2026 to Present

Turning a research team's expertise into computable knowledge.

A research team held deep expertise that existed only in their heads and their papers.

The work made that expertise computable, so they could query it themselves.

Problem

The problem: deep expertise, no pipeline.

The expertise was the requirement, and nobody had ever written it down.

Conventional project shapes assume a customer who can write the requirements. Here the expertise itself was the requirement, and the structure nobody had written down was the input that software would have to read.

Insight

The insight: the hidden process is the expertise itself.

For the other four systems, the hidden process is a business workflow: how to find a lead, how to work a prospect, how to manage a deal, how to pick a meeting slot. Here, the hidden process is the expertise itself, the knowledge in their heads, in their papers, in their mental models. The extraction method is identical to every other system; only the output changes, a knowledge graph in place of a queue architecture. The pattern pushed to its purest form: this is the strongest available proof that the method is not domain-bound.

Built

What was built: a corpus, turned into a graph you can question.

Schematic — shape only
papers+ internal docs parse / chunk extract entities+ relations knowledge graph query layer researchers agents

The pipeline turns a body of documents into a queryable knowledge graph, with a query interface on top of it. One constraint shaped everything: every answer has to be traceable to the source it came from, so the result is checkable rather than merely fluent.

Platform

The other half: the platform the graph is served from.

The extraction pipeline is one workstream. The other is the platform underneath it: a Kubernetes-native system that holds the graph as RDF triples in Apache Jena Fuseki alongside vector embeddings in Milvus, and serves both behind a SPARQL API and a hybrid semantic-search endpoint. A knowledge-graph domain is one configuration file plus one plugin image; it deploys as its own isolated namespace and moves through build, deploy, ingest, verify and an atomic blue/green publish, with rollback and clean-up on the same path.

The point of building it was to retire a hand-operated deployment. SSH sessions into boxes, resizing instances between ingest and serving, hand-edited security groups and ad-hoc secret plumbing were replaced by scripted recipes, a token-authenticated control-plane API with a CLI, and charts proven in CI, with the cloud footprint provisioned and versioned in Terraform. Operators and tenant developers never touch the cluster, which is the same move as everywhere else in the portfolio: absorb the variation underneath a stable interface.

Depth

The engineering depth that makes it real.

The position the work takes is that an LLM-only extraction pipeline cannot meet a research bar. If an output cannot be traced back to the source it claims, it does not ship. Wrong extractions are findable by construction, because there is no untraceable output.

Automated testing, containerised deployment and CI as the gate came into a research codebase alongside the pipeline, and cut release cycles from weeks to days.

One engineer carried all of it. Sole technical owner, embedded as the only engineer in a team of 15, with full lifecycle ownership while the scientists focus purely on their domain.

Outcome

The outcome: researchers producing knowledge graphs themselves.

Within days of the pipeline existing, the researchers were producing knowledge graphs themselves, the fastest time-to-value in the portfolio. That is the whole shift: bring automated testing and containerised deployment into a research codebase, and the researchers stop being blocked by the platform and start being blocked by their own questions. Delivery was accepted by the team's own domain expert.

A knowledge pipeline and the Kubernetes-native platform that serves it, built around a research team's own expertise, 2026 to Present, turning domain knowledge that existed only in people's heads into something they could query themselves. Sole technical owner, the only engineer in a team of 15. The hidden process here is the expertise itself, and the engineer's job is to make it computable.

Talk it through.

The rest of the work sits on the Work page. Prefer to write first? Mail goes directly to [email protected].