Seams

Four places where the entries meet. Each statement comes from the entries named in brackets; negatives are searches of the corpus named in the entry, not statements about the world. The participation of the author of this map in the threads concerned is in the Disclosure.

S1. Discovery layers

ard, lf-ai-catalog, a2a-core, a2a-discovery, mcp-core, mcp-server-card, ucp, ietf-dawn, ietf-dnsaid, schemaorg-baseline, w3c-ai-agent-protocol-cg, pap, pact, shopify

• A2A defines the AgentCard as a message in specification/a2a.proto and registers /.well-known/agent-card.json for a single card (a2a-core, a2a-discovery).
• MCP Server Cards are a static metadata document with a recommended location of <url>/server-card; the extension's discovery document points clients to /.well-known/ai-catalog.json for catalogues (mcp-server-card).
• AI Catalog uses /.well-known/ai-catalog.json; its ADR-0011 says a well-known URI "is not mandatory" (lf-ai-catalog).
• ARD uses /.well-known/ard.json: "A consumer resolving a domain's entries MUST fetch /.well-known/ard.json"; the AI Catalog path is its predecessor, which a publisher "SHOULD move" away from (ard).
• A loose coupling between ARD and AI Catalog is recorded in AI Catalog's ADR-0017 and in ARD PR #70: "Every ARD entry is a well-formed catalog entry, but not every catalog entry is an ARD entry." (lf-ai-catalog, ard).
• A2A PR #2240 proposes ai-catalog.json as the "Preferred" mechanism and issue #2276 proposes /.well-known/agent-card-list.json; on 2026-09-01 a maintainer closed PR #418 with "A2A working group will not be building any kind of registry standard." (a2a-discovery).
• UCP serves a merchant profile at /.well-known/ucp; the charter of its Bulk Product Discovery working group puts business discovery outside and defers it to a future RFC (ucp).
• UCP's overview page says "Profile endpoints MUST NOT use redirects (3xx).", while the Personal Agent Protocol says of its own well-known document that "Personal Agents MUST follow redirects" (pap): the two rules differ, and they concern different paths and different readers; issue #904 (a third-party scan, figures declared by its author, not verified by this map) lists 301 answers at the manifest path of two Shopify stores among the 13 without a parsable manifest (ucp).
• Version 3 of the reporting frame in UCP Discussion #867 (posted 2026-10-09 by the author of this map, comment 18833761) counts a 3xx at the profile path on its own line, since "a profile reached only via a 3xx is never a positive", and reports a "200 after redirect" apart as row 1a; it ties both to the two rules of the overview page, Hosting item 2 (line 1466) and identity resolution item 2 (line 1514), at commit f2206e6; the author of the census answered the same day (comment 18834311) that this is how he will report his next pass (https://github.com/Universal-Commerce-Protocol/ucp/discussions/867#discussioncomment-18833761; ucp).
• Known Good run in Discussion #867 (2026-10-08, figures declared by the source, not verified by this map): 41,424 endpoints answered tools/list, two tool signatures cover 41,352 of them, and the post gives "Merchant count 41,424; decision count 2" (https://github.com/Universal-Commerce-Protocol/ucp/discussions/867#discussioncomment-18816164; ucp).
• The Personal Agent Protocol (draft 0.1, published 2026-10-09) discovers a company through one well-known document: "A Company MUST publish its poppy.json document at https://{domain}/.well-known/poppy.json over HTTPS"; the URL "MAY redirect", and "Personal Agents MUST follow redirects, and every redirect MUST be to an HTTPS URL" (pap).
• PACT (version 1.0, Decagon with Instinct) takes the A2A route and not a document of its own: a business's card is at "https://{brandDomain}/.well-known/agent-card.json", which "serves the card or redirects to" the Provider's URL, and the specification says "This spec does not define a registry." Redirects are therefore allowed on the well-known path of both personal-agent protocols (pact, pap), while the UCP overview says "Profile endpoints MUST NOT use redirects (3xx)." (ucp). A personal agent that reaches a business meets poppy.json at a Poppy company and agent-card.json at a PACT business; neither document is read by the other protocol in the texts read (not found: poppy.json in the PACT specification page, and A2A, PACT and agent-card.json in the Poppy specification page, 2026-10-13).
• Where discovery finds no agent checkout, the README of Shopify/shop (commit d1e8c7c, read 2026-10-13) says: "Some stores have no agent checkout API (UCP); the agent has to enter a payment credential into the site's checkout form in a browser." (shopify).
• IETF DAWN would standardise discovery of "public properties of AI resources", with, for the public Internet, the charter example "discover all agents of example.org, for all its customers/members" ("discover all agents in this shop" is the charter example for the local network, charter 00-10, read on the datatracker on 2026-10-14); catalogues of capabilities beyond a minimum are out of its scope (ietf-dawn).
• The individual draft DNS-AID (draft-mozleywilliams-dnsop-dnsaid-02) "standardizes an approach for publishing AI agents in the Domain Name System (DNS) so that other agents can discover them" (ietf-dnsaid).
• schema.org V30.1 defines the types Organization, LocalBusiness, Product and Offer (schemaorg-baseline).
• In the IANA well-known URIs registry (updated 2026-10-07, read 2026-10-14, https://www.iana.org/assignments/well-known-uris/well-known-uris.xml), of the eight discovery paths listed on the home page (/.well-known/ucp, agent-card.json, schema.org, ARD, AI Catalog, MCP Server Cards, DNS-AID, /.well-known/poppy.json) only agent-card.json is registered (status permanent, controller Linux Foundation, a2a-core); ucp, ai-catalog.json, ard.json and poppy.json are not found in it. A registration request for ucp has been open in the registry's repository since 2026-06-06 (issue #92, https://github.com/protocol-registries/well-known-uris/issues/92), labelled "waiting for input" since 2026-07-11, when the designated expert asked for an e-mail address for the change controller; no later comment (read 2026-10-14). A request for poppy.json, ard.json or ai-catalog.json is not found among the 108 issues of that repository, all states (read 2026-10-14). The registry also holds gs1resolver (permanent, controller GS1, registered 2020-05-18, the path used by the GS1-Conformant Resolver, gs1-conformant-resolver), vacation-rental.json (provisional, registered 2026-08-19; the record points to vacationrentalprotocol.com, whose author commented on schema.org issue #4824, schemaorg-open-agent-commerce-items) and api-catalog (RFC 9727, permanent, 2024-12-23), a general mechanism for publishing API catalogs that this map does not count among the agent-specific approaches.
• KYAPay token-02 (section 7.3) asks IANA to register the well-known URI suffix jwks.json (status permanent) for the key set of a token issuer (kyapay); jwks.json is not found in the registry read on 2026-10-14.
• The draft W3C Agentic Web charter is in refinement; strategy#576 lists four AI-related community groups for outreach, the AI Agent Protocol CG among them (w3c-agenticweb-wg, w3c-ai-agent-protocol-cg).
• Two individual IETF drafts survey or analyse discovery mechanisms, draft-jimenez-dawn-discovery-landscape-00 (2026-07-03) and draft-moussa-dawn-gap-analysis-01 (2026-06-12); a text search of both finds no occurrence of AI Catalog, ARD, UCP or commerce (2026-10-06). A DAWN use-case draft names ARD as "an illustrative option" (ietf-dawn).

S2. Product and seller identity

schemaorg-baseline, schemaorg-open-agent-commerce-items, gs1-digital-link, gs1-conformant-resolver, untp-identity-resolver, un-gtr-urn, w3c-gs1-ecommerce-workshop, w3c-did-resolution, lf-ai-catalog, ucp, acp, x402

• schema.org V30.1 (2026-09-16) has Product, Offer, Organization, LocalBusiness, LodgingBusiness, MerchantReturnPolicy and the property gtin (schemaorg-baseline). Open items on agents and commerce are in the Open proposals appendix (schemaorg-open-agent-commerce-items).
• A GS1 Digital Link URI carries a primary key such as a GTIN or a GLN and "is a particular form of URL" (gs1-digital-link); the GS1-Conformant Resolver 1.2.1 resolves it to information sources (gs1-conformant-resolver).
• The UNTP Identity Resolver 0.7.0 specifies a link resolver service with an OpenAPI artefact; the gtr URN namespace is described as "IANA registration pending" (untp-identity-resolver, un-gtr-urn).
• W3C DID Resolution uses the relativeRef parameter for product-level references such as Digital Product Passports; PR #344, which rewrites DID URL dereferencing, was merged on 2026-10-13 (02:10 UTC) after a poll of the DID WG on 2026-10-08 (eight +1, one -1, chair's decision to merge), and the latest Candidate Recommendation Draft, of 2026-10-01, marks that feature as at risk; no draft had been published after the merge on 2026-10-13 (w3c-did-resolution).
• The W3C/GS1 workshop of 2026-09-08/09 collected position statements; Sven Böckelmann, author of position statement #31, says "Resolution says where the data is; a signature says who signed it. Neither says who may speak for the product." His workshop slides reduce it to three checks: "Where. Who signed. Who may." (slide 6) (w3c-gs1-ecommerce-workshop).
• UCP carries barcodes on catalogue variants, and issue #375 declined external place identifiers in the core schema (ucp). ACP's product feed (unreleased) has an optional barcode with a type (GTIN, UPC or EAN) and a value (acp). A text search of the x402 issues and pull requests (2026-10-03) returns no occurrence of GTIN, GS1, UPC or EAN (x402).
• Seller identity: ACP's discovery RFC says "Seller identity is established through authentication (Bearer token), which is unavailable at discovery time."; AI Catalog uses urn:air anchored to a domain and did:web verification, and says "This establishes publisher-domain control, not publisher reputation." (acp, lf-ai-catalog).
• UCP pull request #811 (open, 2026-10-09) would let a catalog variant carry offers[], each naming its seller by seller.domain, described as "The seller's canonical host: a bare hostname without scheme, path, port, or trailing slash" that "A Platform resolves ... to the seller's UCP profile at /.well-known/ucp"; the overview page says "Profile endpoints MUST NOT use redirects (3xx)." (line 1466), and which of the bare and the www host is canonical for a profile is not found in the overview page at f2206e6 nor in the five files of the pull request (2026-10-09; https://github.com/Universal-Commerce-Protocol/ucp/pull/811; ucp).

How the two resolver specifications state the "no data" case (gs1-conformant-resolver, untp-identity-resolver):

S3. Agent identity and delegation

ietf-webbotauth, visa-tap, mastercard-agent-pay, kyapay, ucp, x402, acp, ietf-agentproto, w3c-agenticweb-wg, browsers-webmcp, w3c-webmcp-cg-report, oidf-authzen-agents, pap, pact

• IETF Web Bot Auth standardises cryptographic authentication of automated clients (HTTP message signatures, key directories); the first WG draft was adopted on 2026-09-01 (ietf-webbotauth).
• Web Bot Auth list, 2026-10-04 to 2026-10-08: an implementer withdraws an agent by emptying its key directory and asks that honouring Cache-Control become a normative SHOULD, a verifier proposes the text, and a second participant writes that for a key set passed on as a signed artifact the bound is the signature's expires and not the cache lifetime; another participant proposes distinct Signature-Agent values for distinct purposes, which two others support; a participant's HTTP linter emits signatures only when challenged, and text on Accept-Signature is proposed for section 5.3 (ietf-webbotauth).
• The Personal Agent Protocol's session "is built on OAuth" and the customer decides whether the agent has read-only or write access (pap).
• Identity and permission are separate objects in the two personal-agent protocols, in different words. Poppy: "A Personal Agent's client_id MUST be an HTTPS URL that returns its metadata document" (identity, section 4.1), while the access token is "signed in with the account scopes the User granted" (pap). PACT: the personal-agent JWT proves "That a known personal agent is calling for someone it calls sub. Not that sub owns a Brand account." (section 3.3), the scopes come from the customer's login with the business through OAuth device code (section 5), and the Decagon post says of the protocol "It separates the identity of the personal agent from its authority to act on a customer" (pact). Whether the agent identity of either protocol can be carried by Web Bot Auth is not stated: Web Bot Auth is not found in the PACT specification page nor in the Poppy specification page (2026-10-13).
• Visa TAP defines an agent recognition signature based on HTTP Message Signatures (RFC 9421) and aligned with web-bot-auth, a signed consumer or device identity and a signed payment container (visa-tap).
• Mastercard's page of 2025-10-14 says merchants "can verify agent authenticity" by implementing Web Bot Auth at the CDN layer, and that Mastercard has partnered with Cloudflare to support it in Agent Pay (mastercard-agent-pay).
• UCP merged Web Bot Auth interop on 2026-07-03 (PR #483); its overview page at commit f2206e6 defines the values of the Signature-Agent header type parameter by reference to draft-meunier-webbotauth-httpsig-directory-00 (section 4.1: jwks_uri, cimd, directory) and, for cimd, to draft-ietf-oauth-client-id-metadata-document (read 2026-10-14): a dual-audience signature, the "RECOMMENDED path for integrators", limited to requests (ucp).
• x402 specifies an http-message-signatures extension (merged 2026-04-15) that identifies the paying agent, and a sign-in-with-x extension that authenticates the buyer's wallet (x402). A text search of ACP's specification files, issues and pull requests returns no occurrence of Web Bot Auth (acp).
• KYAPay is a family of individual drafts for a signed token carrying verified agent and human identity and payment credentials; the datatracker shows no WG stream (kyapay).
• The IETF agentproto charter (01, approved 2026-10-08) names Web Authorization Protocol (OAuth), webbotauth and WIMSE for identity, authorization and security; its PR #128 on the user agent and service agent distinction was closed without a merge on 2026-10-08 (ietf-agentproto).
• The draft W3C Agentic Web charter lists agent identity, delegation and interaction context among its scope items (w3c-agenticweb-wg).
• Browsers on WebMCP: WebKit issue #670 was closed on 2026-06-11 with "position: oppose"; Mozilla issue #1412 on 2026-08-05 with "position: neutral"; Chrome published an early preview on 2026-02-10; the Edge post of 2026-09-21 says its implementation "is ready for testing" (browsers-webmcp, w3c-webmcp-cg-report).
• An OpenID Foundation whitepaper outlines identity and authorization resources for AI agents and sets a strategic agenda (arXiv 2510.25819) (oidf-authzen-agents).

S4. Signed terms, authorisation and receipts

ap2, verifiable-intent, ucp, acp, x402, ietf-httpauth-payment, emvco-agentic-payments-framework, fido-agentic-standards, aaif-wg-agentic-commerce, ietf-vcon, emilia-protocol, browsers-webmcp, pap, pact, shopify

This seam compares the records the documents describe. It is not an assessment of legal compliance by any protocol, platform or merchant.

What each normative text says is signed, by whom, and what record exists is in the table "Payment protocols compared". By side:

• Buyer authorisation: AP2 mandates are signed Verifiable Digital Credentials, a Checkout Mandate and a Payment Mandate (ap2); Verifiable Intent is a layered SD-JWT credential format (verifiable-intent); the UCP AP2 extension requires platforms to provide mandates "proving the user explicitly authorized the specific checkout state and funds transfer" (ucp). EMVCo's draft framework describes "Intent Services" to "register, reference, retrieve and manage consumer-authorised intent" (emvco-agentic-payments-framework).
• Seller terms: UCP carries the seller's rules in policies[] (PR #572, merged 2026-07-23) and requires the business to "embed a cryptographic signature in checkout responses, proving the terms" (ucp); x402's offer-and-receipt extension lets the server commit to the payment terms of the offer (x402); ACP's checkout session carries a required links field (acp).
• Receipts and records: x402 signs receipts, with the wire shape "not considered stable" (x402); the IETF Payment draft defines an optional Payment-Receipt header with four fields, and its table has no signature field (ietf-httpauth-payment); ACP's order schema has receipt_url (acp); UCP signs order webhook payloads with an RFC 9421 message signature over the body, a property of the delivery (ucp).
• AP2: the merchant provides a merchant-signed Checkout JWT and, after accepting or rejecting the Checkout Mandate, returns a Checkout Receipt (status Success or Error, bound to the hash of the closed mandate); agent_authorization.md defines the Mandate Receipt as a "Verifier-signed JWT" (ap2). UCP's AP2 extension requires ap2.merchant_authorization in checkout responses and does not mention a receipt (ucp).
• AP2 Checkout Receipt, read in the native text on 2026-10-13 (docs/ap2 at commit e1ea56d, the head of main): "Once the Merchant has accepted or rejected the Checkout Mandate, it MUST return a Checkout Receipt." (docs/ap2/specification.md, section Checkout Mandate), returned to the Shopping Agent; the schema checkout_receipt.json requires status, iss, iat and reference (the hash of the closed mandate), with order_id on Success; the flows page calls it the "Merchant-signed Checkout Receipt". The receipt closes the checkout against the mandate. The words refund and cancel are not found in the seven documents of docs/ap2; as a goods-return term "return" occurs only as the field return_policy ("30-day returns") in two example checkouts of checkout_mandate.md; fulfil(l) appears 3 times, only as a generic verb ("fulfill", "fulfilled", "fulfills"), never for the fulfilment of an order (recounted 2026-10-14), and for disputes the specification says that how the mandates and receipts are used is "outside the scope of this specification" (ap2).
• Dispute: Verifiable Intent declares dispute resolution out of scope (verifiable-intent); the AP2 FAQ says that in a dispute a network adjudicator can use the user-signed Checkout Mandate (ap2); x402's auth-capture scheme defines void, refund and reclaim (x402).
• Standards track: the FIDO Alliance release of 2026-04-28 says the AP2 and Verifiable Intent contributions will be reviewed and further developed in its Payments Technical Working Group, and the AP2 repository says its core specification has been donated to FIDO (fido-agentic-standards, ap2).
• AAIF Agentic Commerce group, Running Notes of 2026-07-22: "Presentation is not active consent", with the open question of distinguishing required disclosure, active consent, delegated authority and human escalation (aaif-wg-agentic-commerce).
• Not found in the files, issues and pull requests of UCP, ACP, AP2, x402, Verifiable Intent and Visa TAP, 2026-10-06: vCon; and not found in the vCon texts read, 2026-10-06: any of those protocols; the IETF vcon group and the AUDIT effort work on a record format for agent conversations, and the individual draft CHEQ proposes a signed object by which a human confirms an action proposed by an AI agent (ietf-vcon, ietf-audit).
• Approval gate: UCP Discussion #563 proposes an approval gate for unattended buying agents (ucp); AAIF Identity and Trust issue #13 compares how MintID and Proofable record authority, decision, dispatch and effect (https://github.com/aaif/wg-identity-and-trust/issues/13, read 2026-10-08).
• In PayPal's WebMCP implementation for Store Sync merchants the agent initiates checkout and "The buyer is then handed off to PayPal to sign in, choose or confirm a funding source, review the transaction, and approve payment" (browsers-webmcp). In the EMILIA README example, an MCP payment server "refuses a call without approval, binds approval to the amount, currency, vendor, and destination" and is a local demonstration (emilia-protocol).
• Merchant decisions: UCP Discussion #895 asks about signed, portable evidence for merchant accept and refuse decisions; Issue #896 proposes a contingencies extension in which the business "notes on the Order which rule it applied" (ucp).
• Reasoning and evidence, side by side (not a finding about either): the proposed vCon AI Agent Extension lists prompts and reasoning together with tool call requests and responses (ietf-vcon); the EMILIA architecture draft says "A valid signature, a current credential, a satisfied evidence requirement, and an observed effect remain different facts." (emilia-protocol).
• Digests and bytes: in the Proofable docs repository (https://github.com/proofable/docs) an earlier evidence packet (commits 3a45f02 to 4ceb58b, 2026-10-06 to 2026-10-08) had manifest digests computed over CRLF bytes, as its author stated in the message of commit 63fc73b (2026-10-07), "The prior manifest digests were computed over CRLF bytes while git stores LF."; the packet frozen at commit 9851059 (2026-10-08) matches its SHA256SUMS (recomputed 2026-10-13); issue #287 and pull request #288 of agentrust-io/integrations were open on 2026-10-13 (aaif-identity-trust).
• Signal versus grant: the A2A specification says "Agents MUST NOT treat the TASK_STATE_AUTH_REQUIRED state transition, by itself, as authorization for any particular operation." (a2a-core), and Shopify's Checkout WebMCP documentation says of the permission to place an order that "WBA and ready_for_complete don't grant it." (browsers-webmcp); compare the approval items above (UCP #563, #678 with #883, AAIF issue #13).
• Operator-reported until reproduced (AAIF list message 48, 2026-10-08, read by the author on 2026-10-09): "record the new fixes and traces as operator-reported until independently reproduced" and "out_of_scope does not establish veto enforcement at a protected executor" (https://lists.aaif.io/g/wg-identity-trust/message/48; aaif-identity-trust).
• Reports and confirmations, three texts read on 2026-10-13. Poppy operations, section 8: a confirmation shows that a Personal Agent "stated that the User approved a specific revision of the terms", and "It doesn't prove that the User saw the terms or approved them." (pap). PACT, section 5.6: each reply under a delegation token carries a signed receipt of the grant, scopes used and actions, and "Personal agents SHOULD verify and keep receipts"; section 3.3 says what the identity token does not prove (pact). Shopify/shop, transactions.md: the agent's completion of a spend request "records your report, not payment confirmation", an issued credential state "does not establish credential delivery or payment", and cancelling "does not cancel/refund the purchase or revoke an issued credential" (shopify). In the three, the record is addressed to the Company, the personal agent or the agent's own report; a confirmation to the consumer on a durable medium is not found in the Poppy specification and operations pages, the PACT specification page or the Shopify/shop README, SKILL.md and transactions.md (2026-10-13).
• Open proposals on records (UCP #515, #629, #895, #896; ACP #231, #265, #303, #304; x402 receipts and reviews) are in the Open proposals appendix.

Free text against structured data

ucp

Where a business may answer in free text and a structured capability defines the same kind of fact as a field, the texts say which one a consumer relies on. One line per source; the author of this map commented on the pull request of the last line (see Disclosure).

• UCP ask (Common capability, merged 2026-10-07 in PR #538; docs/specification/common/ask/index.md at commit f2206e6): the answer is free text authored by the business, with plain text required; "An answer is indicative, not authoritative." and where it conflicts with the representation returned by the capability that owns the resource, "that representation is authoritative and the Platform MUST prefer it" (lines 198 to 204; https://github.com/Universal-Commerce-Protocol/ucp/blob/f2206e680f64fe2cc73495acc3557569afd9097a/docs/specification/common/ask/index.md; ucp).
• The same page: "A Platform MUST NOT treat an answer as the binding disclosure for a safety, allergen, or regulatory claim." (lines 205 and 206); a business should carry such a notice as a warning with presentation disclosure "rather than only in the answer text" (lines 214 and 215), and warnings with that presentation "carry notices the Platform MUST NOT hide or dismiss" (lines 304 and 305) (ucp).
• UCP PR #897 (food domain, open; head 4c2c601 on 2026-10-09): the allergen notice is a warning with code allergens and presentation disclosure; the example in docs/specification/food/checkout/index.md gives it as a sentence, "Prepared in a kitchen that handles peanuts, tree nuts, sesame, and wheat.", with a link. A structured allergen field is not found in the 35 files of the pull request at that head (all occurrences of the word are in that one documentation file, 2026-10-09). The author of this map commented on 2026-10-09 asking for an optional list of allergen codes beside the free text, with the code list named because the lists differ by jurisdiction (https://github.com/Universal-Commerce-Protocol/ucp/pull/897#issuecomment-6074516498; ucp).

Not established versus negative

ietf-dawn, ietf-audit, ietf-agentproto, ucp, ard, aaif-wg-agentic-commerce

Several venues distinguish a result that could not be established from a negative one, each in its own vocabulary. One line per venue; none of them defines the others' terms.

• DAWN list, 2026-10-07: a reference that does not resolve, one blocked by the discovering entity's retrieval policy and one that resolves with the record absent, which "end as no discovery result, and they have different owners and different retries" (https://mailarchive.ietf.org/arch/msg/dawn/Ce73ar_tEl0XO2FE41sdNKAGjc8/; ietf-dawn).
• AUDIT list, 2026-10-06: an unavailable source or incomplete coverage "produces an incomplete audit, never an absence finding", and the claim is only that "no qualifying record was found in the declared sources by the cutoff" (https://mailarchive.ietf.org/arch/msg/audit/u04Utry2tPGRqJ_f-SmRk_EMW88/; ietf-audit).
• AAIF Identity and Trust issue #13, 2026-10-04: the labels agreed on the list are not applicable (no equivalent), not emitted (exists, not published, by design) and not measured (https://github.com/aaif/wg-identity-and-trust/issues/13#issuecomment-5981946163).
• UCP Discussion #867, 2026-09-26: the proposed reporting frame counts hosts that refused by robots.txt or could not be reached as their own figures beside the result, and not as a "no" (https://github.com/Universal-Commerce-Protocol/ucp/discussions/867; ucp; the author of this map wrote the discussion, see Disclosure).
• agentproto list, thread "Topic: Existing practice, use cases, and deployment models" (the "Topic 1" input set), 2026-10-05: the author of draft-konda-agentproto-evaluation-state wrote "An unestablished input is a different fact from a negative one" and offered to write the bullet for section 3.3.3 or 3.3.5 of the use cases text (https://mailarchive.ietf.org/arch/msg/agentproto/Oaunfd9TaD0GPF8cS3W9J7m8CQ8/); Iman Schrock answered the same day with, for 3.3.5, "If a required authorization input cannot be established, preserve that fact separately from an evaluated refusal, even when both lead to local denial." (https://mailarchive.ietf.org/arch/msg/agentproto/XMpnWAx0K2u_ct-wh0sYFcPAiQ8/; ietf-agentproto).
• Lighthouse PR #17295 (merged on 2026-10-09, GitHub merge record read on 2026-10-14): the robots-txt and llms-txt audits treat HTTP 429 as a server error and not as an absent file, following Google's robots.txt specification (https://github.com/GoogleChrome/lighthouse/pull/17295; ard).
• draft-krausz-verification-state-03 separates indeterminate from not_evaluated; a commenter on AAIF issue #5 writes that a mapping "would need to preserve the distinction between an inconclusive evaluation and one that did not occur" (https://github.com/aaif/wg-agentic-commerce/issues/5#issuecomment-6052049160; aaif-wg-agentic-commerce).
• AUDIT case 8, 2026-10-08: a verified refusal "can make that effect slot not applicable when the declaration names refusal as a terminal condition", while the refusal "should satisfy the decision slot, not fill the downstream effect slot" (https://mailarchive.ietf.org/arch/msg/audit/p_gA6xAzlBBK3DIMl0SFszYUnmE/; ietf-audit).
• UCP #904 and #867, 2026-10-08 and 2026-10-09: the first version of the census run listed its 7 responses of 200 that did not parse among the cases it could not ask, and the reply of the author of this map read them as row 1 without row 2, an answer of the site (https://github.com/Universal-Commerce-Protocol/ucp/discussions/867#discussioncomment-18812160); in the version of 2026-10-09 of the same comment, a re-run, the 6 that answer 200 and do not parse are counted as "row 1 without row 2" and the site-side and prober-side lines of could not ask are separate (https://github.com/Universal-Commerce-Protocol/ucp/discussions/867#discussioncomment-18810486 and https://github.com/Universal-Commerce-Protocol/ucp/discussions/867#discussioncomment-18831816; ucp).
• Counterexample: UCP PR #691 makes not declared and absent the same thing; its author wrote on 2026-10-07 that "an absent price_treatment and an absent tax now mean the same thing everywhere" (https://github.com/Universal-Commerce-Protocol/ucp/pull/691#issuecomment-6039591246; ucp).
• Lodging, Discussion #864, 2026-10-08: a hotel revenue management practitioner writes that a rate restriction such as a minimum stay would "likely return inventory_exhausted, which gives the agent nothing to recover with"; the standard error table lists inventory_exhausted as "The selected accommodation unit or inventory hold is no longer available" and no code for restrictions (https://github.com/Universal-Commerce-Protocol/ucp/discussions/864#discussioncomment-18816854; ucp).
• On whether a 404 or a 410 at the profile path means an absence or a decision not to take part, the author of this map commented in UCP issue #904 on 2026-10-07 (https://github.com/Universal-Commerce-Protocol/ucp/issues/904#issuecomment-6032850150; see Disclosure; ucp).
• AAIF Identity and Trust, shared runner (agentrust-io/integrations issue #287, 2026-10-07): the scope asks to "Preserve not_applicable, not_emitted and not_measured" as distinct states (https://github.com/agentrust-io/integrations/issues/287; aaif-identity-trust).
• AAIF Identity and Trust, list message 45 (a participant who submitted the runner, 2026-10-08, read by the author on 2026-10-09): "all 14 contract fields receive explicit states, with not_applicable, not_emitted and not_measured kept distinct"; the fixes are in an external repository and pull request #288 of agentrust-io/integrations had not been updated on 2026-10-09 (aaif-identity-trust).
• AAIF Identity and Trust, list message 46 (a MintID participant, 2026-10-08, read by the author on 2026-10-09): "a verifier's refusal is a decision, not evidence that a relying party enforces the veto"; and a 5xx is "recorded as a service interruption, never as a decision" (aaif-identity-trust).
• Evidence named, not only its age (AAIF list message 40, a MintID participant, 2026-10-06, read by the author on 2026-10-09): "name the evidence each decision rested on (for us, the root's epoch and height), not only its age; that is what lets a reader tell" (https://lists.aaif.io/g/wg-identity-trust/message/40; aaif-identity-trust).
• Evidence-strength labels, AAIF Identity and Trust issue #5 (opened 2026-08-25 by a participant): the title is "Proposal: evidence-strength labels for agent identity, authorization, and consent claims (declared vs observed)" and the body says "an approval record is an evidence claim that can be self-declared or independently verified"; a comment of the Proofable author (6020760992, 2026-10-06) writes "portable proof/receipt = the verifiable protocol record" and "appraisal = what the relying party established about that record" (https://github.com/aaif/wg-identity-and-trust/issues/5; aaif-identity-trust).