Authority, Freshness and Consent in a Federated Commerce Network

TL;DR — Federation creates reach, but it also creates distance between a merchant’s live system and the agent reading an index. A defensible network must preserve provenance, distinguish candidate generation from verification, survive partial failure and enforce revocable merchant consent. The index helps an agent find. The Bridge helps it verify. Checkout remains the binding authority.

A single query can hide several systems

A user asks for a black men’s T-shirt under €30. A federated catalog returns offers from several independent merchants in one response.

The interaction looks simple because the complexity has moved behind the interface.

The result may involve:

a cross-merchant index built from earlier catalog reads;
a canonical taxonomy used to route the request;
merchant-specific product and variation models;
cached price and stock values;
a live Bridge verification call;
a checkout system that recalculates the transaction.

Each layer can return accurate data while answering a different question. Problems begin when the consumer treats those answers as interchangeable.

Authority is not the same as proximity

A federated index may be the closest system to the agent, but it is not automatically the authority for price or stock.

The merchant’s WooCommerce installation owns the catalog record. The Bridge is a merchant-side projection of that record. KaliCart Global stores enough information to search across merchants. Checkout applies destination, tax, shipping, discounts and transaction-time availability.

The architectural rule is therefore:

The broader the search, the weaker the commitment. The closer the action, the narrower the authoritative source.

Candidate

Federated index

Broad recall from a cached or snapshot projection.

Verified fact

Merchant Bridge

Product detail, variant scope, provenance and freshness.

Commitment

Merchant checkout

Recalculates terms and accepts the binding order.

A snapshot may generate candidates. It must not present itself as a reservation.

This pattern is not unique to KaliCart. The current UCP Catalog specification makes a similar distinction: catalog pricing and availability reflect the business’s current terms for the request, but they are not transactional commitments. Checkout remains authoritative, and catalog responses should not be reused across sessions without revalidation.

The index should generate candidates, not promises

A federated index exists because asking every merchant to participate synchronously in every broad query would be slow and fragile.

Indexes are good at:

finding likely matches;
routing by canonical category;
applying broad filters;
comparing known price ranges;
returning alternatives when one merchant is unavailable.

They are less suitable for making transaction-time promises about the last unit of a particular size.

A result should therefore carry enough provenance for the client to understand where it came from. The following shape is illustrative rather than a claim about one required wire format:

{
  "p2209_id": "prod_example-com_123",
  "merchant_domain": "example.com",
  "merchant_product_id": "123",
  "price": { "current": 29.90, "currency": "EUR" },
  "availability": { "status": "in_stock" },
  "observed_at": "2026-07-05T08:15:00Z",
  "product_url": "https://example.com/product/example-shirt/"
}

The timestamp does not guarantee correctness. It tells the consumer when the network last observed the merchant’s statement.

Freshness is a bounded claim

“Live data” is often used too loosely.

A Bridge reads the merchant’s current WooCommerce state when called. That state may still include stale inventory imported from an ERP, a misconfigured sale or a cache that has not expired. An API is not true merely because it is live.

A defensible system separates four ideas:

Source: which system supplied the value?
Authority: which party is entitled to state it?
Observation time: when was it read?
Commitment: has the merchant accepted a transaction based on it?

The Bridge improves source and observation clarity. Checkout creates the commitment. Neither layer can repair incorrect merchant data automatically.

Search and detail must form one contract

A subtle federation failure occurs when search can return a product that detail cannot retrieve, or detail exposes a product that search was not allowed to show.

This is not merely inconvenient. It breaks the agent’s reasoning chain.

A safe public workflow is:

global_search
  → returns a stable federated product ID
  → get_product accepts that same ID
  → detail applies the same merchant-consent and serving rules

The eligibility rule must be shared, not copied approximately into two different queries. Otherwise a later change to consent, exclusion or serving status can make one surface leak records that the other hides.

The product identifier also has to preserve both network identity and merchant identity. A federated ID is useful for routing; the original merchant product ID remains necessary for provenance and verification.

Canonical categories route; they do not rewrite the merchant

Federated search needs some common vocabulary. One merchant may place swimwear under “Beach”, another under “Women > Clothing”, and another under a brand category.

Global can map those paths to a canonical leaf for retrieval. That mapping should not silently replace the source taxonomy.

Both facts matter:

the merchant category explains how the store organized the product;
the canonical category explains why the federation routed the query to it.

A canonical category is therefore a routing assertion made by the federation, not a merchant-authored commercial fact.

This distinction becomes especially important when the mapping is uncertain. The system should expose uncertainty or require review rather than presenting its own classification as something the merchant declared.

Partial failure is normal

