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 Commerce Journey Layers

A complete agentic commerce transaction spans up to seven artifact layers. The first two (discovery and referral) are present only when the consumer arrived via an external AI platform:

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:

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

2.6 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 and is RECOMMENDED whenever the participating protocols are available.

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. This produces a cross-protocol interoperability record that no single protocol produces on its own, and provides the primary signal for the evidence strength ranking defined in §3.9.12.

Fallback behavior. Transactions that occur without any standard agentic protocol in play (for example, a consumer completing a traditional web checkout with no agent involvement) MUST set protocol to GENERIC and MAY omit the delegation artifact entirely. In this case, the chain proceeds directly from intent to policy.

2.7 Cross-Artifact Required Fields

The following fields MUST appear on every artifact in every chain, regardless of type. They establish chain identity, scoping, and deterministic ordering. Implementations MAY carry the chain-level fields (chain_id, merchant_id, session_id_hash, spec_version) at the bundle level rather than duplicating them per artifact; the normative canonical-JSON hash input MUST include them either way.

2.8 Signal Classification

Every field in every artifact payload has a signal class that tells dispute reviewers, regulators, and downstream systems how much weight to place on the field in evidentiary use. Signal classification is a first-class AEP concept and MUST be preserved on export. The four classes are:

Classification is per-field, not per-artifact. A single artifact MAY carry fields of multiple classes — for example, the Authorization artifact's network_transaction_id is Deterministic, while fraud_score is Deterministic but dependent on the PSP's engine, and hypothetical custom merchant fields would be Asserted. Implementations MUST propagate the signal class through exports (§6) so representment reviewers see it.

Strengthening signals is an implementation goal. A chain with many Attested and Deterministic fields is evidentiarily stronger than one with many Asserted fields. §3.9.12 defines an evidence strength tier (S/A/B/C/D) derived from the Delegation artifact's signal composition; future AEP revisions MAY extend the tier calculation across the full 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

{
  // Inferred — the AI platform attribution
  "platform":               "'chatgpt' | 'gemini' | 'perplexity' | 'copilot' | 'meta' (required
                             if at least one of platform or product_url_cited present)",
  "attribution_method":     "'url_params' | 'merchant_tracked_link' | 'referrer_header' |
                             'behavioral_heuristic' (required)",
  "attribution_confidence": "'high' | 'medium' | 'low' (required) — deterministic by
                             attribution_method: url_params + merchant_tracked_link = high,
                             referrer_header = medium, behavioral_heuristic = low",

  // Deterministic — product citation
  "product_url_cited":      "string — URL as it appeared in the AI response (required)",
  "citation_position":      "number — rank in AI response (asserted; only available if agent
                             reports it)",

  // Asserted — the consumer's query (only if agent leaks it; rare)
  "query_hash":             "string — 'sha256:...' of the query; raw query never stored (optional)",

  // Cross-artifact required fields
  "captured_at":            "string — ISO 8601 UTC (required)",
  "idempotency_key":        "string — stable per-discovery-event key (required)"
}
// 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

{
  // Deterministic — generated server-side on session start
  "referral_event_id":    "string — UUID of the agentic_referral_event row (required)",
  "referrer_domain":      "string — observed Referer header domain, if present (optional)",

  // Deterministic — pseudonymized; HMAC-SHA256 with per-merchant salt
  "consumer_ip_hash":     "string — 'sha256:...' (required)",
  "consumer_ip_country":  "string — ISO 3166-1 alpha-2 (required)",
  "user_agent_hash":      "string — 'sha256:...' (required)",

  // Deterministic — consent signals captured at the moment of session start
  "consent_gpc":          "boolean — Global Privacy Control header value (required)",
  "consent_cookie":       "'granted' | 'denied' | 'unset' (required)",

  // Deterministic — product context
  "product_id":           "string — product cited in the AI response (optional)",

  // Cross-artifact required fields
  "captured_at":          "string — ISO 8601 UTC (required)",
  "idempotency_key":      "string — stable per-request key (required)"
}

Actor & Signing

