Skip to content
Project VELAProject VELA

Project VELA

Agentic, advisory anomaly-investigation for satellite operations — the ground-segment brain that turns a telemetry deviation into a cited root-cause narrative and a drafted recovery procedure, with every claim traceable to the spacecraft’s own manuals and knowledge graph.

A Verified Evidence Layer for Anomalies: every claim is verifiable, or it is blocked.

Operating model — autonomous where it’s safe

VELA autonomously detects the deviation, investigates the root cause, and drafts the recovery. Recovery actions stay under operator authority by design — VELA reads telemetry and advises; it never commands a spacecraft. That boundary is the moat: it is what lets a mission-assurance team, an insurer, and a defence programme trust an AI on a live fleet.

What this documentation covers

  • :material-rocket-launch: Getting started

    Set up the Python + Node stack, run an investigation, and drive the console.

  • :material-sitemap: Architecture

    The full stack — deterministic graph, the MCP audit boundary, stores, and the console — plus the data & ingest pipeline and the frontend console.

  • :material-shield-lock: Security

    The no-command guardrail, threat model, air-gap posture, RBAC/SSO/SCIM, audit, and export control.

  • :material-server-network: Deployment

    Local dev, Docker Compose, Helm/Kubernetes cloud, one-command on-prem, and fully air-gapped installs.

  • :material-flask: Testing & eval

    The make check gate, golden cases, and the benchmark harnesses.

  • :material-map-marker-path: Roadmap

    What is built today and what is coming next.

The one-paragraph architecture

VELA is ground segment only and advisory only. Telemetry enters through a swappable TelemetrySource (seeded replay, a samples file, Yamcs, OpenC3, MQTT, AWS Ground Station, or a raw CCSDS downlink). A detector forms an AnomalyEvent, which a fixed, deterministic LangGraph walks: supervisor → triage → investigator → validator → drafter → approval. Every reasoning node reaches data only through the MCP client — the audit boundary — and every claim it makes carries a Citation that must resolve, or the claim is emitted as UNGROUNDED and blocked from release. A human approves the drafted procedure; VELA never executes it.

flowchart LR
  TS[TelemetrySource<br/>replay · file · yamcs · openc3 · mqtt · ccsds] --> DET[Detector<br/>annotation · ecod · graph · onboard]
  DET --> EV[AnomalyEvent]
  EV --> SUP{supervisor}
  SUP -->|suppressed| END1([END])
  SUP -->|investigate| TRI[triage] --> INV[investigator] --> VAL[validator] --> DRA[drafter]
  DRA -->|procedure| APR[approval gate<br/>human authorizes] --> END2([END])
  DRA -->|none| END3([END])
  INV -. MCP client<br/>the audit boundary .-> KG[(Knowledge graph<br/>+ documents + telemetry)]

Hard guardrails

Non-negotiable — enforced in code and CI

  1. No commanding. VELA never constructs, formats, or transmits a telecommand. Enforced by a grep guardrail in a pre-commit hook and two CI workflows.
  2. No fabricated data. All spacecraft data is a synthetic reference spacecraft (VELA-REF-1) plus seeded replay scenarios. Nothing is presented as a real mission.
  3. Citations are load-bearing. A grounded step with no citation is a violation; an UNGROUNDED step that carries a citation is also a violation. A hallucinated reference is a sev-1.
  4. Agents reach data only via the MCP client. Enforced by import-linter.

See Security overview for the full model.

Built by SKOPAQ AI Pvt Ltd. Proprietary. This documentation describes the system as built; where something is planned rather than shipped, it is marked roadmap.