RoboSystems

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.

Platform

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.

RoboLedger

Accounting and financial reporting extension — a ledger-grade system of record that AI and analysts can both query and operate. 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 publish as a holon (dataset-form JSON-LD, the stored anchor and the one form that carries the whole report), with an XBRL International Tavi compiled model and a filing-grade XBRL 2.1 package (Arelle-validated) built on first download, all three projections of the same assembled report
• Pipelines & data — QuickBooks ELT via dbt/Dagster with a configurable write_policy, and SEC XBRL financial reporting

Dedicated frontend app: roboledger-app.

RoboInvestor

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

# Install uv and just
brew install uv just

# Start robosystems backend
just start

# Start frontend apps - robosystems-app, roboledger-app, roboinvestor-app
just start apps

# Refresh images and recreate the containers that changed (after a git pull)
just upgrade

# Local builds: restart to pick up code changes; rebuild after dependency changes
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

just start runs the published images as released, so the checkout supplies configuration, not code. To run your own changes, comment out the image lines in .env: the stack is then built from the checkout, with its source mounted so an edit applies on just restart.

# Setup Python environment (uv automatically handles Python versions)
just init

Examples

See RoboSystems in action with runnable demos that create graphs, load data, and execute queries with the robosystems-client:

just demo-sec               # Loads NVIDIA's SEC XBRL data via Dagster pipeline
just demo-roboledger        # End-to-end RoboLedger demo: bulk OLTP, schedules, FY 2025 filed report, AI close
just demo-custom-graph      # Builds custom graph schema with relationship networks
just demo-coffee-roaster    # Synthetic manufacturing scenario
just demo-saas-startup      # Synthetic SaaS scenario
just demo-roboinvestor      # Cross-graph traversal from a private holding to its issuer's filed report (run demo-saas-startup first)

Each demo has a corresponding documentation page with detailed guides.

Development Commands

Testing

just test-all               # Tests with code quality
just test                   # Default test suite
just test adapters          # Test specific module
just test-cov               # Tests with coverage

Code Quality

just test-code              # Lint, format, and typecheck (what the git hooks run)
just lint fix               # Auto-fix lint issues
just typecheck              # Type checking

Log Monitoring

just logs api                 # View API logs (last 100 lines by default)
just logs graph-api           # View Graph API logs
just logs dagster-webserver   # View Dagster Webserver logs
just logs dagster-daemon      # View Dagster Daemon logs

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

Required Tools

• uv for Python package and version management
• just 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 guide.

• 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 across the shared repository's disclosures

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.

• Documentation: AI Operators and MCP | stdio bridge (proxy mode) for clients without HTTP transport support

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

Technical Documentation

Getting Started & Platform:

• Home / Overview · Quick Start · Core Concepts · Architecture Overview · Bootstrap Guide · Windows Setup (WSL2) · Security & Compliance

Operations Layer:

• Graphs & Multi-Tenancy · Authentication & API Keys · Enterprise SSO & SCIM · Querying the Analytical Graph · Graph Operations · AI Operators & MCP · Shared Repositories · Credits & Billing · Pipeline Guide

Extensions Layer:

• Extensions Surface Overview · GraphQL Reads · RoboLedger Operations · RoboInvestor Operations · Connecting QuickBooks Locally

Content & Contribution Fabric:

• Information Blocks · Taxonomy & Frameworks · Event-Driven Ledger · Reporting & Rendering · Serialization & Export

Documents & Search:

• Search & AI Retrieval · Document Management · File Uploads

Demos:

• RoboLedger Demo Walkthrough · SEC XBRL Pipeline · Custom Graph Schema

Codebase Documentation

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:

• Graph API - Graph API overview
• Client Factory - Client factory system
• Core Services - Core services layer

Middleware Components:

• Authentication - Authentication and authorization
• Graph Routing - Graph routing layer
• MCP - MCP tools and pooling
• Billing - Subscription and billing management
• Observability - OpenTelemetry observability
• Robustness - Circuit breakers and retry policies

Infrastructure:

• CloudFormation - AWS infrastructure templates
• Setup Scripts - Bootstrap and configuration scripts

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

• API reference — every endpoint, with its parameters, schemas and an example call
• Interactive API console — Swagger UI, to run a call against the live API with your own key
• OpenAPI specification — the machine-readable source, what the SDK generators read

Support

• Issues
• Documentation
• Projects
• Discussions
• CONTRIBUTING.md — branch conventions, coding standards, and the pull request process

License

This project is licensed under the Apache License 2.0 - see the LICENSE file for details.

Apache-2.0 © 2026 RFS LLC