Searching one way finds one kind of case. The layers exist so that no one kind of coverage can quietly collapse.

A query that asks only about "AI" returns opinion. The shape that works asks for all three at once: a concrete business process, a word that means the thing is actually running, and a word that implies a measured outcome. That triple is the cheapest stand-in for the call the validator will later have to make properly — between something a company announced and something a company does. Queries that drop any leg of the triple have been measured at a zero survival rate.

A fixed set of queries stops working after about three days: it keeps finding the same articles, which are by then already on record, and the run's entire output becomes duplicates. Rotation ensures the same question does not repeat for weeks. The choice comes from the date, so the same day always asks the same questions — which matters when you are trying to explain why a particular day found nothing.

Originally every query tried the tools in one fixed order, falling through on failure. The effect was that the cheapest tool answered almost everything and the strongest semantic search was never reached at all — it went weeks without being called once. Assigning each layer a primary tool forces all of them into use, and a measured comparison showed that the starved tool produced several times more surviving candidates than the chain it had been buried under.

The failure that shaped this rule was a tool hitting its weekly quota and returning that as a successful response containing zero results. Nothing crashed, nothing was logged as broken, and the day simply recorded that the world had produced no AI deployments. Empty is now treated as a failure signal in its own right, alongside rate limits, timeouts and unparseable responses. A rerun through a different tool recovered twenty candidates and a real case that would otherwise have been lost silently.

The retry budget stops at two attempts per query. Beyond that the query is abandoned and recorded as abandoned — a run that takes all day to fail is worse than one that reports a gap.

A Chinese power-grid deployment and a Japanese bank rollout are first-class cases. The source may be in any language. The output must be English, so a non-English article is translated, not discarded. A machine check enforces that, because the failure runs both ways: told "output must be English", a model starts throwing away perfectly good foreign-language sources; told "translate everything", it sometimes leaves the original text in place. Both have happened.

Most of what the web publishes about enterprise AI is a press release about intent. It shares almost every word with a real case study — the same company names, the same "AI", the same "deployed". The distinction comes down to verb tense.

"Two hundred thousand employees now have access to an AI assistant" is a real, verifiable, well-sourced fact, and it says nothing about how anyone's work changed. The bar says so explicitly: headcount announcements are not use cases and mean nothing for the atlas. The same company becomes acceptable the moment the article names a process — claims handling, document review, fraud triage — and what changed about it.

Anonymous case studies — "a leading European insurer" — are dropped entirely rather than recorded with a blank. A model will be tempted to invent a plausible name, and one fabricated company would undermine every other record in the dataset. Consortiums, alliances, initiatives and project names are likewise not companies. The atlas is a map of who is doing this, and a point on it that names nobody is worse than an empty space.

After the validator finishes, mechanical checks run over its output looking for the specific ways it is known to fail: untranslated text left in place, vendor press domains accepted as sources, announcement phrasing, roundups and listicles, missing geography. Anything they catch is moved into the rejected pile before persistence sees it. These exist because on two separate days the validator was confident and wrong — once shipping untranslated records, once shipping seventeen vendor pages. They are not optional, and they do not get skipped when the output "looks fine" — looking fine is exactly the failure mode.

If an article is already on record it is skipped — even when a reviewer read that earlier record and retired it. That is counter-intuitive but deliberate: retired means someone judged this source invalid. Re-ingesting it would overrule that decision automatically, every week, forever. Reviving a retired case is a manual act, never an automatic one.

The record keeps the deployment's full text — five hundred characters at minimum — rather than a link and a headline. Articles rot: they get retracted, paywalled, restructured, or quietly rewritten to say something softer. A case that lives only as a URL is a case that can evaporate without anyone touching the database.

It also makes a specific repair possible. When the article turns out to be poor but the deployment behind it is worth keeping, there is a set procedure: find a better source and attach it, rather than throw the case away and hope the same deployment turns up again.

A use case is not a standalone note. It carries a deployer, a place, an industry and a source, and each has to resolve to something real before the case can be written — a named organisation, coordinates that put it somewhere on the globe, an industry from the closed vocabulary. A field that does not resolve sends the case back. It is never filled with a blank.

A retired case is never revived automatically. It was retired because that article was judged bad, and nothing about a later day makes it good.

A case is written in a state that means "awaiting review". It is visible in the product, but labelled as such. That is a deliberate trade: showing it unverified is more useful than hiding it, as long as nobody can mistake it for verified. The pipeline never promotes its own work.

A malformed field is corrected and retried. A network failure is retried once. If a case still cannot be written, it is skipped and recorded as skipped, and the run continues with the rest. The stage always hands something onward, even when it wrote nothing at all — because the alternative is a day that ends in silence, and silence is the one outcome the design does not permit.

A day can produce nothing in several different ways, and each calls for a different fix. Nothing was searched means a tool is broken. Nothing survived validation means the day's questions were poorly aimed. Everything was already on record means the queries have saturated and need rotating. Collapsing all three into "no results" would throw away the only signal that says what to fix.

Because everything the pipeline records waits for review, the review queue is a real bottleneck — and one the pipeline can see but not fix. So the daily message reports the backlog and changes its tone as it grows, from a note to a warning.

The day's metrics are archived after delivery is confirmed, never before. This makes the metrics history mean something precise: every line in it is a run that finished and got reported. A run that produced cases but failed to report leaves no line. That is correct: from the reviewer's point of view that day did not happen, and the gap says so honestly.

The observations at the end of each report are written against the running record of what has and has not been working, not off the day in isolation. That shared reference is what turns a daily message into a feedback loop: patterns noticed in reports become notes, notes become retired queries and new rules, and those rules change what tomorrow's search asks.