slorg

Overview

slorg inverts the usual order of operations in search. Conventional retrieval matches a query against an index and ranks what comes back, which works when the user's words resemble the document's words and degrades when the user knows what they want but not what it is called. slorg drafts an answer first, from what the model already knows, and uses retrieval to check and correct that draft.

The pipeline has six fixed steps: draft an answer, extract a knowledge graph from the draft, derive search keywords from the graph, query SearxNG, fetch and extract the results, and score each result between zero and one against the original query. Every intermediate artefact is exposed — the draft, the graph, the keywords, the scored results and the token count — so the reasoning can be inspected rather than trusted.

The important architectural decision is that this is a fixed pipeline and not an agent loop. An agent that decides for itself how many times to search is unpredictable in latency and cost, and hard to debug when it goes wrong, because no two runs take the same path. Six deterministic steps cost the same on every query and fail in the same place when they fail. That predictability is worth more in a search product than the extra flexibility an agent would provide.

Drafting first has a specific benefit and a specific risk. The benefit is that the draft supplies vocabulary the user did not have, which is exactly the failure mode of keyword search. The risk is anchoring: if the draft is confidently wrong, the derived keywords search for confirmation of the wrong thing. Scoring each result against the original query, rather than against the draft, is the partial mitigation, and it is partial.

Where it loses: Algolia, Meilisearch and Typesense return results in single-digit milliseconds and slorg does not. For site search, e-commerce facets, or anywhere the user types a product name and expects an instant list, a fast inverted index is the correct tool and this approach is strictly worse. slorg targets exploratory questions where the user cannot name the thing they are looking for.

It is built on Node with SvelteKit for the interface, chosen because the intermediate artefacts are most useful when they are visible, and a rendered pipeline view is easier to build in a framework designed for it.

Within the portfolio, slorg and polymathy approach retrieval from opposite ends and are easy to confuse. polymathy is infrastructure: it fetches, chunks, embeds and hands back evidence with provenance, and makes no attempt to answer anything. slorg is a search application with an opinion about the order of operations, and it happens to use retrieval as a correction step rather than as a first move. A team building its own answer engine wants the first; a reader who wants a different kind of search wants the second.