A-Comm Evidence Protocol (AEP) v1.0.1

1.1 Problem Statement

AI-mediated commerce is growing rapidly. Consumers increasingly discover and purchase products through AI chat interfaces — ChatGPT, Google Gemini, Perplexity, Microsoft Copilot — where product recommendations drive real transactions. This creates a new class of dispute risk:

• The consumer interacted with an AI agent, not a human or traditional web UI
• No browser-native referrer chain is reliable across AI platforms
• The authorization trail exists, but the intent trail — what was asked, what was recommended, what was confirmed — is typically absent from PSP evidence
• Merchants cannot prove to card networks that a consumer explicitly authorized an agentic transaction

AEP solves this by defining a tamper-evident evidence chain that captures every step from AI-driven discovery through order fulfillment, producing a dispute-grade artifact bundle that merchants can submit to PSPs and card network reviewers.

1.2 Design Goals

• Tamper-evident: Any modification to any artifact in the chain is detectable at all subsequent nodes without requiring a trusted third party.
• Dispute-grade: The evidence bundle maps directly to Stripe, Adyen, and card network representment evidence fields.
• PII-minimal: Consumer identifiers are pseudonymized. No raw card data, no PAN, no personal identifiers in any artifact payload.
• Platform-agnostic: Works across Shopify, WooCommerce, BigCommerce, Magento, and any PSP.
• Open: Apache 2.0. Any implementation can generate and verify AEP chains without dependency on A-Comm Inc.
• Attribution-aware: Bridges AI platform citation events (ChatGPT, Gemini, Perplexity, Copilot) into the cryptographic chain as a first-class artifact type.

2.1 Evidence Chain

A transaction chain is a linear sequence of artifacts, beginning with a genesis artifact and extending forward as the consumer progresses through discovery, intent, authorization, and fulfillment. Each artifact carries:

• A canonical type (one of seven defined artifact layers)
• A typed payload specific to that layer
• A cryptographic hash of the previous artifact, linking the chain
• A signature from the artifact's producer

The chain is tamper-evident: modifying any artifact changes its hash, which breaks every subsequent link. Verification is deterministic and requires no trusted third party.

2.2 Artifact Layers

A complete agentic commerce transaction spans up to eight artifact layers. The first two (discovery and referral) are present only when the consumer arrived via an external AI platform. The fourth (delegation) is present when one or more agentic commerce protocols (TAP, AP2, ACP, UCP, MCP) carried the transaction.

Normative payload schemas for each layer are defined in Section 3 of the full specification. Every field carries a signal class (see §2.6) so evidence weight is legible to reviewers.

2.3 Actors

Four actor roles participate in an AEP chain:

• Consumer — the end user whose intent drives the transaction. Identified pseudonymously.
• Agent — an AI platform or on-site conversational agent that surfaces products or takes action on behalf of the consumer.
• Merchant — the seller fulfilling the transaction; producer of intent, policy, cart, and fulfillment artifacts.
• PSP — the payment service provider (Stripe, Adyen, Square, etc.); producer of the authorization artifact.

Each artifact is signed by the actor that produces it, enabling downstream verifiers to attribute responsibility for every step in the chain.

2.4 Sealing Model

An AEP chain is sealed when its final artifact is produced and no further artifacts are appended. A sealed chain produces a single, exportable evidence bundle containing all artifacts in sequence, their hashes, and their signatures. The bundle is the primary unit consumed by dispute resolution workflows, regulatory audit, and analytics.

Sealed chains are immutable. To record a correction or follow-up action (refund, return, chargeback response), a new chain is started and cross-referenced via artifact metadata; the original chain is never modified.

2.5 Protocol Interoperability

AEP is protocol-agnostic. It does not replace or compete with the emerging agentic commerce protocols — it wraps them. Every AEP artifact carries a protocol field identifying which protocol carried the handshake it represents, and a protocol_metadata sub-object carrying the protocol-specific payload (signatures, mandates, session IDs, tool call records).

Supported protocols (v1.0.1):

Multi-protocol chains: A single transaction may carry multiple protocols simultaneously — for example, TAP for agent identity + AP2 for consumer authorization + ACP for session binding. AEP captures all three in one Delegation artifact. This composition is the strongest possible evidence configuration.

Cross-protocol witness: Because AEP wraps rather than replaces these protocols, an AEP chain is the only evidence structure that records which protocol(s) carried a given transaction, producing a cross-protocol interoperability record that no single protocol produces on its own.

2.6 Signal Classification

Every field in every AEP artifact carries a signal class that tells dispute reviewers, regulators, and downstream systems how much weight to place on the field. Signal classification is a first-class AEP concept and is preserved on export to PSPs, card networks, and dispute-management platforms.

Chain-level strength ranking. §3.9.12 of the full specification defines an S/A/B/C/D evidence strength tier derived from the Delegation artifact's signal composition (TAP present, AP2 present, ACP session-binding present, etc.). Future AEP revisions may extend strength scoring across the full chain.

9.1 Transaction Flow Diagram

┌───────────────────────────────────────────────────────────────────────────────┐
│                       PAYMENT PATH (in the flow)                              │
│                                                                               │
│  Consumer → AI Agent & Protocol → Merchant → PSP → Network → Issuer           │
└────────────────────────────────────┬──────────────────────────────────────────┘
                                     │
                        Reads events from every step
                                     │
┌────────────────────────────────────▼──────────────────────────────────────────┐
│                     A-COMM EVIDENCE LAYER (adjacent)                          │
│                                                                               │
│  Discovery → Referral → Intent → Delegation → Policy → Cart → Auth → Fulfill  │
│                                                                               │
│  Hash-chained, cross-network, dispute-grade evidence bundle                   │
└───────────────────────────────────────────────────────────────────────────────┘

9.2 Positioning by Phase

9.3 What A-Comm Is NOT

A-Comm is explicitly not in any of the following categories:

9.4 Regulatory Classification

A-Comm operates in the observability and evidence infrastructure category — the same category as Datadog, Snowflake, and Segment. A-Comm is subject to:

• CCPA and applicable U.S. state privacy laws (consumer data, DSRs within 45 days, published privacy policy)
• Two-party consent state requirements for chat/voice recording (CA, FL, IL, MD, MA, MI, MT, NV, NH, OR, PA, WA)
• FTC AI disclosure requirements (chat agent identifies itself as AI when sincerely asked)
• SOC 2 compliance for evidence storage
• GPC signal and consent cookie honoring in referral tracking

A-Comm is not subject to money transmitter licensing, PCI-DSS Level 1 scope (as an acquirer or processor), banking regulation, or Visa/Mastercard operating regulations for participants in the payment path.