Document Workspaces, Collections, and Flows in README (#990)

Added section on Workspaces, Collections, and Flows to explain the organizational structure of TrustGraph.
This commit is contained in:
Jack Colquitt 2026-06-17 16:48:22 -07:00 committed by GitHub
parent 0ba1eeeda0
commit 345da375b1
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -62,6 +62,16 @@ What's inside a Context Core
Context Cores decouple what agents know from how agents are deployed. Build once. Run in Docker locally, Kubernetes in production, or on any cloud. Pin a version. Roll back. Promote across environments. This is context engineering — and it works because knowledge is finally treated like the infrastructure it is.
## Workspaces, Collections, and Flows
TrustGraph has a [three-level system](https://docs.trustgraph.ai/overview/workspaces) for organizing and isolating knowledge.
A **Workspace** is the outermost boundary — a fully isolated tenancy scope where all data, users, configuration, and pipelines live independently from every other workspace. Isolation is structural: enforced at the pub/sub queue, storage, and API gateway layers, not by trusting a field in a message body.
Within a workspace, a **Collection** groups related holons, graph structures, embeddings, and documents together — think of it as a dedicated shelf in a library, scoped to a specific domain, project, or customer.
A **Flow** is a running data processing pipeline that defines how raw data moves through ingestion, extraction, structuring, and storage — the assembly line that turns documents into queryable knowledge. Together, the three layers let you run multiple isolated tenants on a single deployment, separate knowledge by domain within each tenant, and process that knowledge through fully configurable pipelines — all without restarting the system or rebuilding your infrastructure.
## The Full Stack
TrustGraph is not a wrapper around a graph database. It is the complete backend for production agentic systems.