Commercial truth

When Structured Data Still Needs Judgment

Commerce is getting easier for machines to read. The remaining difficulty is deciding whether the field a machine found is actually the field that should govern this purchase.

VendorAgent · September 13, 2026

Much of the infrastructure being built for agentic commerce improves retrieval. Shopify Catalog synchronizes product data, pricing, and inventory across connected AI channels; the emerging procurement.txt proposal gives businesses a compact way to describe catalogs, ordering interfaces, and escalation paths; other systems expose plans, entitlements, prices, and actions through typed APIs. Those developments remove a large class of scraping and extraction errors, which is real progress.

They do not, however, answer a different question: once several correct records are available, which one belongs to the transaction in front of the buyer?

Structure can make a fact easy to retrieve without making it safe to apply.

Two clean records can still produce one bad conclusion

Suppose a seller publishes these records:

Record A
support_response_p1 = 1 hour
support_plan = business
Record B
service_availability = 99.99%
plan = enterprise

Nothing is wrong with either record. They are current, official, and trivial for software to parse. Trouble begins only when a buyer treats them as alternate values for one generic promise and forgets that response time and service availability answer different questions.

Applicability lives in the conditions around the value

B2B software rarely offers commercial facts in isolation. A price, SLA, compliance claim, retention period, or regional option may depend on all or some of the following:

If those boundaries disappear during normalization, the resulting record may look cleaner while becoming easier to misuse.

There is a reason B2B commercial truth is scattered

For many consumer products, “What does this cost right now?” can be answered by a central commerce system. B2B SaaS usually has more layers. The pricing page may own the public base price, the support page may define response targets, the SLA may control availability, a trust center may describe compliance artifacts, and an older negotiated agreement may still govern an existing account.

Those sources were created for different purposes, so their coexistence is not automatically a documentation failure. The challenge appears when an AI buyer tries to compress them into one deterministic qualification decision.

Freshness becomes part of the answer at transaction time

An Agentic Commerce Protocol discussion illustrates the problem neatly. A platform may synchronize a seller's catalog price, display that value during discovery, and then encounter a different live price at checkout because the seller changed state after synchronization. The earlier value was not necessarily wrong when it was captured; it simply stopped being authoritative for the transaction.

In cases like that, refreshing or escalating is more accurate than defending stale structured data.

Delegated authority does not resolve applicability

New protocol work is also starting to model who is allowed to act. A202, for example, defines experimental commercial mandates and a canonical commercial model for synthetic pilot transactions, while leaving the final PolicyDecision to the acting party's own policy evaluator.

That separation matters. A protocol can establish that an agent has authority to make a commercial move, yet the seller still has to determine whether the facts supporting that move apply to this plan, service, contract, and moment.

Authority answers whether the agent may act; applicability determines whether it is acting on the right commercial state.

Competing true answers are harder than missing data

When information is absent, a system can return unknown, ask a clarifying question, or escalate. Ambiguity becomes more dangerous when every candidate answer is defensible inside a different scope. A capability may exist only on Enterprise, a compliance artifact may be available while the customer's required state remains unknown, and today's public price may coexist with an older agreement that still controls an existing account.

Retrieval can succeed perfectly in that environment. The hard work is deciding what the evidence permits the buyer to conclude.

A machine-readable fact needs enough context to remain itself

predicate — what is actually being claimed
value — the fact itself
scope — plan, service, region, data type, configuration, contract, and other boundaries
source authority — why this source controls
freshness/effective state — when the fact applies
conflict state — whether another authoritative fact still disagrees

The field names are negotiable; the principle is not. Conditions that make a statement true have to survive the trip from the seller's systems to the buyer's conclusion.

A practical way to test your own surface

Start with questions that force multiple public facts to interact: Which plan actually qualifies for this SLA requirement? Does the compliance capability cover this service and this customer state? What is the real cost once support and required add-ons are included? Which residency statement governs this data type and deployment? Does today's public term apply to an older contract?

When one authoritative source answers the question cleanly, there is little to reconcile. When the answer changes depending on which true page the machine reads first, the problem is no longer readability alone.

Readability gets the agent to the evidence

Seller information should absolutely be crawlable, structured, fresh, and usable. Once those basics work, though, procurement asks a stricter question: did the conditions that made the retrieved value true remain attached all the way through the buying decision?

That distinction can determine which vendor qualifies, what the buyer expects to pay, and what the seller appears to have promised.

Test what happens after retrieval works

VendorAgent's $250 AI Buyer Failure Scan runs 10 public-information buying scenarios against one B2B SaaS/API product and traces where seller facts can be combined into a commercially unsupported conclusion.

Request a Failure Scan

Sources