Capabilities

A capability is a free-form identifier a package declares to advertise what it provides or requires. The catalog stores them but does not yet enforce provider-consumer matching — that is target state.

Today's behavior

A package may declare capabilities at two levels:

Top-level (matrix.json.capabilities[]): aspirational summary for the whole package.
Component-level (matrix.json.components[*].capabilities[]): per-actor.

The catalog stores both, but treats them independently. There is no automatic aggregation from component to package or vice versa.

Capabilities are searched by:

bash

# Find packages declaring a capability
matrix invoke system.packages registry.search '{"capability":"inference"}'

Match is case-insensitive equality against metadata.capabilities[]. Component-level capabilities are searched separately via the text query field collection (component.capability lines).

Naming convention

There is no enforced grammar. Convention from existing packages:

Capability	Meaning	Example packages
`inference`	Provides LLM inference (request/response or streaming)	`@open-matrix/system-inference-openai`, `@open-matrix/system-inference-anthropic`
`chat`	Provides chat conversation/threading	`@open-matrix/chat`
`auth`	Provides authentication/session	`@open-matrix/system-auth`
`gateway`	HTTP gateway behavior	`@open-matrix/system-gateway-http`
`device`	Device linking/inventory	`@open-matrix/system-devices`

These are not enforced anywhere. A package may declare any string. Standardizing the vocabulary is a future workstream item.

Required vs. provided

Status: target state. The discovery-metadata spec (WORKSTREAMS/core-and-packaging/MATRIX-DISCOVERY-METADATA-SPEC.md) distinguishes CapabilityDeclaration.requires and CapabilityDeclaration.provides. The catalog field today is a single capabilities[] array, with no requires/provides split. Future manifest versions will separate them.

When that split lands, a package's required capabilities will be checkable against another package's provided capabilities at install time. Today this is documentation-only.

What capabilities are NOT

Not permissions. A capability says what a package can do, not what it is allowed to do. Permissions are enforced by matrix.json.permissions (fsPolicy, network, subprocess, env).
Not actor ops. An actor's accepts[] lists ops; capability is a higher-level descriptor.
Not skills. skills[] is for agent-level discovery (e.g. "this actor can summarize text"); capability is for runtime/component composition.

Example

json

{
  "name": "@open-matrix/chat",
  "capabilities": ["chat", "ui"],
  "components": [
    {
      "type": "ChatActor",
      "mount": "chat",
      "capabilities": ["chat.threads", "chat.history"],
      "skills": ["summarize", "translate"]
    }
  ]
}

A search like capability=chat matches this package via its top-level declaration. A search via the text field for "chat.threads" matches via the component-level capabilities.

Capabilities ​

Today's behavior ​

Naming convention ​

Required vs. provided ​

What capabilities are NOT ​

Example ​