Commerce Execution Assurance
CRAB Q&A
What commerce execution assurance is, what CRAB verifies, and what it deliberately does not claim.
Every answer here describes what the engine does today. Where a capability is implemented but not yet exposed automatically to the public, the answer says so.
The category
What is Commerce Execution Assurance?
Commerce Execution Assurance is the independent verification that a commerce journey produces the correct commercial outcome — that the specific product, variant, option and quantity a buyer asked for survives discovery, selection, the cart and the checkout boundary, with evidence for each step.
It is distinct from uptime monitoring, which asks whether a site responds; from SEO and structured-data auditing, which ask whether a store can be found and understood; and from protocol conformance testing, which asks whether an endpoint answers correctly. A store can pass all three and still put the wrong item in the basket.
CRAB is VSN's implementation of this category. The method it applies is the Commerce Execution Method (CEM).
#
What is agentic commerce?
Agentic commerce is commerce in which the buyer is an autonomous software agent acting for a person — finding the product, choosing the variant, adding to the cart and reaching checkout without a human reading the page at each step.
The shift matters because of what it removes. A human notices instantly that the cart shows a 41 when they asked for a 42, or a 250ml when they asked for 500ml. An agent has no such reflex. Whatever the page returns is what it proceeds with, so errors that a person would catch and silently correct now travel all the way to checkout.
#
What is an AI shopping agent?
An AI shopping agent is a program — usually built on a language model driving a browser or calling a merchant's interfaces — that carries out a buying task from an instruction such as "order the black size 42".
It reads the page or the API response, decides what to click or call next, and reports what it did. That last part is the problem CRAB exists for: the agent's report is a claim about the agent, not a fact about the shop.
#
Can AI agents buy from ecommerce websites?
Often they can complete the mechanical steps — locate a product, select options, add to cart, reach a checkout. Whether they end up with the right item is a separate question, and it is the one that decides whether the transaction was a success.
In our own inspections we have observed journeys that reached checkout carrying a different variant than the one requested. Mechanically successful, commercially wrong.
#
What does "agent-ready is not commerce-ready" mean?
Agent-ready describes a store an agent can operate: readable markup, working controls, published structured data, perhaps a machine-readable commerce interface.
Commerce-ready describes a store where operating it produces the correct commercial result. The first is about access. The second is about outcome. A store can be entirely agent-ready and still fail the only test that matters to a buyer.
#
What is the difference between discoverability and execution?
Discoverability is whether your product can be found and understood — indexing, feeds, structured data, machine-readable surfaces. Execution is whether the buying journey then delivers that exact product.
Discoverability is necessary and is not sufficient. Being found perfectly and then adding the wrong variant to the cart is a worse outcome than not being found, because it consumes the buyer's trust as well as their time.
#
What CRAB verifies
What does CRAB test?
CRAB inspects one commerce mission — a specific intended product on a specific authorised store — across nine canonical stages: discovery, identity, price, availability, add to cart, verify item, cart, checkout and totals.
At every stage it records what the surface said about the item's identity, and compares it with what was requested. The result is a merchant verdict, an inspection-validity assessment, an attribution, and the evidence each rests on.
#
How is CRAB different from a traditional ecommerce audit?
A traditional audit reviews configuration, markup, performance and best practice, and produces recommendations. It largely inspects the shop at rest.
CRAB executes the buying journey and verifies the commercial outcome, then retains the evidence so the finding can be checked by someone who does not trust CRAB. It reports what happened, not what should be improved — CRAB never implements or remediates what it verifies.
#
Why is reaching checkout not enough?
Because reaching checkout only proves the journey completed, not that it carried the right thing. Getting something into the cart is not success. Getting the right product into the cart is.
A checkout holding the wrong variant is a completed journey and a failed transaction. Measuring completion alone reports it as a pass.
#
How can the wrong product or variant reach a cart?
Common causes we have observed include: a default variant silently substituted when the requested one is unavailable; an option selector that updates the visible label but not the underlying variant; a sibling SKU with a near-identical name being matched instead of the requested one; a quantity that resets; and a cart that reflects a previous session's item.
None of these announce themselves. The page looks correct, the journey completes, and the basket is wrong.
#
What is product identity preservation?
It is the requirement that the item identified at each stage is the same item that was requested — tracked as a typed identity through requested, discovered, product, selected, add, cart and checkout.
The governing rule is that no downstream success may erase an upstream identity violation. Size 42 requested, size 41 in the cart, checkout reachable: that is a violation with a reachable checkout, not a success.
#
What is variant integrity?
Variant integrity is identity preservation applied to the dimensions that distinguish one purchasable item from its siblings: size, colour, capacity, material, edition, bundle, and any other option axis a merchant defines.
CRAB compares option axes by name, so it is not limited to size and colour. A different option value is a different commercial thing.
#
How does CRAB verify a shopping journey?
It freezes the requested identity before the journey starts, executes the journey against an authorised store, records typed observations and evidence at each stage, compares each observation with the frozen request, and produces a canonical record bound to an evidence-integrity manifest.
The comparison is deterministic. No language model participates in deciding whether two items are the same item.
#
How does CRAB detect the wrong variant?
By comparing typed identifiers rather than appearances. A disagreement on a strong identifier — variant id, SKU, product id, canonical product reference — is decisive and is never outweighed by agreement elsewhere. A matching page title cannot rescue a mismatched SKU.
Where a catalogue contains near-identical neighbours, CRAB also builds a bounded confusion set of candidates and assesses whether the requested item could be distinguished from them at all. If it could not, CRAB says the assurance is incomplete rather than claiming a pass.
#
Agents, evidence and trust
Does CRAB trust an AI agent when it says it succeeded?
No. An autonomous executor's self-report is recorded as evidence about the executor and is never the source of truth about the merchant.
This is structural, not a matter of policy: the canonical verdict is derived from observed evidence, and a self-report has no path into it.
#
What happens if an agent says success but the cart contains the wrong item?
The inspection records an identity violation and the merchant verdict follows the evidence, not the agent. Both facts are retained — the executor said SUCCESS, and the cart held a different item — because the disagreement is itself informative.
We ship a reference assurance bundle demonstrating exactly this case so it can be examined rather than taken on faith.
#
What is deterministic commerce verification?
It means the same evidence always produces the same conclusion, because every comparison is a typed, rule-based operation that a reviewer can reproduce by hand.
Identity equality, price comparability, availability mapping and change classification are all deterministic. Where a mapping cannot be made deterministically, CRAB records that it was not observed rather than guessing.
#
What evidence does CRAB retain?
Per-stage observations with their provenance, the artifacts they were derived from, and a SHA-256 evidence-integrity manifest with a deterministic root hash. For a machine-readable channel it also retains a digest of the exact response bytes, an allowlisted projection of the commerce fields, and the source path behind every canonical value.
It deliberately does not retain credentials, cookies, headers, tokens or customer identity. Evidence records have no field for a header set, so there is nowhere for a credential to land.
#
What is commerce execution evidence?
It is the retained material that supports a commercial conclusion: what each surface said the item was, when, and where that came from — enough that an independent reviewer can re-derive the conclusion without re-running the journey and without trusting the tool that produced it.
#
Does CRAB place real orders?
No. CRAB stops at the ordinary checkout boundary. It does not place an order, submit a payment, or complete a purchase.
#
Does CRAB enter payment details?
No. CRAB never submits payment credentials, never fabricates a customer identity or address, never creates accounts and never requires admin credentials.
Where a figure such as a delivery-inclusive total genuinely requires a destination, CRAB reports the total as not observed rather than inventing one.
#
What ecommerce platforms does CRAB support?
CRAB inspects the browser commerce journey, which is platform-independent, and has platform-specific support for Shopify, WooCommerce and Magento / Adobe Commerce. See the platform pages.
#
Does CRAB support Shopify?
Yes — the browser journey, plus the Shopify Ajax cart endpoint as a machine-readable merchant channel, so the merchant's own account of the cart can be compared with what the storefront displayed.
#
Does CRAB support WooCommerce?
Yes — the browser journey, plus the WooCommerce Store API cart as a machine-readable merchant channel, so the merchant's own account of the cart can be compared with what the storefront displayed.
The Store API is read only in CRAB. The adjacent routes that would change a cart are never called.
#
Does CRAB support Magento / Adobe Commerce?
Yes, for the browser commerce journey. There is no Magento-specific machine-readable channel adapter today; the browser inspection is platform-independent and applies in full.
#
What is UCP?
UCP refers to proposed universal commerce protocol work intended to let agents interact with merchants through a defined machine interface rather than by driving a storefront.
CRAB does not currently implement UCP. It appears in our channel vocabulary as a placeholder for a capability, not as a claim of one. In our own screening of external merchants, none published a UCP surface.
#
What is MCP?
MCP — the Model Context Protocol — is a protocol for exposing tools and context to models. It is a tool interface, not a commerce data model: a merchant MCP server may expose commerce tools, but MCP itself does not define commercial truth.
CRAB does not currently implement MCP as a commerce channel. Arbitrary MCP connectivity is not commerce support, and we do not describe it as such.
#
What is the difference between a commerce protocol and a successful transaction?
A protocol defines how a request and a response are shaped. A transaction is whether the buyer ends up with what they asked for. The first is a contract about form; the second is a fact about outcome.
Conformance testing establishes the first. It cannot establish the second.
#
Does UCP support prove that checkout works?
No. Publishing or implementing a protocol surface demonstrates capability, not correctness. Protocol support does not prove a correct commercial outcome — the interface can answer perfectly while describing the wrong item.
#
Can an API return HTTP 200 and still produce the wrong commercial outcome?
Yes, and this is the case worth designing for. HTTP 200 carrying the wrong SKU is a working protocol and a broken shop.
CRAB keeps the transport result and the commercial result as separate dimensions for exactly this reason. A channel that could not be reached establishes nothing about the merchant; a channel that answered with the wrong item establishes a great deal.
#
Can a machine-readable commerce channel disagree with the browser?
Yes. A storefront and a merchant's own cart API can report different variants for the same cart, and that divergence is a genuine defect an agentic buyer would hit.
CRAB compares them only within one seller. Two sellers are not two channels of one thing, and a price difference between them is a market, not a divergence.
#
What is cross-channel commerce assurance?
It is verifying that every commerce interface belonging to the same merchant tells the same commercial truth — the browser storefront and any machine-readable channel they publish — and comparing each of them against what was actually requested rather than against each other alone.
Comparing everything to the browser would make the browser the definition of correct, and it is not. The request is.
#
Can correct structured data still lead to a wrong cart?
Yes. Structured data describes the product page. It says nothing about what the add-to-cart control actually does, which variant the cart receives, or what the checkout carries.
Perfect markup and a substituted variant coexist comfortably.
#
Reinspection and regression
How does CRAB compare two inspections?
A finalized inspection can become a baseline for a later one. CRAB first checks the two are legitimately comparable — same seller, same requested product, same mission scope, compatible method versions — and refuses the comparison outright if they are not.
It then compares canonical truth, never report prose, and classifies each change as unchanged, improved, regressed, newly observed or no longer observable.
#
What is commerce regression testing?
It is verifying that a change to a store — a theme update, an app install, a platform upgrade, a remediation — did not break the commercial outcome that previously worked.
Conventional regression testing asks whether the code still runs. Commerce regression testing asks whether the buyer still ends up with the right item. See commerce regression testing.
#
How can an ecommerce agency verify a deployment?
Inspect before the change, deploy, then reinspect against that baseline. CRAB reports what was confirmed fixed, what regressed, what became newly observable and what it could no longer verify.
The agency implements; CRAB determines the comparison from evidence. The party doing the work is not the party judging whether it worked.
#
What does CONFIRMED FIX mean?
It means a later comparable inspection produced positive evidence that the same invariant now holds — the cart was observed, and it held the requested item.
It never means the failure was merely absent from the second report.
#
Why is "not observed" not the same as "fixed"?
Because a cart CRAB could not read produces exactly the same silence as a cart that now holds the right item, and only one of those is a remediation.
That outcome is reported as no longer observable — neither a pass nor a failure. A merchant told their defect is no longer observable learns something true; one told it is fixed learns something CRAB did not establish.
#
What can break between product page, cart and checkout?
Variant substitution at add-to-cart; option values that display correctly but are not applied; quantity drift; price shown on the product page differing from the cart line; availability contradicting itself between stages; a checkout that carries a different line than the cart; and totals that cannot be established at all.
Each is a separate typed finding, because each is a different thing to fix.
#
The method, and what we do not claim
What is the Commerce Execution Method (CEM)?
CEM is the documented method CRAB applies: the identity model, the nine stages, the evidence and integrity rules, the attribution rules, and the semantics of every state CRAB can report.
It is published as a prepublication draft at /crab/cem so the method can be examined independently of the product.
#
Is CEM a standard?
No. CEM is a technical assurance method published by VSN. It is not an ISO standard, not a W3C standard, not an industry standard, not a regulatory framework and not a certification scheme.
It currently carries version cem-0.2-prepublication. Calling it 1.0 would imply a settledness it has not earned.
#
Is CRAB a certification authority?
No. CRAB certifies nothing, issues no seal, and confers no status. There is no such thing as "CRAB Certified". It produces evidence-backed findings about a specific store, mission and moment.
#
Does CRAB give a numeric score?
No. CRAB reports READY, PARTIAL, BLOCKED or INDETERMINATE, and shows where the buying journey stops.
#
Why does CRAB not use a 0–100 score?
Because a score averages, and a commerce failure does not average. A store that puts the wrong variant in the cart has one defect that matters, and no number of passing unrelated checks makes the buyer's order correct.
A score would also invite comparison between stores whose missions, catalogues and channels are not comparable. Counts of findings are facts; a score would be a claim we cannot support.
#
What is a CRAB assurance bundle?
A portable, self-contained record of a finalized inspection: the frozen method versions, the canonical record, the evidence manifest, the evidence artifacts, and whichever assurance sections were actually performed.
A capability that was not exercised has no section and no placeholder. Absence stays absence and is never rendered as a pass.
#
Can a CRAB evidence bundle be independently verified?
Yes. A bundle is verified by a standalone verifier that needs no database, no network, no CRAB installation and no credentials, and which imports nothing from the engine — a verifier built from the engine would be checking our work with our own code.
It reports one of three states. VERIFIED: internally consistent, evidence present and unaltered, versions known. INVALID: the bundle contradicts itself; something was changed. NOT_VERIFIABLE: the check could not be completed because evidence is absent or the declared method version is unknown to that verifier.
Those last two are deliberately different. A missing file is not an accusation, and an unrecognised version is not a failure.
#
What is agentic checkout?
Agentic checkout is the point where an autonomous buyer moves from a cart to the ordinary checkout flow. CRAB verifies that the item identity survives that transition and stops at the checkout boundary without placing an order.
#
How should merchants prepare for autonomous shopping agents?
Make the store operable by a program — readable markup, stable controls, honest availability — and then verify that operating it produces the correct item. The second half is the half that is usually skipped.
Concretely: check that the requested variant is what reaches the cart, that the cart and any machine-readable channel agree, and that a theme or app change has not quietly altered either.
#
How should ecommerce agencies test AI commerce implementations?
Establish a baseline inspection before the work, reinspect after it, and require positive evidence that the specific failure is corrected rather than absent from the new report.
Keep the verification independent of the implementation. An agency judging its own remediation is not assurance.
#
Who built CRAB?
CRAB is built by VSN. CRAB is VSN's commerce execution assurance product and the implementation of the Commerce Execution Method.
To discuss commerce execution assurance, see the company page or request an inspection from the check page.
#