A-Comm Evidence Protocol (AEP) v1.1.0

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
• The delegation trail — what the consumer authorized the agent to do, within what limits, and at which merchants — is not captured by any existing payment infrastructure
• Merchants cannot prove to card networks that a consumer explicitly authorized an agentic transaction

Payment networks are responding with enforcement-layer solutions: Visa Intelligent Commerce (TAP + Payment Instructions + AI-Ready Cards + Verifi) provides agent identity verification, spending limits, and category restrictions enforced at VisaNet. Mastercard Agent Pay (Verifiable Intent + Agent Pay program + Ethoca) captures identity and action-level intent with real-time dispute data sharing. These are valuable prevention systems within their respective networks.

However, enforcement-layer solutions face structural limitations in the dispute context:

• Network-bound: Visa IC operates on the Visa rail only; MC Agent Pay on the Mastercard rail only. Neither produces evidence usable in a cross-network dispute.
• Enforcement, not evidence: Payment Instructions are rules loaded into VisaNet. When enforcement fails — misconfiguration, agent circumvention, or a transaction that processes on a different rail — there is no hash-chained evidence artifact proving the rules existed.
• Category-level, not semantic: Payment Instructions capture "electronics under $200." They cannot capture "wireless noise-canceling headphones" — the semantic detail that agent-mediated disputes actually turn on.
• No fulfillment attestation: Both systems' scope ends at authorization. Neither produces a post-authorization delivery proof artifact.

AEP solves this by defining a tamper-evident, cross-network 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. AEP is designed to complement network enforcement systems — not replace them. When prevention succeeds, the dispute never happens. When prevention fails or the transaction crosses rails, AEP provides the post-hoc evidence layer.

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.
• Cross-network: Evidence bundles are usable in disputes on any payment rail — Visa, Mastercard, Amex, ACH, or emerging rails. AEP is not bound to any single network's infrastructure.
• Network-complementary: Designed to work alongside network enforcement systems (Visa Intelligent Commerce, Mastercard Agent Pay) — not replace them. AEP captures the evidence layer that enforcement systems do not produce.
• Semantic-resolution: Captures consumer intent at the natural-language level ("wireless noise-canceling headphones under $200"), not category-level ("electronics") — the resolution at which agent-mediated disputes are adjudicated.
• 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 Commerce Journey 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 delegation layer is present only when an AI agent acts on behalf of a consumer:

2.2 Transaction Type Matrix

Transactions are classified on two orthogonal axes: how the consumer arrived (AI referral vs. direct) and how they purchased (via merchant agent vs. standard storefront checkout). This produces a 2×2 matrix. The delegation artifact is present only for agent-mediated purchase paths:

2.3 Sequential Hash Chain Model

AEP uses a sequential previous-hash model where previous_hash is included inside the hash input of every artifact. This is distinct from reference-pointer hash chain models:

Because previous_hash is inside the hash input, any reordering or insertion in the sequence invalidates the hash of every subsequent artifact. Verification does not require a trusted third party — anyone with the artifact sequence can independently verify integrity.

2.4 Actors

Every artifact is attributed to a specific actor — the entity responsible for that event in the commerce journey:

2.5 Sealing Model

The chain is sealed at the authorization layer. Sealing means:

• The current_hash of the authorization artifact is stored as sealed_bundle_hash on the transaction chain record
• sealed_bundle_hash is immutable once set — no update path exists
• Only fulfillment artifacts may be appended post-seal, via the async late-arrival append path
• The fulfillment artifact includes the sealed authorization hash in its chain, so any post-seal fulfillment record is still cryptographically bound to the sealed chain

3.1 Discovery Artifact

The discovery artifact bridges the citation monitoring system into the evidence chain. It records the moment an AI platform surfaced a merchant product in a consumer-facing response — before any click, referral, or purchase event.

Payload Schema

{
  "platform": "chatgpt" | "gemini" | "perplexity" | "copilot" | "meta",
                                     // at least one of platform or referral_url is required
  "query": "string — the consumer's query to the AI platform (optional)",
  "referral_url": "string — URL cited by the AI platform (optional)",
  "citation_position": "number — rank of product in AI response (optional)",
  "attribution_method": "referral_param" | "merchant_tracked_link"
                       | "referrer_header" | "behavioral_heuristic" (optional),
  "confidence_score": "number 0.0–1.0 (optional)"
}
// Note: at least one of `platform` or `referral_url` must be present.
// Unknown fields are stripped by the reference implementation (strict validation).

