Knowledge Navigation
This is the capability that separates ORQO from every other agent platform. Standard RAG gives you similarity search — you ask a question, you get the most similar text chunks back. ORQO's Knowledge Engine gives your agents structured navigation through knowledge, following typed semantic paths just as a human learner would.
The Problem with Flat Retrieval
Consider a standard RAG pipeline. An agent asks: "What is a load balancer?" The system returns the three most similar chunks. The agent reads them and responds.
Now the user asks: "Why do we need one?" The system runs a completely new similarity search. There's no connection between the two queries. No depth. No continuity. Each question starts from scratch.
This is the fundamental limitation: flat retrieval has no concept of navigation. It can't go deeper into a topic, step back to see the bigger picture, follow a causal chain, or trace a learning sequence. Every query is an independent similarity lookup.
The Relation Similarity Cannot See
The difference between a similarity graph (Obsidian, an LLM-authored wiki, vector search) and a typed-relation graph is felt most sharply on a connection between two topics that are genuinely related but share almost no words.
Topic A — "Wolves hunt elk in the valley." Topic B — "The river meanders less and its banks stop eroding."
To an AI's similarity model these are about as far apart as two texts get — one is predators and prey, the other is hydrology and soil; their word-overlap is near zero. Yet they are tightly related, by the famous trophic cascade: wolves thin the elk → elk stop over-browsing willow and aspen → vegetation and beavers return → roots and dams stabilize the banks → the river meanders less. How wolves change rivers.
- Vector search / RAG asks "what looks like the wolves text?" and returns more wolf-and-elk passages. It will never surface the river text from a wolf query (or the reverse) — there is no lexical or semantic bridge to follow.
- An Obsidian or LLM-authored wiki can connect A and B only if some document already states the link — a human wrote
[[…]], or the ingesting AI happened to write a sentence joining them. The connection is document-inherent: if no single source spells out the whole chain, there is no backlink to follow, and the model must re-scrape and re-reason the corpus to rediscover it each time. - ORQO's Long-Term Memory stores the chain as typed, directed edges —
Wolves hunt elk —causes→ Elk browse less willow —causes→ Beaver dams return —causes→ Banks stabilize —causes→ River meanders less. From the wolves node an agent navigatesconsequencesand arrives at the river node in a few deterministic hops — no scraping, no re-reasoning, whether or not any single document ever stated the connection.
That is the whole point in miniature: the value is in the edges, not the similarity. Causal, foundational and means–end relations routinely bridge distant-seeming ideas — prime numbers are the basis for online-payment security; a missed consent checkbox causes a regulatory finding. A graph built from similarity (or from links that had to be authored into the source) cannot represent these; a graph built from typed relations treats them as first-class, navigable structure.
Ontology-Aware Navigation
ORQO's Knowledge Engine stores content as a typed graph. Every knowledge unit has a classification (what kind of knowledge it is) and is connected to other units through typed relations (how they relate). This structure enables navigation.
When an agent finds a knowledge unit, it doesn't just get text — it gets a navigation map: a set of directions it can follow to explore related knowledge.
The 11 Navigation Directions
| Direction | What the agent is asking | Relations followed |
|---|---|---|
| deeper | "Tell me more detail" | Specializes, PartOf, ComponentOf, SubProcessOf, AspectOf |
| broader | "What's the bigger picture?" | Generalizes, WholeOf, ComponentWholeOf, ParentProcessOf |
| why | "Why is this the case?" | EffectOf, UnderpinnedBy, DeterminedBy |
| consequences | "What follows from this?" | CauseOf, BasisFor, Determines |
| context | "What surrounds this?" | ContextOf, ContextualizedBy |
| related | "What's connected?" | Similar, Alternative, Analogous, Complementary, Affine |
| next | "What comes after?" | DidacticallyBefore, TimelineBefore |
| previous | "What came before?" | DidacticallyAfter, TimelineAfter |
| examples | "Show me a concrete case" | Knowledge units typed as Example |
| how | "How do I do this?" | Knowledge units in the Action class |
| sources | "Where can I read more?" | Knowledge units in the Reference class |
How It Works in Practice
An agent queries the Knowledge Engine and finds a unit about "database indexing" classified as Explanation:What:Description. The navigation map shows:
The agent can now traverse this map — following "deeper" to understand B-tree internals, or "how" to get the actual PostgreSQL commands, or "why" to understand the theoretical basis. Each step is a typed graph traversal, not a new similarity search.
Query Modes
Agents interact with the Knowledge Engine through three query modes:
Search Mode
Entry point discovery. The agent provides a natural-language query, and the Knowledge Engine returns the most relevant knowledge units via embedding similarity — similar to RAG, but each result includes a navigation preview showing available directions.
Agent: search("database performance")
→ Returns: top-5 units with titles, types, and navigation previews
Navigate Mode
Structured traversal. The agent has a specific knowledge unit and wants to follow a direction. This is pure graph traversal — no similarity search involved.
Agent: navigate(node_id=42, direction="deeper")
→ Returns: all units connected via Specializes, PartOf, etc.
Inspect Mode
Full context. The agent requests the complete navigation map for a specific unit — all available directions and their targets.
Agent: inspect(node_id=42)
→ Returns: the unit's full content + navigation map in all 11 directions
Concept Containers
Knowledge units are organized into concept containers — topic-level groupings that provide semantic scope. When you upload a document about "PostgreSQL performance tuning", all classified units are linked to a "PostgreSQL Performance" concept container via BelongsTo relations.
Containers can form hierarchies: "PostgreSQL Performance" might be a component of "PostgreSQL", which is a component of "Databases". This hierarchy enables scoped navigation — an agent can search within a specific domain or traverse the full graph.
Why This Is a Differentiator
The ontology was validated in production through a funded research project. That project demonstrated a remarkable finding: using just four relation types, multiple distinct learning paths emerged from a single knowledge domain — without any manual path authoring. The structure of the typed relations was sufficient to generate meaningful navigation.
ORQO implements the full taxonomy of 48 relation types. This means your agents can explore knowledge in ways that are simply impossible with flat retrieval:
- Follow causal chains — from root cause through consequences to implications
- Navigate abstraction levels — from overview down to implementation detail and back
- Trace learning sequences — content that builds on prerequisites, in order
- Discover alternatives — related approaches, contrasting views, complementary techniques
- Find practical guidance — from theory to procedure to example
This isn't a feature. It's a fundamentally different approach to how AI agents interact with knowledge.