Building Monitor Supply

01 / Why this exists

Monitor specs are messy.

Phone buyers can open a site like GSMArena and compare two devices row by row. Monitor buyers get a different experience. One brand says "Nano IPS Black." Another says "Fast IPS." A third puts the useful numbers in a PDF. Product names are long, refresh rates may change with resolution, and yesterday's monitor quietly vanishes from the current catalog.

Monitor Supply is our attempt to make that mess boring in the best possible way: one durable catalog, one normalized schema, and enough source transparency that a buyer can see where a fact came from. It complements lab reviewers such as RTINGS. They can measure a smaller number of displays deeply; we can map the market broadly and give every model the same basic language.

03 / Two real pipelines

How two brands get imported.

A brand catalog tells us which products exist. A product page tells us what each one can do. Sometimes a PDF has the details the page forgot. The pipeline joins those sources into one record and keeps a link to the evidence.

05 / The spec checklist

What we need before publishing.

We grouped the schema by consequence, not by how impressive a field sounds. P0 is the minimum needed to identify and compare a monitor without misleading anyone. P1 covers the questions buyers ask most often. P2 makes deeper side-by-side comparison possible.

Release year sits outside these coverage scores. Brands often omit it, so it is best effort: an official announcement is ideal, and a focused web search can locate one. Missing release year alone never holds a monitor back.

07 / Running it again

Only fetch what changed.

Every pipeline is designed to be incremental and idempotent. It stores stable product identity, source hashes, first-seen and last-seen times, and the last verification date. An incremental run fetches detail only for products that are new, changed, stale, or already waiting for review.

Disappearance is handled just as carefully. A monitor is marked deprecated only after a complete, authoritative, healthy catalog run omits it. Failed requests and suspicious count drops cannot erase products or change lifecycle state. We keep old pages because discontinued monitors do not stop existing the day a brand removes a listing.

09 / Daily refresh

A Mac mini runs the checks.

The operating model is simple: Codex scheduled tasks on a Mac mini invoke each brand's deterministic incremental command. Normal runs finish without AI judgment. When a run produces a small evidence queue, Codex can investigate those specific items and submit structured proposals. Humans see the exceptions, not hundreds of unchanged products.

11 / Token spend

Use AI for the hard parts.

This build crossed several Codex model generations. The development record includes GPT-5.5 and later variants internally labelled Terra and Sol. The newer reasoning-heavy sessions did much of the modern pipeline work: endpoint research, parser design, source recovery, and the argument about exactly what "smart monitor" should mean.

We are deliberately not printing a made-up percentage chart from memory. Exact model shares and token totals should come from exported Codex usage telemetry. The durable lesson is clearer anyway: the expensive reasoning is concentrated in discovering a source and handling exceptions; unchanged daily checks should not require a fresh grand investigation.