Skip to main content
Every change a merchant makes to their store is answerable from a single graph. When did it happen, what was the state before, what was the state after, what did it cost or earn in revenue, and (when something went wrong) how do they roll it back. That single answerable timeline, joined across every connector and every Vortex App, is what turns Vortex IQ from an analytics layer into an operating layer. This page explains what is in the graph, what it makes possible that no single-tool analytics platform can do, and what is wired today versus on the roadmap. It is the answer to “what is the AI OS actually”.

​
Why the graph exists

A working ecommerce merchant runs roughly twelve tools at the same time: a commerce platform, a payment gateway, two or three ad platforms, an email service, a customer support tool, an analytics tool, one or two monitoring tools, three or four carriers, and a sprinkle of marketplaces. Each of those tools ships its own dashboard. Each one tells the merchant a true number inside its own boundary. None of them can join the picture. When conversion drops on a Tuesday morning, the merchant does not have a tool. They have a triage routine: open Google Ads, open GA4, open the commerce dashboard, open Datadog, open the deploy log, scroll, hypothesise, ask a colleague. Most of the time the cause is found within an hour. Sometimes it is found in three days. Sometimes it is never found and the merchant settles for a vibe explanation (“seasonal”). All of this is because the joined timeline does not exist anywhere outside the merchant’s head. The graph is the joined timeline. Every entity in every connector becomes a node. Every change to every entity becomes a versioned edge. Every outcome (an order, a refund, a session, a chargeback, a conversion event) becomes a timestamped edge against the entity it touched. Joined, the graph answers in seconds the questions that today take hours.

​
What is in the graph today

The graph is layered. Each layer adds a different shape of evidence.

​
Layer 1: Live connector state

Every connector at parity contributes its native entities and metrics. Products, orders, customers, channels, inventory, campaigns, ad creatives, email sends, support tickets, parcel events, payment transactions, incident records, all live, all current. This is the layer the Nerve Centre reads to compute its KPI cards and the layer the Cross-Channel Kill-Shots reach across to compute joined values. Currently 41 connectors contribute live nodes and edges, with 148 cross-channel cards already joining two or more connectors at the data layer. The full per-connector inventory is in the Cross-Channel Kill-Shots catalogue.

​
Layer 2: Continuous change history (RollbackPro)

RollbackPro is the Vortex App that continuously backs up every change to a BigCommerce store. The backup is granular. For Products it captures every variant, option, modifier, image, custom field, bulk pricing rule, video, and channel assignment. Pricing is captured at every level: Price, Cost Price, Retail Price, Sale Price, and the Minimum Advertised Price (MAP) field that BigCommerce exposes (in the UK this concept is the closest equivalent to RRP, recommended retail price), plus per-variant overrides and bulk-pricing tables. Categories carry their hierarchy, sort rules, SEO fields, and image. Customers, Orders, Coupons, Promotions, Pages, Email Templates, Blog Posts, Brands, 301 Redirects, Channels, and Gift Certificates all version on change. Real-time webhooks capture changes for the entities BigCommerce exposes webhook coverage on (Products, Categories, Customers, Orders, Channels, Pages, Email Templates). Scheduled backup captures the rest (Brands, Promotions, Blog Posts, Coupons, Gift Certificates, 301 Redirects). The result is that for every BigCommerce merchant running RollbackPro, the graph knows the complete state of their store at every point in time, plus the trail of who or what changed it. The same merchant can ask “what did this SKU’s price look like at 14:00 last Tuesday” and get a clean answer with the change actor recorded.

​
Layer 3: Staging-to-production diff (StagingPro)

StagingPro gives every merchant a parallel staging environment for their BigCommerce store. The staging copy is a full BigCommerce store with its own store hash, kept in sync against production through versioned indices. The graph holds both the live production state and the candidate staging state per merchant, plus the per-entity diff between them, in a strictly tenant-isolated store. The version layer of each merchant’s indices is the joined timeline made queryable: every entity change recorded against its outcome. Before a merchant clicks Deploy, the graph already knows the answer to “what will change in production when I push this staging diff”. The audit is a graph query, not a manual walkthrough.

​
Layer 4: AI-engine optimisation artefacts (SEO GEO)

The SEO GEO data set holds the pillar-and-spoke content artefacts that Vortex IQ generates and tracks for AI-engine optimisation. Pillars are the long-form authoritative pages a merchant ranks for inside ChatGPT, Perplexity, and Gemini citations. Spokes are the supporting briefs that link back to a pillar. Impact snapshots measure the citation footprint over time. Joined into the graph against Products and Categories (the entities the content describes), the SEO GEO layer makes “is this SKU’s canonical content being cited correctly by AI engines” a graph query, not a manual audit.

