Reference
Architecture & integration
The single-workspace deployment model, control plane, core engine, request flow, and integration surfaces.
Architecture & integration
GreatMemory currently runs as a single-workspace product. It is not a public shared SaaS. One codebase ships as cloud-marketplace packaging, private-cloud packaging, or an appliance bundle. The deployment mode changes packaging and defaults, not product behavior.
System at a glance
The control plane owns authentication, guardrails, audit, connectors, and provider configuration. The core engine owns retrieval, graph memory, episodes, and storage. The starter UI is intentionally thin; customers can build their own UI against the same APIs.
Deployment modes
| Mode | Package | Default posture | AI providers |
|---|---|---|---|
| Cloud marketplace | AWS, Azure, or Google Cloud marketplace packaging | Entitlement at deploy time, telemetry on by default and configurable | Public LLM APIs and local providers allowed |
| Private cloud | Helm, Terraform, or compose | Offline license key, telemetry off by default and opt-in | Public LLM APIs and local providers allowed |
| Appliance | Hardware/server bundle for local-only environments | No external egress, local Grafana only | Local LLM providers only; external AI is blocked |
Marketplace and private-cloud installs run in the customer's environment. The customer keeps the data plane, database, network boundary, cloud logs, and LLM keys. Private-cloud customers can either buy and install the required services from our prescription, or ask us to procure, install, configure, and maintain them under a custom quote.
Request flow
Every caller passes through the same auth, guardrail, and audit path: starter chat UI, customer-built UI, REST integrations, and third-party ETL.
Integration surfaces
| Surface | Typical owner | Purpose |
|---|---|---|
| Starter web UI | Business users and admins | Chat, search, source management, provider setup, and audit review |
| REST and streaming chat API | Customer application teams | Build a custom UI or embed grounded answers into an existing product |
| Ingest/source/run API | Data and platform teams | Connect ETL, synchronize documents, purge data, and inspect runs |
| MCP tools | Agent platforms | Give agents long-term memory and retrieval through tool calls |
Operational controls
- Auth: local users plus LDAP/AD, with admin and member roles.
- Guardrails: regex/rule checks first, optional customer-configured LLM checks second, with monitor/redact/block modes.
- Audit: tamper-evident hash chain with redacted content previews, content hashes, source IP, user-agent, outcome, trace id, and export events.
- Observability: OpenTelemetry fan-out to bundled Grafana, cloud-native monitoring, or both.
- Storage: SQLite for small/local installs, Postgres + pgvector or MySQL for managed server deployments.
- Provider keys: BYO provider configs are encrypted and resolved by the control plane. Marketplace and private-cloud modes allow hosted LLM APIs; appliance mode enforces local-only endpoints.
Data isolation
Each install runs one workspace today. The core engine still stores data under a
space_id internally, and the packaged product pins the install to one default
space for simpler operations. Multi-workspace access is on the roadmap for teams
that need one user to move between multiple data estates, similar to switching
between several databases.