Memory model
Tenants, workspaces, memories, departments and spaces — and which boundary does what.
Five nested concepts. Only one of them is a security boundary, and knowing which saves a great deal of confusion later.
Tenant
Your organisation. This is the isolation boundary — the one that matters.
Every query against every store carries a tenant scope, and the helpers that build those queries fail closed: a blank tenant raises before any data is touched. The tenant is always derived server-side from your credential and is never read from a request body or query parameter, which removes the entire class of "pass someone else's id and see what happens" bugs.
A read that crosses tenants returns 404, not 403, so the existence of another
organisation's data is never disclosed.
Workspace
A container inside a tenant — typically an environment (production, staging) or a business unit. Every tenant has exactly one default workspace.
A workspace owns a primary memory. Calls that do not name a memory resolve against the active workspace's primary memory, which is why the quickstart works without creating anything.
Workspaces are an organisational boundary, not a security one. Two workspaces in the same tenant are separated by scoping, not by architecture.
Memory
The unit that actually holds knowledge: application, vector engine, graph engine, cache and object store. A memory is a deployable unit, which is what makes the four deployment postures possible without forking the product.
| Type | Runs on | Isolation |
|---|---|---|
| Shared | Chordian infrastructure, shared engines | Logical — mandatory per-tenant filters |
| Dedicated | Chordian infrastructure, own namespace | Physical — own engines, network-policed |
| Own server | Your Linux server | Physical, and off our premises entirely |
| Own cloud | Your AWS / GCP / Azure / DigitalOcean account | Physical, in your account |
See Memory types for how to choose.
Each memory also gets its own hostname, derived from a sequential serial:
https://acme-1045.api.uni-flow.aiPair that host with a per-memory key and you have a credential that can reach exactly one memory and nothing else — the right shape for an agent or a third-party integration.
Department
An automatic subdivision of a memory: Sales, Engineering, Finance. Content is classified into a department on ingest.
Below a confidence threshold of 0.70 the classifier declines to guess and files
the content in v_unassigned instead. That is deliberate — a document filed
confidently in the wrong department is worse than one flagged for review, because
nobody goes looking for it.
You will see departments called vaults in some older material and in the
vault_id parameter. They are the same thing; the API parameter name is the one
to trust.
Space
A named container inside a department, scoped to a project, team or integration. A space has its own members, its own conversation history, its own MCP endpoint and its own scoped credentials.
Spaces are how you give a coding assistant access to one project's knowledge rather than the whole organisation's. Scope is injected server-side from the credential, so a space-scoped key cannot read outside its space no matter what the request asks for.
Which boundary should I use?
| Goal | Use |
|---|---|
| Separate two customers or legal entities | Separate tenants |
| Separate production from staging | Separate workspaces |
| Guarantee data never leaves your infrastructure | A memory on your own infrastructure |
| Keep Finance content out of general answers | A department |
| Scope an agent or IDE to one project | A space |