Permitted 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. Artifact signing actor: merchant (the merchant's referral-tracking endpoint records and signs the event).

3.3 Intent Artifact

Records the consumer's or agent's explicit purchase intent — the specific product selected and configured before cart addition. When an AP2 Intent Mandate is present, its signature MUST be captured in the Delegation artifact (§3.9) rather than duplicated here.

Payload Schema

{
  // Deterministic identifiers
  "intent_id":          "string — UUID, stable per-intent (required)",
  "product_id":         "string (required)",
  "product_name":       "string (required)",
  "variant_id":         "string — merchant SKU or variant ID (optional)",
  "quantity":           "number, integer ≥ 1 (required)",

  // Deterministic pricing — captured at the moment of intent
  "unit_price":         "integer — minor units (e.g. cents), avoids float precision (required)",
  "currency":           "string — ISO 4217, e.g. 'USD' (required)",
  "price_displayed_at": "string — ISO 8601 UTC when the price was shown to the consumer (required)",

  // Optional agent-mediated context
  "query_hash":         "string — 'sha256:...' of the consumer's spoken/typed query if captured (optional)",

  // Cross-artifact required fields
  "captured_at":        "string — ISO 8601 UTC (required)",
  "idempotency_key":    "string — stable per-request key (required)"
}

Permitted actor types: user, agent. Artifact signing actors: agent + user + merchant. The merchant's server signs the artifact wrapper (always). When AP2 is in use, the user-signed Intent Mandate is carried inside the artifact and contributes a user signature attesting to the natural-language purchase intent. When TAP is in use, the agent contributes a domain-bound identity attestation that the agent observed and relayed this intent. The wrapper signature alone (merchant) is conformant for v1.0.1 deployments without AP2 or TAP; agent and user signatures SHOULD be present where the underlying protocols are deployed and are RECOMMENDED for full evidentiary strength.

3.4 Policy Artifact

Records the outcome of the merchant's policy engine evaluation. The policy check MUST occur after intent (and after delegation, if present) and before authorization. Implementors MUST never authorize a transaction without a preceding policy artifact.

Payload Schema

{
  // Deterministic — merchant's engine output
  "decision_id":          "string — UUID of this specific policy decision (required)",
  "policy_engine_vendor": "string — e.g. 'a-comm', 'sift', 'kount', 'internal' (required)",
  "policy_version":       "string — e.g. '2026.04.17' (required)",
  "outcome":              "'approved' | 'blocked' | 'escalated' (required)",
  "escalated":            "boolean (required)",
  "risk_score":           "number 0–100, integer (required)",
  "rules_triggered":      "array of strings — rule identifiers that fired (required, may be empty)",
  "reason":               "string — required if outcome is 'blocked' or 'escalated'",
  "evaluated_at":         "string — ISO 8601 UTC when the policy engine returned (required)",

  // Cross-artifact required fields
  "captured_at":          "string — ISO 8601 UTC (required)",
  "idempotency_key":      "string — stable per-decision key (required)"
}

Actor type and signing actor: merchant. In pilot deployments without a full policy engine, this artifact is auto-generated by the reference implementation with outcome: "approved", policy_engine_vendor: "a-comm", policy_version: "default-v1", risk_score: 0, and rules_triggered: [].

3.5 Cart Artifact

Records the consumer's explicit cart confirmation — the final review step before checkout. The confirmed: true field plus the matching AP2 Cart Mandate signature (carried in §3.9 Delegation) are the dispute-resolution signals that demonstrate the consumer (or their agent acting with consent) explicitly approved the cart contents before payment.

Payload Schema

{
  // Deterministic identifiers
  "cart_id":               "string — UUID (required)",
  "confirmed":             "boolean — MUST be true (required)",

  // Deterministic cart composition
  "items":                 "array of items, each with:
                              { product_id, product_name, variant_id,
                                quantity, unit_price (minor units) }  (required)",
  "subtotal":              "integer — minor units (required)",
  "shipping":              "integer — minor units (required)",
  "tax":                   "integer — minor units (required)",
  "discounts":             "integer — minor units, non-negative (required)",
  "total":                 "integer — minor units; MUST equal
                              subtotal + shipping + tax − discounts (required)",
  "currency":              "string — ISO 4217 (required)",

  // Deterministic addresses (hashed, not raw)
  "shipping_address_hash": "string — 'sha256:...' (required)",
  "billing_address_hash":  "string — 'sha256:...' (required)",

  // Deterministic payment credential reference (PSP-issued token only)
  "payment_method_token":  "string — PSP token, never PAN (required)",

  // Deterministic timestamps
  "cart_confirmed_at":     "string — ISO 8601 UTC (required)",

  // Cross-artifact required fields
  "captured_at":           "string — ISO 8601 UTC (required)",
  "idempotency_key":       "string — stable per-cart key (required)"
}

Permitted actor types: user, agent. Artifact signing actors: agent + user + merchant. The merchant's server signs the artifact wrapper (always). When AP2 is in use, the user-signed Cart Mandate (carried in §3.9 Delegation) contributes a user signature binding the consumer to the specific cart contents and total. When TAP is in use, the agent contributes a domain-bound identity attestation that the agent composed or relayed this cart on the user's behalf. The wrapper signature alone (merchant) is conformant for v1.0.1 deployments without AP2 or TAP; agent and user signatures SHOULD be present where the underlying protocols are deployed and are RECOMMENDED for full evidentiary strength. The total integrity check (subtotal + shipping + tax − discounts = total) is a verification requirement — mismatch fails §5 verification.

3.6 Authorization Artifact

Records the PSP authorization result. This artifact is the seal point. Its current_hash becomes sealed_bundle_hash on the transaction chain. The fields in this artifact are specifically chosen to map to card-network representment evidence schemas (Visa CE 3.0, Mastercard First Chargeback evidence, Stripe Evidence API, Adyen RevenueProtect) so exports in §6 can be produced with no schema translation loss.

Payload Schema

{
  // Deterministic — PSP transaction identifiers
  "psp":                     "string — e.g. 'stripe', 'adyen', 'square', 'braintree' (required)",
  "payment_intent_id":       "string — PSP intent/session ID (required if applicable)",
  "charge_id":               "string — PSP charge/payment ID (required)",
  "payment_method_token":    "string — PSP-issued token, never PAN (required)",
  "payment_method_type":     "'card' | 'apple_pay' | 'google_pay' | 'klarna' | 'affirm' |
                              'afterpay' | 'ach' | 'sepa' | 'wallet_other' (required)",

  // Deterministic — authorization outcome
  "result":                  "'approved' | 'declined' | 'review' (required)",
  "amount":                  "integer — minor units; MUST match cart.total (required)",
  "currency":                "string — ISO 4217 (required)",
  "auth_code":               "string — issuer-returned authorization code (required if approved)",
  "authorized_at":           "string — ISO 8601 UTC (required)",

  // Deterministic — CARD NETWORK REPRESENTMENT FIELDS (critical for dispute defense)
  "network_transaction_id":  "string — the card-network-assigned transaction ID (NTI).
                              Visa CE 3.0, Mastercard First Chargeback, and Compelling
                              Evidence 3.0 workflows all key on this field. (required
                              for card transactions)",
  "card_brand":              "'visa' | 'mastercard' | 'amex' | 'discover' | 'jcb' | 'unionpay' (required for card)",
  "card_last4":              "string — last 4 digits of PAN, PSP-returned (required for card)",
  "card_funding":            "'credit' | 'debit' | 'prepaid' | 'unknown' (optional)",
  "card_country":            "string — ISO 3166-1 alpha-2 of issuing country (optional)",

  // Deterministic — authentication and risk results from issuer/network
  "avs_result":              "'Y' | 'A' | 'N' | 'U' | 'R' | 'S' | 'Z' | 'W'
                              (AVS response code; Y = full match — required for card)",
  "cvv_result":              "'M' | 'N' | 'U' | 'P' | 'S' (CVV2 response code;
                              M = match — required for card)",
  "three_ds_result":         "'authenticated' | 'attempted' | 'frictionless' |
                              'failed' | 'not_supported' | 'not_applicable' (required for card)",
  "three_ds_version":        "string — e.g. '2.2.0' (required when three_ds_result ≠ 'not_applicable')",

  // Deterministic — fraud decisioning output (if the PSP ran its own engine)
  "fraud_score":             "number — PSP's fraud score (e.g. Stripe Radar score) (optional)",
  "fraud_engine":            "string — e.g. 'stripe_radar', 'adyen_revenueprotect' (optional)",

  // Cross-artifact required fields
  "captured_at":             "string — ISO 8601 UTC (required)",
  "idempotency_key":         "string — PSP's idempotency key (required)"
}

