Context Service
Overview
The Context Service (ContextService, accessed via client.context) is the SDK
wrapper for the Kamiwaza Context Service. Located in
kamiwaza_sdk/services/context.py, it manages workroom-scoped vector databases,
ontologies (knowledge graphs), ingestion pipelines, and retrieval against the
documents and knowledge held inside a Workroom.
Every Context Service resource lives inside exactly one workroom. The SDK targets
a workroom by passing workroom_id to a method (sent to the server as the
X-Workroom-ID header). Some methods make workroom_id a required
keyword-only argument (e.g. list_collections, create_pipeline_job, search,
retrieve, upload_file); others accept it optionally, and when it is omitted
the server resolves the caller's default workroom.
For PAT/API-key automation that makes several calls against the same workroom,
derive a local scoped client instead of calling workrooms.enter():
with client.workroom_scope(my_workroom_id) as scoped:
db = scoped.context.create_vectordb(name="project-vdb", engine="milvus")
scoped.context.insert_vectors(
db["id"],
collection_name="project_docs",
vectors=[embedding],
metadata=[{"source": "seed"}],
)
The scoped client only adds the explicit workroom header on SDK requests; it does not change the parent client or mutate server-side selected-session state. It is not a client-side security boundary; the server must still authorize the caller for the requested workroom on every request.
Workrooms and the Global Workroom
A Workroom is the collaboration and isolation boundary for context: vector collections, ontologies, ingested files, and pipeline jobs all belong to a workroom, and access is scoped to that workroom's members.
The Global Workroom is a special, well-known workroom (the all-f sentinel
ffffffff-ffff-ffff-ffff-ffffffffffff, exposed as
ContextService.DEFAULT_WORKROOM_ID). It holds the platform's shared,
read-only catalog of context — knowledge that is visible to everyone but owned
by no single member.
The Global Workroom is read-only for tenant writes
Key semantics: Any direct write that targets the Global Workroom is rejected by the server with HTTP 403 and a body of
Global Workroom is read-only for <operation>(for exampleGlobal Workroom is read-only for ontology creation). This is intentional and by design, not a bug — the Global Workroom is a shared catalog, so it is populated only by the platform's own ingestion paths, never by ad-hoc tenant writes.
Reads against the Global Workroom are always allowed (results are
requester-scoped where appropriate). Writes are blocked. The table below lists
the server-side policy categories — some (e.g. pipeline retry/rerun/delete,
workroom archive/restore/purge) are enforced by the Context Service but are not
all surfaced as client.context methods; the SDK exposes a subset (see the
method lists below).
| Operation category | Against a normal workroom | Against the Global Workroom |
|---|---|---|
| List / get / query / search / retrieve (reads) | ✅ allowed |