CAVEMANAIQ all four storylines
storyline 04 · the catalogue

Why are our products called unavailable?

GA
ME
TM
G4
SC
MC
DM
DB
01
01 · one console

Seven dashboards to one console

the console · all seven servers, one login
ask anything…
7 servers docked · each holding its own login
The refusal surfaced on one platform, the rule that decides it lives in the shop’s own database, and the reason it changed is in neither · it is in the record of what each feed version believed.
02 · you ask · on the record

The question is the whole interface

Why does the advertising platform call these products unavailable when the shop sells them · and how much of the catalogue is really orderable?
you
the console
on the record
7 servers docked · each holding its own login
handed to the agent, word for word · nothing runs unasked
▸ we write the request down before we send it
▸ and the answer when it comes back
It arrived as a platform complaint, but the answer needed a definition first: what does this shop mean by can be bought.

What can be bought had to mean before any feed was believed

The platform’s complaint was about products; the answer was a definition.

what had to be settled first

three ways to be sellablethe shop releases a product on what is on the shelf, on the supplier status that permits checkout, and on a setting that can override both · the storefront reads the three together
access was never the problema reader pointed at exactly the right advertising account still returns a confident wrong answer when the feed behind it consults one field
the internal figure toothe headline everyone quoted for unavailable stock was built on the same single-field assumption as the feed · not merely stale, wrong in the same way
nothing tried on the live cataloguescale came from read-only owned data, platform state from private account readers, and every change was proved against a production-shaped staging feed before the platform was asked to reprocess anything
03 · dispatch

The agent decides who to ask

THE MCP FLEET
THE PLATFORMS · reached by API, not by login
the agent
reasoning: what do I need, in what order?
DB the database 01
what the shop itself will actually sell
MC Merchant Center 02
what search refuses to serve, and on what grounds
ME Meta 03
the same of the social catalogue
VH version history 04
when each rule changed, and what it believed then
GA
Ads
stands down
Google Ads API
your ad account · Google’s cloud
03
ME
Meta
spend · conversions
Meta Marketing API
your ad account · Meta’s cloud
TM
GTM
stands down
GTM API
the tag container running on your site
G4
GA4
stands down
GA4 Data + Admin APIs
your site’s events · browser + server
SC
GSC
stands down
Search Console API
how Google search sees your site
02
MC
MC
products · feed
Merchant Center API
your product feed · Google’s cloud
DM
DM
stands down
audience · conversion upload
your audience lists · Google’s cloud
YOUR OWN RECORDS · READ THROUGH THE DATABASE MCP, NOT A VENDOR CLOUD
01
DB
the database
your own records
the database · your own records
the buy-button test
04
VH
version history
your own records
the database · your own records
when each rule changed
Two destinations are asked what they refuse to serve.
04 · the crossing
data plane · no human · always running

The rule goes in

THE DATA PLANE · runs whether or not anyone is watching
a shopper · not you
the site · code running
every visit writes the record · no one at the wheel
Google’s servers · shopping runtime
the rule is collected as a file · staged first
Meta’s servers · ads runtime
the same rule, pushed item by item
what changed in the plane
A product is offered to the advertising platforms on the same test the buy button uses
the shop and its advertisements finally answer the same question the same way.
The combined rule ships to both feeds.
05 · gather

The evidence converges on the session

MC
MC
what it refuses · and on what grounds
ME
Meta
the same question · a different route
DB
the database
the buy-button test
VH
version history
when each rule changed
one payload · assembling
MC
what it refuses · and on what grounds
Meta
the same question · a different route
the database
the buy-button test
version history
when each rule changed
all 4 answers in · ready to combine
The answer is an uncomfortable one.
06 · the readout

Neither field was the answer

what had to be settled first
The platform’s complaint was about products; the answer was a definition.
three ways to be sellablethe shop releases a product on what is on the shelf, on the supplier status that permits checkout, and on a setting that can override both · the storefront reads the three together
access was never the problema reader pointed at exactly the right advertising account still returns a confident wrong answer when the feed behind it consults one field
the internal figure toothe headline everyone quoted for unavailable stock was built on the same single-field assumption as the feed · not merely stale, wrong in the same way
nothing tried on the live cataloguescale came from read-only owned data, platform state from private account readers, and every change was proved against a production-shaped staging feed before the platform was asked to reprocess anything
the availability finding
built from MC ME DB VH
the complaintthe platform refused products the shop page was selling · roughly a fifth of the catalogue
the causea repair shipped three weeks earlier on the other catalogue, carried across as a lesson
the rulethe storefront reads what is on the shelf, the supplier status and the setting that overrides both · together
Judging stock on one signal alone was wrong on both feeds · and the repair that proved it was the one that had to be undone.
Both stock fields were plausible and both were incomplete.
07 · the loop closes

You decide

you, again
“Yes · restore the rule on both.”
applied · and read back
The named products moved from unavailable to available and their mismatch cleared. Every control held · including one chosen because it should not move. The social catalogue, brought onto the same rule, went from just over half serveable to about three quarters.
Nothing shipped until a staged run had named which products should move and which should not.
08 · how it ended

How it ended

how it ended

a conclusion was corrected
Revenue recovered: unknown, and not claimed.
Two things changed in the same window, so no lift is claimed either.
What is proven is a faulty rule corrected, the predicted products moved and a misleading internal measure withdrawn · not that every residual mismatch cleared.