# Interop SIG, 05 November 2026: Capability Declarations

**URL:** <https://discourse.openrobotics.org/t/interop-sig-05-november-2026-capability-declarations/59512>\
**Category:** OSRA Announcements and News\
**Tags:** open-rmf, interoperability\
**Created:** [November 4, 2026, 4:56am UTC](https://discourse.openrobotics.org/t/interop-sig-05-november-2026-capability-declarations/59512 "2026-11-04T04:56:16Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![grey](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/grey/32/10444_2.png) [@grey](https://discourse.openrobotics.org/u/grey)\
**Post date:** [November 4, 2026, 4:56am UTC](https://discourse.openrobotics.org/t/interop-sig-05-november-2026-capability-declarations/59512/1 "2026-11-04T04:56:16Z")

</div>

[Meeting Link](https://meet.google.com/nyz-isrs-kzz)

[Calendar Link](https://calendar.google.com/calendar/u/0/embed?src=agf3kajirket8khktupm9go748@group.calendar.google.com)

2026-11-05T15:00:00Z

The Next Generation Open-RMF initiative aims to have a highly modular architecture that will allow users to swap out parts of the system (e.g. Traffic Management, Task Management, Execution, Door Management, Elevator Management) with alternative implementations. This framework is meant to be deployed across many different kinds of environments which may have different kinds of devices and drastically different use cases. As a result, there won’t be a one-size-fits-all set of features or behaviors for the modules. A factory environment may care about high throughput above all else, whereas an airport environment may care about robustness to human presence more than throughput. This can lead to preferring different traffic management algorithms for each environment, and those traffic management systems may have different behaviors, capabilities, and requirements.

This will lead to significant complexity in understanding how to compose an Open-RMF system correctly, because now the user needs to ensure that all the modules they choose to use are compatible _and_ are suitable for their use-case and environment. It also complicates integration and e2e testing since expectations will vary by the choice of module implementations.

This month’s discussion will be about **Behavior Declarations** , a concept we’re introducing to Next Gen Open-RMF to allow module implementations to declare (e.g. through a manifest file) what their capabilities and behaviors are, in a formal, extensible way. This will help users validate that combinations of module implementations match their intended use cases. Moreover, we will use these declarations to auto-generate and/or configure expectations for integration tests and e2e tests for combinations of module implementations.