Kainora gives retrieval more paths to evidence with a knowledge graph

Kainora connects business applications with organizational knowledge. Finding a relevant passage is only part of the problem: it also needs to know which entity the passage concerns, what it relates to and which evidence supports it. ArcadeDB holds those connections, and the team runs it in Docker and Kubernetes.

About Kainora

Kainora brings together management thinking, capability architecture, and governed enterprise intelligence. This case study focuses on its development and pilot work using ArcadeDB to connect knowledge with entities, relationships, and supporting evidence. Oleg Cohen, Founder, Kainora, is the author of Managing After Intelligence.

The challenge

Finding a relevant passage is only part of the challenge. Kainora also needs to understand which entity a passage concerns, what it relates to and which evidence supports it. When those connections are missing, answers risk being incomplete, and people are left to do the contextual work by hand.

Consider a question such as “What evidence supports Product X for Use Y, and what limitations apply?” Text similarity might return a product description or an isolated study passage. A graph can tie together the product, its uses, the supporting studies, the limitations and the source passages, which gives retrieval additional paths to the relevant evidence.

This example illustrates the intended behavior. Kainora has not measured it as a before-and-after comparison.

Why ArcadeDB

Oleg Cohen evaluated Neo4j, OrientDB, JanusGraph, ArangoDB and HugeGraph. Exploring OrientDB is how he discovered ArcadeDB, and he liked it immediately. ArcadeDB fits Kainora's Java-based architecture, including embedded graph storage and SQL and Cypher access, which suit its development environment.

ArangoDB's licensing change and aspects of its high-availability features put him off. ArcadeDB became his preferred choice. This is Oleg's own experience and preference, not a benchmark comparison.

How Kainora uses ArcadeDB

In Spectra Nexus, Kainora's retrieval component, document processing extracts entities, relationships and references to source passages into ArcadeDB. At query time Nexus combines graph retrieval with OpenSearch keyword search and Milvus vector search, then merges and ranks the evidence before answer generation.

The graph queries use SQL and Cypher, including traversal through shared entities to find related passages across documents. Embeddings are handled in the complementary vector layer.

“Graph structure is useful only when the connections are trustworthy.”

Oleg Cohen, Founder, Kainora

How Kainora runs it

Kainora's development configurations include a graph embedded in the Java application and a separate Docker-based ArcadeDB appliance. The team runs ArcadeDB in Docker and Kubernetes and keeps up with the latest releases.

Giving back to ArcadeDB

Kainora is also a contributor. Oleg Cohen contributed the initial gRPC implementation to ArcadeDB.

Lessons for other teams

Oleg's advice for a team starting with ArcadeDB as a knowledge-graph layer:

• Define entity identity, relationship meaning and source provenance early. Graph structure is useful only when the connections are trustworthy.
• Keep graph retrieval complementary to keyword and vector retrieval, and inspect which evidence each one contributes.
• Maintain a small, repeatable question set, so that added graph complexity can be judged against actual retrieval improvements.

What comes next

Kainora has not yet published latency, accuracy or cost figures. A useful evaluation would run the same questions over the same corpus with and without graph enrichment, and measure evidence coverage, answer correctness and latency.