Overview
Rootstock is a per-client deployment, not a shared multi-tenant SaaS your data disappears into. Each client gets its own retrieval index, its own domain ontology, and its own trace log — built on a fixed, opinionated stack so a Sinew Labs engineer can configure it in weeks rather than architect it from scratch.
Three layers do the actual work: a retrieval layer that turns your documents into a queryable, versioned knowledge base; an agent layer that reasons over that knowledge using a domain-specific ontology instead of a hard-coded script; and an operations layer that traces every query, tool call, and dollar spent. Identity and access sit underneath all three, tied to your existing SSO.
System architecture
The diagram below is the mechanism, not the marketing version: where documents and questions enter, which component talks to which, and — the part most security reviews care about — the one edge where a request leaves Sinew Labs' managed boundary and reaches a third-party model provider.
Every model call — regardless of provider — routes through the LiteLLM gateway. That gives you one place to swap OpenAI for Azure OpenAI, Anthropic, or a self-hosted vLLM endpoint without touching the agent logic, and one place to enforce rate limits, redaction, and per-client model allow-lists.
Data flow
What happens between a document landing in Rootstock and an answer landing in front of a business owner.
- Upload & ingest.
A document is uploaded via the console or API under an SSO-scoped session. It's parsed (tables, headers, and structure preserved), chunked, and embedded.
- Version & store.
Chunks and vectors land in the client's pgvector schema; the previous version is archived, not overwritten, so retrieval can be pinned to a point in time.
- Query arrives.
A question comes in through the chat window or the API. The retriever runs hybrid search — dense vector plus keyword — scoped to what that user's role is allowed to see.
- Agent reasons.
Retrieved context and the client's domain ontology (entities, relationships, rules) are handed to the LangGraph agent, which decides what to answer directly and what requires a tool call.
- Model call.
Where a completion is needed, the agent calls out through the LLM gateway — the one edge that reaches a third-party model provider, always over TLS, never with raw documents attached beyond the retrieved context.
- Trace & return.
The retrieval, the reasoning steps, the tool calls, and the token cost are all written to Langfuse in real time. The answer returns with citations back to the user.
Layer-by-layer stack
Ingestion & knowledge base
Handles everything between "a file" and "a queryable fact."
Agent & reasoning layer
Where domain knowledge becomes a decision, not just a paragraph.
Identity & access
Every query is scoped to a person, not just a client.
LLMOps & observability
The dashboard your consultant shows you isn't decorative — it's reading the same trace store as this section.
API surface
A representative slice of the REST API — enough to see the shape of what your team would integrate against.
| Endpoint | Purpose |
|---|---|
POST /v1/documents | Upload and version a document into the knowledge base |
GET /v1/documents/{id}/versions | List version history for a document |
POST /v1/query | Ask a domain question; returns an answer, citations, and a trace ID |
POST /v1/agents/{workflow}/run | Trigger a named agentic workflow directly |
GET /v1/ontology | Fetch the current domain schema (entities, relationships, rules) |
PUT /v1/ontology | Update the domain schema |
GET /v1/metrics | Cost, latency, and usage summary — mirrors the Langfuse dashboard |
Webhooks are available for document.ingested, query.answered, workflow.completed, and escalation.triggered, so Rootstock can push into a client's own systems rather than waiting to be polled.
Deployment model
Cloud-first. Each client runs in its own environment — an isolated Postgres schema by default, a dedicated instance for enterprise clients — deployed into the client's own AWS, GCP, or Azure account, or into Sinew Labs' managed cloud. Services ship as Docker containers; smaller deployments run on ECS Fargate / Cloud Run, larger ones on Kubernetes (EKS/GKE/AKS). Infrastructure is defined in Terraform and provisioned the same way every time.
On-premise. The same container images ship as a Helm chart or Docker Compose bundle for air-gapped or on-prem clusters. The client provides Postgres with the pgvector extension, S3-compatible object storage (MinIO works), and either an approved egress path to a hosted model provider or a self-hosted vLLM endpoint. Functionally identical to the cloud deployment — the only thing that changes is who operates the boxes.
Security & compliance posture
What's actually in place today, stated plainly rather than rounded up.
| Encryption | TLS 1.2+ in transit; AES-256 at rest for documents, vectors, and traces |
| Access control | SSO-backed authentication; row-level security scopes every query to a user's role and permitted documents |
| Audit trail | Immutable log of document access, queries, and agent tool calls, queryable per user or per document |
| Secrets | AWS Secrets Manager or HashiCorp Vault, never stored in application config |
| Data retention | Configurable per client, including full export and deletion on offboarding |
| Certification | Architecture is designed around SOC 2 Type II control objectives; formal certification is on the roadmap, not yet completed — we'll tell you plainly where we stand when you ask |
Stack reference
One table, for the whiteboard.
| Layer | Default technology |
|---|---|
| Parsing | Unstructured.io |
| Embeddings | OpenAI text-embedding-3-large |
| Vector store | PostgreSQL + pgvector |
| Object storage | AWS S3 / MinIO |
| Agent orchestration | LangGraph |
| Tool protocol | Model Context Protocol (MCP) |
| Model gateway | LiteLLM |
| Reranking | Cohere Rerank 3 |
| SSO | OIDC/SAML via WorkOS |
| Observability | Langfuse |
| Evaluation | Ragas |
| Compute | Docker on ECS Fargate / Kubernetes |
| IaC | Terraform |
| CI/CD | GitHub Actions |
Every row is swappable — this is the default we configure unless your environment already standardizes on something else.