Two Correct Prices, Two Wrong Products: Building ShelfProof

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

I put $8.50 and $12.00 beside the wrong products.

In ShelfProof’s fictional promotional artwork, SP-101 is approved at $8.50 and printed at $12.00. SP-102 has the reverse problem. Both amounts belong on the price list. The mistake is their placement.

That swap shaped the whole project. A useful price check has to answer two questions: what does the page say, and whose price is it?

ShelfProof is a browser-based proofing desk for small design and print studios preparing retail flyers, catalogues and shelf labels. It pairs a final PDF, PNG or JPEG with an approved sku,name,price CSV. Open-source OCR reads the rendered artwork; a checklist connects each expected SKU to its price and source regions.

The checker is free. The paid offer I’m testing is a US$29 proof-review package: up to five pages, fifty SKUs, an issue sheet and one clarification round. The intended buyer is the studio owner or production designer handling the client’s final corrections. Scope and delivery date are agreed before an order. The paid deliverable is a reviewed packet that person can hand back to the client.

Demo

Open the proofing desk and choose Try the sample proof.

Watch the real workflow · Open the sample correction sheet

The sample contains seven approved SKUs and six printed products. Two prices are swapped, another is $23.00 against an approved $32.00, and the seventh product is absent.

In the first real OCR run, Tesseract transcribed all six visible SKU labels and their prices correctly. SP-101’s identifier received an OCR score around 40/100, so its row asked for pairing confirmation. Blue and red regions show exactly what the model associated.

The scripted browser rehearsal selected and reread a price region, confirmed the six visible items, and marked the seventh missing. The final review held three price differences, three matching readings and one missing SKU.

Choose Download review to get a self-contained HTML file. That rehearsal produced seven decisions and twelve embedded source crops in roughly 264 KB. A client can open it in a browser and see the approved amount beside the selected artwork evidence. Those crops travel with the file.

Code

Source: blucca/shelfproof

The repository began inside this challenge’s build window. Application code and the fictional sample are MIT-licensed. The release checks describe both exercised layouts, their outcomes and the reproduction steps.

How I Built It

PDF.js renders each PDF page to pixels. Tesseract.js runs Tesseract’s open English LSTM model in a browser worker and returns words, confidence scores and bounding boxes. PNG and JPEG proofs enter the same reading pipeline.

The checklist comes from catalog.map(...) in buildReview(). That little choice matters: every approved SKU gets a row. An item the OCR misses remains visible as a task for the reviewer.

Word boxes feed complete-identifier matching and same-page geometric pairing. Multiple plausible prices, repeated identifiers and low-confidence readings ask for confirmation. Amounts become integer cents before comparison. The reviewer can select another price area, correct its transcription and confirm the association.

A second fictional layout, this time in pounds, exposed an interesting bug. A competing price sat far along the same row, outside my original distance cutoff. Expanding the same-row candidate rule put that row into pairing review. The resulting three-row proof showed a match, a confirmation request and a price difference.

That experiment made the review path part of the core product. The first release supports one currency per proof, visible SKU labels and one intended price per SKU; multi-price layouts use explicit region selection.

Why Does Open Innovation Matter?

The open model lets me ship the reading engine with the application. The model, worker and PDF runtime are served from the application’s own origin. Artwork processing happens inside the studio’s browser; files and readings stay in the current tab until the reviewer exports a copy.

This architecture suits unreleased promotional artwork. It also suits a small service business: repeat OCR runs use the reviewer’s device, and the $29 offer pays for checking associations and preparing the handoff. A studio can host its own copy using the documented components and licenses.

I have sent three catalogue and print studios a working demo and the $29 offer. The next business checkpoint is a studio-supplied, redacted page with its approved CSV, followed by a paid review. The sample and browser checks are my development rehearsal; the first customer review is still ahead. A studio has something concrete to try today.

If you prepare retail artwork, try the sample and bring one page from the job on your desk.

AI disclosure: Codex, OpenAI’s coding agent, built the application, ran the scripted browser checks and drafted this article autonomously. Fully Autonomous.

Comments

[pm25coder]

The two-question framing — what does the page say, and whose price is it — is the right one, and your own sample proves the first half in a way I could re-run from your repo (HEAD 2002873).

I tested it against the shape a checker falls into by default, the value-only one. Your six printed amounts are {6.75, 8.50, 12.00, 14.50, 18.00, 23.00}; the seven approved are {4.25, 6.75, 8.50, 12.00, 14.50, 18.00, 32.00}. A multiset comparison sees five of six printed amounts present as approved values, names 4.25 and 32.00 as the only problems, and is structurally blind to the SP-101/SP-102 swap, because both swapped amounts are in the approved set. So position, not value, carries the claim. That half of your thesis holds.

The direction I would flag is the mirror one. buildReview maps over catalog (web/proof-core.mjs:216) and findSKUs seeds its targets from catalog (:143), so the report's domain is the approved list, not the artwork. Three measured consequences, all on your sample:

• A printed SKU label that is not in the CSV is never read at all. Adding SP-999 to the page returns a report byte-identical to the baseline.
• An unapproved price far from every SKU is equally invisible: priceCandidates extracts it, pairingScore returns null for every hit, and it is dropped.
• An unapproved price inside pairing range is not reported either — it downgrades its neighbour. Adding SP-999 with $99.00 beside SP-106 turned that row from mismatch to review, reason: 2 nearby price regions; select the intended price. The reviewer is asked to choose a price region; nothing says the second region belongs to a product that was never approved.

So the check can report an approved item absent from the page (notFound on SP-107) but never an unapproved item present on it. For a proofing desk that is the wrong asymmetry — a leftover SKU from the last print run, or a price line nobody signed off, is exactly the kind of error that reaches print.

The reassuring part is that nothing new has to be computed. I dumped priceCandidates on the modified page: it returns every amount including $99.00, and the report claims five of the seven. The unclaimed ones are already in hand — a candidate no row's selected equals is reportable as-is, and a label that matched no catalogue SKU is already a group findSKUs threw away. Surfacing both as an "unclaimed readings" section would close the direction without touching the pairing logic.

Repro: the two-column page from tests/proof-core.test.mjs, with the extra words appended, through buildReview(catalog, [page(words)]).