Actor type and signing actor: psp. The artifact is produced by the PSP webhook handler and is the seal point for the chain. Any non-card payment method (Klarna, Affirm, Afterpay, ACH, SEPA, wallet) MAY omit the card_*, avs_*, cvv_*, and three_ds_* fields, but MUST set them to null (not omit) so canonical JSON serialization is stable.

3.7 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 (see §2.5 Sealing Model). Proof of delivery to an address matching the authorization is one of the strongest representment signals in card-network dispute workflows — this artifact carries the evidence required to produce that proof.

Payload Schema

{
  // Deterministic identifiers
  "fulfillment_id":           "string — UUID (required)",
  "platform_order_id":        "string — merchant-platform order ID, e.g. Shopify GID (required)",

  // Deterministic shipping data
  "carrier":                  "string — e.g. 'ups', 'fedex', 'usps', 'dhl' (required)",
  "tracking_number":          "string (required)",
  "tracking_url":             "string — publicly accessible carrier URL (optional)",
  "status":                   "'pending' | 'in_transit' | 'delivered' | 'failed' | 'returned' (required)",
  "shipped_at":               "string — ISO 8601 UTC (required when status ≥ in_transit)",
  "delivered_at":             "string — ISO 8601 UTC (required when status = delivered)",

  // Deterministic address-match evidence (representment-critical)
  "delivery_address_hash":    "string — 'sha256:...' of canonical delivery address (required)",
  "delivery_address_match":   "boolean — MUST equal
                                 (delivery_address_hash === cart.shipping_address_hash) (required)",
  "signature_captured":       "string — recipient signature when carrier provides it (optional)",
  "proof_of_delivery_url":    "string — carrier-provided POD document URL (optional)",

  // Cross-artifact required fields
  "captured_at":              "string — ISO 8601 UTC (required)",
  "idempotency_key":          "string — stable per-fulfillment-event key (required)"
}

