Platform · Syncratic · Architecture
One governed path for humans and agents.
Every capability in Syncratic is an API surface, and the layers underneath are deliberately decoupled: serving, background processing, and data each scale, inspect, and upgrade on their own. This page walks the critical design choices that make the platform safe to bet a large operation on, organized around three functions: the Knowledge, Intelligence, and Control planes.
API-first by construction
Agentic-ready, because the platform was never UI-first
The platform's interfaces were designed as APIs before they were screens. That single sequencing decision is why governed agents, automation, and external applications arrive as ordinary clients.
API-First
Every capability is an API surface
Search, Ask, Explorer, Graph, Insights, document delta, and threads are exposed as compact /api/v1 facades. There is no capability hidden behind the UI that an automation cannot reach.
Agentic-Ready
Agents ride the governed path
Service-account clients and AI agents call the same interfaces a person uses, with owner-bounded permissions, the same privacy gates, and the same audit trail. Non-human traffic is first-class.
One Contract
No shadow integration tier
Because every caller passes through one governed path, there is no parallel pipeline to secure, audit, or maintain. The agentic-governance mechanics are detailed on the AI Gateway page.
How policy, privacy, spend, and evidence govern every call before a model is invoked: see the AI Gateway.
Control Plane
governs everything below
Governs how knowledge and intelligence are accessed and produced.
- Gateway
- Identity
- Tenant isolation
- RBAC
- Policy
- Model routing
- Audit
- Observability
Knowledge Plane
Acquires, structures, relates and maintains enterprise knowledge.
- LLMFS
- Enterprise connectors
- Knowledge graph
- MDM
- Classification
- Provenance
- Knowledge evolution
Intelligence Plane
Uses knowledge and signals to produce contextual intelligence.
- Ask
- Insights
- SignalOps
- Reasoning
- Agents
Scaling principles
Decoupled by design, scalable by structure
Large operations need flexibility and control. Syncratic separates the application layer from the data layer and splits background work into dedicated classes, so each part of the deployment can be sized, secured, and changed on its own schedule.
A stateless serving tier
Interactive and API traffic lands on services that hold no session state of their own. Add replicas behind your load balancer and capacity follows demand, with no re-architecture at twice the users.
Specialized worker classes
Background work is split into dedicated worker classes: enrichment, graph construction, change detection, and knowledge events. Each consumes its own event queues, so ingestion storms never starve interactive queries, and each class scales to its own load profile.
A pluggable data layer
Relational, vector, graph, and cache stores run as independent services behind the application layer. Swap, size, back up, and secure each store on your own schedule, with your own infrastructure choices.
Boundaries and packaging
Independence is the enterprise feature
The same decoupling that scales the platform also gives an enterprise control over it: explicit boundaries between planes, versioned contracts between components, and cloud-native packaging throughout.
Control plane and data plane, separated
Configuration, identity, and policy operate as a control plane distinct from the data processing it governs: the same Control Plane that governs the Knowledge and Intelligence planes in the diagrams on this page. Each fails, recovers, and upgrades independently, so a policy change never risks in-flight work.
Event contracts between runtimes
Components communicate through versioned, well-defined event contracts. One side can deploy without the other consenting. Coupling is a deliberate design decision.
Cloud-native packaging
Helm/K3s deployment with image pinning, readiness APIs, and per-class autoscaling. The platform is containerized, declaratively configured, and observable from the start, and deployment evidence replaces assumptions.
Conceptual dataflows
Three flows you can trace end to end
The layered structure shows up in how data actually moves. Each flow crosses the same boundaries: governed entry, event queues, specialized processing, and stores. That shared structure is precisely why each can scale without disturbing the others.
- 01
Ingestion
Uploads and connector syncs enter through one governed path and land on event queues. Worker classes built for each kind of work, such as enrichment, graph construction, and change detection, pick them up before they settle into the stores as indexed, related knowledge.
- 02
Retrieval
A query fans out across lexical, semantic, and graph retrieval modes, assembling evidence from the stores it is permitted to touch, with boundary decisions applied at the store itself.
- 03
Reasoning
Assembled evidence passes the Privacy Engine before any model role sees it. The model answers with citations back to source; the invocation, the policy decisions, and the evidence trail are all recorded.
- 04
Events back into the platform
What reasoning produces, from threads to insights to signals, is persisted as governed knowledge, so the next question starts further ahead. The flows compose.
- 01 Ingestion
- 02 Retrieval
- 03 Reasoning
- 04 Events
Control Plane
Identity and tenant scope at entry
Boundaries enforced at the store
Policy and privacy before models
Audit trail on every call
Knowledge Plane
Ingestion
Connector syncs and uploads enter through one governed path and settle into the stores as indexed, related knowledge.
Retrieval
Queries fan out across lexical, semantic and graph modes, with boundary decisions applied at the store.
Events
Threads, insights and signals persist back as governed knowledge, so flows compose.
Intelligence Plane
Reasoning
Evidence passes the Privacy Engine before any model role sees it; answers return with citations.
Data sovereignty
Local custody. Local processing. Local enforcement.
Sovereignty is how the architecture is drawn. Data stays inside your boundary, processing happens inside your boundary, and the rules that govern both are enforced inside your boundary. Nothing about scale requires any of it to leave.
Your knowledge. Your infrastructure. Your control.
Boundaries enforced at every store
Tenant and user scopes are enforced across every store in the deployment, where the data lives. A boundary is a property of the data itself.
Privacy enforced before models
The Privacy Engine gates what context may reach a model role, with reversible tokenization and admin-configurable modes. Evidence is governed before any reasoning happens.
Deployment-local model roles
Model roles bind to private, deployment-local models or approved external endpoints: your choice, per role. With offline-safe licensing and air-gapped operation, scale does not cost you custody.
Governed knowledge assurance
See the architecture run.
We will walk the layers on live data: an agent invoking Search through the governed path, a worker class scaling to an ingestion storm, and the audit trail both leave behind.