​
The four archetypes of cross-graph insight

The graph lights up four qualitatively new capabilities that did not exist when each layer lived in its own silo. Each archetype is a class of work the merchant otherwise does manually, intermittently, and incompletely.

​
Archetype 1: Cause attribution with Rollback

When an outcome moves, the cause is almost always a change somewhere in the merchant’s stack. Conversion does not drop for no reason. Refund rate does not spike for no reason. Click-through does not collapse for no reason. The cause was a price edit, a category move, a JS deploy, a promo overlap, a payment routing change, a copy rewrite. The merchant rarely connects the cause to the effect because the cause and the effect live in different tools with different time grains. The graph removes that gap. Every outcome metric is a node with a timestamp. Every entity change is a node with a timestamp. The system continuously asks, for every metric on every dashboard, “what changed in the entity neighbourhood in the 24 hours before this metric moved”. When a match scores high enough, it surfaces as a card. A worked example, drawn from the shape of a live mid-market apparel merchant. The merchant runs several thousand active products, millions of live orders, and over a million customer records on BigCommerce. RollbackPro records several gigabytes of product version history for them, capturing every catalogue edit. If their checkout conversion drops six percentage points tomorrow, today’s tool surfaces “conversion dropped six points”. The graph surfaces:
“Conversion dropped six points. Three of the four SKUs accounting for seventy percent of the abandoned carts had a price change in the prior 24 hours. The price changes raised retail by between eleven and seventeen percent. The fourth SKU had no price change but received a category-tree move that orphaned it from the canonical landing page. RollbackPro has the prior state on all four. Roll back the three price changes and the category move in one operation.”
That entire diagnostic is a single graph query. The merchant moves from “what just happened” to “here is the cause and here is the fix” without leaving the dashboard. The pattern generalises across every entity the graph knows about. Refund spike traced to a product description rewrite that promised the wrong dimensions. Email-attributed revenue dip traced to a Klaviyo flow that turned off when a segment definition was edited. ROAS drop traced to a Google Ads campaign budget cut that happened twelve hours earlier. The change is always in the graph, the outcome is always in the graph, and the join finds the cause. The merchant value is straightforward to name. Time to diagnosis falls from hours to seconds. Revenue lost during the diagnostic window stays in the store. Confidence in deployment goes up because every change carries a continuous before-and-after record.

​
Archetype 2: Pre-launch audit at scale

A merchant about to push staging to production faces a question they cannot answer well today. What will this deploy actually change in production, and is any of it likely to break something. The typical answer is a manual walkthrough by the developer who wrote the change. The walkthrough catches obvious issues. It misses subtle ones. It particularly misses cross-cutting issues, where a small change in one place breaks a dependency in another. The graph already holds both sides of the diff. Production live state for every entity. Staging candidate state for every entity. Plus all the live connector state that production currently joins against (ad spend on which SKUs, Minimum Advertised Price rules for which brands, indexable pages in Search Console, listings on which marketplaces). The pre-launch audit becomes a set of graph queries that the merchant or their Technical Account Manager runs before clicking Deploy. Five queries that are computable today on data already in the graph:
“Does this staging push lower any product price below its Minimum Advertised Price floor on a brand the merchant has a distribution agreement with.”
RollbackPro carries the Minimum Advertised Price field per variant (the field BigCommerce exposes as MAP Price; in the UK this concept maps closely to RRP, recommended retail price). The brand-to-Minimum-Advertised-Price-policy map is in the merchant’s product attributes. The staging diff names the SKUs whose price has changed. The query joins all three.
“Does this staging push slow Largest Contentful Paint on any top-revenue page into the red band, based on the PageSpeed baseline of equivalent pages today.”
StagingPro carries the JS bundle and theme diff. website_performance carries the LCP percentile per URL. The query joins the diffed routes to the baseline LCP and predicts which pages slip below threshold.
“Does this staging push orphan any SKU from its canonical category, breaking the SEO landing page and any GEO pillar that cites the URL.”
Category-tree diff joined to product-to-category edges joined to SEO GEO pillar URLs.
“Does this staging push create a double-discount where an active Coupon overlaps a Promotion that targets the same audience and same SKUs.”
Coupon diff joined to active Promotion records joined to overlapping segment definitions.
“Does this staging push rename a custom field that is referenced by any other product, by any marketplace listing export, or by any Klaviyo flow.”
Custom-field diff joined to product metafield references, marketplace export schemas, and Klaviyo flow filters. Every one of these is a graph query that returns either a list of affected entities or an empty set. An empty set is a green light. A non-empty set is a list of issues to address before deploy. Run all five and the merchant has a complete pre-launch audit in seconds. This is the answer to a question that BigCommerce’s GTM leadership has surfaced explicitly. Their Technical Account Managers currently run health checks manually, intermittently, on a small fraction of accounts. The graph turns “we run quarterly health checks on the top accounts” into “we run a full health check on every staging push for every account, automatically, with the issues surfaced as a checklist”. The TAM goes from running audits to triaging audits. The merchant ships fewer surprises into production.

