Workspace Context
Workspace Context separates reusable company knowledge from project-specific truth. Use it to keep business standards, code rules, examples, presentations, diagrams, and client work understandable for humans and reliable for LLMs.
Product model
Workspace Context is the team-level hub. Projects remain the scope for client, internal, code, and research work. This keeps reusable company knowledge separate from active project truth without forcing customers to create separate Snipara workspaces.
What Lives Where?
| Area | Typical Content | Use It For |
|---|---|---|
| Team Business Context | Business Library, offer templates, company presentations, reference diagrams, standards, approved examples, and delivery methodology. | Reusable company knowledge that should guide future work but is not the active truth for one client. |
| Team Code Context | Engineering rules, architecture defaults, repository conventions, API preferences, review rules, and technical operating notes. | Technical guidance that should apply across projects without configuring every project manually. |
| Projects | Client projects, internal projects, code projects, and research projects with their own documents, collections, diagrams, health, and memories. | Current or historical work scoped to a client, mandate, codebase, initiative, or research effort. |
Team Business Context
Team Business Context is implemented as team shared collections. The dashboard gives teams fast presets for the common business knowledge bases:
- Business Library: reusable company knowledge, methodology, approved examples, offer structure, and delivery standards.
- Offer Templates: base documents, proposal sections, assumptions, exclusions, and reusable commercial language.
- Company Presentations: pitch decks, PowerPoint-derived notes, positioning slides, and presentation scripts.
- Reference Diagrams: reusable schemas, visual conventions, topology patterns, and explanation notes.
These collections can be linked to projects when a client or internal mandate needs that reusable knowledge. They are not treated as the current truth for a client unless you place the relevant material in that client project.
MCP clients can manage the same model with rlm_list_business_collections, rlm_ensure_business_collection, rlm_upload_business_document, rlm_list_client_projects, and rlm_create_client_project. Current client files should still use rlm_upload_document or rlm_sync_documents so metadata and health signals remain attached to the project.
Project Scopes
Projects are the operational scopes where current work happens. A project can represent a client, an internal initiative, a codebase, or research.
The project UI follows that scope. Code projects show Codebase, Repo Docs, Technical Diagrams, and Attachments. Client or business projects show Client Context, Presentations, Diagrams, and Reference Material. Business Library remains a workspace-level reusable collection, not a lane inside a repository project.
| Scope | Examples |
|---|---|
| Client | ACME rollout, XYZ proposal, discovery notes, deliverables, client diagrams |
| Internal | Company operations, internal documentation, sales enablement, team initiatives |
| Code | Repositories, technical docs, code graph, architecture notes, implementation context |
| Research | Experiments, evaluations, prototypes, spikes, proof-of-concept work |
How LLMs Should Use It
A well-scoped query can combine reusable business context with active project context. For example, an agent can reuse the diagram conventions from the company library, compare with a historical ACME delivery, and then adapt the answer to the active XYZ project.
Workspace Context
├── Team Business Context
│ ├── Business Library
│ ├── Offer Templates
│ ├── Company Presentations
│ └── Reference Diagrams
├── Team Code Context
│ └── Team-wide technical rules
└── Projects
├── Client projects
├── Internal projects
├── Code projects
└── Research projects