Commerce Execution Method (CEM)

Status

CEM is a technical assurance method. It is not an ISO standard, not a W3C standard, not an industry standard, not a regulatory framework and not a certification scheme. There is no such thing as "CRAB Certified".

This is a prepublication draft, version cem-0.2-prepublication, published for independent technical review. It carries no DOI, has not been submitted to any standards body, and no external licence grant is in effect.

CEM is the method. CRAB is VSN's implementation of it. The method is written to be understandable without reference to the product.

Scope

CEM covers the assurance of one commerce mission: whether a specific, intended product can be found, identified, priced, added, verified in the cart, carried to ordinary checkout and its payable total established — on a specific merchant store, through one or more channels.

It distinguishes two activities that must not be confused. Merchant inspection is carried out on a store whose owner authorised it. Brand Scope observation is a commissioning brand asking where a buyer lands for a declared product; the destinations reached authorised nothing, so no merchant verdict of any kind is produced there. A brand's consent is not a retailer's consent.

Commerce identity

A typed description of which exact thing a surface is describing: product id, SKU, variant id, canonical product reference, canonical URL, quantity, and an open list of options supporting arbitrary product dimensions.

Canonicalization rule. Representation may be normalized — whitespace, option-name case, URL trailing slash, option ordering. Commercial meaning may never be normalized. A different SKU, variant, option value or quantity is a different commercial thing.

Comparison rule. Deterministic and total. A disagreement on a strong identifier is decisive and is never outweighed by agreement elsewhere. No language model participates in identity equality.

The identity chain

Requested → discovered → product → selected → add → cart → checkout. Each stage is observed, not observed, or not applicable.

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.

A surface that stays silent about identity has not proven a mismatch and is recorded as not observed.

The nine stages

Discover · Identity · Price · Availability · Add · Verify item · Cart · Checkout · Totals.

Stage results are READY, PARTIAL, BLOCKED, INDETERMINATE or NOT_APPLICABLE. A stage is READY only when every probe that ran passed and none is missing.

Verdict and validity are separate dimensions

The merchant verdict is about the store. Inspection validity is about CRAB, and is independent of it. A poor merchant result may be perfectly reportable; a flattering result observed under contaminated conditions is not.

A store is never READY on an observation CRAB does not trust.

Attribution

STORE, AGENT, INSPECTOR, ENVIRONMENT or UNKNOWN. Inspector or environment limitations never become merchant failures. Where an autonomous executor fails a mission that the deterministic control completes, attribution is AGENT and no merchant defect is established. STORE requires the deterministic control to reproduce the defect with canonical evidence.

Evidence and integrity

Every finding is tied to captured evidence; nothing is asserted without it. Every finalized inspection carries a deterministic evidence-integrity manifest — canonical JSON, per-evidence SHA-256, and a manifest root hash. No absolute machine path enters the canonical root.

For a non-browser interface, each reading also carries a digest of the exact response bytes, an allowlisted projection of the commerce fields, and the source path behind every canonical value — so a reviewer can re-derive the mapping by hand.

Hashes only. Nothing is signed, no key material is involved, and there is no distributed ledger.

Portable verification

A finalized inspection can be exported as a self-contained assurance bundle and checked by a standalone verifier requiring no database, no network and no CRAB installation.

Verification states are VERIFIED, INVALID and NOT_VERIFIABLE. The last two are distinct on purpose: INVALID means the bundle contradicts itself, NOT_VERIFIABLE means the check could not be completed. A missing file is not an accusation.

The trust direction runs one way — source evidence, then manifest, then canonical record, then assurance results, then report. The report is presentation and is never an input to a verification decision.

Limitations

• CRAB observes the public commerce journey; it does not see merchant internals.
• A stage that could not be observed is reported as such, not inferred.
• Results describe the store, mission and channels inspected, at that time, under frozen versions. They are not a claim about other stores.
• No platform-wide failure rate or prevalence statistic is published without a measured, disclosed study.
• CRAB never implements or remediates what it verifies, certifies nothing, and signs nothing.

Next steps

• Check your commerce journey — request an inspection of a store you are authorised to test.
• CRAB Q&A — fifty questions on commerce execution assurance.
• The Commerce Execution Method — the method itself, as a prepublication draft.
• Commerce Execution in the Age of AI Agents — the whitepaper.

CRAB is built by VSN.