Architecture

Six fixed steps. No agent loop.

slorg does not decide whether to search, and it does not pick tools at runtime. The pipeline is identical on every query. What it buys is plan-conditioned retrieval and full visibility into every intermediate artifact.

The pipeline

Draft → graph → keywords → search → fetch → score

Step 1 Draft answer GPT writes a first-pass answer from training data alone. No web access yet. LLM round-trip #1.

Step 2 Knowledge graph Entities and relationships are extracted from the draft into a typed graph.

Step 3 Keyword extraction Search terms are derived from the graph nodes, not the raw prompt. LLM round-trip #2.

Step 4 Multi-engine search SearxNG queries Google, Bing, Yahoo, DuckDuckGo with the graph-derived keywords.

Step 5 Content fetch Each candidate URL is fetched and its readable content extracted.

Step 6 Relevance scoring GPT scores each result 0–1 against the original query. LLM round-trip #3.

  user query
      │
      ▼
  ┌─ 1 ─ draft answer ───────────┐   LLM (from training data, no web)
  │        │                     │
  │        ▼                     │
  ├─ 2 ─ extract knowledge graph │   entities + relationships
  │        │                     │
  │        ▼                     │
  ├─ 3 ─ derive keywords ────────┤   LLM (from graph, not prompt)
  │        │                     │
  │        ▼                     │
  ├─ 4 ─ SearxNG multi-engine ───┤   Google · Bing · Yahoo · DuckDuckGo
  │        │                     │
  │        ▼                     │
  ├─ 5 ─ fetch + extract content ┤   per candidate URL
  │        │                     │
  │        ▼                     │
  └─ 6 ─ score results 0–1 ──────┘   LLM (against original query)
      │
      ▼
  { answer, knowledgeGraph, keywords, results[], tokenCount }

Why plan-first

Spend the first round-trip on the model, not on Google.

The dominant AI-search pattern throws the raw user prompt at a search engine and wraps whatever comes back in an LLM summary. slorg inverts the order: it drafts an answer first, turns that draft into a knowledge graph, and derives the search keywords from the graph. The web query is therefore conditioned on a structured plan rather than on the literal phrasing of the question.

Three LLM round-trips

Steps 1, 3, and 6 each call the model once. That is the latency cost slorg pays for a visible plan — roughly 5–15 seconds wall-clock on the default configuration.

One content-fetch sweep

Step 5 fetches and extracts each candidate URL returned by SearxNG. This is the other half of the time budget, and it scales with the result limit.

Why it is not an agent

An agent chooses actions at runtime: it might search, might not, might call one tool or another depending on intermediate state. That flexibility makes behaviour hard to predict and hard to audit. slorg deliberately gives that up. Because the six steps are fixed, the failure modes are enumerable and every run produces the same set of inspectable artifacts. The trade is intentional: less adaptivity, far more legibility.

honest caveat Plan-conditioned does not mean correct. If the step-1 draft is wrong about the topic, the graph and keywords inherit that error and the retrieved set is wrong in a correlated way. slorg makes the plan visible so you can catch this — it does not prevent it.

The canonical reference is the architecture overview in the docs. See the terms used here in the glossary.