Field report
When LLM Extraction Invented a Price Ladder
The short answer
What happens when a model extracts figures from a page you republish?
On 2026-07-28, the first day of OEM scraping on our car-leasing build, an extraction model read a manufacturer page carrying exactly 1 lease offer — $479 per month — and returned a fabricated ladder of $249–$399 offers. A human caught it by eye, not a gate. The verbatim-verification rule that now drops any figure absent from the source text landed one commit later, the same day [our data].
Most writing about AI extraction errors uses hypothetical examples. This is a real one from our own pipeline, with the date, the figures, and the commit that followed. It is published because the useful part is not that a model fabricated something — that is well known — but that the fabrication was more plausible than the truth, and that nothing in a well-built pipeline caught it.
What happened on the first day of OEM scraping?
An extraction model turned one offer into several. On 2026-07-28 — day 16 of our car-leasing build, and the first day of scraping manufacturer lease pages — the pipeline read an OEM page that carried exactly 1 national offer at $479 per month, and returned a ladder of offers spanning $249 to $399 per month. None of those figures appeared anywhere in the page text [our data].
The correct page was in the model's context the whole time. This was not a case of a model answering from memory with no source; it was a model looking at the right document and reporting something else.
Detection was human. Our record puts it plainly and no more precisely than that: the fake ladder was caught by eye [our data]. There was no gate that could have caught it, because the pipeline had been built to extract and store, with verification assumed to be a property of the model rather than a step in the system.
Why did the fabricated version look more normal than the truth?
Because it matched the pattern of the category. Manufacturer lease pages usually carry several offers at several price points, so a ladder of offers reads as an ordinary result and a single $479 offer reads as an incomplete scrape. A reviewer skimming for weirdness would have flagged the true output and passed the false one.
That inversion is the reason editorial review is not a control here. Plausibility is what generation optimizes for, so the failures that survive review are precisely the ones that look right. The general mechanism has its own definition at AI hallucination; what this incident adds is the operational half — retrieval put the correct source in front of the model and the model fabricated anyway, so grounding shrinks the surface without closing it.
What changed in the pipeline that day?
Verification became a gate instead of an assumption, and it shipped one commit after the scraping code, the same day [our data]. The rule is mechanical and has no editorial component: every figure headed for publication — monthly payment, due at signing, term, mileage allowance, even image URLs — must appear verbatim in the scraped page text, or the offer is dropped rather than published with a gap.
Three gates now sit between a manufacturer page and a published route, and only two of them came from incidents we can document:
| Gate | The failure it answers | Documented incident |
|---|---|---|
| Verbatim verification | Extraction returns figures that are not in the source | Yes — the $249–$399 ladder, 2026-07-28 [our data] |
| Zero-render grace window (48 hours) | A bad render empties live data | Yes — a naive replace-on-scrape emptied a brand [our data] |
| Ordered canonicalization rules | Inconsistent naming across sources resolving unpredictably | Not an incident on our record — a design rule, stated as one |
The third is named for completeness and described no further, because we have no incident report behind it and this page is a record, not a product tour.
What broke next, and what did that add?
The fix created its own failure mode. A verification gate that drops unverifiable offers produces empty results whenever a source page renders badly — and the pipeline's original write step was a naive replace: whatever the scrape returned became the stored set. On one bad render, an entire brand's offers were replaced with nothing [our data].
The answer was a 48-hour zero-result grace window: stored offers survive empty scrape results for two days before removal, so a single failed render degrades freshness instead of deleting a brand. That is the honest sequencing lesson — strict verification and zero-result handling are the same design decision, and shipping the first without the second trades a fabrication risk for a deletion risk.
What does an extraction bug have to do with AI answer engines?
Republished figures are the most quotable sentences on a page. A specific number in a specific sentence — "$479 per month, 36 months, 10,000 miles" — is exactly the kind of passage an answer engine lifts whole, and it travels without the page's caveats, its date stamp, or its correction history. A fabricated price does not stay a database defect; it becomes a claim in an answer, attributed to your brand, on a surface you cannot edit. Google's people-first guidance puts trustworthiness at the center of the questions it asks publishers to self-assess (Google, helpful content guidance), and the mechanism above is what "trustworthy" means for a pipeline that republishes numbers.
The structural response on this build is a two-layer split: perishable numbers live in the data board with verification and expiry, and the static content library never hard-codes a current offer — worked examples in the prose stay explicitly hypothetical [our data]. That keeps stale prices out of the quotable layer entirely, which is a different discipline from publishing numbers only you have and complementary to it.
What is the generalizable rule?
Install verbatim verification before the first scrape run, not after the first fabrication. Our gate exists because we ordered those two steps wrong by a single commit, and the fabrication arrived in the very first session [our data]. Three rules generalize beyond car leasing:
Verify mechanically, never editorially. A figure publishes only if its exact string exists in the source. Reviewers cannot be the control for a failure mode that produces more plausible output than the truth.
Design zero-result handling in the same commit as the verification gate. Strict verification makes empty results more likely, and empty results delete things. A grace window is not a refinement; it is the other half of the gate.
Treat every republished figure as a claim you are making. Not the source's claim — yours, on your domain, quotable by anything that reads the page. The wider claim-level discipline is in our fact-audit process, and the counts from running it across our builds are in what fact-auditing 400+ pages actually catches.
Against our own interest as a team that builds automated publishing systems: if you cannot fund the verification layer, do not automate the publishing. An unverified pipeline manufactures liabilities at machine speed, and the ones nobody catches are the plausible ones. That constraint is part of the system, not an exception to it — the full version is in our generative engine optimization guide.
Frequently asked questions
What did the model actually get wrong?
It invented the numbers. The manufacturer page carried 1 national lease offer at $479 per month; the extraction output was a ladder of offers spanning $249 to $399, none of which appeared in the page text. The source was correct and in context [our data].
How was the fabrication caught?
By eye, during review of the first scraping run on 2026-07-28. No automated rule existed that could have caught it, because the pipeline had been built to extract and store rather than to verify. That gap is the reason the incident is worth publishing [our data].
What is verbatim verification?
A mechanical rule: a figure publishes only if the exact string appears in the scraped source text. Payments, due-at-signing amounts, terms, mileage caps, even image URLs are checked, and anything failing the check drops the offer rather than the figure [our data].
Why does a zero-result grace window matter?
Because pages render inconsistently. A naive replace-on-scrape wiped a whole brand's offers when 1 render came back empty, so stored offers now survive 48 hours of empty results before removal — the failure mode a strict verification gate makes more likely, not less [our data].
What does this have to do with AI search visibility?
Republished figures are the most quotable sentences on a page. An engine that lifts a fabricated price repeats it under your brand name, on a surface you cannot edit — so verification is a visibility control, not just an editorial one.