Workspaces

A workspace is the main boundary for knowledge in Usable. It brings related fragments, fragment types, collections, members, and settings together in one place.

The most useful way to think about a workspace is as a context with a clear purpose. A product team might have a workspace for internal product knowledge. A support team might maintain troubleshooting guidance in another. Public documentation can live in a workspace intended specifically for external readers.

What belongs to a workspace

Every memory fragment belongs to one workspace. The workspace determines which fragment types are available, which collections can include the fragment, and who may read or change it.

A workspace can contain:

• memory fragments and their attached files;
• default and custom fragment types;
• collections used to curate related fragments;
• members, roles, and visibility settings;
• integrations such as webhooks and AI access.

Search is also workspace-aware. Scoping a search to the right workspace reduces noise and prevents unrelated knowledge from being mixed into the result.

Public and private workspaces

A private workspace is intended for invited members. Use one for internal procedures, private project context, or any material that should not be broadly discoverable.

A public workspace can be discovered by other authenticated Usable users. People may subscribe to gain read-style access where the workspace permits it. Public does not mean permissionless: creating fragments, changing settings, or managing integrations still requires suitable access.

Choose visibility based on the most sensitive material you plan to store. Do not make a workspace public as a substitute for reviewing its contents.

Choose boundaries deliberately

Workspace boundaries affect both security and retrieval quality. One enormous workspace is simple at first, but it can become difficult to search and govern. A separate workspace for every small initiative creates the opposite problem: knowledge becomes fragmented and harder to reuse.

A good workspace usually represents a durable domain, audience, or responsibility. Examples include:

• Public product documentation
• Internal engineering knowledge
• Customer support playbooks
• A long-running product or research area

Create a separate workspace when the audience, access requirements, or knowledge lifecycle is meaningfully different—not merely because a new project started.

Example: public docs and internal operations

Suppose a team documents an API. Public concepts, tutorials, and references can live in a public documentation workspace. Deployment procedures, incident notes, and private infrastructure details belong in a separate internal workspace.

The two workspaces may discuss the same product, but they serve different audiences and have different disclosure rules. Keeping them separate makes both search and access control easier to reason about.

Public workspace discovery

Public workspaces can be found through the dashboard’s discovery experience or through supported APIs and MCP tools. Subscribing makes an accessible public workspace appear alongside your other workspace contexts. It does not grant editing rights.

When publishing a workspace, use a clear name and description so prospective readers understand its purpose before subscribing.

Good practices

• Give each workspace one clear, durable purpose.
• Put the intended audience in the name or description when it is not obvious.
• Keep public and sensitive material in separate workspaces.
• Review visibility before adding real content or integrations.
• Use collections and tags to organize material within a workspace before creating more workspaces.
• Periodically archive or consolidate workspaces that no longer have a distinct purpose.

Related concepts

• Memory fragments are the individual knowledge units stored in a workspace.
• Fragment types are defined per workspace and describe what kind of knowledge a fragment contains.
• Collections organize related fragments without changing workspace boundaries.

Member roles and detailed permission management belong to the People & Access documentation.