MemoryOS: Why dijin Is Not a Search Engine

Most digital assistants treat your data like a search index. You ask a question, they scan for keywords, return the closest match. dijin takes a fundamentally different approach.

🔑

dijin is not a search engine. It is an Execution Engine — a structured memory system that routes each question to the right resolver before any model runs.

7 active

Resolvers

Languages

4 layers

Tiers

< 2s

Latency

The Problem with Search-Based Memory

When you ask "What was the Q2 budget decision?", a search engine scans for "Q2" and "budget." But what if the budget was mentioned in three different contexts? What if the decision was confirmed in a follow-up?

✗ Search-based tools

✗Return keyword fragments

✗Miss context across sessions

✗No confidence level

✗Same cost for simple + complex

✓ dijin MemoryOS

✓Route to exact resolver

✓Connect context over time

✓Deterministic confidence where possible

✓Simple queries skip expensive tiers

How MemoryOS Works

dijin treats every question as a system call. An Execution Planner classifies your intent and routes it to the right subsystem — only the necessary tiers execute.

Query → Intent → Tier Routing

YOUR QUESTION "When is the board meeting Yuki flagged?"

INTENT CLASSIFICATION temporal │ numeric │ relational │ analytical ✓ │ │ │

EXECUTION PLANNER Intent = temporal → Route to Tier 0 Skip Tier 1, 2, 3 (short-circuit)

TIER 0: DETERMINISTIC RESOLVER Calendar DB → "Tuesday, 10:00" → confidence 1.0

└─────────────────────────────────────────────────┘```

The Four Tiers

Tier	What It Does	Example Query	Data Source	Local model needed?
Tier 0 — Deterministic	Direct database query	"When is the board meeting?"	Calendar, counts, dates	No — 100% confidence
Tier 1 — Claims Graph	Knowledge graph traversal	"Who committed to the deadline?"	Verified facts, relationships	No — graph lookup
Tier 2 — Episodic Search	Hybrid FTS + vector search	"What was the Q2 budget decision?"	Transcript segments, embeddings	Partial — ranking only
Tier 3 — Compacted Memory	Pre-computed summaries	"Summarize the Q2 Marketing Sync"	Daily/topic summaries	Yes — synthesis

The Short-Circuit Principle

💡

If Tier 0 answers your question deterministically, Tiers 1-3 never run. Faster answers, lower battery, zero hallucination risk for factual queries.

Short-Circuit in Action

Question: "How many action items from Q2 Marketing Sync?"

Intent: numeric → Route to Tier 0

Tier 0: COUNT query → ActionItems WHERE session="Q2 Marketing Sync"

Result: 4 action items → confidence: 1.0

Tier 1 │ SKIPPED (not needed) Tier 2 │ SKIPPED (not needed) Tier 3 │ SKIPPED (not needed)

Output: "There are 4 action items from Q2 Marketing Sync."

Cost: 1 SQL query. No embeddings. No LLM reasoning.```

Execution Flow: Step by Step

Intent Classification

Your question is classified: temporal, numeric, relational, identity, analytical, or continuation. Each type has a different resolution strategy.

Execution Planner

The Planner selects which tiers to activate. Simple factual questions go to Tier 0 only. Complex analytical questions may activate Tier 2 + Tier 3 + LLM.

Tier Execution

Selected tiers run in order. Each tier either resolves the question or passes to the next. Short-circuit: if an earlier tier succeeds, later tiers are skipped.

Result Assembly

Structured facts from tiers are merged into a response context. Evidence links point to exact source moments.

LLM Rendering

The LLM formats the structured answer into natural language. It does not reason, interpret, or add information — it is a renderer only.

The 7 Active Resolvers

Resolver	Query Type	Example	Resolution Method
CountResolver	"How many..."	"How many action items from Q2 Marketing Sync?"	COUNT query on ActionItems
DateRangeResolver	"Between X and Y..."	"Meetings last week"	SQL BETWEEN on timestamps
WhenObjectResolver	"When was..."	"When is the board meeting?"	Calendar + ActionItem lookup
WhatResolver	"What did we..."	"What was the Q2 budget decision?"	Keyword → full-text search + Claims
WhoResolver	"Who said/did..."	"Who committed to send the proposal?"	Entity graph + Claims
IdentityResolver	"Who am I..."	"What do you know about me?"	Claims(subject=user)
ParticipantResolver	"Who was in..."	"Who attended the Q2 Marketing Sync?"	Session participants + diar

Why This Matters: The 20-Year Principle

ℹ

LLMs change. Embeddings change. Vector databases change. But dates, counts, and graph relationships are permanent. Deterministic-first design is the only architecture that remains correct as models evolve.

This is not an optimization. It is a design philosophy:

Structured-first — resolve from structured data before searching text

Deterministic-first — exact answers before probabilistic ones

Semantic-second — use semantic search only when structure cannot answer

LLM as renderer — the model formats output, never generates facts