Knowledge bases

The three knowledge surfaces in Scrydon — conversation knowledge, workspace knowledge bases, and the governed organization KB — when to use which, why they differ, and how we benchmark retrieval quality against the market.

Scrydon ships more than one kind of knowledge base on purpose. Enterprise knowledge has different lifecycles — a file you drop into a chat, the living documentation of a team's workspace, and the compliance-governed facts your whole organization relies on are not the same thing, and pretending they are is how knowledge platforms end up with either no governance or no usability. This page explains the surfaces, when to use which, and how we measure retrieval quality.

The three knowledge surfaces

	Conversation knowledge	Workspace knowledge bases	Organization KB (governed)
What it is	Files attached to a Chat conversation, indexed automatically.	Named KBs you create in a workspace — documents, transcripts, pasted content.	Typed, compliance-governed organizational knowledge with access markings and a review lifecycle.
Scope	One conversation.	One workspace (shareable per access policy).	The whole organization.
Lifecycle	Deleted with the conversation.	Managed by you — add, update, remove.	Content enters through promotion and review; changes are audited; retirement is governed.
Governance	None needed — private by construction.	Clearance levels per page, secrets scanning at ingest.	Full: access markings, clearance, governed retrieval, audit bundles.
Set up by	Nobody — attach a file and it exists.	Workspace members, via the UI or Chat.	Org admins and pack authors, via the Authoring SDK.

When to use which

You're answering a question right now — attach the file to the conversation. The conversation-private KB needs zero setup and leaks nowhere. See Chat → Knowledge bases.
A team works against the same material every week — project documents, runbooks, meeting transcripts, a product's support history — create a workspace knowledge base. Workflows, agents, and Chat can all query it, and clearance levels keep sensitive pages from users who shouldn't see them.
The whole organization must agree on it — customer entities, policy facts, vetted institutional learnings — it belongs in the organization KB. Content is promoted into it through review, carries access markings, and every read is governed. If you need to ship knowledge with a pack, this is also the surface packs install into.

A common pattern uses all three: a conversation surfaces something worth keeping → it lands in a workspace KB → after review, the durable facts are promoted to the organization KB. Promotion is a built-in flow, not a copy-paste exercise.

Two retrieval engines, and why

Workspace knowledge bases offer two engines at creation time:

	RAG	Memex
How it retrieves	Vector similarity — your documents are embedded and queries match by semantic closeness.	Deterministic multi-signal text retrieval — exact and language-aware matching, citation-link following, and statistical ranking. No embeddings.
Model dependency	Requires an embedding integration; results shift if the embedding model changes.	None. No model calls at ingest, no model calls at query time. Same query, same corpus → same result, every time.
Best at	Fuzzy semantic recall — "find things about this idea" when wording differs completely.	Enterprise material — documents, chat logs, PRs, meeting notes — where names, identifiers, and citations carry the signal.
Audit story	Similarity scores are model-dependent and hard to explain to a reviewer.	Every result is explainable from the corpus alone — why a page ranked is inspectable, reproducible, and reviewable.
Infrastructure	pgvector + an embedding provider.	PostgreSQL only. CPU-only, no GPU, air-gap friendly.

Memex is the same design stance as the rest of the platform — see Why deterministic. LLMs are used where language is the bottleneck (answer synthesis when you ask a KB a question), not for deciding what gets stored or what gets retrieved. That keeps ingest free (index a million documents without a single model call), keeps retrieval reproducible, and keeps the whole path runnable in an air-gapped cluster.

Which engine should I pick? Default to Memex for enterprise document collections — it is the engine we benchmark, it needs no embedding integration, and its results are auditable. Pick RAG when your queries genuinely won't share vocabulary with your documents and you have an embedding integration installed.

How we benchmark — and how we score against the market

Retrieval quality claims are easy to make and hard to verify, so we measure ours on a public, third-party benchmark: HERB (Heterogeneous Enterprise RAG Benchmark, Salesforce AI Research). HERB is built to look like a real company's knowledge: documents, Slack threads, meeting transcripts, GitHub PRs, and URLs, with multi-hop questions whose answers are scattered across artifact types — including deliberate traps like a mid-history product rename.

Two findings from the paper frame the market:

Even the best agentic RAG systems average ~33/100 on HERB end-to-end.
Retrieval — not the LLM — is the bottleneck: systems fail because they never surface the right evidence, then reason confidently over partial context.

That second finding is why we invest in retrieval first. Below is how standard market techniques score against Scrydon's shipped Memex retrieval — all measured by us, on the same HERB slice, with the same harness, so the numbers are directly comparable (precision@5: of the top 5 results, how many are artifacts the benchmark says the answer needs):

Retrieval approach	precision@5
Naive keyword overlap	0.39
Standard database full-text search (typical "just use Postgres FTS" baseline)	0.44
Retrieve-and-rerank with a cross-encoder model (the common "add a reranker" market pattern)	0.55
Scrydon Memex retrieval (shipped)	0.64

The shipped path beats the cross-encoder reranker pattern without using any model at all — no embeddings, no reranker pod, no GPU, no per-query model cost, and identical behaviour in an air-gapped deployment. The deterministic ranking signals encode what the generic reranker would have to guess at.

The shipped pipeline is also structure-aware: pages that cite the same link, messages that belong to the same conversation thread, and typed facts on pull-request pages (approved / merged / author) all feed retrieval directly — so a question like "which PRs were not approved?" or one whose answer lives in a chat thread resolves through structure that keyword scoring alone can never express. On the full benchmark (30 products, 38,600 artifacts, 815 questions), structure awareness raised the share of needed evidence retrieved into the candidate pool by 73% in a single release — still with zero model calls.

What we do and don't claim

These are retrieval scores — did the right artifacts surface — not end-to-end answer scores. Retrieval is the bottleneck HERB identifies, which is why we measure it directly.
The comparison table is measured on the benchmark's single-product slice (17 multi-hop questions over 471 artifacts); treat the deltas as directionally strong, not as decimal-precise. We additionally run the full benchmark (30 products, 38,600 artifacts, 815 questions) in CI on every release and track per-question-family results, so regressions on any corpus shape surface before they ship.
Benchmarks are fictional companies. To see how retrieval performs on your data, the Knowledge Health Report runs the identical measurement harness against your own corpus and produces a signed report — retrieval precision, grounded-citation rate, knowledge reuse, decay, and bus-factor coverage. Ask your Scrydon contact to schedule one.

Chat → Knowledge bases — conversation knowledge and creating KBs from Chat.
Platform → Knowledge base clearance — clearance levels on workspace KBs.
Authoring SDK → Organization KB — the governed org-KB surface, markings, and promotion.
Why deterministic — the platform-wide design stance Memex retrieval follows.