ROBOT CAPABILITY MODEL

A body description says what exists. A capability model says what the embodiment can do.

Capability modeling bridges physical resources and task semantics: actions should be grounded in required sensors, actuators, preconditions, constraints and expected effects.

CITATION RECORDCanonical source ↗
MATURITYMIXED — EXPERIMENTAL + CANDIDATE
LAST VERIFIED22 Sep 2026
SOURCE VERSIONAgency skill schema + CapabilityPlan / Somatic Contract 0.1.0
EVIDENCE BOUNDARYCapability primitives exist at mixed maturity; no universal OpenRGD capability ontology is claimed stable.

TERMINOLOGY

Capability, skill, task, action and affordance should not be treated as interchangeable.

01

Capability

A declared ability of the embodiment under specified prerequisites and constraints.

02

Skill

A reusable behavior or policy that may realize one or more capabilities.

03

Task

A goal-oriented unit of work to be achieved in a context.

04

Action

An explicit operation or semantic intent considered for execution.

05

Affordance

A relation between agent/body and environment that makes an action possible.

06

Resource

Sensors, actuators, body parts, software or context required to realize the capability.

GROUNDING

A useful capability should be testable against the actual embodiment.

KnowRob/SRDL has long represented robot hardware, software and capabilities and can check whether dependencies of action descriptions are available on a robot. OpenRGD’s current Agency material explores a similar practical problem from an embodiment-profile perspective.

01Body resources
02Capability declaration
03Preconditions
04Skill / policy
05ActionIntent
06CapabilityPlan
07Safety gate
08Execution

OPENRGD CURRENT WORK

The repository already exposes useful capability primitives — with mixed maturity.

The current skill schema includes required sensors and actuators, world-model preconditions, safety envelopes, control profiles, runtime learning policy and fallback behavior. Separately, the candidate Somatic Translation contract defines a hardware-agnostic CapabilityPlan.

These artifacts are valuable design evidence, but they do not all share the same maturity. The CapabilityPlan contract remains candidate, and OpenRGD.org should present capability modeling as an evolving architectural area rather than a finalized universal ontology.

WHY VLA NEEDS THIS

Generalist models still need embodiment-specific grounding.

A model can propose “pick up the box,” but a heterogeneous robot fleet needs a separate answer to: which embodiment has the sensors, reach, gripper, payload, safety envelope and context required to perform that action? Capability models make that compatibility problem explicit.

PRIMARY SOURCES