The knowledge base belongs to your organization. When you upload a document, FAQ or PDF, or add a scraped URL, FixControl splits it into chunks, embeds each one, and stores them for retrieval. At query time the agents get grounded context for the issue they are working on.
User-facing knowledge management lives in the user knowledge guide. This page is the operational picture: what happens underneath, and what FixControl takes care of on the hosted service.
Who runs what
| Part | Who |
|---|---|
| Adding, scoping and removing sources | You, in Knowledge |
| Choosing the embedding provider and model | FixControl, for the whole deployment |
| Re-embedding after a provider or model change | FixControl |
| Retrieval depth and search weighting | FixControl, platform-wide |
| The embeddings health page | FixControl staff |
There is nothing for an organization admin to switch or trigger here. If search results look wrong to you, ask Command Center "what would you read if I asked X?" to see the exact passages retrieval would hand an agent (see the knowledge guide), and tell your FixControl contact what you found.
Fingerprinting
Every chunk is stored alongside the provider, model and dimensions it was embedded with — its fingerprint. If the embedding provider or model changes, a new query embedding cannot be meaningfully compared with chunks embedded under the old fingerprint: they live in different vector spaces.
Retrieval handles this automatically. Chunks under an older fingerprint are marked stale: they stay findable through full-text and fuzzy text matching, and their vector score is ranked lower until they are re-embedded. A provider change degrades vector search for a while; it does not empty your knowledge base.
Re-embedding
When FixControl changes the deployment's embedding provider or model, it re-embeds the affected chunks in the background. You do not need to do anything, and there is no re-embed button in your workspace.
While that runs, queries keep working: chunks that are not yet re-embedded are still found through text matching. If a re-embed pauses partway (provider down, rate limit), it continues with the chunks still marked as needing it; a chunk that was already done is not embedded twice.
FixControl staff watch an embeddings health page that shows the active provider and model, how many chunks match the active fingerprint, how many are stale, and the outcome of the last re-embed. It is not part of your organization's settings.
Hybrid retrieval
At query time, the agents that use knowledge combine three kinds of search into one ranking:
- vector search — semantic similarity to the question;
- full-text search — word and phrase matches;
- trigram matching — fuzzy text matching that survives typos and partial words.
The scores are fused into a single ranking, and an optional re-ranking pass can reorder the best candidates before the top results are handed to the agent. How many candidates are considered and how many results an agent receives are platform settings that FixControl sets for the whole service; they are not configured per organization.
Isolation and scope
Every knowledge search is scoped to your organization. A user in another organization can never retrieve one of your chunks, including through the API.
Within your organization, retrieval follows the project boundary: an agent working on an issue sees that issue's project sources plus organization-wide sources — never another project's. Sources of a removed project or codebase are left out of retrieval.
FAQ
Do I need to re-embed after FixControl switches embedding provider? No. Different model spaces, different dimensions, different fingerprints — FixControl runs the re-embed for you.
Can different organizations use different embedding models? Not today — the provider and model are set per deployment.
Can I keep a source out of agent context? Remove it, or scope it to the project it belongs to so other projects never see it. A source stored as a reference (a pointer without indexed content) is visible by name but its content is not searched.