AI Platform Coverage

The discovery artifact captures product citations from all major AI chat platforms that drive agentic commerce traffic. Platform-specific notes:

Actor Constraints

Permitted actor types for discovery artifacts: agent (when the AI platform citation is detected via synthetic monitoring or the citation system), merchant (when the discovery event is triggered via a merchant-controlled tracked link).

3.2 Referral Artifact

Records the inbound session event — the consumer clicking through from the AI platform citation to the merchant's site. Links the discovery artifact to the on-site session.

Payload Schema

{
  "referral_event_id": "string — ID of the agentic_referral_event row (required)",
  "session_token": "string — signed, merchant-scoped session token (required)",
  "product_id": "string — product cited in the AI response (required)",
  "agent": "string — AI agent slug: chatgpt | gemini | perplexity | copilot | meta (required)",
  "consent_given": "boolean — whether GPC / acomm_consent signal was clear (optional)"
}

Actor type: user. The consumer's actor ID is HMAC-SHA256(consumer_ip, per-merchant-salt) — a pseudonymized identifier that cannot be reversed to a real IP address. The referral tracking system records this event on the backend; the actor type represents the consumer whose session originated from the AI citation.

3.3 Intent Artifact

Records the consumer's or agent's explicit purchase intent — the specific product selected and configured before cart addition.

Payload Schema

{
  "product_id": "string (required)",
  "product_name": "string (required)",
  "quantity": "number, integer ≥ 1 (required)",
  "variant": "string — size/color/SKU (optional)",
  "query": "string — consumer's request if agent-mediated (optional)",
  "unit_price": "string — price at time of intent, avoids float precision (optional)",
  "currency": "string — ISO 4217, e.g. 'USD' (optional)"
}

Permitted actor types: user, agent.

3.4 Delegation Artifact

Records the consumer's delegation of authority to an AI agent — the scope, constraints, and limits within which the agent is authorized to act. This artifact is the primary evidence layer for agent-mediated delegation disputes: spending limit violations, unauthorized merchant purchases, and scope exceedances are deterministically provable by comparing the delegation artifact against the authorization artifact.

Payload Schema

{
  "delegatee_agent_id": "string — agent identifier (required)",
  "delegatee_agent_name": "string — human-readable agent name (required)",
  "scope": "full" | "limited" (required),
  "spending_limit": {
    "value": "string — decimal amount (required if scope=limited)",
    "currency": "string — ISO 4217 (required if scope=limited)"
  },
  "allowed_actions": ["string"] (required),
  "merchant_restrictions": {
    "type": "allowlist" | "blocklist" | "category" | "none" (required),
    "values": ["string"] (optional)
  },
  "time_window": {
    "start": "ISO8601 UTC (optional)",
    "end": "ISO8601 UTC (optional)"
  },
  "authentication_method": "string — how consumer authorized delegation (required)"
}

Permitted actor types: user. The delegation artifact always records the consumer's action — the consumer is the delegator.

Present only in agent-mediated transaction types (ai_referral_agent_session, agent_session_only). Absent in standard checkout types.

3.5 Policy Artifact

Records the outcome of the merchant's policy engine evaluation. The policy check must occur after intent and before authorization. Implementors must never authorize a transaction without a preceding policy artifact.

Payload Schema

{
  "policy_version": "string (required)",
  "evaluation_result": "approved" | "blocked" | "escalated" (required),
  "rules_evaluated": ["string"] (optional),
  "reason": "string — required if blocked or escalated (optional)"
}

Actor type: merchant. In pilot deployments without a full policy engine, this artifact is auto-generated by the reference implementation with evaluation_result: "approved" and policy_version: "default-v1".

3.6 Consent Artifact

Records the consumer's explicit confirmation of the specific items, quantities, and total price before checkout. In agent-mediated transactions, this is the artifact that binds the consumer's approval to the exact products the agent selected — proving not just that the consumer authorized a purchase, but that they confirmed these specific items at this specific price.

Payload Schema

{
  "confirmed": true,
  "consent_method": "explicit" | "delegated" | "implicit" (required),
  "items": [
    {
      "product_id": "string",
      "product_name": "string",
      "quantity": "number",
      "unit_price": "string",
      "variant": "string (optional)"
    }
  ],
  "total_amount": "string",
  "currency": "string (ISO 4217)"
}

