A product page is not a contract.
It is a presentation surface.
That distinction matters more once AI agents start interacting with commerce systems.
Traditional ecommerce platforms can rely on human interpretation. A human can read a product title, inspect images, compare delivery notes, scan a return policy, notice uncertainty, and decide whether to continue. A product page can be visually useful even when the underlying commercial state is incomplete, stale, or spread across several systems.
An AI agent needs a different interface. It should not need to scrape a product page, infer policy meaning from free text, guess whether inventory is fresh, or decide whether a price is reliable enough to quote. If the platform expects agents to recommend products, compare alternatives, prepare checkout, or act within delegated authority, then the platform needs to expose more than product presentation.
It needs to expose commercial truth.
This is the second article in the Agent-Ready Commerce series. Part 1 introduced the broader model:
Facts → Eligibility → Authority → State transition → Evidence → Audit
This article focuses on the first part of that chain: facts.
The central argument is simple: a raw product record is not enough for agent-ready commerce. The platform needs a source-backed, freshness-aware, action-supporting view of the product before agents can safely act on it.
A normal product page compresses many different concerns into one human-readable surface:
Product identity
Price
Inventory
Images
Description
Badges
Variants
Delivery estimate
Return policy snippet
Warranty information
Promotional copy
Reviews
Cross-sell modules
Checkout call to action
That compression is useful for presentation, but it is lossy from a systems perspective.
The page may show “In stock,” but the inventory value may be several hours old. It may show a price, but the pricing source may have changed since the last feed publication. It may show a return-policy sentence, but the policy may not apply to every category, region, or customer type. It may show marketing claims that are approved for humans to read, but not precise enough for agents to quote.
A human can tolerate some of this ambiguity. An agent should not be forced to.
A product page answers a presentation question:
How should this item be shown to a buyer?
An agent-facing product contract has to answer operational questions:
What is currently known about this item?
Where did that knowledge come from?
How fresh is it?
Is it complete enough for discovery?
Is it complete enough for comparison?
Is it complete enough for checkout?
Is it safe for an agent to quote?
Those are different questions. Treating the product page as the source of truth mixes them together.
Consider a product in a catalog:
Product: Travel Backpack
SKU: BAG-TRAVEL-42
Price: €129
Catalog status: active
Inventory status: in_stock
Category: Travel Bags
A simple storefront can render this product. It has a title, a price, an image, a category, and an inventory flag.
A basic product model might look like this:
type Product = {
id: string;
sku: string;
title: string;
description: string;
price: {
amount: number;
currency: string;
};
inventory: {
status: "in_stock" | "low_stock" | "out_of_stock";
quantity?: number;
};
categoryId: string;
imageUrls: string[];
active: boolean;
};
This is enough to display a product card.
It is not enough to decide whether an AI agent can safely act on the product.
Suppose the real platform state looks like this:
Price: fresh, verified 5 minutes ago
Inventory: stale, last synced 18 hours ago
Return policy: missing for Travel Bags
Warranty policy: known
Shipping policy: known for EU, unknown for US
Generated description: pending review
Feed publication: last published yesterday
A human-facing storefront may still show the product. The commercial system, however, has several unresolved questions.
Can an agent discover this product? Probably yes.
Can an agent compare it with another backpack? Maybe yes, if comparison only needs identity, price, category, and basic attributes.
Can an agent quote the return policy? No, because return-policy coverage is missing for the category.
Can an agent prepare checkout? No, because inventory is stale.
Can an agent trigger delegated payment? Definitely not, because checkout is not even valid yet.
A single field like active: true
cannot represent these distinctions.
This is the gap commercial truth is meant to fill.
Product data describes the item.
Commercial truth describes what the platform is currently willing to rely on about the item.
Those are related, but not identical.
A catalog record may say:
const product = {
id: "bag_travel_42",
title: "Travel Backpack",
price: {
amount: 129,
currency: "EUR"
},
inventory: {
status: "in_stock"
},
active: true
};
A commercial truth summary might say:
type ProductTruthSummary = {
productId: string;
truthVersion: string;
facts: {
identity: FactStatus;
price: FactStatus;
inventory: FactStatus;
policyCoverage: FactStatus;
media: FactStatus;
generatedClaims: FactStatus;
};
overallStatus: "verified" | "incomplete" | "stale" | "conflicting";
};
type FactStatus = {
status: "known" | "missing" | "stale" | "conflicting" | "unknown";
sourceRefs: string[];
lastVerifiedAt?: string;
};
For the backpack example, the truth summary could look like this:
const truth: ProductTruthSummary = {
productId: "bag_travel_42",
truthVersion: "truth_2025_10_18_001",
facts: {
identity: {
status: "known",
sourceRefs: ["catalog_import_2025_10_18"],
lastVerifiedAt: "2025-10-18T09:00:00Z"
},
price: {
status: "known",
sourceRefs: ["pricing_sync_2025_10_18_0905"],
lastVerifiedAt: "2025-10-18T09:05:00Z"
},
inventory: {
status: "stale",
sourceRefs: ["warehouse_sync_2025_10_17_1500"],
lastVerifiedAt: "2025-10-17T15:00:00Z"
},
policyCoverage: {
status: "missing",
sourceRefs: []
},
media: {
status: "known",
sourceRefs: ["media_library_2025_10_15"]
},
generatedClaims: {
status: "unknown",
sourceRefs: ["ai_description_draft_778"]
}
},
overallStatus: "incomplete"
};
The commercial truth object does not replace the product. It qualifies it.
The product says what the item is.
The truth summary says how much confidence the platform has in the facts required to use that item in commerce workflows.
Source references are not metadata decoration. They are part of the reliability model.
A price from a pricing service, an inventory value from a warehouse sync, a warranty statement from a policy document, and a description generated by an AI workflow should not be treated as equally authoritative.
A source reference can be modeled simply:
type SourceReference = {
sourceId: string;
sourceType:
| "catalog_import"
| "merchant_admin"
| "pricing_system"
| "inventory_system"
| "policy_document"
| "media_library"
| "generated_content";
sourceVersion?: string;
sourceHash?: string;
observedAt: string;
};
The important point is that commercial facts should be traceable.
Without source references, the platform cannot easily answer basic operational questions:
Where did this price come from?
Was this inventory value synced or manually edited?
Was this policy claim approved or generated?
Did the source change after the feed was published?
Which source should be revalidated before checkout?
For human-facing commerce, missing traceability may create debugging pain. For agent-facing commerce, it also creates trust problems.
If an agent quotes a return policy or prepares checkout based on stale inventory, the platform needs to know which fact led to the decision and which source produced that fact.
This is why commercial truth should be evidence-aware from the beginning.
Freshness is often modeled too broadly.
A product is marked fresh or stale.
That is not precise enough.
Different facts have different risk profiles. Stale inventory is more dangerous than a stale product image. Stale price may block checkout but not discovery. Missing warranty information may block policy quotation but not product comparison. A generated description pending review may block agent quotation but not internal merchandising.
A better model tracks freshness by fact group:
type ProductTruthFreshness = {
identity: "fresh" | "stale" | "unknown";
price: "fresh" | "stale" | "unknown";
inventory: "fresh" | "stale" | "unknown";
policyCoverage: "fresh" | "stale" | "unknown";
media: "fresh" | "stale" | "unknown";
generatedClaims: "fresh" | "stale" | "unknown";
};
For the backpack example:
const freshness: ProductTruthFreshness = {
identity: "fresh",
price: "fresh",
inventory: "stale",
policyCoverage: "unknown",
media: "fresh",
generatedClaims: "unknown"
};
This allows the platform to make more useful decisions:
Discovery: allowed
Comparison: allowed
Policy quotation: blocked
Checkout preparation: blocked
Delegated payment: blocked
A single productIsFresh
value would hide the reason. Fact-level freshness gives the platform a way to degrade gracefully instead of treating the product as either fully usable or fully unusable.
A commercial truth layer should describe what is known. It should not become responsible for every business decision.
This boundary is important.
Commercial truth answers:
What facts exist?
Where did they come from?
How fresh are they?
Are they complete?
Are they conflicting?
Eligibility answers:
Given those facts, which actions are allowed?
Those two layers should remain separate.
For example:
type TruthReadiness = {
productId: string;
facts: {
price: "fresh";
inventory: "stale";
policyCoverage: "missing";
};
};
The truth layer can produce that result without deciding what the agent may do.
The eligibility layer can then apply action-specific rules:
type AgentCommerceAction =
| "discover"
| "compare"
| "quote_policy"
| "add_to_cart"
| "prepare_checkout"
| "delegate_payment";
type EligibilityDecision = {
productId: string;
action: AgentCommerceAction;
allowed: boolean;
blockers: string[];
};
A simplified eligibility function might look like this:
function evaluateCheckoutReadiness(truth: TruthReadiness): EligibilityDecision {
const blockers: string[] = [];
if (truth.facts.price !== "fresh") {
blockers.push("Price must be revalidated before checkout.");
}
if (truth.facts.inventory !== "fresh") {
blockers.push("Inventory must be revalidated before checkout.");
}
if (truth.facts.policyCoverage === "missing") {
blockers.push("Required policy coverage is missing.");
}
return {
productId: truth.productId,
action: "prepare_checkout",
allowed: blockers.length === 0,
blockers
};
}
This separation prevents the truth layer from becoming a hidden monolith.
If a business later decides that stale inventory should still allow cart insertion but block checkout, that change belongs in eligibility rules, not in the definition of inventory truth.
A useful boundary is:
Truth describes the commercial facts.
Eligibility decides what those facts allow.
Not every action requires the same quality of truth.
Discovery may require only identity, visibility, media, and basic category information. Comparison may require price and comparable attributes. Policy quotation requires policy coverage and source references. Checkout preparation requires fresh price, fresh inventory, and applicable policies. Delegated payment requires even more: checkout validity, cart integrity, payment authority, and possibly human confirmation.
The same product can therefore have different readiness levels for different actions.
type ActionTruthRequirement = {
action: AgentCommerceAction;
requiredFacts: Array<
| "identity"
| "price"
| "inventory"
| "policyCoverage"
| "media"
| "generatedClaims"
>;
};
Example requirements:
const requirements: ActionTruthRequirement[] = [
{
action: "discover",
requiredFacts: ["identity", "media"]
},
{
action: "compare",
requiredFacts: ["identity", "price"]
},
{
action: "quote_policy",
requiredFacts: ["policyCoverage"]
},
{
action: "prepare_checkout",
requiredFacts: ["price", "inventory", "policyCoverage"]
}
];
For the backpack example, the resulting matrix might be:
discover allowed
compare allowed
quote_policy blocked: return policy missing
prepare_checkout blocked: inventory stale, return policy missing
delegate_payment blocked: checkout not valid
This is more useful than marking the product as generally available or unavailable.
Agent-facing systems need to know what kind of action is safe. Operators need to know which missing facts block which commercial capabilities.
Some product facts are direct values. Others are derived.
Direct fact:
Price is €129.
Derived fact:
Product is visible to agents.
The second statement depends on rules. It might depend on catalog status, product category, merchant settings, policy completeness, feed publication status, generated claim review, and regional restrictions.
Derived facts should include provenance.
type DerivedFact<T> = {
value: T;
derivedFrom: string[];
computedAt: string;
ruleVersion: string;
};
For example:
type AgentVisibilityFact = DerivedFact<{
visible: boolean;
reason?: string;
}>;
A derived visibility fact might look like this:
const visibility: AgentVisibilityFact = {
value: {
visible: true
},
derivedFrom: [
"catalog_status",
"media_status",
"merchant_agent_visibility_setting"
],
computedAt: "2025-10-18T09:10:00Z",
ruleVersion: "agent_visibility_v3"
};
This makes the decision easier to debug.
If the product disappears from the agent feed, the platform can inspect the rule version and input facts instead of searching through route handlers, frontend logic, feed jobs, and protocol adapters.
Derived facts without provenance become another form of hidden state.
Agent-facing systems need to know when commercial truth changes.
A product may have been published to a feed yesterday. Since then, the price may have changed, inventory may have gone stale, or a policy source may have been updated.
A truth version gives the platform a stable reference point:
type TruthVersion = {
productId: string;
version: string;
generatedAt: string;
};
Hashes can help detect changes within specific scopes:
type TruthHash = {
productId: string;
scope: "identity" | "price" | "inventory" | "policy" | "media" | "full";
hash: string;
generatedAt: string;
};
A hash is not a replacement for domain logic. It only says that something changed.
The domain still needs to decide whether the change matters.
type TruthChangeSummary = {
productId: string;
changedScopes: Array<"identity" | "price" | "inventory" | "policy" | "media">;
requiresFeedRepublish: boolean;
requiresCheckoutRevalidation: boolean;
requiresMerchantReview: boolean;
};
For example:
Price hash changed:
- requires feed republish
- requires checkout revalidation for open sessions
Media hash changed:
- may require feed republish
- does not require checkout revalidation
Policy hash changed:
- requires policy quotation revalidation
- may block checkout if policy coverage becomes incomplete
The hash detects change. The domain decides impact.
This separation matters because not every change is equal.
A product feed for agents should not be a raw export of the catalog.
It should publish selected commercial truth.
A feed item might look like this:
type AgentProductFeedItem = {
id: string;
title: string;
description: string;
price: {
amount: number;
currency: string;
lastVerifiedAt: string;
};
availability: {
status: "in_stock" | "low_stock" | "out_of_stock" | "unknown";
lastVerifiedAt?: string;
};
policySummary: {
returnPolicyKnown: boolean;
shippingPolicyKnown: boolean;
warrantyPolicyKnown: boolean;
};
actions: {
discoverable: boolean;
comparable: boolean;
checkoutEligible: boolean;
};
truthVersion: string;
publishedAt: string;
};
This structure does not expose every internal field. It exposes the parts of commercial truth that are safe and useful for external consumption.
That distinction keeps the architecture cleaner:
Catalog stores product data.
Commercial truth qualifies product data.
Feed publication exposes selected truth.
Eligibility decides allowed actions.
If the feed is generated directly from the catalog, it can easily overstate what the platform knows. If the feed is generated from eligibility decisions alone, it can hide useful context. Publishing selected commercial truth gives agents enough information without turning the feed into a second internal database.
Feeds usually focus on current products, but removed products matter too.
If an agent saw a product yesterday and the product disappears today, absence is ambiguous. The product may have been deleted, temporarily unpublished, replaced by another SKU, blocked because of policy issues, or merged into a variant group.
A tombstone makes removal explicit.
type ProductFeedTombstone = {
productId: string;
previousTruthVersion: string;
reason:
| "deleted"
| "unpublished"
| "blocked"
| "merged"
| "replaced";
replacementProductId?: string;
removedAt: string;
};
This is useful for cached agent contexts.
If an external system still has a cached product reference, the platform can communicate that the product should no longer be used and why.
For example:
Product BAG-TRAVEL-42 was removed from the agent feed because checkout policy coverage became incomplete.
That is much safer than silently removing the item and relying on the external system to infer meaning from absence.
A commercial truth layer should serve both agents and operators.
When facts are stale, missing, or conflicting, the system should produce actionable remediation work.
For example:
type CommercialTruthIssue = {
productId: string;
scope: "price" | "inventory" | "policy" | "media" | "generatedClaims";
severity: "info" | "warning" | "blocker";
issue: string;
impact: string;
nextAction: string;
};
For the backpack example, the system might produce:
Issue:
Inventory freshness is stale.
Impact:
Product can remain discoverable, but checkout preparation is blocked.
Next action:
Revalidate inventory from the warehouse source.
and:
Issue:
Return-policy coverage is missing for the Travel Bags category.
Impact:
Agents should not quote return terms, and checkout preparation remains blocked.
Next action:
Attach or approve a return policy for the category.
This is more useful than a generic validation failure.
The operator needs to know which commercial capability is affected. The agent needs to know which action is blocked. The platform needs to record why.
A good commercial truth system connects all three.
Truth issue → Action impact → Operator task → Feed or eligibility recovery
Commercial truth also matters when AI is used to generate storefront content.
A model may generate product descriptions, category copy, landing-page sections, benefit claims, warranty statements, shipping summaries, or promotional language. Some of that content may be useful. None of it should automatically become commercial truth.
Generated content needs review boundaries.
type GeneratedCommerceClaim = {
claim: string;
claimType: "product" | "policy" | "shipping" | "warranty" | "promotion";
grounded: boolean;
sourceRefs: string[];
requiresReview: boolean;
publishBlocked: boolean;
};
For example, a generated description for the travel backpack might include:
Includes lifetime warranty and free international returns.
If the warranty source does not support that claim, and the return policy is missing for the category, the claim should not be published as agent-quotable truth.
The model generated text. It did not create authority.
That is an important distinction.
AI-generated commerce content should be treated as a draft until it is grounded in approved sources or reviewed by an authorized workflow.
Commercial truth should be tested with scenarios, not only field validation.
Useful test scenarios include:
Product has fresh price, fresh inventory, and complete policy coverage.
Product has fresh price but stale inventory.
Product has fresh inventory but missing return policy.
Product has conflicting policy sources.
Product has generated claims pending review.
Product changed price after feed publication.
Product was removed after an agent feed was published.
Product has different policy coverage by region.
Each scenario should test both truth output and downstream impact.
type TruthScenarioExpectation = {
truthStatus: "verified" | "incomplete" | "stale" | "conflicting";
discoverable: boolean;
comparable: boolean;
policyQuotable: boolean;
checkoutEligible: boolean;
requiresFeedRepublish: boolean;
operatorTaskCount: number;
};
For example:
Scenario:
Fresh price, stale inventory, missing return policy.
Expected:
discoverable = true
comparable = true
policyQuotable = false
checkoutEligible = false
requiresFeedRepublish = true
operatorTaskCount = 2
These tests are useful because they verify the behavior that matters to agents and operators, not just whether the product object matches a schema.
A commercial truth layer exists to prevent specific failure modes.
If the feed is generated directly from catalog rows, stale or incomplete values may be exposed as if they were trustworthy.
The storefront, feed publisher, protocol adapter, and admin UI may each calculate availability or visibility using different rules.
Without fact-level freshness, the system may block the entire product because one low-risk field is stale, or allow checkout even though a high-risk field is stale.
A field like agentVisible
is useful only if the platform can explain why it is true or false.
If deleted or blocked products simply disappear, external systems cannot distinguish removal from temporary absence.
AI-generated copy may contain unsupported product, policy, shipping, warranty, or promotion claims unless grounding and review are explicit.
A validation error that says “policy missing” is less useful than an operational task explaining which agent action is blocked and how to fix it.
Commercial truth adds complexity.
It introduces more schemas, more versions, more source tracking, more tests, and more ownership decisions. A small storefront may not need this layer. A simple ecommerce site can often rely on catalog data, page rendering, and checkout validation.
Agent-ready commerce changes the threshold.
Once external systems can discover products, compare options, quote terms, prepare checkout, or act within delegated authority, raw product data becomes too weak as the interface.
The platform needs a stronger answer to the question:
What are we willing to let software believe and act on?
That is the purpose of commercial truth.
It is not a replacement for checkout validation, payment authority, or policy enforcement. It is the factual foundation those layers depend on.
A practical commercial truth layer should follow a few principles.
A product page is not a machine contract. It is a human-facing projection of commerce state.
Prices, inventory, policies, generated claims, and availability decisions should be traceable to their sources.
Price, inventory, policy, media, and generated content do not carry the same risk. They should not share one generic freshness flag.
Truth describes what is known. Eligibility decides which actions are allowed.
Fields such as agentVisible
, checkoutReady
, or policyQuotable
should be explainable.
Hashes can detect that something changed. Domain rules should decide whether the change affects feeds, checkout, review, or operator tasks.
Agent-facing feeds should not dump raw catalog records. They should expose a stable, safe subset of commercial truth.
Tombstones help external systems understand why a product is no longer available in a feed.
Missing or stale facts should produce actionable remediation work, not only validation errors.
AI-generated commerce claims should not become authoritative without source grounding or review.
Agent-ready commerce starts with facts, but not every product fact is ready for agent use.
A raw catalog record can render a storefront. It cannot always support recommendation, comparison, policy quotation, checkout preparation, or delegated payment.
The missing layer is commercial truth: a source-backed, freshness-aware, versioned view of what the platform currently knows about a product and how reliable that knowledge is.
Commercial truth does not decide every action. It provides the factual foundation for later decisions.
Catalog data says what the product is.
Commercial truth says what the platform can currently rely on.
Eligibility decides what actions are allowed.
That separation becomes important as commerce platforms expose more agent-facing surfaces. Product pages remain useful for humans, but agents need structured facts with provenance, freshness, and clear action impact.
Part 3 will move from facts to decisions:
Agent-Ready Commerce, Part 3: Why “Available” Is Not Enough for AI Agents
That article will examine action eligibility: why product availability is too broad, how different agent actions require different decision rules, and how eligibility connects commercial truth to safe commerce behavior.
Written by Dimitrios S. Sfyris, Founder & Software Architect at AspectSoft.
AspectSoft designs and develops custom software platforms, e-commerce systems, SaaS infrastructure, integrations, analytics tools, and practical digital products.
You can also follow the AspectSoft LinkedIn page for updates on software platforms, commerce systems, AI tooling, and developer-focused products.