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.

KYA treats 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 cannot show that the agent stayed inside that limit, that the order was fulfilled, or that 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 the evidence does not support a stronger claim. The system does not turn a request ID, traceparent, or bare trace string into an attestation.

A historical record is useful only if a later replay can trust its boundaries. Phase 0 writes 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 cannot be moved to another identity.

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. The record can therefore 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 KYA marked the trace as validated. A client-supplied payload trace cannot create the link.

Direct activity submissions follow the same rule. The account-scoped API actor determines the source and environment. The caller cannot label a direct request as Shopify, WooCommerce, Stripe ACP, or production. This keeps an integration receipt and a direct merchant report from becoming interchangeable records by accident.

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

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