The Slide Checker That Inspected Thumbnails Where Text Was Four Pixels Tall

The surprise we ran into

We built a gate for machine-generated slide decks. Its job was simple on paper: catch any slide that would ship with cut-off text, overflow, or overlapping elements before delivery. We thought the checks would be mechanical and reliable. Then the third checker read the system for logic and found 18 faults. That was the turning point.

What we tried and what actually broke

First attempt: run visual inspection on a thumbnail grid so reviewers can scan dozens of slides fast. It looked beautiful. An independent reviewer gave it top marks for presentation. Everything looked done.

What happened in practice was obvious once you saw it. Body text rendered at 16 pixels in full size shrank to about four pixels in the thumbnail. Cut-off lines and tiny overlaps vanished into noise. The thumbnail could not show the problem that mattered; it hid it.

We had another check that compared text read off the rendered image against a checksum. That seemed clever. In reality it was logically impossible. OCR from an image will vary. A checksum will never tolerate that variation. The check could neither meaningfully pass nor meaningfully fail. It produced noise.

We also discovered the pass receipt was embedded into the deck file after the gate had run. So the file that left our production line was not the file we validated. The gate signed a different artifact than the one we shipped. That was bad.

The third checker cataloged each failure. Eighteen concrete issues. Several were fatal to the gate’s purpose. We stopped the line, fixed them, and shipped version 1.1 that same day.

The fixes that changed everything

We replaced the thumbnail-based visual checks with full-resolution frame checks. We still keep the thumbnail grid for quick human overview, but every automated pass runs on the full-size render so text renders at real pixel heights. Once we made that switch the cut-offs showed up reliably in the automation.

We reworked the text-comparison check. Instead of image-read text versus a checksum we now compare extracted text against the original raw slide text. The comparison uses a similarity floor and a simple presence check for the first and last three words. That combination is forgiving of OCR differences while still catching missing or mangled passages.

We stopped modifying the deck file after validation. The validated build is delivered byte for byte identical to the file we checked. The receipt rides alongside as a sidecar that a third party can re-hash. That restored the chain of custody.

We closed all 18 issues the day the third checker handed them in. And then we watched the gate behave like a gate should.

The rule that came out of this

If a file is changed after the gate runs, the gate never saw the file it claims to have validated. We formalized that as policy and engineering constraints across the production line.

A representative detail (a taste)

One concrete tweak: when a slide’s body text was below the density cap we render a full-resolution image and verify the top and bottom lines’ text tokens are present in the original raw text before allowing it to pass. That single change turned intermittent false negatives into consistent true positives. The full runnable skill lives in our members’ library.

How we know

We have test decks that failed in v1.0 and passed in v1.1 only after the fixes. In one test, a three-line paragraph lost its bottom line in thumbnails but showed full damage at full size; the new check caught it every time. In another, the checksum-based text check returned inconsistent results across runs; replacing it with similarity plus first-and-last presence removed that flakiness. An independent reviewer had praised the first build for form, and the third checker’s logic review produced the exact bug list we then closed. The causal chain is traceable through the ticket history and the validated builds.

Counter-example we learned from

Appearance can deceive. The first version looked polished. It passed human glance review. Yet the system failed at its core mission. That mismatch taught us to separate human overview from machine verification: one shows; the other must prove.

Questions we got

Did the thumbnail view get removed?

No. We kept it for people to scan decks quickly. We stopped using it for any automated decision. Thumbnails are for humans only.

How do you handle OCR errors now?

We don’t rely on exact matches. We use a similarity floor plus simple checks for anchor words at the start and end of passages so small OCR variance doesn’t break validation while major omissions still fail.

Is the delivered file modified with receipts?

Not anymore. The deck file is byte-for-byte the validated build. The receipt is a separate sidecar file a reviewer can re-hash to confirm the artifact.

One-line sources: fixes and observations recorded in our production notes and the v1.1 release log.