Vega
Capability Development

Overview

A Vega Capability is an independently packaged and versioned unit of functionality that extends Vega Runtime through the public Capability manifest and Vega Capability SDK. Each Capability owns one bounded integration domain — robot, device, vendor API, or service.

Concepts

TermMeaning
Capability packageA directory containing capability.yaml, schemas, Provider code, and optional configuration assets.
ProviderA Python object that implements the VCP lifecycle and Actions.
ActionA versioned, schema-defined operation declared in the Capability manifest.
ManifestPortable declaration of identity, compatibility, resources, configuration, dependencies, secrets, and Actions.
Backend adapterCapability-owned code that isolates vendor or robot APIs from Provider logic.

Why Capabilities exist

Capabilities let a team add one domain-specific function without modifying Vega Runtime. A speech Capability owns its audio integration; a vision Capability owns its camera and inference dependencies; an HTTP Capability owns its service client. Each package is versioned, tested, deployed, and upgraded independently.

Vega Runtime
Capability Provider
Capability adapter
Robot, device, or service

Responsibilities and boundaries

  • Declare what each Action can, cannot, requires, guarantees, and limits.
  • Validate integration-specific preconditions and use injected context services.
  • Keep vendor dependencies inside the Capability package and report physical uncertainty accurately.
  • MUST NOT import vega.* Runtime internals.
  • SHOULD NOT make Runtime scheduling, mission retry, resource arbitration, or recovery decisions.
  • MUST NOT claim an external or physical effect it cannot establish.

Relationship with Runtime, SDK, and VCP

The Runtime validates, loads, initializes, invokes, and shuts down a Provider. The SDK is the current Python binding used by Provider code. VCP defines the public manifest and Provider contract surface. Current VCP has no remote transport; the Runtime invokes loaded Python Providers through the SDK contract.

Lifecycle and workflow

Design
Package
Validate
Test
Deploy
Initialize
Execute
Maintain
  1. Define a narrow outcome and its operational boundaries.
  2. Design input, output, and optional progress schemas.
  3. Create the manifest and package structure.
  4. Implement a Provider with a separate backend adapter.
  5. Validate, test, package, and deploy in controlled stages.

Example

The repository's unitree_go2_speak package implements speech.speak. It declares a Unitree Go2 compatibility boundary, an exclusive speaker resource, non-idempotent execution, progress support, and no restart recovery. Its Provider delegates work to a backend adapter and accurately reports uncertain physical termination for the Go2 bridge.