How to publish prices, leadership details and other changing facts so AI engines stay up to date
Match each fact to the system that can correct it as fast as the fact changes: search, knowledge graphs or the language model
Fabrice Canel spent nearly thirty years at Microsoft, most of them running crawling and indexing for Bing, and IndexNow was his answer to one specific problem: a search engine finding out about a change late. With IndexNow, a site tells participating engines the moment a page changes, instead of waiting for the next crawl (Microsoft Bing, 2021). Google made a similar move years earlier, when its Caffeine update switched its index to continuous updating. Search now takes in a change within days, and sometimes much faster.
That solves the problem for search, and only for search. In the terms of the Two Clocks paper, IndexNow speeds up the fast clock and does nothing directly to the slow one. A fact that has already settled in a knowledge graph or in a language model changes there on a much slower cycle, however quickly you notify search.
So the real decision happens earlier, when you choose which of the facts you’ve harvested from your business to publish, and where. Get that wrong and you can spend months trying to correct something the AI engines learned from you.
Search, knowledge graphs and language models update at different speeds
Every AI assistive engine draws on three kinds of system, the combination I’ve called the Algorithmic Trinity since 2024: search, knowledge graphs and the language model. They learn about you on very different timescales: search takes in a change within days, knowledge graphs update over weeks to months, and the model only changes when it’s retrained, which usually means six to twelve months.
The Two Clocks paper describes the same thing from the machine’s side. On the fast clock, search picks your content to answer one question at the moment somebody asks it. On the slow clock, knowledge graphs and models absorb evidence into what they durably hold, through update cycles you can’t see and can’t trigger.
This article looks at it from your side. If the systems learn at different speeds, then the facts you publish need sorting by how fast they change, so that each one ends up in a system that can keep up with it.
Sort your facts by how often they change: never, occasionally or often
Every fact you publish is a claim, with a frame and, ideally, proof. Some of those facts never change, some change every few years, and some change every week.
| How often the fact changes | Example | Where to publish it | Where you want it to end up |
|---|---|---|---|
| Never | Your founding date | Everywhere, including third-party sites, as strongly corroborated as possible | Everywhere, with the Knowledge Vault as the goal |
| Occasionally | Your CEO | Widely, but only on pages where it can be changed later, with moderate corroboration | The model, correctable through search |
| Often | Your prices | Only where you control the value: your own site, your API, your feed | Search, and the fast graphs built for that kind of data |
The rule behind the table is simple: publish each fact where it can be corrected at least as fast as the fact itself changes, and keep it from settling in a system that’s slower than that.
There’s one subtlety in the top row. A company name can change, and it still behaves like a permanent fact, because the old name stays true: it becomes another name for the same company. A price doesn’t work that way: the old price isn’t another name for the new price, it’s simply wrong. So the question to ask of any fact isn’t only “does this change?” It’s “once it changes, is the old value still true?” A change that adds to what’s known is safe to have everywhere. A change that replaces the old value is the dangerous kind, and how often it happens decides which row it belongs in.
Only some knowledge graphs feed the Knowledge Vault, and fast-changing data stays out
“The knowledge graph” is misleading, because there are many of them and they’re built for different jobs. There are product graphs fed by merchant feeds, maps, book and scholarly databases, and the knowledge graph each engine builds from its web index. I’d bet that every major engine runs one of those last ones, Google certainly does. These graphs are easy to build and easy to maintain, and they change often.
Then there’s the one I call the Knowledge Vault, a name I borrow from Google’s 2014 research paper (Dong et al., KDD 2014) without claiming Google’s current system is built that way. It’s the solid one: a semi-permanent encyclopedia, built to collect evidence until it’s convinced, and to resist contradiction once it is.
Information reaches the Knowledge Vault selectively, and what I’ve seen over the years suggests the selection follows how often things change. The web index knowledge graph is the first step in. Books and scholarly records can make it too. Maps generally doesn’t: local businesses and office locations stay in Maps, with educational establishments and tourist attractions the exceptions. Product data generally doesn’t either, because it changes so often. That’s my reading of how Google behaves rather than anything Google has documented.
HOW OFTEN IT CHANGES WHERE IT SHOULD SETTLE
never --------------> Knowledge Vault, via the web index
knowledge graph (resists contradiction)
occasionally --------------> the model; answers correct through
search once search carries the new value
often --------------> search, your own feed and API, and the
fast graphs (products, maps)Where to publish facts that never change: everywhere you can
Your founding date should be on your own site, in your structured data, in every directory profile, in press coverage and on every third-party page you can influence. Corroborate it as heavily as you can. The aim is for it to settle in the Knowledge Vault, because once it’s there a lookup is cheap, it needs no interpretation, and it resists contradiction. That resistance is exactly what you want for a fact that will never need correcting.
Where to publish facts that change occasionally: only on pages you can update
This is the hard case. You can’t keep your CEO’s name off the web, and you wouldn’t want to. But both the model and the Knowledge Vault hold on to what they’ve learned, so a fact that changes every few years is a risk in both.
Three things reduce that risk. Publish it only on pages where the value can be changed later: your own properties, profiles you control, partners who’ll update when asked. Keep corroboration moderate rather than maximal. And plan in advance where the new value will go when it changes, because copies will inevitably land somewhere you can’t edit, and the only way to deal with those is to outnumber them.
Here’s my reasoning about why moderate corroboration matters, and it’s reasoning rather than documented behaviour. An engine answering a question seems to check search when it’s unsure, and answer from memory when it’s confident. A fact corroborated heavily enough to be answered from memory keeps being answered from memory after it’s changed. A fact held with moderate confidence gets checked, and if search is carrying more of the new value than the old one, the answer updates. Research on how models weigh retrieved evidence against what they learned in training points the same way (Mallen et al., 2023; Xie et al., 2023). In my experience, overwhelming an old value that’s settled on pages you can’t change takes a few months.
Where to publish facts that change often: your own site, API and feed
Prices are the clearest example. Publish them where you control the value: your own site, your API, and feeds you manage. Keep third-party corroboration of a specific price thin on purpose, so that no engine ever becomes confident enough to answer from memory. It then has to come back to you, and every answer it gives is current.
Product graphs fed from a merchant feed fit here, because they’re built to be overwritten, on a cycle measured in hours or days rather than months. You control the feed, though, not the graph, so other sites that list your products can still supply an old price.
There’s one trap here. A price that stays the same for a long time and gets repeated by many third parties starts to look permanent, and that’s how product data can end up somewhere much harder to correct. Keep prices thinly corroborated even while they’re stable.
Search, knowledge graphs and the model only need to agree on where the current value lives
The goal of perfecting your digital footprint is for search, knowledge graphs and the model to agree about you, because agreement across independent systems is what confidence is made of. Keeping prices out of two of them looks like it breaks that. It doesn’t, because for a fact that changes often, what they need to agree on is where the current value lives. If every system knows that your prices are on your site and in your feed, the engines agree, and every answer is right on the day it’s given.
What to do this week: sort the facts on your most important page
Take the most important page on your site and list every fact on it. Mark each one: never changes, changes occasionally, or changes often. For every fact that changes, ask whether the old value stays true once it’s changed. Then check where each fact is currently published against the table above. The facts that change often and are sitting on third-party pages you can’t edit are the ones to deal with first, because they’re the ones that will be wrong in an AI answer long after you’ve changed them.