The consent_method field is critical for dispute adjudication:

• explicit — consumer reviewed and confirmed each item individually (strongest evidence)
• delegated — agent confirmed items within delegation scope on consumer's behalf (delegation artifact must be present)
• implicit — standard storefront checkout with cart review (traditional e-commerce model)

Permitted actor types: user, agent.

3.7 Authorization Artifact

Records the PSP authorization result. This artifact is the seal point. Its current_hash becomes sealed_bundle_hash on the transaction chain.

Payload Schema

{
  "payment_token_reference": "string — PSP-issued token only, never PAN",
  "psp": "string — PSP name (e.g., 'stripe', 'adyen')",
  "authorization_code": "string",
  "amount_authorized": "string",
  "currency": "string (ISO 4217)",
  "payment_method_type": "string (e.g., 'card', 'apple_pay')"
}

Actor type: psp.

3.8 Fulfillment Artifact

Records the fulfillment provider's shipping and delivery data. This artifact may arrive asynchronously after the chain is sealed and must be accepted via the late-arrival append path.

Payload Schema

{
  "carrier": "string (required)",
  "status": "pending" | "in_transit" | "delivered" | "failed" | "returned" (required),
  "tracking_number": "string (optional)",
  "tracking_url": "string — publicly accessible URL (optional)",
  "shipped_at": "ISO8601 UTC timestamp (optional)",
  "delivered_at": "ISO8601 UTC timestamp (optional)",
  "destination_address": "string — city/state/country only; no street address (optional)",
  "platform_order_id": "string — platform-native order ID, e.g. Shopify GID (optional)"
}

Actor type: fulfillment_provider.

3.9 Artifact Type Reference

4.1 Hash Formula

The current_hash of every artifact is computed as SHA-256 over the canonical JSON representation of the artifact's hash input. All fields that contribute to the hash are listed below:

current_hash = SHA256(canonical_json({
  actor_id,           // normalized actor identifier
  actor_type,         // 'user' | 'agent' | 'merchant' | 'psp' | 'fulfillment_provider'
  artifact_type,      // 'discovery' | 'referral' | 'intent' | 'delegation' | 'policy' | 'consent' | 'authorization' | 'fulfillment'
  interaction_channel, // 'voice' | 'text_chat' | 'voice_and_text' | null
  metadata,           // {protocol, sdk_version, merchant_id, session_id, ...} | null
  payload,            // type-specific payload object
  previous_hash,      // SHA256 of preceding artifact | null (genesis only)
  timestamp           // ISO8601 UTC — RFC3339 'Z' format enforced
}))

The hash is output as a hex-prefixed string: sha256:<64-character lowercase hex>.

Hash Output Format

sha256:a3f1c8b0e2d4f6a1b3c5e7f9a1b3c5e7f9a1b3c5e7f9a1b3c5e7f9a1b3c5e7f9

4.2 Genesis Artifact

The first artifact in any chain is the genesis artifact. Its distinguishing property is that previous_hash is null. All subsequent artifacts must have a non-null previous_hash equal to the current_hash of the immediately preceding artifact.

4.3 Ed25519 Server Signature

Every artifact carries a required Ed25519 server signature over its current_hash. The signature is stored as a separate field (server_signature) on the artifact record and is never included in the hash input itself.

server_signature = Ed25519Sign(private_key, current_hash)

The corresponding Ed25519 public key is published by the implementing party (A-Comm Inc. or any independent implementor) to allow third-party verification without access to the private key.

Verification Steps (per artifact)

1. Recompute current_hash from the artifact's hash input fields
2. Assert recomputed hash equals stored current_hash (constant-time comparison)
3. Verify Ed25519 server_signature against the stored current_hash using the published public key
4. Verify previous_hash equals current_hash of the preceding artifact (except genesis)

7.1 Platform Coverage

AEP natively supports four AI platforms as discovery sources. Each platform has distinct referrer behavior that affects which attribution methods are reliable:

7.2 Attribution Methods

The attribution_method field on the discovery artifact records how the AI citation was linked to the inbound session:

7.3 Session Linkage Chain

Connecting a discovery artifact to a payment authorization requires the ehc_transaction_id to propagate through the consumer's browser session. The reference implementation uses the following linkage chain:

