Allow capability-scoped services in Business profiles

[DevinCodes]

Hey all!

First off, thank you for all your work on this. Very excited to see the field evolving and the role you're playing in this. I'd like to propose a change to the spec to make it a bit more flexible, in the hopes to make it easier to adopt UCP.

Today, a UCP Business profile declares the services, capabilities, and payment handlers it supports. The service binding operates at the service/transport level, such as a single REST endpoint used as the base URL for the entire UCP API surface.
That works well when a business can expose its UCP implementation through one service. But many businesses are headless, composable, or somewhere in between. Catalog discovery, availability, cart, checkout, payments, order management, and post-purchase workflows are often owned by different systems.

For example, a business might use an inventory or PIM system for product data and availability, a commerce SaaS to handle cart and order management, a custom payment gateway, and a third-party search provider for catalog search and lookup. For those cases, the current model pushes the business toward either fronting the full UCP surface through one service or building a custom aggregation layer that fans out to the systems that actually own each capability. Both options add avoidable complexity: the first centralizes ownership of capabilities that may belong to different systems, resulting in potential loss of functionality or personalization that the business has put in place, while the second creates a bespoke orchestration layer for routing, consistency, error handling, and lifecycle management that adds a big upfront investment as well as maintenance cost.
I’d like to propose allowing a Business profile to bind specific capabilities, or groups of capabilities, to specific service endpoints.

The Business would still publish one coherent UCP profile and remain the authority for capability negotiation, as well as the single integration point for platforms. Platforms would still interact through UCP semantics, schemas, authentication, and transport bindings. The change would simply allow the different systems managed by the business to expose parts of the UCP API that are relevant to their domain.

This could be done, for example, by adding a capability binding field to service transport declarations, or by allowing multiple declarations for the same service namespace where each declaration has an id and an explicit capability subset. Existing behavior could remain the default when no capability binding is present.

This would reduce implementation friction, especially for headless and composable commerce architectures. It would also make incremental adoption easier: a business could expose catalog first, checkout later, order management later, without having to build a UCP aggregation layer up front. Allowing for decoupling of capabilities on a per-service basis would also mean parts of UCP could still work if other services are degraded.

A more detailed RFC would need to address the edge cases here. It should lay out a deterministic endpoint-resolution path so a platform can map a negotiated operation to exactly one UCP-compliant endpoint. It should also define how authorization works across capability-scoped endpoints, whether that means using the Business signing keys directly, delegated signing keys, or an explicit delegation mechanism. If a Business exposes multiple capability-scoped endpoints, it is still responsible for consistent IDs, state transitions, idempotency, pricing, availability, and error behavior across the negotiated UCP flow. This change should not change the Business’s responsibility for end-to-end correctness.

Curious whether others see this as useful. If so, I’m happy to draft an RFC with concrete schema changes, endpoint-resolution rules, examples, and backwards-compatibility considerations.