UCP Integration
Universal Commerce Protocol — links for discovery, policies[] for a per-transaction record. There is no extensions map.
This section is advisory and non-prescriptive. It describes what the host protocol permits, read from its own primary artifact. Where this page and the host protocol disagree, the host is correct — build from its schema, not from an example here.
What it is. An open-source standard for the full commerce lifecycle (discovery, catalog, checkout, orders, fulfillment, post-purchase adjustments). Uses composable extensions with reverse-domain naming. Publishes a well-known discovery file at /.well-known/ucp.
Tier A — Available today, at two strengths.
Links, for discovery without integrity. UCP checkout responses include a required links array with
privacy_policy and terms_of_service as well-known type values. Terms become discoverable without
coordination — but a standing policy page is not a per-transaction terms record and carries no hash.
Policies, for a per-transaction record in the negotiated baseline. policies is a property of the base
checkout schema — not an extension, so it needs no negotiated intersection. The schema describes a policy as a
durable business rule about the items in a response; its type is an open reverse-DNS vocabulary whose two
well-known values are dev.ucp.shopping.policy.return and dev.ucp.shopping.policy.warranty, in which
"Businesses MAY define custom types in their own domain" and "Platforms MUST tolerate unknown values". A policy
object is additionalProperties: true. description is REQUIRED beside type and is a Description object
(plain, html or markdown — at least one of them), not a bare string. applies_to carries RFC 9535
JSONPath expressions relative to the response root, and the schema notes that when it is absent or empty the
reader should refer to the URLs in links[]:
{
"policies": [
{
"type": "com.example.policy.legal_context",
"description": { "plain": "Terms of sale governing this order." },
"url": "https://example.com/terms/v3.md",
"atrHash": "0x7f83b165..."
}
]
}Tier B — Forward work. A capability in UCP's own dev.ucp.* namespace would put legal context in the
negotiated baseline rather than requiring both parties to declare it. That is the only part of the UCP path
that needs the working group.
Limitations. There is no extensions map on the UCP checkout response. Extensions compose onto the
base schema via allOf and surface as top-level fields — the checkout schema's own description says so — so a
reference written into an extensions container is never read. The constraint on a vendor capability is not
registration but negotiation: capabilities activate only within the negotiated intersection of what both
parties declare, so a published LCP capability the counterparty does not declare is silently excluded rather
than rejected loudly, and it does not degrade to a weaker form. A deployment that requires legal context to be
present regardless SHOULD carry it in policies[], which is in the base schema and whose unknown types
platforms are required to tolerate.
Relationship to existing UCP capabilities. UCP's Buyer Consent extension provides declarative consent capture; LCP Level 3 provides cryptographic consent. The two compose. UCP's Adjustments framework logs post-purchase events including disputes but provides no resolution mechanism; LCP Level 4 provides the mechanism.
Steward invitation. The UCP working group is invited to register legal-context as a first-class extension and publish guidance on its interaction with Buyer Consent and Adjustments.