Authorization Needs an Outcome Record

Most agent-commerce systems can log a request. Some can verify a signature. Fewer can connect that request to a terminal merchant event without accepting client-supplied IDs as truth. That missing linkage is where the useful history lives.

We treat the verification record as the join key. A normalized attestation set points to the internal verification row, while a later outcome receipt points to that same row. Each part keeps its own meaning:

authorization claim
        |
        v
normalized attestation set  --->  KYA verification decision
                                      |
                                      v
                         authoritative outcome receipt

This matters because authorization is not behavior. A valid trace can show that an agent had a spending limit. It’s silent on whether the agent stayed inside that limit, whether the order was fulfilled, and whether a later dispute was resolved correctly.

The record normalizes facts from documented authorization sources into one issuer-neutral shape. The first adapters cover Visa TAP observations, Web Bot Auth observations, and KYA trace credentials. Each observation includes the issuer, adapter version, verdict, non-secret reference, asserted scope, key identifier, and time bounds when those facts are verified.

A failed or unavailable credential is recorded as invalid, expired, or unobservable when that is as far as the evidence goes. A request ID, a traceparent, or a bare trace string stays raw input, and none of the three becomes an attestation.

A historical record is useful only if a later replay can trust its boundaries. In Phase 0 we write through a service-role function that derives the merchant and agent from the verification row. The corpus rejects direct updates and deletes, and the verification-to-set link stays with the identity it’s written under.

Replays are part of the design. Concurrent writes for the same verification resolve to one set. Repeated outcome events resolve to one receipt before additive interaction or spend effects run. That’s why the record can answer both questions: what was observed, and whether the same event was counted twice.

The Shopify outcome path now resolves the public verification reference stored during checkout to the internal verification UUID. It scopes that lookup to the merchant and agent, and it copies a trace only when we marked that trace validated. The link comes from that lookup alone, so a client-supplied payload trace has no effect on it.

Direct activity submissions follow the same rule: the account-scoped API actor determines the source and environment, so the labels Shopify, WooCommerce, Stripe ACP, and production stay out of the caller’s reach. That keeps an integration receipt and a direct merchant report from becoming interchangeable records by accident.

Phase 0 adds no Visa-specific field, no Visa score bonus, and no new user interface. A future directory observation would enter the same attestation schema as any other source, and a directory listing would still be evidence about authorization rather than proof that an agent behaved well after authorization.

This work is record-only and local until deployment evidence exists. The next useful step is collecting enough trusted, linked outcomes to test whether the corpus explains merchant risk better than isolated verification logs do. Dashboards can wait.