​
Archetype 3: AI-engine-native commerce

Search behaviour is changing faster than most ecommerce stacks are prepared for. A measurable and growing share of buyer research is happening inside AI engines (ChatGPT, Perplexity, Gemini, Copilot) instead of Google’s blue links. The merchant who optimised for SEO ten years ago has no instrumentation for AI-engine citations today. The pillar-and-spoke content patterns that maximise AI-engine citations are different from the keyword-and-backlink patterns that maximised Google rankings, and there is no industry-standard tool for measuring how well a brand is cited inside an AI engine answer. The SEO GEO layer of the graph is the instrumentation for that shift. It already holds pillar-and-spoke content artefacts, the canonical product attributes those artefacts cite, and impact snapshots that measure how the citations move over time. Joined against RollbackPro’s product history and the connector graph, the graph supports a set of AI-engine-native questions:
“Is Perplexity citing this SKU at the correct current price.”
The graph joins RollbackPro’s current price for the SKU against the impact snapshot of the SKU’s pillar content. If the snapshot shows the AI engine quoting a price that is no longer the live price, the merchant gets a card pointing to the stale citation, with the recommended content refresh attached.
“Which pillar pages are pulling weight as AI citations, and which are not.”
The graph reads the impact snapshot history of every pillar and ranks by citation frequency and attributed traffic. Pillars that consistently appear in AI answers are the ones to lean into. Pillars that never appear are candidates for rewriting against a different angle.
“What share of branded mentions is now AI-engine-driven, and how is it trending.”
The graph computes “AI citation share” as a first-class metric, sitting alongside organic share and paid share in the channel-mix view. Merchants who watch this metric over twelve months will see one of two outcomes. They are growing into the new traffic channel before their competitors notice, or they are losing presence in a channel they did not know they were in.
“Generate pillar-spoke content from the actual product graph.”
Combining the product entity graph with the pillar-spoke template generates AI-engine-citable content on demand. Schema-rich JSON-LD, pillar-grounded copy, FAQ blocks that match the questions AI engines extract. The merchant does not have to choose between writing canonical content and trusting an AI-engine-native generator; the generator is grounded in the merchant’s own catalogue graph and the rollback layer keeps every change reversible. This is the forward-looking bet. Three to five years from now, “did the AI engine cite me correctly” will be the dominant marketing channel question for most consumer brands. The merchants who have the graph today are the ones who will have telemetry on that channel when it matters.

​
Archetype 4: The agent layer with rollback as the safety net

The first four archetypes are about the merchant or the Technical Account Manager reading the graph and acting on it. The fifth is about agents reading the graph and acting on it, with the merchant in the loop or with the merchant out of the loop, depending on the action. A grounded agent is qualitatively different from a chatbot. A chatbot answers a question from training data. A grounded agent runs a query against the merchant’s actual graph, reasons over the result, optionally executes an action through the connector or through a Vortex App, and records the action back into the graph so the next agent can read what happened. Three agent patterns the graph supports today:
The pricing agent. A merchant has staged a price change. The agent reads the staging diff. It reads RollbackPro’s history of price changes on the affected SKU on this merchant’s own store. It reads ad spend on the SKU and Klaviyo audience size that touches the SKU. It produces a recommendation: “Staging contains a seventeen percent price increase on SKU W74-3. The last price increase of this scale on this SKU dropped conversion twenty-two percent within 48 hours. Active ad spend on this SKU is forty dollars per day. Recommend: stage at ten percent instead, run an A/B test for seven days, watch the conversion delta. RollbackPro keeps the original price queued for one-click revert.”
The inventory agent. A top-revenue SKU goes out of stock. The agent reads previous out-of-stock events on the same SKU to estimate restock lead time. It reads ad spend, Klaviyo audience size, marketplace listings, and current cart contents to estimate revenue at risk. It pauses the affected ad campaigns through the Google Ads connector. It triggers a back-in-stock notify flow through the Klaviyo connector. It drafts a supplier escalation note. It records every action back into the graph so the merchant sees a single timeline of what the agent did and why.
The deploy agent. A staging diff appears. The agent runs the five pre-launch audit queries from Archetype 2. If all five return empty sets, it greenlights the deploy. If any return non-empty, it blocks the deploy and surfaces the affected entities and the recommended remediation. The merchant cannot bypass the block on critical findings, but can override on flagged findings with an audit-logged reason.
Each agent has rollback wired in. Every action is reversible through RollbackPro or through the originating connector’s API. Every action is recorded in the graph timeline so the next agent or the merchant can read the trail. The safety net is the structural difference between agents that move fast and break things and agents that move fast and do not break things. This is the AI OS payoff. The graph plus the agent layer is what makes Vortex IQ a system the merchant operates with, not an analytics tool they read.

