5 min read

Is Your UCP Validator Lying to You About Cart and Catalog?

Draft-spec capabilities like Cart and Catalog break validators that can't tell the difference between a spec evolution and a real failure. Here's how draft-aware validation works and what to check in your current workflow.

Is Your UCP Validator Lying to You About Cart and Catalog?

You ran validation. Your store got a "FAIL" on Cart and Catalog capabilities. The report says your catalog endpoint returns an invalid response shape. Your cart lifecycle doesn't match the schema. You spend an afternoon debugging endpoints that look fine when you test them manually. You open a support ticket with your platform provider.

The problem isn't your store. It's your validator.

The draft-spec trap nobody talks about

The Universal Commerce Protocol isn't static. It's a living specification with capabilities at different maturity levels. As of the April 2026 release:

  • Identity Linking is stable. The spec is finalized. Agents expect a specific response shape, and that shape won't change without a new protocol version.

  • Cart and Catalog are draft. The endpoints exist. They work. Agents interact with them in production. But the schema, the response shapes, the exact field names - these are still evolving. The spec explicitly says they "MAY version independently when breaking changes are required."

Here's what happens when a validator doesn't distinguish between stable and draft capabilities:

Your Catalog endpoint returns products correctly. An AI agent asks "show me hiking boots under $200" and your store responds with actual products. But the response includes an optional metadata field that the draft spec didn't mention six months ago. Or it nests variant data differently than the current draft expects. Or the pagination token uses a slightly different key name.

A spec-unaware validator sees this mismatch and flags it as a failure. Hard stop. Red X. "Catalog validation failed." Your dashboard says your store isn't agent-ready.

The agent, meanwhile, browses your catalog just fine. It reads the products that matter, ignores the extra fields, and builds a cart. Your store works in practice. Your validator said it doesn't.

What a hard-fail actually costs you

False negatives aren't just annoying - they steer you toward the wrong work.

When your validator says Cart validation failed, you investigate. You read the draft spec. You compare your endpoint response to the schema. You spend hours figuring out whether the mismatch is on your side or the spec's. You might even modify your endpoint to match a draft schema that changes next month.

Meanwhile, the actual problems - the ones that stop real agents from completing purchases - go unnoticed. Your signing keys rotated and the manifest wasn't updated. Your CDN changed how it serves .well-known/ucp. Your payment handlers reference an old gateway endpoint. These are genuine, production-breaking failures that get buried under draft-spec noise.

The validator that flags everything with equal severity trains you to ignore all of it.

The fix: draft-aware validation

As of July 2026, UCPtools handles draft capabilities differently. When validating Cart and Catalog:

  • Stable spec requirements are checked as before. If your Cart endpoint returns a 4xx response code, if your Catalog doesn't serve JSON at all, if a required stable-spec field is missing - those are real failures.

  • Draft-spec mismatches produce warnings, not failures. If your response shape doesn't match the current draft schema, if an optional field is present that the draft doesn't document yet, if the nesting structure changed - you get a clear warning explaining what's different and why it might matter, not a red X that blocks everything else.

The difference: you still see the mismatch. You still know something changed. But you're not punished for a moving target. Your validation score reflects what actually breaks agent interactions, not what might break them six months from now.

Three things to check in your current validation workflow

1. Does your tool report spec status for each capability?

If every failure looks the same - same severity, same color, same urgency - you can't tell a broken endpoint from a draft-spec evolution. Your validation should distinguish between "this will stop an agent today" and "this may not match the spec next quarter."

2. Does a Cart/Catalog failure block your entire validation run?

A genuine signing_keys failure and a draft-spec Catalog warning are not the same problem. If your tool treats them identically, you're spending time on the wrong one.

3. When was your tool last updated against the current UCP spec?

The April 2026 update was the largest spec release since January. If your validator hasn't been updated since then, it's validating against a version of the protocol that no longer reflects what agents expect - for both stable and draft capabilities.

The spec is moving. Your validation should move with it.

Google shipped the April 2026 update with Cart, Catalog, and Signals. Shopify Editions Spring '26 made UCP the default on every store. The protocol is in active development - and that's a good thing. It means agentic commerce is real enough that the spec keeps improving.

But it also means point-in-time validation tools that don't distinguish between draft and stable create more noise than signal. You end up debugging spec evolution instead of fixing what actually breaks agent interactions.


Want validation that treats draft specs like drafts? Validate your UCP profile now - free, no account needed. Our 4-level validation flags draft-spec mismatches as warnings so you can focus on what actually stops AI agents from buying from your store.

Running validation across multiple domains? Start a free 7-day trial for monitoring, multi-domain dashboards, and weekly automated checks. No credit card required.

← Back to Blog