This page is not a finished study. It updates every time we change something on Founder Lab and rescan it, in the order it actually happened, including the parts that do not work. For the full baseline write-up, start with Day Zero.
Atom Foundry operates its own live Shopify store, Founder Lab, as a permanent controlled experiment. Most measurement of AI commerce is observational: you watch stores you do not control and infer what matters. Founder Lab lets us do the opposite. We own every variable, so we can change one thing at a time, a product description, a schema field, a trust signal, and watch, in real time, how AI systems respond.
What we measure there goes beyond a single score. We track how each change moves the store's AI Commerce Score™, but also which AI agents crawl the store and when, which pages they read, whether they retrieve it in live shopping answers, and how its recommendation profile shifts over time. It is a live sensor for the same signals we measure across the wider commerce graph, validated on a store we fully control. Over time, Founder Lab becomes the causal ground truth behind Atom Foundry's research: the place where we confirm what actually moves AI behavior, before we claim it anywhere else.
Before touching anything, we scanned Founder Lab once on July 12 and five more times on July 17, all within 62 seconds, to see how stable the score is before we start changing it. Score held between 76 and 78. Every component except intent was identical across all six scans, only intent moved, between 4 and 6 out of 10. We also checked our AI bot visit log across the store's full history: zero visits recorded, from any AI agent, ever.
The plan going forward: fix technical first, since it is deterministic and currently the weakest score component at 7 out of 15. Then rework headlines and product copy for intent, the one factor our own research has shown actually separates recommended stores from the rest. Every change gets rescanned more than once before we trust the delta.
We gave ChatGPT the URL directly and asked for a full audit. It could not load the page. Its own explanation was that the store was probably blocked for bots or running in a non-public mode, and that its search kept surfacing a completely different company called Founder Foundry instead of us.
We did not take that explanation on faith. We already know robots.txt is wide open, we checked it ourselves. So we ran the same two requests through our own fetch tooling right after: the homepage and robots.txt both came back clean, full content, no block, no timeout. Whatever stopped ChatGPT, it was not a robots.txt block, that specific claim does not hold up.
Founder Foundry turned out to be real: an established founder community with its own site, LinkedIn, Instagram, and press mentions going back years, nothing to do with us. That is a plausible, if unproven, explanation on its own. A search-grounded model reaching for the closest well-known match to "founder" plus a startup context would find a name with a real web footprint before it finds a two-week-old store with almost none, exactly what our own web-traces research already predicts.
What we cannot say for certain is why the direct URL fetch itself failed on ChatGPT's side when it succeeded on ours. We do not have visibility into their browsing tool's infrastructure, so we are not going to guess at a mechanism we cannot verify. We are logging this as it happened: a real external failure, one explanation that checked out, and one that remains open.
We then ran a small test on our own tracking. We visited the store twice more, once through a plain fetch and once through a real browser session, both deliberate, both successful, both fully logged on our side as page loads. Neither visit appears anywhere in our AI bot visit tables, checked within minutes of it happening. That does not prove no AI has ever reached the store. It proves our own instrumentation cannot currently confirm one way or the other, which is its own separate problem, and a more urgent reason to fix the tracker before we draw any conclusion from a zero.
We ran a controlled test: spoofed a GPTBot user agent in a real browser session and reloaded the tracking script by hand. It worked exactly as designed. The script correctly detects known AI agent signatures, calls the webhook, and the webhook correctly received and processed the request, response code 200.
The database write is where it breaks. The insert step in the n8n workflow hardcodes the row id to 0 on every single call, instead of letting Postgres assign a new id automatically. That means every visit, from any bot, on any store using this pipeline, lands on the exact same row and overwrites whatever was there before. The table was never failing to log visits. It was only ever able to hold one, the most recent one, forever erasing the history before it.
This changes what the earlier zero meant. It was not necessarily zero visits. It could have been any number of real visits, each one erasing the last, with no way for us to have seen it. We deployed the fix, a plain insert with the id left to its own default, then tested it twice more with two different spoofed bot signatures to confirm. Both showed up as separate rows with their own ids. The single-row overwrite is gone. From this point forward, every visit gets its own permanent record.