How we keep the brief honest.

When the model reads an operator’s promo page, it returns a confidence score along with the data. If anything looks unclear — wagering rules half-stated, two bonus amounts that don’t match, a page hidden behind a login — the page is held back. It doesn’t reach the brief.

Held pages go to a private review queue. The editor reviews them by hand, keeps the data, fixes a specific number, or discards the page entirely. Every decision is logged with both the original and the corrected version.

Two places this matters most. The first time we ever read a casino, there’s no history to compare against — a human checks once before that operator’s first numbers ship. And when the model raises a fresh flag on a recurring operator, the new data sits in the queue rather than overwriting yesterday’s known-good values.

The model is allowed to say “I’m not sure.”

Casino promo pages aren’t built for outsiders. They detect bots, block out-of-region traffic, hide bonus terms behind cookie banners, and sometimes show the offer as a banner image with no readable text at all. Every one of those is a way to get the wrong data.

We read each page in three steps.

First, a plain web request — fast and quiet when it works. If the page comes back too short or hides behind a cookie wall, a real browser takes over. It identifies as Dutch in the Netherlands, Italian in Italy, Swedish in Sweden, and so on. It dismisses the cookie banner. It clicks open the T&C accordions so the wagering rules end up in what the model reads.

If the page is still nothing — bonus terms baked into an image, say — we take a screenshot and let a vision model read it. That’s how we recover offers from operators who only ship them as banner art.

The country part is non-negotiable. Before we touch a Dutch casino, our traffic routes through a Dutch IP. We verify the geolocation before any fetch runs. If the country can’t be confirmed, the scrape doesn’t happen — we’d rather have no data than data from the wrong place.

A change in the data isn’t automatically a story. Before anything reaches the brief, it passes through a list of refusal rules.

The list grew from the mistakes we’ve already made. Made-up numbers that don’t appear on the page. Two ways of saying the same offer where the model has chosen different phrasing today than yesterday. A “no wagering” note that turned into a wagering value overnight. A pound-quoted page that somehow returned euros. A field that gained a value not because the operator changed, but because we improved the prompt and started catching it.

Each rule has a name. When a story doesn’t ship, we know which rule kept it out. When a rule fires too often, we read its log and either tighten the prompt or loosen the rule. The judge isn’t a black box. It’s a list of failure modes we’ve already seen and chosen to refuse.

Six numbers from every welcome-bonus reading get checked twice before they reach the brief: the wagering multiplier, the minimum deposit, the free-spin count, the welcome percentage, the maximum bonus, and the maximum bet allowed during wagering.

The check is a second LLM read of the same page, asked one narrow question: what are these six numbers? If you can’t see one on the page, return null.

When the two reads agree, the number ships. When they disagree, we drop the disputed field and log the disagreement. By the time a number lands in the brief, two independent reads have produced the same answer. We’d rather have a hole than a number we can’t trust.

Two specific shapes look like news but aren’t.

The first is a flip-flop. When today’s reading matches a value we already had a few days ago, what looks like a change between yesterday and today is almost always the model picking differently from the same page — option A on Monday, B on Tuesday, A again on Wednesday. Real operator changes don’t oscillate. We compare every new value against the operator’s last seven days; if we’ve already seen it, we drop the change.

The second is our own cleanup. Sometimes a secondary URL we were scraping turns out to point at an old promo page from years ago, and we have to remove it. The next morning’s data makes the operator look like they cut their bonus by 99%. They didn’t — we did. The rule recognises the shape: a secondary URL that used to return data, now intentionally cleared. The change is our cleanup, not their news.

Six of our markets price their bonuses in something other than euros — Danish kroner, Swedish kronor, pounds, Canadian dollars, US dollars, Norwegian kroner. We convert everything to euros so the brief reads in one currency. The trouble is, exchange rates move daily.

Read the data the obvious way and you get a phantom story every morning. “100% up to €134” becomes “100% up to €134.05” when the krone wobbles by a basis point. The operator did nothing. The rate did.

So every snapshot now records the rate it used. When we compare yesterday and today, we don’t compare the euro figures directly. We undo the conversion on both sides and check the kroner instead. 1,000 kroner yesterday, 1,000 kroner today — no story, regardless of where the rate sat. 1,000 becomes 1,500 — that’s a real change, and it shows up either way.

Every snapshot we save also records how we got there. Which URLs we fetched, how we fetched them, whether the secondary URL came through, which exchange rate we used, what the second LLM check returned, which prompt version we ran, and how many T&C accordions we clicked open before reading.

If a number ever looks wrong, that record tells us where it came from. The page changed. The model drifted. The secondary URL started returning something different. We touched the pipeline ourselves. Whichever it was, we can reconstruct what we said and why.