Knowledge bases
Conversation knowledge, workspace knowledge bases, and Company Context — when to use each, how they are governed, and how we benchmark retrieval quality.
Scrydon ships more than one kind of knowledge base on purpose. A file you drop into a chat, the living documentation of a workspace, and organization-wide Company Context have different owners and lifecycles. This page explains the surfaces, when to use each, and how we measure retrieval quality.
The three knowledge surfaces
| Conversation knowledge | Workspace knowledge bases | Company Context | |
|---|---|---|---|
| What it is | Files attached to a private Chat conversation, indexed automatically. | Named KBs created for workspace documents, transcripts, and pasted content. | One organization-wide Memex KB for verified priorities, policies, terminology, constraints, and other durable company facts. |
| Scope | One private conversation. | One workspace (shareable per access policy). | One organization; readable by authorized organization members. |
| Lifecycle | Deleted with the conversation. | Managed by workspace members — add, update, remove. | Managed centrally from Settings → Organization → Company Context. |
| Governance | Private by construction. | Clearance levels per page, secrets scanning at ingest. | Organization membership, page clearance, and an administrator-only write surface. |
| Set up by | Nobody — attach a file and it exists. | Workspace members, via the UI or Chat. | Organization owners and administrators only. |
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.
- Every workspace should understand the same company facts — put verified policies, strategic priorities, terminology, constraints, and stakeholder information in Company Context. Pack-authored AI steps can ask a task-aware question of it before running, while keeping the pack's prompt stable.
Company Context is centrally managed
Each organization has at most one Company Context. It is a Memex knowledge base, not an ontology or a table-backed organization knowledge base. Organization owners and administrators maintain it from Settings → Organization → Company Context, using the page, folder, source, upload, search, and classification controls provided there.
Authorized members, AI actions, and Cortex can read Company Context when their membership and clearance permit it. They cannot edit it through Chat, a Process Flow, a generic knowledge-base mutation, or an instance-KB projection. There is no promote-to-Company-Context operation: conversations and process artifacts stay in their process instance knowledge base until an administrator deliberately updates Company Context from its dedicated editor.
Company Context grounds an AI action; it does not replace its prompt. A pack can define a stable, task-aware briefing question, and the platform injects the cited answer as a separate context category. Missing or unavailable Company Context does not rewrite the prompt or block the action.
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.
Company Context always uses Memex; its engine is not selectable.
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.
Related
- Platform → Company Context — administer the organization-wide singleton and understand its read-only consumers.
- Chat → Knowledge bases — conversation knowledge and creating KBs from Chat.
- Platform → Knowledge base clearance — clearance levels on workspace KBs.
- Platform → Knowledge editing — the page, folder, source, and classification controls also used by the dedicated Company Context editor.
- Why deterministic — the platform-wide design stance Memex retrieval follows.