Components

component means one public compatibility contract for a component-role subsystem. A component is composed from one or more API contracts. Component IDs are what component-role subsystems expose to other subsystems and compound robots.

The canonical component roots are these.

Root	Role	Meaning
component.*	component	semantic components such as mobile-base, manipulator, gripper, and perception subsystems

This is intentionally narrower than robot and narrower than capability. A robot contains gateway, component, compound, and app subsystems. A component.* ID names the public compatibility promise of a component subsystem, not the whole robot and not an app-facing capability.

Public Rule

Use component.* when a component-role subsystem provides a component.

provides:
  manipulator:
    contract: component.manipulator.v1

API Contracts such as api.motion.manipulator.state.v1 remain the validation unit behind the component. Gateways still provide api.* contracts directly, and compound subsystems provide capability.* contracts to apps.

The conformance_apis field in a component spec is not the same thing as a manifest requires block. It lists the API contracts that define the component's public behavior. The runtime binding direction is still decided by the subsystem manifest. A provides entry claims a provider of that component, and a requires entry asks for a provider of that component.

Summary Table

Canonical contract	Role	Backing API contracts
component.articulated.trajectory.v1	component	articulated state articulated trajectory
component.articulated.velocity.v1	component	articulated state articulated velocity
component.manipulator.v1	component	articulated state articulated velocity articulated trajectory manipulator state manipulator cartesian manipulator tooling
component.gripper.v1	component	api.end_effector.gripper.v1
component.mobile_base.v1	component	locomotion velocity mobile-base state
component.mobile_base.localized.v1	component	locomotion velocity mobile-base state localization
component.mobile_base.autonomous.v1	component	locomotion velocity mobile-base state localization navigation
component.perception.v1	component	api.perception.query.v1

Component Subsystems

Component subsystems expose semantic control contracts. They should not own fieldbus resources such as NICs, CAN, RS-485, or SPI directly. CPU and scheduling claims are allowed when a controller needs deterministic execution, but hardware interface resources belong behind a gateway subsystem.

Components here are intentionally closed compatibility promises.

• no optional API contract set
• no basic/standard/advanced ladder unless the API surface is actually distinct
• if two component bundles differ semantically, give them different component IDs

Gateway Contracts

Gateway subsystems aggregate one or more physical hardware channels and expose them as api.* contracts. This is the standard place to hide EtherCAT, CAN/CANopen, serial, I2C, SPI, or vendor-specific SDKs.

The public contract describes the semantic gateway role, not the underlying bus.

Compound Contracts

Compound subsystems aggregate component and gateway interfaces into application-facing capability.* contracts. A compound subsystem may require component.* contracts when it is coordinating standard controllers, and it may also require api.* contracts when a robot-specific capability needs direct gateway access such as a digital output or custom actuator channel.

Applications should bind to the compound capability surface instead of binding to the lower-level component or gateway topology.