Skip to content

Platform

A control plane you subscribe to, a data plane you own.

The SaaS holds metadata and orchestration. Your Runner holds the data and the compute. The two talk over a single outbound connection, and only safe artifacts cross it.

The architecture at a glance

Two planes, one boundary. The SaaS never stores raw client data; the Runner never opens an inbound port.

Control plane and data plane separation The KeplerAI SaaS control plane holds only metadata and orchestration. The client's on-premise data plane Runner holds all raw data and compute; it connects outbound and pulls jobs. Raw data never crosses the boundary. CONTROL PLANE · KeplerAI SaaS our multi-tenant hosting Angular front · business UI FastAPI backend · tenants, RBAC Use-case & template library AI agent orchestration (Claude) Stores only metadata: schemas · column stats · results metrics · connection refs (no creds) Never any raw client data DATA PLANE · client-side Runner on-premise / client private cloud Kepler Runner · sandboxed exec DuckDB / Spark-local · near-data Connectors · MySQL/PG/SQL/HDFS Trained models stay here Holds everything sensitive: raw data · DB credentials model weights Data never leaves this box outbound pull jobs ↓ / results ↑

Confidentiality frontier

What crosses the boundary — and what never does

Metadata and code flow down, aggregates and metrics flow up. Raw rows, credentials and model weights are blocked.

The confidentiality boundary Metadata and code flow down to the data plane; aggregates and metrics flow up to the SaaS. Raw rows, credentials and trained model weights are blocked at the boundary. SaaS · Control plane Client · Data plane boundary schema · column stats · code ↓ aggregates · metrics ↑ raw rows DB credentials model weights agents reason over metadata only

What's inside

Everything you need to take a compliance use case from raw source to monitored, explainable results.

On-premise Runner

A lightweight agent you deploy near your data. Runs DuckDB / Spark-local, connects to your databases, executes jobs in a sandbox, serves scoring in memory.

AI agents

Business + data-science agents built on Claude. They generate transforms, training and scoring code from schema and stats — never from raw rows.

Data ingestion & profiling

Scan sources, map tables and columns to use cases with access control, type and describe fields, and get per-field data-quality KPIs.

The Lab

On-demand Jupyter with CPU/memory reservation, scenarios, cron jobs, and the Kepler Copilot (Data · Assistant · Docs · Profile tabs).

Monitoring & explainability

Scored results with status, labels and assignment, SHAP explanations, score histograms and an entity/network graph.

Multi-tenant & RBAC

Tenants, typed use cases, scenarios and members with business roles: manager, controller, analyst, auditor.

The agents

How the two agents collaborate

The two AI agents A business/compliance agent talks to the user and delegates technical tasks to a data-science agent. The data-science agent emits code that executes in the data plane; only metrics return. Business user Business agent KYC / AML / fraud / scoring understands · interprets · guides Data-science agent DuckDB SQL · PySpark · Polars transform · train · evaluate Runner · data plane executes code on real data returns metrics, not rows Built on Claude reasons over metadata only delegate code ↓ metrics ↑

The protocol

Pull-based jobs, near the data

The Runner long-polls the SaaS, claims a job, executes it in a sandbox on local data, and posts back aggregates. Leases and idempotency make it resilient to restarts and network loss.

Pull-based job protocol The Runner long-polls the SaaS job queue over an outbound connection, executes each job near the data, and posts back aggregated results. No inbound port is opened on the client side. SaaS job queue queued → running → succeeded / failed lease + reclaim on timeout idempotent by job_id Runner (client) sandboxed execution on local data (NVMe) firewall stays closed heartbeat every ~15s long-poll: GET jobs/next job payload (code) ↓ POST result: metrics only ↑
ingestscorescore_realtimeschemaprofileconncheckdiagnostics

Domain model

Tenant → Use Case → Scenario → Results

A clean hierarchy that scales from a single use case to an enterprise-wide compliance program.

Domain model hierarchy Each tenant has many use cases; each use case has many scenarios; each scenario produces many result tables. Tenant a client organization · isolation boundary 1 : N Use Case typed: KYC · AML · Fraud · Credit · IFRS 1 : N Scenario a transform + model + scoring config 1 : N Results monitoring tables & dashboards

Run compliance where your data lives.

Create your account, install it in your environment with a single command, and let the AI copilots build your first use case — in a self-serve trial.

Sign up now See how easy onboarding is