Understanding Knowledge of a Space

What changed

Previously, an organization could create several independent Knowledge Bases, freely linked to Spaces: one Space could point to multiple Knowledge Bases, and a single Knowledge Base could be shared across several Spaces. In parallel, each Space also had a separate "Context" area, where files were uploaded to be loaded automatically into every conversation.

We've merged these two mechanisms into a single one, now called Knowledge, built directly into the Space. There are no longer standalone Knowledge Bases living outside a Space, nor a separate "Context" area.

Why we made this change

A simpler model to understand. The previous model asked users to manage an abstract concept — the Knowledge Base — independently of where they actually worked, along with the relationship between that concept and their Spaces. This raised questions with no obvious answer: what is a Knowledge Base good for on its own? Why link it to this Space rather than another? Where should a file go, in Context or in a Knowledge Base? By attaching Knowledge to the Space, the concept becomes concrete: Knowledge is what this Space knows. It no longer exists in the abstract — it belongs to the Space's purpose. Merging the former "Context" into Knowledge removes a second point of hesitation: there is now a single place to put a Space's files.

Clearer data governance. In the old model, a single Knowledge Base could be shared across several Spaces with different members. This made access rights hard to reason about: who could see which files, once the same base served distinct spaces? By attaching Knowledge to a single Space, access to Knowledge now follows access to the Space: a Space's members see its Knowledge, and no one else. A file's sharing scope becomes predictable — which matters especially for organizations subject to confidentiality and data-protection requirements.

A better-targeted scope. A Space has a specific purpose — organizing an event, keeping a set of files up to date, tracking a recurring topic. Knowledge scoped to that purpose tends to improve the relevance of the information retrieved during a search: on a coherent set of files, search is less likely to surface an off-topic document. This is a design principle that accompanies the change, rather than a performance goal on its own.

How Knowledge fits among a Space's data sources

To place Knowledge properly, it helps to see the three ways data can reach the LLM in Goodweek — from broadest to most targeted:

1. Integrations — the LLM retrieves information from the company's information system (OneDrive, SharePoint...) when the user needs it. The potential volume is huge, and the challenge is extracting the relevant portion through search.

2. The Space's Knowledge — a smaller set of files than the full IS, but entirely dedicated to the Space's purpose. These files, in any format, are vectorized and then used by the LLM within the Space. It's the Space's durable, targeted memory.

3. Files added in the conversation — a file dropped directly into the prompt, used for the current exchange. This is the most immediate, one-off layer.

Knowledge therefore sits in the middle layer: more targeted than an IS-wide integration, more durable than a file added on the fly in a conversation.