# Agent readiness — the rubric, in full > Rubric `zc-0.8` · config hash `1b0b85079a68dfb5` · 22 scored checks across 5 weighted pillars, plus 7 that run and report without affecting a grade. This is the specification the scanner actually runs, generated from the same rubric file the scorer loads. If a check is listed here, it runs. ## How to read this - Every check scores 0 to its published max from evidence gathered in one live scan. - Points normalise within a pillar: pillar score = points earned ÷ points evaluable. Raw totals never compare across pillars. - Pillar scores are multiplied by their weights and summed; the total maps to a grade, A–F. - A check we could not evaluate shrinks the denominator instead of scoring zero. A site is never marked down for evidence we failed to gather. - Scores are comparable only within one config hash. This page describes 1b0b85079a68dfb5; a different hash is a different instrument. **Do not sum the points column.** Raw points normalise inside each pillar; weight is the only number that compares across them. Right now, transactability is the heaviest pillar at 0.30 and carries 23 raw points. ## The buying journey Every check is also tagged with where an agent hits it. A check behind a blocked step reports *not reached*, never *failed*. 1. **Network probe** — Can an agent reach you? (3 checks) 2. **Read** — Can it understand what you sell? (4 checks) 3. **API catalog** — Can it find what to call? (7 checks) 4. **Payment & account** — Can it get in and get billed? (3 checks) 5. **Checkout** — Could it actually complete? (6 checks) ## What to implement, in order of effect ### transactability — weight 0.30 *Can it pay and provision without a human?* 5 checks · 23 raw points, normalised to 1.0, then multiplied by 0.30 of the grade. #### `x402_probe` (8 pts · 4 · Payment & account) During the buying session, requires the agent to select a concrete product, identify its documented purchase operation, and POST an empty body to that exact operation. Full credit requires a correlated, parseable x402 or MPP HTTP 402 receipt; static discovery and guessed endpoints never score. *Why:* The handshake only matters when it belongs to the thing the agent is trying to buy. Documentation is a routing hint, not proof that the selected operation is payable; a 402 challenge is still not proof of authorization, settlement, retry success or delivery. *Evidence:* session-behavior: probe_payment fetched and cited in all 3 fresh prod sessions (A3); x402 is also the volume leader at ~169M payments across 100k sellers (A4). *See:* [x402](https://x402.org) · [Machine Payments Protocol](https://mpp.dev) · [AgentReady AR-COMM-01](https://agentready.org/#x402) · [AgentReady AR-COMM-05](https://agentready.org/#mpp) #### `self_serve_payg` (6 pts · 4 · Payment & account) Tiers provisioning — no-signup, self-serve signup, or sales-gated. *Why:* An agent cannot create an account, clear an email loop, or take a sales call. *Evidence:* session-behavior: 2 of 3 fresh prod runs died on identity/credentials before payment could fire — credentials are the wall (A3). *See:* ZeroClick criterion (unpublished) #### `auth_md` (4 pts · 4 · Payment & account) Fetches /auth.md and requires non-trivial authentication guidance, rejecting HTML soft-404s. *Why:* A lighter-weight, human-and-agent-readable description of how to authenticate — touched in half the stored buying sessions, which is what earned it points. *Evidence:* session-behavior: /auth.md touched in 47 of 293 stored sessions (16%), and credentials were the terminal blocker in 2 of 3 fresh deep-reads (A3). *See:* [Cloudflare Discovery](https://blog.cloudflare.com/agent-readiness/) #### `documented_host_resolvability` (3 pts · 3 · API catalog) Resolves and fetches the hosts the site's own documentation points agents at — api., agents., docs. endpoints named in llms.txt or the docs corpus. *Why:* Agents found live specs at agents. hosts the static probes never tried; a documented host that does not answer is a dead end the docs themselves created. *Evidence:* session-behavior: agents followed the docs to dead infrastructure with no check penalizing it — api.reallybigmagnet.com is ENOTFOUND (A3). *See:* ZeroClick criterion (unpublished) #### `mcp_surface` (2 pts · 3 · API catalog) Looks for a discoverable MCP endpoint or server card. *Why:* Useful, but weighted low — generic HTTP plus a 402 handshake already serves every agent. *Evidence:* external-consumer:shopify-catalog-mcp: Shopify ships Catalog MCP to every store under UCP (A4); kept low and bonus because one session's MCP fetches 404'd while the check still held partial credit (B3). *See:* [Model Context Protocol](https://modelcontextprotocol.io) · [AgentReady AR-CAPA-01](https://agentready.org/#mcp) · [AgentReady AR-CAPA-02](https://agentready.org/#mcp-server-card) ### legibility — weight 0.20 *Can it understand what is for sale?* 9 checks · 29 raw points, normalised to 1.0, then multiplied by 0.20 of the grade. #### `llms_txt` (6 pts · 2 · Read) Fetches /llms.txt and /llms-full.txt and requires non-trivial content, rejecting HTML soft-404s. *Why:* A machine-readable front door orients an agent without it parsing marketing pages. *Evidence:* session-behavior: fetched and cited in all 3 fresh prod sessions (A3); weighted low because 97% of published llms.txt files get zero AI requests (A4, Ahrefs). *See:* [llmstxt.org](https://llmstxt.org) · [AgentReady AR-DISC-03](https://agentready.org/#llms-txt) · [AgentReady AR-DISC-04](https://agentready.org/#llms-full-txt) #### `offer_catalog` (6 pts · 3 · API catalog) Looks for schema.org Product/Offer JSON-LD carrying a real price, or a priced catalog manifest. A price of 0 scores partial. *Why:* An agent needs to know what is sold and what it costs. Markup advertising price 0 while the product is paid reads as free, which is worse than silence. *Evidence:* external-consumer:shopping-agents: shopping agents consume schema.org Product feeds (A4) even where our own shopper reads prose pricing instead. *See:* [schema.org/Offer](https://schema.org/Offer) #### `pricing_machine_readable` (4 pts · 2 · Read) Looks for a price in server-rendered HTML, without running JavaScript. *Why:* Agents that fetch rather than render never see a price that only appears after hydration. *Evidence:* session-behavior: pricing fetched and cited in all 3 fresh prod sessions (A3). *See:* [schema.org/PriceSpecification](https://schema.org/PriceSpecification) · ZeroClick criterion (unpublished) #### `api_docs_surface` (4 pts · 3 · API catalog) Finds a public docs or API-reference surface. *Why:* The fallback an agent reads when there is no machine-readable description. *Evidence:* session-behavior: docs subdomains were reached in 5 of 12 stored sessions, which the utilization map undercounted as 1 (B3). *See:* [OpenAPI 3.1](https://spec.openapis.org/oas/v3.1.0) · ZeroClick criterion (unpublished) #### `openapi_document` (4 pts · 3 · API catalog) Fetches conventional OpenAPI paths on the apex and on api./docs. subdomains, and requires the document to parse and describe at least one path. *Why:* For an API business this is what an agent actually reads to learn what to call. Prose docs are not an API description. *Evidence:* session-behavior: agents fetched live 200 specs on 3 domains the probe never tried, and it is the highest-variance static at σ=0.458, so a false negative moves grades (B3). *See:* [OpenAPI 3.1](https://spec.openapis.org/oas/v3.1.0) · [AgentReady AR-CAPA-08](https://agentready.org/#openapi) #### `schema_product_gtin` (3 pts · 3 · API catalog) Looks for a GTIN/MPN-class identifier in schema.org Product markup. *Why:* A stable product identifier lets an agent match the listing against external catalogs and price data instead of trusting one page's self-description. *Evidence:* external-consumer:shopping-agents: shopping agents consume schema.org Product + GTIN feeds (A4); our own shopper never reads them, which is why the tag is the consumer and not the session. *See:* [schema.org/Product](https://schema.org/Product) · [schema.org/Offer](https://schema.org/Offer) #### `agent_skills` (2 pts · 3 · API catalog) Looks for a published Agent Skills index and requires it to parse. *Why:* Describes what an agent can do here, rather than only what exists — and stored sessions read it where it was published. *Evidence:* session-behavior: named among the checks agents leaned on hardest while working out how to get in (A3); promoted under scenario A (B4). *See:* [AgentReady AR-CAPA-07](https://agentready.org/#agent-skills) · [Cloudflare Capabilities](https://blog.cloudflare.com/agent-readiness/) #### `sitemap` (informational · 2 · Read) Finds a sitemap directly or via robots.txt. Informational since zc-0.8 — 0 points. *Why:* Cheap breadth for crawler-shaped agents — but a shopping agent is not crawler-shaped. No stored session fetched a sitemap while working a purchase errand, and no external shopping-agent consumer reads one, so it reports without scoring. *Evidence:* informational: fetched in 5 of 293 stored sessions (2%), far below scoring relevance, and no shopping-agent consumer reads it — a crawler-indexing artifact, not a buying signal. *See:* [sitemaps.org](https://www.sitemaps.org/protocol.html) · [AgentReady AR-DISC-02](https://agentready.org/#sitemap) #### `markdown_negotiation` (informational · 2 · Read) Requests the homepage with `Accept: text/markdown` and checks the response content-type and `Vary` header, then falls back to looking for an /index.md twin. Informational since zc-0.7 — 0 points. *Why:* Agents that fetch rather than render read markdown far more reliably than HTML — in principle. No stored agent session ever negotiated it, and the check's historical credits came from a retired over-broad matcher, so it reports without scoring until real demand appears. *Evidence:* informational: zero real demand in any stored session; its historical credits came from the retired over-broad .md matcher (B3). *See:* [Cloudflare Markdown for Agents](https://blog.cloudflare.com/agent-readiness/) · [AgentReady AR-CONT-02](https://agentready.org/#markdown-negotiation) · [AgentReady AR-CONT-03](https://agentready.org/#index-md) · ZERO-626 (unpublished) ### outcome — weight 0.20 *Did agents actually get the job done?* 6 checks · 25 raw points, normalised to 1.0, then multiplied by 0.20 of the grade. #### `bhv_machine_payable` (5 pts · 5 · Checkout) Graded from the transcript as the agent's broader path outcome, then constrained by the deterministic selected-operation payment receipt. A documented claim alone cannot establish machine-payability. *Why:* An agent cannot type a card number, and a payment protocol somewhere else on the site does not make this product's operation payable. *Evidence:* session-behavior: judged from the transcript and then constrained by the correlated payment receipt for the same selected operation. *See:* [x402](https://x402.org) · [ACP](https://agenticcommerce.dev) · [AP2](https://ap2-protocol.org) #### `bhv_free_tier_transaction` (5 pts · 5 · Checkout) Reads the structured commerce catalog the shopper actually fetched to decide whether a free allowance applies. An explicit zero/no allowance is not applicable; an advertised allowance remains unmeasured until a payment-capable session continues the selected operation through authorization, retry and delivery; missing authoritative allowance data stays unknown. *Why:* A challenge proves that payment was requested, not that authorization was accepted or that the purchased result arrived. A future executable arm must keep those receipts linked to the same selected product and operation. Not offering a free tier remains a pricing decision, not a readiness failure. *Evidence:* session-behavior: judged from the structured catalog the shopper fetched; unresolved rather than failed when this read-only arm holds no wallet. *See:* [x402](https://x402.org) · [Machine Payments Protocol](https://mpp.dev) · internal baseline v0.4 (unpublished) #### `bhv_found_product` (4 pts · 5 · Checkout) Graded from the live agent transcript — did it locate the thing it was asked to buy. *Why:* Everything downstream is moot if the product cannot be found. *Evidence:* session-behavior: judged from the shopper's own transcript — the errand's first checkpoint, and everything downstream is moot without it. *See:* ZeroClick criterion (unpublished) #### `bhv_purchase_path` (4 pts · 5 · Checkout) Graded from the transcript — did the agent identify a specific path to purchase. *Why:* A pricing page is not a purchase path. *Evidence:* session-behavior: judged from the transcript — the checkpoint 2 of 3 fresh runs stopped at, on identity rather than payment (A3). *See:* ZeroClick criterion (unpublished) #### `bhv_no_human_gate` (4 pts · 5 · Checkout) Graded from the transcript — did a CAPTCHA, KYC, email loop or sales call block the path. *Why:* Business-rule gates are readiness factors, not implementation details. *Evidence:* session-behavior: judged from the transcript — credentials are the wall agents actually hit, in 2 of 3 fresh runs (A3). *See:* ZeroClick criterion (unpublished) #### `bhv_understood_pricing` (3 pts · 5 · Checkout) Graded from the transcript — did the agent extract a concrete price or rate. *Why:* An agent that cannot price the call cannot budget it. *Evidence:* session-behavior: judged from the transcript; pricing was fetched and cited in all 3 fresh prod sessions (A3). *See:* ZeroClick criterion (unpublished) ### access — weight 0.15 *Can an agent get in at all?* 2 checks · 4 raw points, normalised to 1.0, then multiplied by 0.15 of the grade. #### `robots_ai_crawlers` (2 pts · 1 · Network probe) Fetches /robots.txt and reads the rules for AI crawler user-agents. *Why:* A Disallow aimed at agent crawlers stops the visit before anything else matters. *Evidence:* scaffold-confounded: our own prompt partly scripts the fetch order (A3 caveat, ZERO-782) and the pillar scored 1.0 on all 10 graded reports (B3); dual-sourced by vendors' published crawler docs, clean validation deferred to Arm A, the unscripted benchmark funnel (docs/plan-readiness-benchmark-arms.md). *See:* [RFC 9309](https://www.rfc-editor.org/rfc/rfc9309) · [AgentReady AR-DISC-01](https://agentready.org/#robots-txt) #### `agent_ua_reachability` (2 pts · 1 · Network probe) Fetches the homepage as Chrome and as ClaudeBot, GPTBot and Claude-User, then compares status and content. *Why:* A bot wall that serves agents something different from browsers is the most common silent block. *Evidence:* scaffold-confounded: the UA comparison is scripted by our own prompt and scored a constant 1.0 across graded reports (A3, B3); the hard-bot-wall case it exists for is carried by the agent-ua-hard-blocked cap, and clean validation waits on Arm A (docs/plan-readiness-benchmark-arms.md). *See:* ZeroClick criterion (unpublished) ### trust — weight 0.15 *Mid-errand on your site, was the agent suspicious of you?* 7 checks · 15 raw points, normalised to 1.0, then multiplied by 0.15 of the grade. #### `trust_live_session` (10 pts) Reads the buying agent's own transcript for moments where it doubted this site enough to say so, or declined to proceed — tracker redirects, hosts that disagree with each other, a price it could not verify before spending, ambiguous licensing, flagged provenance. No concerns raised across a session that actually engaged scores full marks; a flagged concern is partial; an outright refusal fails. *Why:* Hesitation while an agent is mid-task is stronger evidence than hesitation when asked to judge a site cold, because the agent had a live reason to keep going and stopped anyway. This is what the pillar is now for: whether the agent doing the errand was suspicious of you. Graded on the same transcript as the outcome checks and on an inverted axis — here silence is the good outcome — and unmeasured rather than passed when the run never engaged, since raising no concern about a site you never reached says nothing. *Evidence:* session-behavior: the one aligned trust signal, clean on 276 of 284 stored reports, naming tracker-redirect laundering, cross-TLD entitlement hosts and license ambiguity at the pay decision (B2). *See:* internal baseline v0.2 (unpublished) #### `manipulation_pressure` (5 pts) Scans the agent-readable surface for manipulation pressure — tracker-link laundering, hard-sell or steering copy aimed at automated buyers. *Why:* The live sessions' own trust events named exactly these patterns; a site that pressures agents earns distrust it deserves, statically observable before any purchase. *Evidence:* session-behavior: the 8 event-bearing runs named exactly these patterns — tracker-redirect laundering and cross-TLD hosts — properties no check measured before (B2, A3). *See:* ZeroClick criterion (unpublished) #### `https_hsts` (informational · 1 · Network probe) Checks TLS and the Strict-Transport-Security header. Informational since zc-0.8 — 0 points; a site that serves no HTTPS at all still trips the `no-https` cap, which limits the grade regardless of this check's points. *Why:* Table stakes for anything an agent is asked to trust with a payment — but every reachable site scored 3 or 5 here and nothing between, so as points it ranked nobody. The catastrophic case is worth a cap, not a weight. *Evidence:* informational: observed values clustered at 3 or 5 with nothing between, so it ranked nobody; the catastrophic case is carried by the no-https cap rather than by weight. *See:* [RFC 6797](https://www.rfc-editor.org/rfc/rfc6797) #### `org_identity` (informational) Looks for verifiable organisation identity in structured data or on the page. Panel input since zc-0.7 — 0 points; the finding is context for the willingness panel, which since zc-0.8 is itself unscored. *Why:* An agent directed to buy needs to know who it is buying from — but agents mid-errand never fetched these pages, and the check passed everywhere reachable, so it ranked nothing. *Evidence:* informational: fetched mid-errand in 14 of 293 stored sessions (5%) and passes everywhere reachable, so it ranked nothing (B2). *See:* [schema.org/Organization](https://schema.org/Organization) #### `policies_present` (informational) Looks for terms, privacy and refund/cancellation policies, by footer link or conventional path. Panel input since zc-0.7 — 0 points; the finding is context for the willingness panel, which since zc-0.8 is itself unscored. *Why:* Reversal terms are what an agent would check before committing someone else's money — yet no stored session read them, and scoring the statics anti-correlated with buyability. *Evidence:* informational: /terms was never fetched mid-errand (B2), and the panel this finding feeds is itself unscored from zc-0.8. *See:* [schema.org/MerchantReturnPolicy](https://schema.org/MerchantReturnPolicy) · ZeroClick criterion (unpublished) #### `reputation_signals` (informational) Looks for third-party reputation markup rather than self-hosted testimonials. Panel input since zc-0.7 — 0 points; the finding is context for the willingness panel, which since zc-0.8 is itself unscored. *Why:* Self-reported praise carries no weight with an agent that can read the whole web — and as a scored static this rewarded incumbency, not buyability. *Evidence:* informational: a 5-site hardcode that fails vercel, fly and nike (B2) — it measured incumbency, not buyability. *See:* [schema.org/AggregateRating](https://schema.org/AggregateRating) #### `trust_panel_willingness` (informational) Asks three models from three different vendors, in a directive framing, what they do when told to buy from this site: proceed, proceed with a warning, or refuse — and reports what each one said in its own words. Informational since zc-0.8 — 0 points, and the refusal grade cap is removed. *Why:* It answers a question about MODELS, not about the site: held against real buyability, warnings anti-correlated at r=-0.49, because what the panel flagged was wallet checkout itself — the thing this product exists to make normal. Most refusals turned out to be fetch artifacts rather than judgements. It still runs and is still worth reading, as three vendors' stated reaction to a storefront; it just does not move a score. *Evidence:* informational: anti-correlates with buyability at r=-0.49, and 13 of 14 refusal runs were fetch artifacts or catalog facts rather than trust judgements (B1). *See:* internal baseline v0.2 (unpublished) ## Declared but not scored Published before they are measured, so the direction is public. None carries points: a check that every site passes, or that every site fails, tells a reader nothing about where they stand. - `link_headers` — Would read HTTP `Link` headers advertising llms.txt and markdown alternates. - `content_signals` — Would read Content Signals directives in robots.txt. - `web_bot_auth` — Would look for /.well-known/http-message-signatures-directory. - `oauth_discovery` — Would look for OAuth authorization-server and protected-resource metadata. - `api_catalog` — Would look for /.well-known/api-catalog. - `mcp_server_card` — Would look for /.well-known/mcp/server-card.json. - `a2a_agent_card` — Would look for /.well-known/agent-card.json. - `mpp_discovery` — Would detect MPP payment discovery alongside x402. ## Inherited and not run Declared by our internal baseline v0.7 and removed here, rather than left on the board as points nothing can earn. - `hosted_agent_reachability` — Structurally unobservable here rather than merely unbuilt. It counts refusals by a hosted browser's URL-safety and reputation layer; this scanner fetches directly and drives a local browser, neither of which has such a layer, so there is nothing to observe. The tempting substitute — calling a URL-reputation API — measures something we already score under reputation_signals, and would not tell anyone whether a real agent's stack refuses the site. Better to remove the points than to report a number we did not measure. --- Scan a domain: `GET https://readiness.withzero.xyz/api/v1/scan/stream?url=`. Machine-readable rubric: `/api/v1/spec`. Human page: `/spec`. Generated 2026-09-27.