AIRANKS — The Authoritative Rankings for AI Web Content

AIRANKS measures AI visibility: we ask AI models real product and service questions, capture the complete answers as immutable observations, and publish what they contain — which brands were mentioned, which domains were cited, and which exact pages were linked. Every domain gets an AIR score from 1–10 (a decile of visibility in the active dataset; 0 means insufficient data), with the methodology in the open.

Skip to main content

AIRVER. FIGHTING — 2026

Artificial Intelligence Rankings

the ledger notes

The brake that read zero, and the data that lied three layers deep

Build LogAugust 15, 2026 by Jeremy Schoemaker

This afternoon an automated log sweep emailed a finding: recurring slow-query storms on the production database, hourly, worsening — 74s, then 97s, then 100s peaks on the same three-table aggregate. Not an outage. No errors. Just a query getting slower on a schedule.

Pulling that thread unraveled three separate defects stacked on top of each other, each one hiding the next. The order of discovery matters, because every fix exposed the layer below.

Layer one: the timeout that was hiding everything

The hourly domain-scoring job had been timing out for hours — sized at 240 seconds against a citation table that had grown past 1.6 million rows. The morning fix was obvious: measure a real run (585s), set the timeout above it, done. Scores computed again. Everyone clapped.

Except the timeout had been acting as an accidental circuit breaker. For as long as the job died early, it never reached its write phase. The moment it could finish, it started writing — and what it wrote was wrong.

Layer two: the filesort that shredded the results

Another instance of this same agent — a log-responder that reads the alert inbox — ran the EXPLAIN the first fix skipped. The aggregate filtered on one column (host, two thousand values) while grouping by another (bare_host). One table gets one index: the optimizer served the filter and left the GROUP BY to a filesort.

The filesort wasn't just slow. On this engine, at this scale, it returned corrupted group keys — 33 mangled groups where 1,519 real ones existed. The hourly job took those 33 garbage keys, matched them against nothing, and wrote zeros into the phrase and brand counts of every tracked domain. The public API served those zeros. A cheap first-principles check (count one domain's citations directly, no GROUP BY) confirmed it: helixsleep.com had 79 phrases and 22 brands in the raw data, and 0/0 in the serving table.

Filtering on the same column the query groups by — the responder's one-line suggestion — dropped the chunk time from 47.7 seconds to 2.0 and returned clean keys. A fresh run healed every count. The equivalence check that "proved" old-matches-new was meaningless, because the baseline itself was corrupt; only direct per-host counts settled it.

Layer three: the question mark nobody cut

Why did some group keys look like asana.com?utm_source=chatgpt.com? Because they were. The host column is computed from the citation URL by cutting at the first slash — and a URL with a query string but no path has no slash. Every such citation minted a fake host, and the hourly job's upsert dutifully turned 128 of them into real rows in the domains table: 512 garbage domains over time, 39 of them publicly ranked, one empty-string host quietly accumulating 28,071 occurrences.

The column is virtual, so fixing the expression (cut at /, ?, and #) healed all 609 polluted source rows instantly — and handed asana.com the 11,282 citations that had been credited to its query-string doppelgänger. The garbage rows are purged (backed up first), and a CHECK constraint now makes the domains table reject non-hostname bytes at the storage layer — the same backstop pattern that already guards against www. prefixes, for the same reason: the write path that leaks is upsert, and upsert bypasses every app-level guard.

What this day actually taught

A brake that reads the wrong gauge doesn't fail — it succeeds at nothing, forever, silently. This was the day's recurring shape: a spend gate that read $0.00 against a counter holding $5.81 (wrong key prefix), a timeout that masked a corrupt write phase, an equivalence proof measured against a corrupted baseline. None of them errored. All of them were found the same way: by putting the real number next to the derived one and refusing to look away when they disagreed.

And the diagnosis that broke it open came from a second instance of the same agent, reading an inbox, running the EXPLAIN, and mailing its findings with the parts it couldn't prove clearly labeled. The main session took the candidate, proved the equivalence properly, found the two layers underneath, and shipped all three fixes inside two hours. The machines are starting to peer-review each other. The data is better for it.

← Back to blog