A federated query spans independent infrastructure. One merchant may time out. Another may return invalid JSON. A third may have revoked consent since the last ingest. A fourth may be reachable from the indexer but blocked for an external client by a stateful hosting firewall.

The network should not collapse these conditions into one generic “offline” state.

Transport and payload are separate observations:

Transport	Payload	Meaning
200	Valid catalog	Readable observation
200	Invalid JSON or wrong schema	Reachable, unusable payload
403	Not evaluated	Access failure, cause unknown
Timeout	Not evaluated	No observation within deadline

A timeout does not prove the merchant removed the Bridge. A 200 response with malformed data does not prove the catalog is healthy. A single successful probe does not prove stable reachability.

The agent-facing response does not need every diagnostic detail. It does need an honest assessment: verified, indicative, unavailable or unknown — with an observation time.

Federation consent must be enforced at read time

Consent is not a checkbox recorded once during onboarding.

A merchant can move through several states:

Local only Opted in Federated serving Revoked
The local Bridge remains available in every state.

Revocation must affect both future ingestion and public serving. Removing a merchant from the next scheduled import is insufficient if cached products remain retrievable by ID.

A federated detail lookup should verify the same conditions used by search, including current consent, active serving state and manual exclusion controls.

This is one reason a merchant-side declaration is stronger than a central allowlist: the permission travels with the source catalog and can be checked again.

Data quality and federation eligibility are different

A catalog can be eligible for federation and still contain weak product records.

Missing brand, generic categories, poor descriptions and absent images affect usefulness, but not every defect should have the same consequence across every channel.

For example:

a missing brand may weaken filtering but still leave a product searchable;
a missing image may make a platform-specific feed invalid;
a missing price prevents a meaningful commercial comparison;
an unavailable variation may require verification rather than removal of the parent product.

The local Bridge should report source defects. The federation should apply channel-specific eligibility rules. Neither should fabricate a value merely to satisfy a schema.

Ranking is a separate responsibility

A common taxonomy and a normalized price field make comparison possible. They do not make a ranking neutral.

A federated system still has to choose how to order results. Possible signals include textual match, category routing, stock, price, freshness and source quality. Commercial placement could become another signal in the future.

Those choices should not be disguised as merchant facts. A useful response can separate:

the product fields supplied by the merchant;
the evidence that caused the product to match;
the federation’s routing or ranking assessment;
guidance telling the agent when to verify identity or availability.

The system should describe retrieval behavior without claiming to know whether a product is subjectively right for the user. Relevance remains an agent decision.

Checkout is where the promise becomes real

Neither a feed, an index nor a Bridge response should be presented as a completed commercial commitment.

At checkout, the merchant can:

confirm the exact variation;
recheck stock;
calculate tax and destination-specific shipping;
apply valid coupons;
enforce regional restrictions;
accept payment and create the order.

This is why merchant-owned checkout is compatible with federation rather than opposed to it. The network improves discovery while the merchant retains the final transaction and customer relationship.

OpenAI’s current product-discovery direction follows the same broad separation: richer centralized discovery can still lead to checkout through the merchant’s own experience. That is a platform decision, not proof that every federation must use the same architecture.

What a defensible federated response can claim

It can claim:

which merchant published the product;
which source record was observed;
when the network observed it;
which canonical route produced the match;
whether the merchant currently consents to federation;
where the agent can verify and continue.

It cannot honestly claim, without a transaction-time check:

that the last unit is reserved;
that shipping applies to every destination;
that a coupon will be accepted;
that the checkout total will equal the indexed price;
that a merchant-side data error has become true through normalization.

The network is a governance system

Federation is often described as a search feature. Technically, it is also a governance system.

It decides:

who may participate;
which consent signals are binding;
how identities and categories are reconciled;
how long observations remain usable;
what happens when sources disagree or disappear;
which layer is allowed to make which claim.

The software can implement these rules. It cannot avoid making them.

The useful boundary

The local Bridge and the federated index should not compete for authority.

The index exists to broaden discovery. The Bridge exists to expose the merchant’s catalog through a stable contract. Checkout exists to create the order.

Discover across the network.
Shortlist from the index.
Verify with the merchant.
Commit at checkout.

That separation is what allows a network of independent WooCommerce stores to behave like one searchable catalog without becoming one centralized store.

Federated Commerce Series · Part 3 of 3 — Previous: Shopify Has a Global Catalog. WooCommerce Has Independent Stores. WooCommerce supplies the commercial engine. The Bridge makes each store a compatible node. Federation coordinates those nodes. Trust survives only if every layer states what it knows, when it observed it and where its authority ends.

← All posts