Inside the SKU Graph

This is a plain-language tour of the SKU Graph, the map at the center of JENNi. It covers what a product is, which stores have it, how sure we are, and how every order makes the map better.

Physical inventory is huge, and most of it is invisible to digital demand. Shoppers, apps and AI agents can't see what's on a shelf down the street. The SKU graph is how we make that inventory usable.

It joins three things: canonical products anchored on barcodes, the stores that carry them, and how sure we are right now. Let's take them in turn.

Supply: what stores have in the SKU graph

The first layer is supply. Each store that carries a product is represented by a store offer.

A store offer holds:

the item,
its price,
its stock,
the source we learned it from,
when we last saw it,
and the store's hours.

Two details matter here. First, the source and the last-seen time travel with every offer, so age is never hidden. Second, every offer is tied to a store, so it's clear where the item would come from.

Search shows in-stock items only. That rule applies to shoppers and to agents alike.

Identity: what a product is

The second layer is identity. Stores describe the same product in their own words, so titles, photos and descriptions drift from store to store.

To cut through that, the graph defines a canonical product once and joins store listings to it. The anchor is the barcode, a UPC or GTIN. Same barcode, same product, whatever each store calls it.

The graph also has to handle variants: sizes, colors, counts and flavors that sit under one product and differ in stock. Sized goods are often listed one size per product today, which is why a size belongs in an agent's search query. We're building toward handling these options more directly, but we won't describe it as finished before it is.

Identity is what lets a shopper at shop.jennipro.com pick a product instead of a store. The product stays steady, and JENNi resolves the store behind it. Every offer reads "Delivered by JENNi."

Promiseability: can this offer serve this request

Having a product and a store isn't enough. The real question is narrower: can this offer serve this request, at this address, by this time?

That's what we call promiseability. It takes in several facts at once:

Is the item in stock?
Is the store within reach of the address? Local delivery is offered when a store with the item is within about 30 miles.
Are the store's hours known, and will it be open?
Which fulfillment mode applies, local_delivery or ship_to_home?

An order can arrive the same day, but we promise it only when the quote says "Get it today." If store hours are unknown, we don't promise it.

This is what an agent sees through get_buying_options: availability, price, delivery fee, delivery promise and total before tax. The graph does the work, and the agent gets a clear answer to act on.

How sure we are

Across all three layers sits confidence. We don't claim stock is real time, and we don't claim to cover every store or product. What we hold is how sure we are right now, next to when we last saw each fact.

That's why a system built on this graph can be honest. It can say what it knows, how it knows it and how recently.

Learning: every order makes the map better

The last layer is what keeps the map from going stale: learning.

Delivered orders and failed orders both feed back into the graph. A delivery confirms that the offer held up. A failure says something didn't, maybe the stock, maybe the hours, maybe the match between listing and product.

Neither outcome is wasted. Over time the graph gets less dependent on what stores claim and more grounded in what actually happened.

One interface for agents

Agents reach all of this through our MCP server at https://shop.jennipro.com/mcp. MCP is the Model Context Protocol, and any agent can connect.

In plain terms:

search_catalog finds products for a query and a ZIP.
get_product returns product facts.
get_buying_options returns the promise and the total.
start_checkout returns a hosted checkout_url where the buyer reviews and pays.
get_order_status reports where an order stands, given the private order token from the shopper's JENNi order page.

Behind each call is the same graph. Checkout re-verifies current price and availability, refuses stale prices, and charges nothing until the shopper approves the final total.

JENNi is the seller on these orders. We buy the item from the store for the customer, so issues come to us.

What's next

The graph is never finished. Shelves change, and so does the map. If you build agents, connect to https://shop.jennipro.com/mcp and watch it work with a ZIP you know.

If you run shelves, we'd like to hear from you. Want your shelves visible to AI agents? Get in touch at jennipro.com.