The agent cannot try the shoe on. So we wrote the measurements down.

In July we wrote that the agentic commerce stack had four floors, communication, commerce, authorization, settlement, and that one floor was missing: the body. An agent could compute what a return would cost down to the öre, and could not say whether the shoe would fit. We said that whoever wrote that part would shape the category, and that nobody was writing it.

Since then we have read the specifications properly, line by line, and published a first draft. This is what we found, and what we put forward.

What the protocol says about fit today

The Universal Commerce Protocol has grown quickly since January: a Stripe seat on the governing council, technical councils for payments, lodging and food, a release in August, a lodging specification in September. The repository changes almost daily. We read the whole of it with one question: where does fit live?

The answer is in two places, and neither is usable by a machine.

• Size as a label A product variant carries options, and size is one of them, in the same family as colour and material: a list of values such as EU 38, 39, 40. The schema's own description reads "A product option such as size, color, or material." The label carries no information about what the shoe measures inside.
• Fit as free text The ask capability lets an agent put a plain-language question to the merchant, and the specification's own example is a fit question: "Does this jacket run small?" The answer comes back as plain text, "runs true to size," and the specification describes that answer as indicative. It is the review-page advice that shoppers already get, now relayed by a machine that cannot weigh it.

Nothing on the roadmap changes this. Loyalty, upsell, local pickup, food and hotels are listed. Fit is not.

An agent can ask a merchant whether a shoe runs small. It cannot ask how long the inside of the shoe is, because there is no field for the answer.

The vocabulary already exists

This was the part we did not expect. We assumed that the measurement language for the inside of a shoe would have to be invented. It does not.

The international committee for footwear sizing, ISO/TC 137, maintains a full set of definitions: Mondopoint for the foot (ISO 9407), a sizing vocabulary (ISO 19408), a standard for measuring last dimensions (ISO 19409), a standard for measuring inside the finished shoe (ISO 19410-1), and a 2025 report on global last measurement systems. For the body more broadly there is ISO 7250, and for 3D body data the new IEEE 3141-2026, currently being revised for AI.

Decades of work. The numbers are produced in the factory, and they stop there. They do not appear on a product page, in a catalogue feed, or in any commerce protocol. Nobody needs to invent a language for fit. Somebody needs to carry the existing one across the gap between manufacturing and retail, so that an agent can read it.

What we put forward

UCP's contribution guide is explicit about how new ideas enter: build them under your own namespace first, propose them for the core once more than one party uses them. So that is what we did. The draft is called ai.vsize.shopping.fit. It extends catalog search and lookup, the discovery phase, where an agent decides what to consider. It has three parts.

1. The variant carries its internal dimensions. Not a size label but the space inside the shoe, in millimetres, with a tolerance and a source. The field names follow ISO 19409 and 19410-1 where a term exists.

"fit": {
  "internal_dimensions": {
    "functional_length_mm": 257.0,
    "ball_width_mm": 92.5,
    "ball_girth_mm": 238.0,
    "instep_girth_mm": 244.0,
    "heel_width_mm": 63.0,
    "toe_height_mm": 27.5,
    "tolerance_mm": 2.0,
    "source": "last_derived"
  }
}

source is one of last_measured, last_derived, in_shoe_measured, estimated. An agent should be able to tell a fact from an estimate, so the field is required.

2. The buyer supplies a foot profile, with consent. One entry per foot, because feet differ. It travels in the request context that UCP already defines for provisional, non-identifying buyer signals. It belongs to the buyer, is sent per request, and may not be stored by the merchant without separate consent.

"foot_profile": {
  "feet": [
    { "side": "left",  "length_mm": 251.0, "ball_width_mm": 94.0 },
    { "side": "right", "length_mm": 254.5, "ball_width_mm": 95.0 }
  ],
  "measurement_method": "phone_scan",
  "measured_at": "2026-10-20",
  "consent": true
}

3. The answer is an assessment with its uncertainty attached. When both are present, the variant also carries a zone-by-zone comparison. Confidence is required. unknown is a valid verdict. Who made the assessment is always stated, so an agent can decide whom to trust.

"fit_assessment": {
  "overall": "good",
  "confidence": 0.78,
  "zones": [
    { "zone": "toe",    "delta_mm":  4.5, "verdict": "good" },
    { "zone": "ball",   "delta_mm": -1.5, "verdict": "snug" },
    { "zone": "instep", "delta_mm":  2.0, "verdict": "good" },
    { "zone": "heel",   "delta_mm":  0.5, "verdict": "good" }
  ],
  "limiting_zone": "ball",
  "assessed_by": "ai.vsize"
}

Three things are deliberately absent: reviews and return statistics, size conversion (ISO 19407 already does that), and any storage of foot data on the merchant side.

Why measurements and not opinions

There are two ways to tell an agent whether a shoe will fit. One is to summarise what other people said and did: reviews, exchanges, keep rates. The other is to compare two geometries: the foot and the inside of the shoe.

A human shopper can use opinions, because they weigh them against their own experience. An agent acting under a mandate has no experience to weigh them against. If agentic commerce is built on "runs small, size up," it is built on the one input the agent is least equipped to use. The extension is written so that the input is a measurement, the output is a measurement with a confidence, and the agent does the comparison. That is also what makes it neutral: any merchant can publish dimensions, any scanner can produce a foot profile, any assessor can be named in assessed_by.

What is open

A draft is a set of questions with a shape around them. Three are open, and we have asked them in the protocol's own forum:

1. Do internal dimensions belong on the catalog variant, or in a capability of their own?
2. May a foot profile travel in catalog context, or does buyer measurement data need a consent path of its own, as identity linking has?
3. May a schema reference an externally governed, paid standard such as ISO 19409, the same question the print industry has raised for its own vocabulary?

And one is on us. The extension asks for internal dimensions per variant with a stated tolerance. We derive them from the last, and we publish a tolerance precisely because a measurement without one is not a measurement. Coverage grows one last at a time, starting with the brands we work with. The field is open for anyone who can measure.

Where to find it

The schema is at vsize.ai/ucp/schemas/fit.json, the specification at vsize.ai/ucp/fit, and the discussion where it was proposed is UCP #1027. If you run a footwear catalogue, build foot scanners, or write shopping agents, and you would want to expose or consume these fields, that thread is the place to say so. The draft becomes a proposal to the core the day a second party uses it.

In July the floor was missing. Now there is a drawing of it, in public, with the measurements written in.

← All insights