The vocabulary of plan-first search.
The terms that show up across the docs, in one place — from plan-conditioned retrieval to why slorg is not an agent loop.
Plan-conditioned retrieval
Searching the web with keywords derived from a structured plan (a draft answer turned into a knowledge graph) rather than from the raw user prompt. The core idea behind slorg.
Six-step pipeline
The fixed sequence slorg runs on every query: draft answer, knowledge graph, keyword extraction, SearxNG multi-engine search, content fetch, and 0–1 relevance scoring.
Draft answer
Step 1. A first-pass answer GPT writes from its training data alone, before any web access. It seeds the plan the rest of the pipeline builds on.
Knowledge graph
Step 2. Entities and the relationships between them, extracted from the draft answer into a typed graph. slorg uses the graph — not the prompt — to decide what to search for.
Entity / relationship extraction
The process of pulling named things (entities) and how they connect (relationships) out of unstructured text to build the knowledge graph.
Graph-derived keywords
Step 3. Search terms generated from the knowledge-graph nodes rather than from the literal user prompt, so the web query reflects the plan.
SearxNG
A self-hostable metasearch engine. slorg uses it in step 4 to query multiple public engines (Google, Bing, Yahoo, DuckDuckGo by default) behind one interface.
Content extraction
Step 5. Fetching each candidate URL and pulling out its readable page text, so scoring and grounding operate on real content, not just snippets.
Relevance scoring
Step 6. GPT assigns each fetched result a score from 0 to 1 against the original query. Ranking is an explicit, inspectable pass rather than a hidden reranker.
Intermediate artifacts
The draft, graph, keywords, and per-result scores that slorg exposes as first-class fields on the response object, making the whole plan legible.
Agent loop
A pattern where a system chooses actions at runtime based on intermediate state. slorg is deliberately NOT an agent loop — its steps are fixed, which makes behaviour predictable and auditable.
OpenAI-compatible
slorg speaks the OpenAI API shape, so it works with OpenAI or any endpoint exposing the same interface (set via OPENAI_BASE_URL) — including local models and other providers.