1.  Consumer arrives via AI citation
        → POST /v1/events/referral (referral tracking script)
        → EHC transaction created; discovery + referral artifacts appended
        → Response includes: { ehc_transaction_id: "txn_..." }
        → Store: sessionStorage.setItem("acomm_ehc_transaction_id", id)
                 + cookie: acomm_ehc=txn_...; SameSite=None; Secure

2.  Consumer adds product to cart
        → Shopify Web Pixel: analytics.subscribe("product_added_to_cart", ...)
        → POST /v1/ehc/artifacts  { artifact_type: "intent", ... }
          Auth: X-Acomm-Session header (session token, not cookie)
        → Intent artifact appended (seq 3)

3.  Consumer proceeds to checkout
        → Shopify Checkout Extension (purchase.checkout.block.render)
        → useCartLines() + useTotalAmount() → cart artifact payload
        → POST /v1/ehc/artifacts  { artifact_type: "cart", confirmed: true, ... }
        → Cart artifact appended (seq 5 or 3)
        → Sets Shopify order metafield: acomm_ehc_transaction_id = txn_...

4.  Consumer pays
        → Stripe PaymentIntent created with metadata:
            { acls_ehc_transaction_id: "txn_...", acls_account_id: "acc_..." }
        → payment_intent.succeeded webhook fires
        → Authorization artifact appended + chain sealed

The ehc_transaction_id is the single token that ties all four steps together. Implementations must propagate it from the initial referral response through to the Stripe PaymentIntent metadata. Loss of this token at any step results in an incomplete chain.

8.1 Immutability Enforcement

AEP artifacts must be append-only. The storage layer must enforce immutability at the database level — application-layer enforcement alone is insufficient because it can be bypassed by direct database access or administrative operations.

Recommended PostgreSQL implementation

-- Prevent mutation of immutable fields
CREATE OR REPLACE FUNCTION prevent_ehc_artifact_mutation()
RETURNS TRIGGER AS $$
BEGIN
  RAISE EXCEPTION
    'ehc_artifacts rows are immutable. Attempted update on id=% field=%',
    OLD.id, TG_OP;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER ehc_artifacts_immutability_update
  BEFORE UPDATE ON ehc_artifacts
  FOR EACH ROW EXECUTE FUNCTION prevent_ehc_artifact_mutation();

-- Prevent deletion
CREATE OR REPLACE FUNCTION prevent_ehc_artifact_delete()
RETURNS TRIGGER AS $$
BEGIN
  RAISE EXCEPTION
    'ehc_artifacts rows are immutable and cannot be deleted. id=%', OLD.id;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER ehc_artifacts_immutability_delete
  BEFORE DELETE ON ehc_artifacts
  FOR EACH ROW EXECUTE FUNCTION prevent_ehc_artifact_delete();

Implementors must also ensure that sealed_bundle_hash on the transaction chain record is set once and never updated. Apply a CHECK constraint or trigger on the column to enforce this.

8.2 PII and Privacy

AEP is designed to be PII-minimal. The following rules apply to all artifact payloads:

• Consumer actor IDs must be pseudonymized using HMAC-SHA256 with a per-merchant secret salt: HMAC-SHA256(user_id, per_merchant_salt). Never store raw user IDs in artifact payloads.
• Email addresses, names, and physical addresses must not appear in artifact payloads. Destination addresses in fulfillment artifacts must be redacted to postal code only.
• Session tokens in discovery/referral payloads must be time-limited (maximum 24 hours), merchant-scoped, and verifiable — never raw session identifiers.
• The entire artifact chain must be exportable without exposing any PII that could identify the consumer to a third-party reviewer.

8.3 PCI-DSS Compliance

Authorization artifact payloads must never contain primary account numbers (PANs), CVVs, full magnetic stripe data, or any value that passes the Luhn algorithm.

Luhn check enforcement

Implementations must validate authorization payloads at ingestion using a Luhn check against all digit sequences of 13–19 digits. Any payload field containing a PAN-like pattern must be rejected before the artifact is created:

// PAN detection pattern
const PAN_REGEX = /\b(\d[ -]?){13,19}\b/g;

function passesLuhn(digits: string): boolean {
  const d = digits.replace(/\D/g, '');
  let sum = 0;
  let odd = false;
  for (let i = d.length - 1; i >= 0; i--) {
    let n = parseInt(d[i], 10);
    if (odd) { n *= 2; if (n > 9) n -= 9; }
    sum += n;
    odd = !odd;
  }
  return sum % 10 === 0;
}

