How we score, in plain math.

All 82 checks follow the same shape. Each one targets a single, named signal and produces:

• a permanent slug (e.g. product-jsonld-present) plus a category display ID derived from its position (e.g. STRUCT-9);
• a severity — CRITICAL, HIGH, MEDIUM, LOW, or INFO;
• a check status (`pass`, `partial`, `fail`, `na`, `error`) plus a discrete raw score (`100`, `50`, `0`) for scored states;
• a per-surface weight — how much the signal matters to each AI surface;
• rich evidence — what we looked at, what method we used, the raw HTTP / JSON-LD / sitemap artifacts, and per-issue findings with offending and expected snippets.

Each check resolves to one of five states:

• pass/partial/failScored states. Raw scores are `100` (pass), `50` (partial), `0` (fail); included in aggregation.
• naCheck does not apply to this audit; excluded from aggregation.
• errorRuntime error during this check; excluded from aggregation.

Severity weights drive the impact each check has on its surface sub-score.

The five AI shopping surfaces don't contribute equally to the overall score. Weights reflect how much of each surface's behavior is public-crawl-verifiable today — Google UCP and Schema.org carry the heaviest weight because most of their conformance is observable from the public web.

Weights are configuration, not constants — they're versioned in the scoring engine and change only through a reviewed release, never edited ad hoc.

For each surface S, the sub-score is the weighted average of all applicable checks:

subscore(S) = sum( rawScore_i × severity_i × surfaceAffected_i[S] )
              ─────────────────────────────────────────────────────
              sum( 100 × severity_i × surfaceAffected_i[S] )

  for all checks i where:
    - result is not `na`
    - result is not `error`
    - surfaceAffected_i[S] > 0

Worked example

Perplexity sub-score on a Shopify store with 3 relevant checks:

numerator   = (0 × 10 × 100) + (50 × 5 × 80) + (100 × 3 × 100)
            = 0 + 20000 + 30000
            = 50000

denominator = (100 × 10 × 100) + (100 × 5 × 80) + (100 × 3 × 100)
            = 100000 + 40000 + 30000
            = 170000

subscore(perplexity) = round(50000 / 170000 × 100) = 29

Perplexity sub-score for this store: 29.

The overall score is a surface-weight-blended average of the five sub-scores:

overall = sum( subscore(S) × surfaceWeight(S) )
          ──────────────────────────────────────
          sum( surfaceWeight(S) )

  = ( subscore(chatgpt_acp) × 25
    + subscore(google_ucp)  × 30
    + subscore(microsoft)   × 15
    + subscore(perplexity)  × 17
    + subscore(meta)        × 13 )
    / 100

The denominator is 100 by construction (the surface weights sum to 100). The division is shown explicitly for clarity.

Issue-level impact in the report uses this same blend. A check that costs 3 points on ChatGPT contributes 0.75 points to the headline score because ChatGPT carries 25% of the overall weight. In the issue list, hover the impact value (for example `−5`) to see the unweighted per-surface score subtraction for each surface.

The 0–100 overall maps to a letter grade for at-a-glance reading:

Grade colors are semantic and always paired with the letter. The color is never the sole signal.

The full list of 82 active checks, grouped by category. Each row shows the display ID (derived from the check's position in its category), the canonical slug, severity, and which specs the check normatively cites.

Inventory rendered from the live check registry at build time. The retired check ledger and parked checks live on /spec-status.

Some checks are unfair to score uniformly across platforms because the default differs. Platform normalization currently lives in check logic (per-check) and is versioned through engine releases.

Every check has a fix.byPlatform recipe for shopify, bigcommerce, woocommerce, and custom — so a platform-detection miss never leaves the merchant without actionable guidance.

Every audit persists:

• Engine version — current semver of packages/engine is 2.0.0. Stamped on every audit row.
• Spec versions — exact pinned versions of ACP, UCP, Stripe SPT (Shared Payment Token). Perplexity, Meta, and Copilot tracks are modeled from public docs but are not first-class pinned spec-version fields in the audit record today.
• Raw snapshots — every v2 audit captures the robots.txt / sitemap / JSON-LD it observed into a per-audit tarball so the report can be re-rendered without a recrawl.

Spec-drift changes are surfaced in /spec-status.

Some signals are not in canonical spec documents. Microsoft Copilot in particular has thin merchant documentation — anything past Merchant Center, UCP feed, and Bingbot is inference.

When a check is based on inference rather than canonical spec, the report tags it:

• canonicalDerived from the published ACP / UCP / Stripe / Meta / Perplexity spec.
• inferredBased on observed behavior of the surface, vendor blog posts, or partner statements.
• speculativeKnown unknowns; included for transparency but does not affect the score.

• Brand awareness or perceived authority. We score data hygiene, not reputation. Domain Rating, social signals, and editorial coverage don't enter the score.
• Conversion rate, CTR, or revenue. Those are CRO and analytics problems, not agent-readiness problems.
• Aesthetic quality of the storefront. Beautiful stores can score 30; ugly stores can score 90. Agents read structured data, not screenshots.
• Whether you should enable agentic commerce. That's a business decision. We tell you whether your store is ready — opting in or out is yours.

Every scoring change (new severity weights, new surface weights, new platform floors, new checks) is published with the engine version and ISO date. The retired check ledger on /spec-status tracks the why for every check that has ever been removed.