LCPLegal Context Protocol

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.