Actor type: fulfillment_provider. Signing actors: fulfillment_provider (carrier-attested) + merchant (wrapper). The merchant's server signs the artifact wrapper. The fulfillment provider contributes attested data — tracking number, delivery confirmation, proof-of-delivery URL, signature-captured boolean — sourced from the carrier's API or, where the carrier exposes signing infrastructure, a direct carrier signature on the data subset. When fulfillment is handled by the merchant's own logistics (no third-party carrier), the merchant signs both wrapper and data; signing_actor is then merchant alone.

delivery_address_match: true is the single most valuable representment signal a chargeback reviewer looks for when the dispute reason is "item not received." Its value is deterministic — computed from two already-present hashes — and cannot be forged without breaking the hash chain upstream.

3.8 Artifact Type Reference

The "Permitted Actors" column below lists the actor_type values an artifact may carry — the entity whose action the artifact records. This is distinct from signing_actor (which entity or entities cryptographically signed the artifact); signing-actor configurations are described in each per-artifact subsection above and summarized in §2.2 of the public summary.

3.9 Delegation & Protocol Metadata

3.9.1 Purpose

The delegation artifact records four claims simultaneously:

• Agent identity — which agent is operating (TAP-signed when available)
• Consumer authorization — that the consumer delegated purchase authority to the agent (AP2 user-signed mandate when available)
• Merchant acceptance — that the merchant accepted the handshake and bound the session (ACP session ID, UCP checkout binding)
• Protocol provenance — which protocol(s) carried the handshake, for downstream dispute weighting

3.9.2 Chain Position

The delegation artifact sits after intent and before policy. Sequence:

discovery → referral → intent → delegation → policy → cart → authorization → fulfillment

Delegation MAY be omitted for transactions with no agentic protocol in play (traditional web checkout). When omitted, the chain proceeds directly from intent to policy and any protocol metadata is carried forward on the intent artifact as a fallback.

3.9.3 Permitted Actors

• agent — primary producer of the delegation artifact
• merchant — co-signer when merchant acceptance is captured in the same artifact
• credentials_provider — co-signer when an AP2 Credentials Provider is in the chain

Every delegation artifact MUST be signed by at least one actor. Multi-signature delegation (agent + merchant + credentials_provider) is RECOMMENDED when the underlying protocols support it.

3.9.4 protocol_metadata Payload Schema

The delegation artifact's payload contains a required protocol_metadata object. Each protocol has a defined sub-wrapper. Multiple sub-wrappers MAY coexist in the same artifact (for example, TAP + AP2 + ACP on the same transaction).

Top-level schema