​
What this turns Vortex IQ into

A working ecommerce stack has roughly twelve tools. Each one is a window into one piece of the business. None of them join. The merchant’s mental model of “what is happening in my business right now” is the merchant’s own head, doing the join from memory, intermittently, with gaps. The graph is that join, externalised, continuous, queryable. What it gives a merchant who has been on it for sixty days:
  • They do not remember what they changed last Tuesday. The graph does.
  • They do not click Deploy and hope. The pre-launch audit runs first, every time.
  • They do not wonder whether an AI engine is citing them correctly. The graph watches.
  • They do not write the diagnostic. The cause attribution surfaces it.
Pulling the graph out at day sixty-one means losing three things at once. The continuous change history that lets them say “what changed”. The pre-deploy safety net that catches mistakes before they ship. The cross-connector cause attribution that finds problems they would otherwise miss. These are not features. They are reflexes that the merchant has built into how they operate. A merchant can replace any one of these with a single-purpose tool. Replacing all three at once is the cost of leaving the graph. Most merchants who reach sixty days on the graph do not leave.

​
How the graph relates to other modules

The Vortex IQ AI OS is built around a small set of named mechanisms. The graph is the substrate that the other mechanisms read and write against.
  • The Nerve Centre is what the merchant sees on the dashboard. Cards, alerts, sentiment, and the executive view. Every card the Nerve Centre renders reads from the graph.
  • Vortex Mind is the reasoning layer. Eight live report types from Daily Briefing to Quarterly Business Review. Every report grounds its findings in graph evidence with citations the merchant can click into.
  • Ask Viq™ is the natural-language interface. Every Ask Viq answer is a graph traversal under the hood.
  • Actions is the audit and fix surface. Every audit check runs against the graph. Every fix lands a recorded change back into the graph through RollbackPro or the connector.
  • Vortex Apps are first-party applications that contribute to the graph and act on it. RollbackPro is the change-history Vortex App. StagingPro is the production-vs-staging diff Vortex App. Future Vortex Apps slot into the same pattern.
  • Agent Hub is where the agent layer lives. Agents read and write the graph in the same way the merchant does, with rollback as the safety net.
The Eyes, Voice, and Hands metaphor still applies. The Nerve Centre is Eyes. Ask Viq is Voice. The Actions and Agent Hub layers are Hands. The graph is the body underneath all three.

​
What is wired today versus on the roadmap

Some of the graph is shipping today. Some of it is being wired now. Some of it is on the next-quarter roadmap. Honest current state:

​
Wired and shipping

  • Connector graph for the 41 connectors at parity. The cross-channel join layer is live and the 148 Cross-Channel Kill-Shot cards read from it.
  • RollbackPro change history on the BigCommerce stores that have the app installed. Every entity backed up; webhooks for the entities BC supports them on; scheduled snapshots for the rest. Single-item, bulk, and point-in-time restore are all live.
  • StagingPro production-versus-staging diff for each merchant licensee. Full version indices, queryable through Vortex Insights, strictly per-tenant.
  • SEO GEO content artefacts (pillars, spokes, impact snapshots) for merchants who have run the SEO GEO workflow in Actions.

