UCP Core Concepts: Service / Capability / Extension and Profile Negotiation

Start with a “Minimal Mental Model”

UCP breaks down a commercial interaction into three layers (officially called core constructs):

• Service: Defines an API surface and transport bindings for a vertical domain (e.g., shopping, common).
• Capability: An independent functional unit within a service (e.g., Checkout / Identity Linking / Order).
• Extension: An optional module that enhances a capability through extends (e.g., discounts, fulfillment, AP2 Mandates).

The engineering value of this breakdown is that platforms and businesses can use “intersection negotiation” to select the capability combination to activate for each session, rather than developing custom integrations for every combination.

Profile: The Carrier for Discovery and Negotiation

In the official specification, businesses publish a Business Profile at /.well-known/ucp, while platforms declare their Profile URI in requests. The business calculates the intersection and returns the list of active capabilities for the session.

Below is an example from the official specification (showing the basic structure of services/capabilities):

{
  "ucp": {
    "version": "2026-01-11",
    "services": {
      "dev.ucp.shopping": {
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/overview",
        "rest": {
          "schema": "https://ucp.dev/services/shopping/rest.openapi.json",
          "endpoint": "https://business.example.com/ucp/v1"
        }
      }
    },
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      }
    ]
  }
}

Two Key Points to Watch During Implementation

• Namespace and spec URL binding: Official requirements state that the origin of a capability’s spec/schema URL must match the namespace authority domain (e.g., dev.ucp.* must be https://ucp.dev/...). Platform side should validate and reject when there’s a mismatch.
• Extension pruning: Extensions depend on parent capabilities. If a parent capability is not in the intersection, the extension must be removed, and pruning must repeat until stable.

Continue Reading

• specification/overview: Namespace governance, service definitions, profiles, intersection algorithms, and Schema composition (official specification)
• documentation/core-concepts: Four participant roles and three-layer model (official documentation)
• On-site: Start with Core Concepts and Specification Overview

Canonical Sources

• Official Core Concepts: https://ucp.dev/documentation/core-concepts
• Official Specification Overview: https://ucp.dev/specification/overview