function containsRawPaymentCredentials(payload: Record<string, unknown>): boolean {
  const text = JSON.stringify(payload);
  const matches = text.match(PAN_REGEX) ?? [];
  return matches.some(m => passesLuhn(m.replace(/\D/g, '')));
}

The only permitted payment credential field is payment_token_reference — an opaque PSP-issued token that references a stored payment method without containing any card data.

8.4 Idempotency

Artifact creation must be idempotent. Implementations must derive idempotency keys deterministically from the artifact's identifying properties, allowing retries without duplicate artifact creation:

idempotency_key = SHA256(
  transaction_id + ":" +
  artifact_type  + ":" +
  actor_id       + ":" +
  floor(timestamp_ms / 60000)  // 60-second window
)

The idempotency key must be stored with a UNIQUE constraint on the artifacts table. A duplicate key violation on insert should return the existing artifact rather than raising an error.

8.5 Data Retention

Evidence chain data must be retained long enough to support dispute resolution, audit, and regulatory review. AEP specifies the following retention model:

The retention_until timestamp is computed when the transaction is closed (completed_at is set): retention_until = completed_at + 730 days. Implementations should schedule automated deletion after this date.

9.1 Positioning Principle

Payment network systems and AEP operate at different layers of the agentic commerce stack:

• Network enforcement systems (Visa IC, MC Agent Pay) prevent disputes by enforcing rules at authorization time — spending limits, category restrictions, agent identity verification. When enforcement succeeds, the dispute never happens.
• AEP produces evidence for disputes that reach representment — when enforcement fails, when the transaction crosses rails, or when the dispute turns on semantic detail that enforcement cannot capture.

These are complementary, not competing. A merchant using both Visa IC and AEP has stronger protection than either alone: Visa IC prevents most violations in real time; AEP provides the evidence bundle when violations slip through or when the dispute is adjudicated on a non-Visa rail.

9.2 Visa Intelligent Commerce

Visa Intelligent Commerce consists of four components relevant to agentic commerce disputes:

Structural limitations (where AEP adds evidence Visa IC cannot produce)

• Visa-only: Payment Instructions and VisaNet enforcement operate on the Visa rail only. AEP evidence is usable in disputes on any payment rail.
• Enforcement, not evidence: Payment Instructions are rules loaded into VisaNet. When enforcement fails, there is no hash-chained evidence artifact proving the rules existed. AEP's delegation artifact is an immutable evidence record.
• Category-level, not semantic: Payment Instructions restrict by MCC code ("electronics") and spending limit. AEP's intent artifact captures "wireless noise-canceling headphones under $200" — the semantic resolution at which agent-mediated disputes are adjudicated.
• No fulfillment attestation: Visa IC's scope ends at authorization. AEP's fulfillment artifact provides post-authorization delivery proof.
• No merchant policy check: Visa IC operates at the network and consumer level. AEP's policy artifact records the merchant's own risk evaluation.

9.3 Mastercard Agent Pay

Mastercard Agent Pay consists of three components relevant to agentic commerce disputes:

Structural limitations (where AEP adds evidence MC Agent Pay cannot produce)

• Mastercard-only: Agent Pay and Verifiable Intent operate on the Mastercard rail only. AEP evidence is usable in disputes on any payment rail.
• Action-level, not semantic: Verifiable Intent captures "purchase" as the action. AEP captures the consumer's natural-language request — the semantic detail that determines whether the agent fulfilled the consumer's actual intent.
• No spending limit as structured field: Spending limits are not a native deterministic field in Agent Pay's evidence output. AEP's delegation artifact captures spending limits as a structured, hash-chained field that enables deterministic violation detection.
• No merchant restriction mechanism: Agent Pay has no field for domain-level merchant allowlists. AEP's delegation artifact captures merchant restrictions at the domain level ("sephora.com, ulta.com").
• No fulfillment attestation: MC Agent Pay scope ends at authorization. AEP's fulfillment artifact provides post-authorization delivery proof.
• No cross-layer hash chain: Verifiable Intent has internal cryptographic binding. AEP produces a cross-layer hash chain where every artifact is linked to its predecessor — any insertion, deletion, or mutation is detectable at every subsequent node.

9.4 Cross-Network Evidence Summary