Context for Retail AI

TrustGraph gives shoppers, retailers, and brands advanced intelligence to enhance the shopping experience and capture the "why" of buying decisions. Instead of treating a shopper conversation as disposable chat history, TrustGraph captures the decision context: what the customer wanted, what the system recommended, which constraints applied, what the customer did next, and why.

The result is a continuously improving retail intelligence layer—one that supports better experiences for customers, more accountable automation for retailers, and more defensible insight for the platforms connecting retailers and brands.

Watch Retail AI in Action

A retail shopping assistant powered by an ontology with real-time decision traces

The problem: retail AI misses the decision

A retail assistant may recommend a product, suggest an alternative, apply a promotion, or route a shopper to a store, but most AI implementations retain only fragments of the interaction:

A chat transcript
An event log
A transaction record
A disconnected customer profile
A model response with no durable explanation of the decision

Those interactions are not enough to answer the questions that matter:

What did the shopper ask for?
Which product attributes, inventory conditions, price constraints, promotions, or preferences shaped the recommendation?
What did the assistant show the customer?
Did the customer purchase, abandon, ask a follow-up question, or choose another item?
Which policy was active when the system made its recommendation?
What products were viewed head-to-head?
How should the next interaction change?

Without a shared model of those relationships, the retailers and brands cannot reliably improve the AI shopping agent, measure its influence, resolve disputes, or reuse what it learned across channels.

The use case: retail interaction intelligence

This TrustGraph demo models retail interactions as first-class data. It uses an RDF ontology to represent the people, products, offers, recommendations, decisions, and outcomes that make up an AI-assisted shopping journey. Here's a small exercerpt of the ontology:

@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rt: <http://trustgraph.ai/ontology/retail#> .
@prefix ix: <http://trustgraph.ai/ontology/interaction#> .

# =============================================================================
# Ontology declaration
# =============================================================================

<http://trustgraph.ai/ontology/interaction> a owl:Ontology ;
    rdfs:label "Retail Interaction and Journey Ontology" ;
    rdfs:comment "An ontology for capturing user journeys through an AI-driven retail assistant, and the behavioural signals that emerge from those journeys. Models the full interaction funnel — from session start through search, product engagement, decision-making, and purchase or abandonment — while annotating events with the cognitive and emotional signals they reveal. Uses a mixin pattern where any interaction event can simultaneously carry signal types (objection, priority, decision point) via OWL multiple typing. Designed to be used alongside the retail product ontology (rt:) which models what is being sold; this ontology models how people decide whether to buy it." .

# =============================================================================
# Core structural classes
# =============================================================================

ix:Actor a owl:Class ;
    rdfs:label "Actor" ;
    rdfs:comment "A user interacting with the retail assistant. An actor may be anonymous or identified depending on context. Actors are linked to sessions and journeys, allowing cross-session analysis of returning users. Actor records should not contain personally identifiable information — use opaque identifiers and behavioural segments." .

ix:Journey a owl:Class ;
    rdfs:label "Journey" ;
    rdfs:comment "A coherent decision arc spanning one or more sessions. A user might research a PC build in one session, return a day later to continue, and complete the purchase in a third session. The journey groups these related sessions into a single analytical unit. A journey has an overall outcome (purchase, abandonment, ongoing) and a purpose that may evolve over time." .

ix:Session a owl:Class ;
    rdfs:label "Session" ;
    rdfs:comment "A single continuous interaction between a user and the retail assistant. A session starts when the user begins engaging and ends when they leave or the conversation concludes. Sessions contain a time-ordered sequence of interaction events. A session belongs to exactly one journey and one actor." .

# =============================================================================
# Interaction event classes (what happened)
# =============================================================================

ix:InteractionEvent a owl:Class ;
    rdfs:label "Interaction Event" ;
    rdfs:comment "An observable action or occurrence during a user's interaction with the retail assistant. Interaction events form a time-ordered sequence within a session, representing the steps in the user's journey through the funnel. Each event has a timestamp, a sequence position, and links to the products, categories, or configurations involved. Interaction events describe what happened; signal events describe what it reveals." .

ix:SessionStarted a owl:Class ;
    rdfs:subClassOf ix:InteractionEvent ;
    rdfs:label "Session Started" ;
    rdfs:comment "The user begins interacting with the retail assistant. May carry an initial intent if the user states one immediately (e.g. 'I want to build a gaming PC') or may be intentless if the user is browsing without a specific goal. The first event in every session." .

