RPOMS AI

RPOMS AI checks the cosmetic condition of a refurbished router from a photo. Someone photographs one face of the casing, and the system answers ACCEPTABLE, NOT ACCEPTABLE or UNCLEAR, with a short explanation, against the programme's written acceptance criteria. An admin area, not linked from the public page, covers inspections and reviews, the reference set, model configuration and lifecycle, settings and an audit log.

It belongs to the RPOMS ecosystem but shares nothing with RPOMS: its own repository, its own database and its own deployment. I built it alone, from the design of the decision pipeline to the evaluation and the inference setup.

The programme's cosmetic acceptance criteria exist only as thirteen annotated example photos in a spreadsheet, each with a note and a yes or no. The notes use words like long, multiple, minimal and small, with no numbers behind them.

Handing that to a vision model and asking whether a router passes would produce confident verdicts with nothing traceable behind them. The goal was a decision that can be explained, reproduced and audited, and that says Unclear rather than guessing.

One pipeline function is shared by the public check and the evaluation runs. First a quality gate, with no model involved, rejects a photo that is too small, blurred, dark, over-exposed, full of glare, or where no router or no plain surface is visible. Then the vision model reports observations only: the kind of mark, how many, how large and how visible. Its output contract has no verdict field.

A deterministic rule engine applies ERTH's categories to those observations, and every decision records the rule version it was made under. Finally a qualification gate compares the verdict with what the active model has proved on the reference set: a model may accept only if it made no false accepts and at least two correct accepts there. Anything it has not earned becomes UNCLEAR, which the public sees as a request to check manually.

The thirteen references are pinned by hash and protected by database triggers that refuse updates and deletes. Because their original images carry drawn annotations, annotation-free copies are derived for evaluation, also hash-pinned.

The application runs on Vercel; the model does not. Inference runs on local hardware through Ollama, behind a small gateway that checks a token, reached through a Cloudflare tunnel. The model is Qwen2.5-VL 7B, open-weight and Apache-2.0 licensed, so the inspection itself costs nothing.

The cost that replaced money was time. On the CPU a new photo took 119 seconds. Enabling the integrated GPU through Vulkan brought the median to 41 seconds (38 to 82), and capping the image the model sees at 896 pixels, the scale it was evaluated at, kept a full-size phone photo inside the 60-second function limit.

On the thirteen references with annotations removed, the model's raw observations run through the rules give 3 correct, 6 false accepts, 1 false reject and 3 unclear. That is not good enough to accept a unit, and the system says so rather than hiding it.

Under the qualification gate, the latest run (22 September 2026) gives 2 correct rejections, 0 wrong verdicts and 11 Unclear. Removing the gate would have turned six damaged routers into passes to gain one correct acceptance. Four degraded control photos (glare, blur, a very dark frame and a blank frame) were all stopped by the quality gate before reaching the model.

The public check needs no account. It accepts JPEG or PNG only, checked by magic bytes, up to 4 MB, from the same origin, with burst and hourly rate limits keyed by an HMAC of the address. The browser downscales and re-encodes each photo before upload, which strips EXIF and location data.

Photos are stored in PostgreSQL and served only through an admin-guarded route. Admins sign in with a scrypt-hashed password or Google on an allow-list; sessions are HMAC-signed, HttpOnly cookies that expire after twelve hours, the role is re-read on every request, and an unauthorised request gets a 404. Row Level Security is enabled on every table.

247 automated tests with Vitest across 16 files, using PGlite, PostgreSQL compiled to WebAssembly, so the schema, triggers and queries are tested without a database server. Two further tests call a live model and skip themselves when no model endpoint is configured.