RoboSystems
RoboSystems is an open-source, AI-native financial intelligence platform for accounting, financial reporting, and investment management. It models your financial data as a knowledge graph — transactions, facts, reporting elements, and the calculation structures that relate them are all nodes and edges, with the semantics preserved rather than flattened into rows you query around. On top of that graph it gives AI agents and analysts a ledger-grade system of record they can both query and operate — closing the books, producing reports, and analyzing portfolios across your own ledger, your holdings, and SEC public filings queryable alongside them. Powers RoboLedger and RoboInvestor.
Every tenant gets their own graph. Not a row-level slice of a shared table — a dedicated graph database on its own instance, with a dedicated OLTP schema behind it. Your ontology, your taxonomies, and your calculation structures live in it as artifacts you can read, export, and take with you.
The platform provides the core infrastructure that all extensions build on:
- Dedicated Infrastructure: Tiered LadybugDB graph infrastructure with dedicated instances and configurable memory allocation
- AI Operator System: Autonomous financial Operators (Claude/MCP executors) with automatic credit tracking and SSE progress streaming.
- Shared Repositories: SEC XBRL filings knowledge graph for context mining and benchmarking
- Document Management: Upload, index, and search documents with full-text and semantic search via OpenSearch
- Credit-Based Billing: Flexible credits for AI operations based on token usage
- Subgraphs (Workspaces): AI memory graphs and isolated environments for development and team collaboration
- Web Application: Primary web interface — graph management, the AI query console (natural-language + Cypher over MCP), schema explorer, document search, shared-repository access, and billing —
robosystems-app
The core platform API lives at /v1 — auth, orgs, billing, graph lifecycle (subgraphs, backups, materialize, tier changes), Cypher, and MCP — with reads as REST GET. Every write — across both the core and extensions surfaces — is a named OperationEnvelope operation with Idempotency-Key support, audit logging, and SSE progress streaming via /v1/operations/{id}/stream.
Extensions
Extensions are domain-specific subsystems that bring their own schema, OLTP tables, API routes, data pipelines, and dedicated frontend apps. They share a single PostgreSQL database with schema-per-tenant isolation and materialize to the graph for analytical queries. Domain content is authored as block molecules — self-describing envelopes bundling atomic facts with their structure, rules, and verification — never bare rows.
The extensions API surface is graph-scoped at the URL level — graph_id is always a path parameter, never a query argument — and splits reads from writes by transport:
- Reads →
POST /extensions/{graph_id}/graphql — Strawberry GraphQL, GraphiQL in dev, schema composed dynamically from enabled domains
- Writes →
POST /extensions/{roboledger|roboinvestor}/{graph_id}/operations/{operation_name} — named REST commands
- Analytical views →
POST /extensions/{domain}/{graph_id}/operations/{view_name} — read-only analytical operations (e.g. build-fact-grid, live-financial-statement), same envelope as writes
Behind the API is a CQRS operations kernel (reads/ + commands/ per domain, plus graph-backed views/) that's the single source of truth for business logic — GraphQL resolvers, REST operation routes, and MCP tools all delegate to the same functions. Per-domain feature flags (ROBOLEDGER_ENABLED, ROBOINVESTOR_ENABLED) gate both the routers and the GraphQL schema composition.
Accounting and financial reporting extension — a ledger-grade system of record that AI and analysts can both query and operate. It broadly implements the Seattle Method, a declarative methodology for digital financial reporting. Writes land as self-describing molecules: atomic facts bundled with their structural wiring, rules, and verification in one typed envelope, never bare rows. Three block molecules are the authoring substrate:
- Information Blocks — the envelope for reportable content: schedules, statements, metrics, and text-block disclosures bundled with their period-versioned fact sets, typed mechanics, and rules.
evaluate-rules runs arithmetic checks (EqualTo, RollUp, RollForward, SumEquals, Exists, CoExists) over materialized facts; pinning a fact set separates a live closing book from a frozen report.
- Event Blocks — REA event capture: callers record what happened in the world (a sale, a payment, an asset disposal) through a structured action-verb vocabulary, and a handler registry derives the debits and credits across the three-level ledger (Transaction → Entry → LineItem). Preview handler resolution, execute to post GL atomically, and promote matured obligations (AR/AP, schedule entries) on demand.
- Taxonomy Blocks — accounting frameworks as data, not code: Elements, linkbase Associations (presentation / calculation / mapping), Structures, and auto-generated structural rules in one atomic write. Ships
fac (fundamentals) and rs-gaap (~2,000 curated US-GAAP concepts) behind a two-tier public→tenant library, with CoA→GAAP mapping anchored to calc-DAG leaves.
Built on the blocks:
- Close lifecycle — fiscal calendar, close-target catch-up sequencing, and period close/reopen gated on the balance equation, QuickBooks sync-staleness, and outstanding schedule obligations; every blocker names what is holding the close
- Mapping — CoA→GAAP mapping associations plus AI-assisted bulk mapping via the MappingOperator (confidence-tiered: auto-approve / review / skip)
- Reporting — multi-period reports rendered from shared facts through a Reporting Style; a report lifecycle (draft → under_review → filed → archived) with publish lists for distribution
- Forecasting — operating-plan scenarios projected through the same statement structures: rule-driven forecasts, per-line growth trajectories, and manual line assertions, with forecast periods returned alongside actuals on statement reads
- Analytical operations —
live-financial-statement renders a statement straight from the OLTP ledger (no materialization required); build-fact-grid and financial-statement-analysis query the materialized XBRL hypercube in the graph
- Serialization — reports serialize to web-native JSON-LD (stored, SHACL-validatable) and filing-grade XBRL 2.1 (rebuilt on demand, Arelle-validated)
- Pipelines & data — QuickBooks ELT via dbt/Dagster with a configurable
write_policy, and SEC XBRL financial reporting
Dedicated frontend app: roboledger-app.
Portfolio management and investment tracking extension — tracks holdings in private companies and links them back to the businesses that issued them.
- Portfolio Blocks — the same molecule discipline as RoboLedger: a portfolio plus its positions and securities are validated and written as one envelope, with cost basis and current value held as integer cents and dollar totals computed at the boundary. Positions move through an active / disposed / archived lifecycle; reads expose
portfolios, positions, holdings (rolled up by issuer), and the assembled portfolioBlock.
- Securities — register and maintain ownership instruments (common stock, warrants, convertible notes, …) with an extensible
terms blob for instrument-specific detail (strike price, liquidation preference, vesting)
- Cross-graph research — a security can point at the graph of the company that issued it, when that company also runs on the platform. The investor records the issuer's
source_graph_id up front as a pre-association; when the issuer later shares a published report into the investor's graph, the issuer's entity is materialized there and any securities waiting on that source_graph_id link to it. A holding then traverses through to the issuer's own reported facts — Portfolio → Position → Security → Entity → Report → Fact — with authorization enforced at the report-sharing boundary, not the OLTP layer.
Dedicated frontend app: roboinvestor-app.
Quick Start
Docker Development Environment
brew install uv just
just start
just start apps
just upgrade
just restart
just rebuild
This initializes the .env file and starts the complete RoboSystems stack with:
- Graph API with LadybugDB and DuckDB backends
- Dagster for data pipeline orchestration
- PostgreSQL for IAM, graph metadata, extensions and Dagster
- Valkey for caching, SSE messaging, and rate limiting
- OpenSearch for full-text and semantic document search
- Localstack for S3 and DynamoDB emulation
Service URLs:
With just start apps (frontend apps):
Local Development
Examples
See RoboSystems in action with runnable demos that create graphs, load data, and execute queries with the robosystems-client:
just demo-sec
just demo-roboledger
just demo-custom-graph
just demo-coffee-roaster
just demo-saas-startup
just demo-roboinvestor
Each demo has a corresponding documentation page with detailed guides.
Development Commands
Testing
just test-all
just test
just test adapters
just test-cov
Code Quality
just test-code
just lint fix
just typecheck
Log Monitoring
just logs api
just logs graph-api
just logs dagster-webserver
just logs dagster-daemon
See justfile for 100+ development commands including database migrations, CloudFormation linting, graph operations, administration, and more.
Prerequisites
System Requirements
- Docker & Docker Compose
- 8GB RAM minimum
- 20GB free disk space
uv for Python package and version managementjust for project command runner
Developed and tested on macOS and Linux. On Windows, use WSL2 with the repo cloned inside the Linux filesystem — see the Windows Setup (WSL2) Guide.
Deployment Requirements
- Fork this repo
- AWS account with IAM Identity Center (SSO)
- Run
just bootstrap to configure OIDC and GitHub variables
See the Bootstrap Guide for complete instructions.
Architecture
Built end-to-end on open-source engines — PostgreSQL, LadybugDB, DuckDB, LanceDB, OpenSearch, and Valkey — assembled into a transactional core with a materialized analytical graph and integrated vector search, with no proprietary database lock-in.
That openness runs up the stack as well as down: the accounting ontology, reporting taxonomies, and calculation structures are inspectable, portable artifacts you own, not configuration trapped in a vendor platform — semantic sovereignty for your financial data.
Multi-Tenancy & Isolation
One rule: every isolation primitive keys on graph_id, never on an organization — session search_path, cache keys, idempotency keys, rate-limit buckets, and credit accounting all namespace on the graph. Two graphs inside the same organization are separated by the identical mechanism that separates two unrelated customers; there is no "internal" path that skips the boundary.
- One graph database per tenant — every tier runs
databases_per_instance: 1, so tiers differ by instance size, not by how many tenants share one.
- Schema-per-graph OLTP — each graph gets its own PostgreSQL schema, with
search_path re-stamped on every request rather than inherited from a pooled connection. A CI structural test pins the contract.
- Two databases, two migration histories — platform state (identity, orgs, billing) is separate from extensions OLTP; a migration to one never touches the other.
- The graph is a derived projection — OLTP rows are the system of record and the analytical graph is rebuilt from them blue-green, which is what makes a rebuild routine rather than risky.
- Subgraphs are isolated environments inside a tenant, sharing the parent's credits and permissions — AI memory, development, team workspaces.
- Shared repositories (SEC XBRL) are the one multi-reader surface: read-only, separately replicated, queryable alongside your own graph but never writable through it.
Because tenancy is enforced at the graph rather than in application predicates, the same codebase serves managed SaaS, a dedicated single-tenant deployment, and a fully self-hosted install with no fork. Details: Graphs & Multi-Tenancy.
Identity & Access
Programmatic access uses X-API-Key; the browser apps use short-lived JWTs. How a person logs in is a deployment decision — password, WebAuthn passkey, or an enterprise identity provider — published at GET /v1/auth/providers, so one frontend build renders whichever posture the backend is configured for.
Enterprise SSO (OIDC) and SCIM 2.0 provisioning ship in the repository, off by default — available to any fork without a license gate. Provisioning is link-only: SCIM creates accounts and OIDC only resolves already-provisioned ones, so the identity provider owns the account lifecycle in both directions.
Details: Enterprise SSO & SCIM · Authentication & API Keys · SECURITY.md
Components
Application Layer:
- FastAPI REST API with versioned endpoints
- Extension GraphQL read API plus named REST command operations (CQRS)
- MCP server for AI-powered graph database access — every graph speaks the MCP Streamable HTTP transport, with OAuth or API-key auth
- AI Operator System for autonomous financial operations with automatic credit tracking
- Dagster for data pipeline orchestration and background jobs
LadybugDB Graph Database:
- Embedded columnar graph database purpose-built for financial analytics
- Base + extension schema architecture — extensions define domain models
- Native DuckDB integration for high-performance staging and ingestion
- LanceDB as the semantic-modality engine — per-graph, on-disk vector stores (IVF-PQ, 384-dim embeddings) for AI memory (remember/recall) and vector-search offload
- Tiered infrastructure with configurable memory, rate limits, and subgraph allocations
- Shared tier hosts public repositories with read replicas
Data Layer:
- PostgreSQL (RDS) for IAM, graph metadata, Dagster, and extension OLTP databases (schema-per-tenant)
- OpenSearch for full-text and semantic document search (BM25 + KNN)
- Valkey (ElastiCache) for caching, SSE messaging, and rate limiting
- S3 for data lake storage and static assets
- DynamoDB for instance/graph/volume registry
Infrastructure:
- CloudFormation deployed via GitHub Actions with OIDC
- ECS Fargate for API and Dagster
- EC2 (ASG) for LadybugDB writer clusters; EC2 (ALB + ASG) for shared replica clusters
AI
Model Context Protocol (MCP)
- Financial Analysis: Natural language queries across enterprise data and public benchmark data
- Cross-Database Queries: Compare user graph data against SEC shared repository data
- Tools: Rich toolkit for graph queries, schema introspection, fact discovery, financial analysis, document search, and AI memory operations
- Handler Pool: Managed MCP handler instances with resource limits
AI Operator System
- Unified architecture: stateless Operators (Claude/MCP executors) with protocol-based service injection
- Dual execution: API (sync/SSE) and background worker (Valkey queue + SSE progress)
- Automatic credit tracking per AI call — Operators cannot forget billing
- Extensible: add new Operators for new AI workflows; they inherit execution, credit tracking, and progress streaming automatically
Credit System
- AI Operations Only: Credits are consumed exclusively by AI Operator calls (Anthropic Claude via AWS Bedrock)
- Token-Based Billing: Credits based on actual token usage and model cost
- MCP Tool Access: No credits consumed for MCP calls or database operations
SEC Shared Repository
A curated knowledge graph of US public company financial data from SEC EDGAR XBRL filings. Runs on the shared LadybugDB tier, accessible via MCP tools, Cypher queries, and the AI Operator.
The full corpus is also published monthly as one LadybugDB file on Hugging Face — robosystems/sec-xbrl-knowledge-graphs (tens of GiB to download, well over 100 GiB on disk; the dataset card carries each snapshot's exact sizes). just sec-dump pulls it into data/lbug-dbs for local Cypher, API, and MCP with no pipeline run; see the SEC XBRL Pipeline wiki page.
- Pipeline: EDGAR → Download → Process (Parquet) → Stage (DuckDB) → Enrich (Icebug+fastembed) → Materialize (LadybugDB) → Index + Embed (OpenSearch)
- Graph: the base schema plus the
roboledger extension — 20 node types and 41 relationship types modeling the full XBRL reporting hierarchy
- Extraction: every filing is parsed by xbrlkit — the same open library behind the
disclosures and information-block tools, the holon viewer, and its own MCP server
- Search: Hybrid BM25 + KNN vector search across narrative sections and iXBRL disclosures
- Enrichment: Semantic element mapping, statement classification, and disclosure tagging — applying aspects of the Seattle Method to the shared repository's disclosures (the methodology RoboLedger implements more broadly)
See SEC Adapter for detailed documentation.
Client Libraries
RoboSystems provides comprehensive client libraries for building applications:
MCP (Model Context Protocol)
Every graph is an MCP server, and the graph's URL is the preferred way to connect — Claude, Claude Code, Cursor, or any MCP client that supports HTTP transports, no install required. The URL picks the graph (sec for the public SEC repository, your graph id for your own); sign in with OAuth, or put your API key in the X-API-Key header — never in the URL.
OAuth — sign in and pick a graph. The graph-agnostic endpoint https://api.robosystems.ai/v1/mcp accepts OAuth only: an OAuth-capable client (claude.ai, Claude Code, ChatGPT, VS Code, Cursor) discovers the authorization server from the endpoint, you sign in and choose the graph the connection covers, and the client holds a revocable token bound to that graph — no key to paste. Per-graph URLs accept OAuth too, alongside the key header. (Deployment flag: MCP_OAUTH_ENABLED.)
RoboLedger endpoint. https://api.robosystems.ai/v1/mcp/roboledger is the same OAuth flow for RoboLedger graphs only: sign-in offers only your RoboLedger graphs, and the connection serves the accounting tool set without workspace and platform-administration tools (subgraphs, backups, materialization, write policy). It is the endpoint for RoboLedger directory listings, which freeze one tool list per URL.
claude mcp add --transport http robosystems https://api.robosystems.ai/v1/mcp
Claude Code with an API key — one command:
claude mcp add --transport http robosystems-sec \
https://api.robosystems.ai/v1/graphs/sec/mcp \
--header "X-API-Key: <your key>"
Cursor / VS Code — add to mcp.json:
"robosystems-sec": {
"url": "https://api.robosystems.ai/v1/graphs/sec/mcp",
"headers": { "X-API-Key": "<your key>" }
}
Claude (claude.ai / Desktop) — Settings → Connectors → Add custom connector with https://api.robosystems.ai/v1/mcp (or a per-graph URL): Claude detects OAuth and you pick the graph at sign-in. The MCP page in the app (/connect) has every snippet filled in for the selected graph, and mints graph-scoped keys for header-only clients.
TypeScript/JavaScript Client
Full-featured SDK for web and Node.js applications with TypeScript support.
npm install @robosystems/client
- Features: Type-safe API calls, automatic retry logic, connection pooling, streaming support
- Use Cases: Web applications, Node.js backends, React/Vue/Angular frontends
- Documentation: npm | GitHub
Python Client
Native Python SDK for backend services and data science workflows.
pip install robosystems-client
- Features: Async/await support, pandas integration, Jupyter compatibility, batch operations
- Use Cases: Data pipelines, ML workflows, backend services, analytics
- Documentation: PyPI | GitHub
Documentation
Documentation
Getting Started & Platform:
Operations Layer:
Extensions Layer:
Content & Contribution Fabric:
Documents & Search:
Demos:
Developer Documentation (Codebase)
Each package documents itself — read the README for a directory before working in it.
Core Services:
- Adapters - External service integrations
- Operations - Business workflow orchestration, CQRS reads/commands kernels for extensions
- AI Operators - AI Operator framework: Claude/MCP executors, credit tracking, SSE streaming
- Schemas - Graph schema definitions
- Extensions GraphQL - Strawberry GraphQL read surface, Pydantic auto-derivation, resolver patterns
- Configuration - Configuration management
- Dagster - Data pipeline and task orchestration
Database Models:
- Platform Models - SQLAlchemy models for the platform database
- Extensions Models - SQLAlchemy models for the extensions database with schema-per-graph tenancy
- API Models - Pydantic request/response models for core platform and extensions surfaces
Graph Database System:
Middleware Components:
Infrastructure:
Development Resources:
- Examples - Runnable demos and integration examples
- Tests - Testing strategy and organization
- Admin Tools - Administrative utilities and CLI
Security & Compliance:
- SECURITY.md - Security control catalog with implementation references
- Compliance - Compliance stacks, toggles, and SOC 2 posture
- Trust Center - Live compliance posture and audit artifacts
API Reference
Support
License
This project is licensed under the Apache License 2.0 - see the LICENSE file for details.
Apache-2.0 © 2026 RFS LLC