ix:Search a owl:Class ;
    rdfs:subClassOf ix:InteractionEvent ;
    rdfs:label "Search" ;
    rdfs:comment "The user searches for or describes what they are looking for. In a conversational AI interface this is typically a natural language request rather than a keyword search. Captures the query text and the assistant's interpreted intent. The gap between what the user said and what the assistant understood is itself analytically interesting." .

ix:ResultsViewed a owl:Class ;
    rdfs:subClassOf ix:InteractionEvent ;
    rdfs:label "Results Viewed" ;
    rdfs:comment "The assistant presents a set of products or options to the user. Captures which products were shown and in what order. The difference between what was shown and what was subsequently engaged with reveals which products caught the user's attention and which were ignored. Position bias (users engaging more with items shown first) can be measured." .

ix:ProductViewed a owl:Class ;
    rdfs:subClassOf ix:InteractionEvent ;
    rdfs:label "Product Viewed" ;
    rdfs:comment "The user examines a specific product in detail. Captures which product was viewed, how long the user spent on it (dwell time), and what aspects they engaged with (specifications, reviews, price, images). Dwell time on a product is a weak interest signal; dwell time on specific attributes (e.g. reading the VRAM spec) is a stronger priority signal." .

ix:ComparisonViewed a owl:Class ;
    rdfs:subClassOf ix:InteractionEvent ;
    rdfs:label "Comparison Viewed" ;
    rdfs:comment "The user views two or more products side by side. Captures the product set being compared and which comparison axes were visible or discussed. Comparison events naturally precede decision points — the user is evaluating trade-offs between specific alternatives." .

ix:RecommendationReceived a owl:Class ;
    rdfs:subClassOf ix:InteractionEvent ;
    rdfs:label "Recommendation Received" ;
    rdfs:comment "The assistant proactively suggests a product or set of products to the user. Captures what was recommended, the stated reasoning behind the recommendation, and which conversation flow triggered it (build suggestion, gift idea, upgrade path, accessory cross-sell). Whether the recommendation was accepted, questioned, or rejected is a key effectiveness signal." .

ix:QuestionAsked a owl:Class ;
    rdfs:subClassOf ix:InteractionEvent ;
    rdfs:label "Question Asked" ;
    rdfs:comment "The user asks a question during the conversation. Captures the question text, what it relates to (a product, a specification, a compatibility concern, a general topic), and where in the journey it occurred. Questions reveal uncertainty, priorities, and decision criteria. The type of question (factual, evaluative, reassurance-seeking) indicates the user's cognitive state." .

ix:AnswerReceived a owl:Class ;
    rdfs:subClassOf ix:InteractionEvent ;
    rdfs:label "Answer Received" ;
    rdfs:comment "The assistant provides an answer to a user's question. Captures the answer content and whether the user's subsequent behaviour suggests the answer was satisfying (they proceeded, said thanks, moved on) or unsatisfying (they asked again, rephrased, changed direction, or abandoned). Answer effectiveness is measured by what happens next, not by the answer itself." .

ix:AddedToCart a owl:Class ;
    rdfs:subClassOf ix:InteractionEvent ;
    rdfs:label "Added to Cart" ;
    rdfs:comment "The user adds a product to their shopping cart, PC build, or collection. A commitment signal, though tentative — items can be removed later. In conversational flows, this may be explicit ('add that to my build') or implicit (accepting a recommendation without objection). Captures which product was added and from which context." .

ix:RemovedFromCart a owl:Class ;
    rdfs:subClassOf ix:InteractionEvent ;
    rdfs:label "Removed from Cart" ;
    rdfs:comment "The user removes a product from their cart, build, or collection. Often co-occurs with an Objection signal — the user is rejecting something and may state why. Captures which product was removed. The pattern of adds and removes within a session reveals decision stability or indecision." .

ix:ComponentSwapped a owl:Class ;
    rdfs:subClassOf ix:InteractionEvent ;
    rdfs:label "Component Swapped" ;
    rdfs:comment "The user replaces one product with another in a build or collection. Richer than a separate remove-then-add because it captures a direct preference: the user evaluated both and chose one over the other. Captures what was removed, what replaced it, and any stated reasoning for the swap." .

ix:BuildValidated a owl:Class ;
    rdfs:subClassOf ix:InteractionEvent ;
    rdfs:label "Build Validated" ;
    rdfs:comment "A PC build or product configuration is checked for compatibility. Captures whether the validation passed or failed, which compatibility constraints were violated (linking to rt:CompatibilityConstraint instances), and what the user did in response — fixed the issue, ignored the warning, or abandoned the build. Validation failures that lead to swaps are decision points." .

The full ontology can be found on GitHub here with the full retail demo dataset here.

The interaction ontology defines a durable semantic model for events such as:

Customer requests and product searches
Recommendations and alternative recommendations
Product, price, availability, and promotion context
Stated customer preferences and constraints
Agent decisions and their influencing factors
Purchases, non-purchases, feedback, and other outcomes
Links between one interaction and the next

Rather than placing this meaning only in application code or an opaque model prompt, TrustGraph makes it queryable context. The interaction becomes part of a connected and interoperable system of record, built with open standards, that can support agents, analytics, operations, and governance.

A recommendation is not just a response

Consider a shopper asking for a jacket appropriate for rainy weather within a defined budget.

A conventional assistant might return a product list, then discard the reasoning context after the session ends. The retailer may later see a purchase event, but not the full path that led there.

With TrustGraph, the system can model the complete interaction:

Customer request
  -> Requirements: waterproof, size, budget, preferred style
  -> Available inventory and eligible promotions
  -> Agent recommendation and alternatives
  -> Customer response: purchase, rejection, follow-up, or abandonment
  -> Outcome and reusable context for the next interaction

The recommendation is connected to the factors that shaped it. The customer response is connected to the recommendation. A later analyst, product team, or AI agent can retrieve the relevant context without reconstructing it from fragmented logs.

That makes retail AI measurable as a decision system — not just a conversational interface.

What TrustGraph enables

Improve recommendations with real outcomes

Agents can use prior interactions as structured evidence. They can distinguish between products a customer viewed, products they rejected, products they purchased, and the conditions that influenced each outcome.

This enables context-aware follow-up interactions such as:

“You preferred the lower-priced waterproof option last time.”
“The item you considered is now available in your size.”
“This alternative meets the same requirements but is eligible for your current promotion.”
“Customers with similar constraints selected this option after rejecting the original recommendation.”

Separate policy from behavior

Retail experiences often balance competing priorities: customer satisfaction, margin, inventory levels, promotion commitments, brand obligations, delivery windows, and privacy requirements.

TrustGraph allows those factors to be represented as explicit context around a decision. Teams can inspect whether a recommendation reflected customer preference, availability, a promotion, or an operational policy—rather than relying on an untraceable model output.

That is critical when retailers, brands, marketplaces, and data intermediaries need a common basis for evaluating automated decisions.

Make AI interactions auditable

When an AI system makes a recommendation, the organization needs more than a generated explanation after the fact. It needs a traceable record of the context available at the time and the outcome that followed.

TrustGraph’s CLI includes explainability capabilities for listing and inspecting agent, GraphRAG, and document-RAG traces, while its graph tools support streaming graph inspection, pattern matching, SPARQL queries, and RDF Turtle export.

This gives technical teams a practical path from “the agent said this” to “these were the facts, relationships, constraints, and tools involved.”

Build a shared data product

The same interaction model can serve multiple teams and systems:

Team or system	What it can use
Retail agent	Relevant customer, product, inventory, and outcome context
Merchandising	Which attributes and offers influenced customer choices
Marketing	Promotion performance connected to recommendations and results
Customer support	The prior recommendations and decisions behind a customer issue
Data broker or retail network	A governed semantic model spanning retailer, brand, and campaign data
AI governance	Evidence for how automated recommendations were produced

The ontology becomes a stable contract between applications. Individual channels can change—web, mobile, in-store, service desk, voice, or partner integrations—without redefining the underlying meaning of an interaction.

From ontology to running system

TrustGraph makes the model operational rather than leaving it as a static architecture artifact.

The TrustGraph CLI can load RDF Turtle into the knowledge graph, query or export graph data, configure and run processing flows, and invoke agents, GraphRAG, structured-data queries, and MCP tools. In practice, a team can version a retail ontology alongside its application, load it into a workspace or collection, and use it as the semantic foundation for retrieval, agent tools, and analysis. Detailed guides on working with the CLI with ontologies can be found here.

The CLI uses consistent workspace, collection, flow, API URL, and authentication options, making these operations built for enterprise-grade production workloads.

Why this matters now

Retail AI is moving from search and chat toward systems that recommend, influence, and act. As those systems take on more responsibility, a disconnected collection of embeddings, prompts, event tables, and model logs is not sufficient.

Organizations need context infrastructure that can preserve the meaning of an interaction across time:

What happened
What context was available
What decision was made
What policy or constraint applied
What outcome followed
What should be learned next

TrustGraph turns those connected facts into reusable operational context. It gives retail AI the ability to learn from interactions without losing the lineage, precision, and control that enterprises require.

Build retail AI that remembers

Start with the retail interaction ontology from the demo, adapt it to your customer and commerce model, and deploy it as a governed context layer for your AI systems.