{
  "artifact_type": "delegation",
  "payload": {
    "protocol_metadata": {
      "protocol": "string",                  // enum, see §3.9.5
      "protocol_version": "string",          // SemVer of the carrying protocol
      "captured_at": "string (ISO 8601)",    // when the handshake occurred
      "agent_identity":       { ... } | null,  // §3.9.6
      "consumer_authorization":{ ... } | null, // §3.9.7
      "session_binding":      { ... } | null,  // §3.9.8
      "tool_invocation":      { ... } | null,  // §3.9.9
      "http_payment":         { ... } | null,  // §3.9.10
      "raw_protocol_payload": "string"       // base64; opaque fallback
    }
  }
}

3.9.5 protocol enum

Exactly one of: TAP, AP2, ACP, UCP, MCP, x402, A2A, GENERIC. When multiple protocols are present, the value of protocol is the dominant protocol — the one that carried the primary handshake — and the other protocols' payloads appear in their respective sub-wrappers. Dominance order (highest to lowest) is AP2 > TAP > ACP > UCP > MCP > x402 > A2A > GENERIC.

3.9.6 agent_identity — TAP wrapper

{
  "tap_signature": "string",         // JWS compact serialization
  "tap_public_key_url": "string",    // agent registry JWKS URL
  "tap_key_id": "string",
  "tap_domain": "string",            // merchant domain the agent operates on
  "tap_operation": "string",         // e.g., "payment", "checkout"
  "tap_session_id": "string"
}

All fields REQUIRED when agent_identity is present. The tap_signature MUST be independently verifiable against the published JWKS at tap_public_key_url.

3.9.7 consumer_authorization — AP2 wrapper

{
  "ap2_mandate_type": "CartMandate | IntentMandate",
  "ap2_mandate_id": "string (UUID)",
  "ap2_user_signature": "string",                  // VDC signature (JWS)
  "ap2_user_public_key_url": "string",             // DID or JWKS URL
  "ap2_credentials_provider_signature": "string",  // optional CP co-sign
  "ap2_credentials_provider_url": "string",        // optional
  "ap2_mandate_body": "string"                     // canonical JSON of signed mandate
}

The ap2_user_signature MUST verify against ap2_mandate_body using the key at ap2_user_public_key_url. When a Credentials Provider co-signs, both signatures MUST verify.

3.9.8 session_binding — ACP / UCP wrapper

{
  "session_protocol": "ACP | UCP",
  "session_id": "string",
  "merchant_acceptance_signature": "string",   // merchant signs session creation
  "merchant_public_key_url": "string",
  "session_created_at": "string (ISO 8601)",
  "session_state": "created | updated | completed | canceled"
}

3.9.9 tool_invocation — MCP wrapper

{
  "mcp_server_name": "string",
  "mcp_tool_name": "string",
  "mcp_arguments": { ... },        // JSON object
  "mcp_invocation_id": "string",
  "mcp_result_hash": "string"      // SHA-256 of tool result
}

3.9.10 http_payment — x402 wrapper

{
  "x402_challenge": "string",      // HTTP 402 challenge header value
  "x402_response": "string",       // client response token
  "x402_endpoint": "string (URL)",
  "x402_nonce": "string"
}

3.9.11 Verification Requirements

1. Every non-null sub-wrapper's signatures MUST be independently verifiable against the public keys referenced by the wrapper's URL fields.
2. Timestamps in sub-wrappers MUST be within 24 hours of the delegation artifact's top-level captured_at. Violations fail verification.
3. When agent_identity is present, the tap_domain MUST match the merchant domain on file for this chain.
4. When consumer_authorization is present, the ap2_mandate_body MUST reference the same item(s) and amount(s) as the subsequent cart artifact in the chain. Mismatch fails verification.
5. The raw_protocol_payload field, when present, is opaque to AEP verification and is preserved for downstream tooling.

3.9.12 Evidence Strength Ranking

For dispute weighting, AEP defines an evidence strength score for delegation artifacts based on which sub-wrappers are populated and verify successfully:

Dispute evidence exports (§6) SHOULD surface the strength tier to reviewers. This ranking is deterministic and may be recomputed from any archived delegation artifact.

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' | ... | '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 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 → Policy → Cart → Authorization → Fulfillment  │
│                                                                               │
│  Hash-chained, cross-network, dispute-grade evidence bundle                   │
└─────────────────────────────────────────────────────────────────────────────────┘

9.2 Positioning by Phase

9.3 What AEP / A-Comm Is NOT

The AEP reference implementation, and A-Comm Inc. as its primary operator, 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 (per §7.3 Session Linkage)

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.