​
Being wired now

  • Full Knowledge Graph backing. Today the joins live across Vortex Insights indices and the relational store. The Knowledge Graph layer is the unified property graph that makes traversals cheaper and the agent layer feasible.
  • Universal change-attribution cards. The pattern <connector>_xc_outcome_vs_recent_change is the universal form of the cause-attribution archetype. The first two (Pagespeed-vs-funnel and Price-change-vs-funnel) ship today; the next half-dozen are in active authoring.
  • AI-engine citation tracking against the SEO GEO artefacts. Pillar-spoke linkages are in place; impact-snapshot polling against the four major AI engines is the next pass.

​
On the roadmap

  • The three named agents (Pricing, Inventory, Deploy) move from spec to ship as the change-attribution card family fills out and the rollback graph completes coverage on non-BigCommerce commerce platforms.
  • Shopify and Adobe Commerce parity for the RollbackPro change-history layer. The pattern from BigCommerce ports across; the per-platform connector work is what gates timing.

​
Privacy and tenancy

The graph is strictly per-tenant. The privacy model is described in plain terms in the retention and governance concept page. The headline rules:
  • Every merchant’s per-store data is private to that merchant. No other merchant or partner can read it.
  • A merchant’s connector graph, RollbackPro history, StagingPro diff, and SEO GEO artefacts are stored in tenant-isolated indices. Cross-tenant reads are not possible.
Per-tenant data isolation is what lets the graph serve sensitive operational data commercially. Each merchant’s graph belongs to that merchant.

​
How big the graph gets per merchant

Shape of the per-merchant data layer, as of 2026-05-15:
  • 41 connectors at Heroes-plus-Manifest-plus-Graph parity, contributing live nodes and edges per tenant
  • 148 cross-channel cards joining two or more connectors at the data layer
  • 6,034 unique KPI cards in the compiled registry
  • A typical mid-market merchant’s graph contains tens of thousands to several million entity records across products, orders, customers, categories, channels, and the auxiliary connector data; the largest enterprise tenants reach the tens of millions
  • The version layer of RollbackPro (the change-history timeline) is typically over half of a tenant’s total graph storage; this is the joined timeline that makes change-attribution queries cheap
Per-merchant the graph is the merchant’s complete commerce state plus its complete change history. Per-Vortex-App (RollbackPro and StagingPro) the graph is the version layer that turns Vortex Memory from a search index into a continuous timeline.

​
FAQ

Is this the same as Vortex Memory? The Graph is the structured-data layer of Vortex Memory. Vortex Memory as a section also covers the merchant’s knowledge base (uploaded files like brand guidelines, supplier catalogues, returns policies) and the Reports archive (every Vortex Mind report run, retained). The Graph, the knowledge base, and the reports archive are three surfaces of the same memory layer. Ask Viq cites all three. Do I have to use RollbackPro and StagingPro to get value from the graph? No. The connector graph (Layer 1) lights up the moment you connect two or more connectors. The cross-channel join cards documented in the Cross-Channel Kill-Shots catalogue work without the change-history layer. The change-history layer (Layer 2) requires RollbackPro for BigCommerce merchants. Other commerce platforms inherit a thinner change-history layer from the connector itself (Shopify Admin API change events, for example) until the native rollback layer ships per-platform. The pre-launch audit layer (Layer 3) requires StagingPro. You get more out of the graph the more layers you contribute. Every layer is stored per-tenant. Where does the data physically live? Today, Vortex Insights (for the StagingPro and RollbackPro indices) and the relational store (for the SEO GEO and operational tables). The Knowledge Graph is the property layer being wired now and will sit on top of those stores. The exact storage location for any one merchant is documented in the retention and governance page. What happens to my graph if I leave Vortex IQ? Every layer of the graph is your data and is exportable on request. RollbackPro snapshots and StagingPro indices can be exported in standard ecommerce formats (CSV for products, JSONL for full entities). How is this different from a data warehouse? A data warehouse is a destination for analytics. The graph is a source for actions. The warehouse is read-only and after-the-fact; the graph is read-write and continuous. The warehouse holds rows; the graph holds entities and relationships. The warehouse is good for “what happened last quarter”; the graph is good for “what changed in the last hour, what did it cost, and what is the rollback path”. Many merchants use both. The graph fills the warehouse with cleaner joined data than the merchant could assemble on their own. Can I see the graph itself? Today the graph is accessed through the surfaces the merchant uses (the Nerve Centre, Vortex Mind, Ask Viq, Actions, Vortex Apps, Agent Hub). A direct query surface for the graph is on the roadmap, scoped initially to per-account admin users who want to write their own change-attribution rules.