Published 28 March 2026
What if you could query your entire supply chain just by asking a question? Not by building a dashboard, writing a SQL query, or calling your BI team — just asking, the same way you'd ask a colleague.
That's the promise. The reality of getting there was messier, more iterative, and frankly more interesting than any clean product announcement would suggest. This is the honest account of how TrackVision AI Chat — our conversational interface for GS1 EPCIS 2.0 (Electronic Product Code Information Services) supply chain data — actually got built. It's the same engine that now powers AI-assisted Digital Product Passport (DPP) compliance research across our platform.
In this post, you'll learn:
What is EPCIS AI Chat? TrackVision AI Chat is a conversational interface for GS1 EPCIS 2.0 supply chain data. It lets supply chain teams query production rates, track item disposition, detect counterfeits, and run multi-turn analytical conversations — without writing SQL. It's grounded in the EPCIS standard and your specific schema, not a generic AI model.
Our first version was exactly what you'd expect. We wired up ChatGPT function calls written in Python, built a rough chat front end that looked vaguely like the ChatGPT interface, and pointed it at our EPCIS API. The results were immediately useful — and immediately limited.
A simple question like "show me my products" worked. It returned a nicely formatted markdown response. The demo looked good — but not really that useful. Each new question required more function definitions, more API filtering logic, more edge-case handling. The system was brittle. Every new business question meant another sprint of engineering work. "Show me which batches from our Vietnamese factory shipped to Europe last quarter" — that's not a simple function call. It's a chain of queries, filtered joins, and contextual understanding of what "shipped to Europe" means in EPCIS event terms.
We needed something smarter.
Our EPCIS database is a relational SQL store. So the obvious next step was: can an AI just generate the SQL?
There are a handful of open-source text-to-SQL tools. We tried several. They worked — up to a point. The generic models could handle standard SQL queries well enough, but they hit a wall with EPCIS-specific semantics.
An EPCIS transformation event, for example, is not just "one record became another." It represents a physical or logical change where one or more input items become one or more output items — repacking, manufacturing, aggregation — and understanding whether a query is asking about product tracking or repacking activity requires knowing what the event means, not just what columns it touches. Diversion detection, by contrast, is done by analysing ObjectEvents across unexpected bizLocation or readPoint values — a different event type entirely. Generic SQL generators don't have that knowledge. They'd usually return technically correct queries that were semantically wrong.
We'd also done significant optimisation work on our schema — custom indexes, partitioning strategies, query patterns designed specifically for EPCIS access patterns at scale. A generic model had no way of knowing about those. So any SQL it generated would work, but wouldn't perform.
We needed a way to give the AI our specific knowledge.
Retrieval-Augmented Generation (RAG) was the obvious solution. Document our schema, document the EPCIS standard, encode our query optimisation hints, embed all of it, and let the model retrieve what it needs to answer each question. The approach had real merit — but also a structural limitation that we'd later discover the hard way: according to Google's research into long-context models, retrieval-augmented approaches can miss up to 30% of relevant context compared to loading the full document, because chunking fragments the very relationships between concepts that make domain knowledge useful.
It worked pretty well. Not always, but well enough to push forward. The failures were usually about embedding quality and chunk sizes — classic RAG problems. Some EPCIS concepts chunked badly, losing context. Some queries retrieved slightly wrong schema fragments and generated subtly broken SQL.
We iterated on chunk sizes. We experimented with different embedding approaches. We added caching to improve response consistency. We got to a place we were reasonably happy with — not perfect, but functional.
Then Gemini released a 1 million token context window.
Our entire RAG corpus — schema documentation, EPCIS standard reference, query optimisation hints, business context — was roughly 15,000 tokens. A rounding error relative to a 1M token window.
Suddenly the question wasn't "how do we retrieve the right chunks?" It was "why are we chunking at all?"
We could send the entire knowledge base in every request. No retrieval step. No chunk boundary problems. No missed context. The AI had everything it needed to understand our EPCIS schema, the standard itself, and our specific optimisations — in full, every time.
Gemini also had a significant cost advantage. Sending 15K tokens of context per request at Gemini's pricing was genuinely affordable at scale. We scrapped the RAG system entirely.
Then Gemini released context caching. Your main instruction set — the schema, the standard, the hints — can be cached server-side and reused across requests. Faster responses, lower cost per query. The architecture got simpler and cheaper at the same time, which doesn't happen often.
One thing the early function-call system couldn't do well was maintain context across a conversation. You'd ask something, get a result, then ask a follow-up — and the follow-up would effectively start fresh.
Real supply chain analysis doesn't work that way. You start broad, then drill down. "Show me production rates by region for footwear in 2025" — then "which of those had the lowest output in Q3?" — then "were any of those factories running transformation events that week?"
Gemini's large context window and the low cost per token made genuine multi-turn conversations viable. We pass the full conversation history with each request. The model has everything it needs to understand that "those factories" refers to the ones identified two questions ago. The experience shifted from query tool to genuine analytical conversation.
Here's what makes this genuinely useful in practice. These aren't toy examples — they're the kinds of questions our customers are actually asking:
readPoint locationsbizStep of destroying (the process) or a disposition of disposed (the resulting state), correlated with product categorybizLocation values that fall outside expected territoryWhat's common across all of these is that they require understanding the EPCIS data model — events, EPCs, read points, business steps, business locations — not just running generic SQL. The AI understands what the data means.
The last piece we added was the most interesting. We call it self-optimisation.
When the AI returns a result that isn't quite right — wrong aggregation, missed context, slightly off framing — the user can comment on it. A second AI call, using Gemini's more powerful reasoning model, analyses the feedback and the original response, and optimises the system context for that specific customer. It updates how questions are interpreted, what assumptions are made, what query patterns to prefer.
The system gets smarter as your team uses it. Specifically smarter — for your data, your vocabulary, your business questions. Not a generic improvement, but a customer-specific one.
There are plenty of general-purpose AI chat tools. According to Gartner, over 80% of enterprises will have deployed generative AI applications by 2026 — up from just 5% in 2023. But widespread deployment doesn't mean those tools are fit for every problem. Most of them are fine at summarising documents or answering questions about general knowledge. Supply chain data is a different category of problem.
The EPCIS standard defines specific event types, specific business step vocabularies, specific data structures for recording what happened to a physical item at a specific point in the supply chain. A generic model doesn't know the difference between an AggregationEvent and a TransformationEvent. It doesn't understand what it means when an item's EPCIS history shows an unexpected bizLocation. It can't interpret whether a disposition of sellable_not_accessible is normal or a red flag for a particular product category. The stakes are real: according to industry analysis from HDMA (Healthcare Distribution Management Association), EPCIS data errors in pharmaceutical supply chains alone cost over $6 billion annually in quarantined and stalled shipments — the result of systems that process EPCIS records without truly understanding them.
Here's how purpose-built EPCIS AI compares to generic tools:
| Generic AI (ChatGPT / Gemini) | TrackVision AI Chat | |
|---|---|---|
| EPCIS schema awareness | None | Full GS1 EPCIS 2.0 |
| Multi-turn supply chain queries | Loses context | Stateful sessions |
| Text-to-SQL for your data | Hallucinated SQL | Schema-grounded |
| Self-optimisation | Static | Learns from usage |
| Compliance-aware answers | No | CBV + Digital Link |
We spent two years building a system that understands EPCIS semantics, not just SQL syntax. That's the difference.
TrackVision AI Chat is purpose-built for supply chain EPCIS data. It sits on top of our EPCIS 2.0 repository, understands the full GS1 CBV (Core Business Vocabulary), and is grounded in your specific schema and data — not a generic model of "supply chains."
It's part of the broader TrackVision AI platform, which also includes AI-powered DPP compliance research, the AI Supplier Portal for data collection, and the AI Screen Builder for building custom supply chain interfaces without code.
If you're running EPCIS data and wondering whether your team could get more value from it by simply asking questions — talk to us. We'll show you what the system can do with your own data in a 15-minute call.
Dave Ashenhurst is CTO at TrackVision, where he has spent over a decade building supply chain traceability systems grounded in GS1 standards. He led the architecture and development of TrackVision's EPCIS 2.0 repository, the AI Chat platform, and the Digital Product Passport (DPP) compliance engine. Prior to TrackVision, Dave held engineering leadership roles at logistics and manufacturing technology companies, working directly with EPCIS implementations across pharmaceutical, food, and consumer goods supply chains.
What supply chain questions can TrackVision AI Chat answer? TrackVision AI Chat can answer multi-dimensional analytical questions across your EPCIS 2.0 data — production rates by region, item disposition tracking, counterfeit and diversion detection, cross-facility comparisons, and multi-turn exploratory analysis. It understands GS1 EPCIS event types and business step vocabularies, not just generic SQL.
Does it require a specific database or EPCIS implementation? AI Chat works with TrackVision's EPCIS 2.0 repository. If your supply chain data is stored in TrackVision, AI Chat can query it without any additional setup. If you don't have EPCIS data, we can convert it using our AI-assisted data loading services.
What AI model powers TrackVision AI Chat? AI Chat is built on Google Gemini, using the Flash model for fast, cost-effective multi-turn conversational queries and the Gemini reasoning model for the self-optimisation engine. The model selection is intentional — Gemini's large context window and cost per token make the architecture viable at scale.
How does the self-optimisation work? When a user indicates that a result wasn't quite right, the system uses Gemini's reasoning model to analyse the feedback and update the query context for that customer. Over time, the system learns your vocabulary, preferred aggregation patterns, and common analytical questions — without any manual prompt engineering.
Is TrackVision AI Chat the same as a general-purpose chatbot? No. General-purpose chatbots don't understand EPCIS semantics — the event types, business steps, read points, and EPCs that make up supply chain traceability data. TrackVision AI Chat is grounded in the EPCIS standard and your specific schema, which is why it can answer questions that a generic AI tool can't.