First Photo Spot Checks

The Problem Today

One person, 2,000+ photos a day, eyeballed by hand.

Every day, someone at Redline opens the day's batch of 2,000+ first photos — the lead listing photo for each used car on a dealer lot — and looks at each one to decide whether it's framed correctly. When a photo is bad, they manually compose an email to the Merchandising Specialist (MS) who shot it and that MS's Regional Manager (RM), so the car can be reshot and re-uploaded.

This is the kind of work that is both critically important and soul-crushing to do by hand. A bad lead photo is the first thing a buyer sees; it directly affects how fast a car sells. But asking a human to make the same yes/no framing judgment two thousand times before lunch guarantees three things:

The honest failure mode isn't that the reviewer is bad at it — it's that attention is finite. By photo 1,500, the bar quietly moves. Two reviewers won't reject the same set. And the reshoot email is a second manual job stacked on top of the first: find the MS, find their RM, attach the photo, describe what's wrong, hit send. That second job is exactly the part that gets dropped when the day gets busy — so bad photos stay live longer than anyone wants.

How It Works

A vision model with an explicit rubric, a confidence band that routes borderline cases to a human, and a templated reshoot email.

The core idea, in plain terms

We don't ask a model "is this a good photo?" and trust a vibe. We give it the same checklist the human uses, score each item, and combine those into an accept / reject / not-sure decision. The model never silently invents a standard — it answers a fixed rubric, and we can read its reasons.

The framing rubric

Each first photo is checked against a small, concrete set of pass/fail criteria. These are the things a Redline reviewer is actually looking for:

• Vehicle centered — the car is roughly in the middle of the frame, not shoved to one edge.
• Full vehicle in frame — no wheels, roof, or bumper cropped off.
• Correct angle — the standard 3-quarter front (front + driver side), not a flat side or rear shot.
• Not cut off / no clipping — the whole body fits with reasonable margin.
• No obstructions — no people, price boards, cones, other cars, or hoses blocking the vehicle.
• Adequate lighting — not blown out, not so dark the body color is unreadable.

This list is the spec we tune against, and it's the first thing we'll confirm with Redline so the model is scored on exactly the rules the team enforces today.

Two viable approaches — we'll start with the cheaper one to learn fast

There are two honest ways to build the scorer, and they trade off the same way:

• (A) Vision-LLM + rubric prompt (start here). A hosted vision-language model (via Amazon Bedrock) is given the photo plus the rubric and returns a structured verdict per criterion with a short reason and a confidence. Near-zero training data needed on day one, fast to stand up, easy to read why it decided what it did. Cost is per-image inference. This is how we get a working pilot in days, not months.
• (B) Fine-tuned / few-shot image classifier (graduate into this). Once we have a labeled set from Redline's accept/reject history, we train a dedicated classifier (or few-shot embed-and-compare). It's cheaper per image at 2,000/day volume, faster, and more consistent — but it only earns its keep after we've harvested labels and proven the rubric. We move criteria onto it one at a time as accuracy justifies.

The path is: ship (A) fast, use it to generate and confirm labels, then quietly swap individual checks over to (B) where it's clearly better and cheaper. Redline sees a working system the whole time.

Building the labeled set (the real asset)

Redline already has the most valuable thing for this project: a history of human decisions. Every photo previously flagged-and-reshot is a labeled "reject"; the vast majority that passed are "accepts." We pull a few thousand of each, have the current reviewer confirm a clean validation slice (a few hundred images they re-judge carefully against the rubric), and use that as ground truth. That validation set is what we measure precision and recall against — and what catches the model drifting.

The confidence band + human-in-the-loop

This is the part that decides whether MSs trust the system or learn to ignore it. The model returns a confidence; we split it into three lanes:

per-photo verdict
  ├─ HIGH-confidence PASS      → silently accept, log it
  ├─ HIGH-confidence FAIL      → queue reshoot email (MS + RM)
  └─ BORDERLINE (uncertain)    → human review queue
                                  reviewer clicks Accept / Reject
                                  → that click becomes a new training label

The whole point is that the human now only looks at the borderline few percent instead of all 2,000 — and every click they make feeds back as a fresh label. The system gets more confident over time, so the review queue shrinks. We tune the band's width to hit our error targets, not to hit a tidy number.

Precision and recall — and why precision matters more here

We will deliberately bias the system toward precision on rejects. A false reject (telling an MS to reshoot a perfectly good photo) is the expensive mistake: it wastes a field rep's drive time and, worse, teaches them the tool cries wolf. Once an MS believes that, they ignore every email — and the project is dead even if it's technically accurate.

The borderline lane is what lets us be aggressive on precision without dropping real problems on the floor — anything we're not sure about goes to a person, it doesn't get auto-rejected or auto-passed.

The reshoot notification

When a photo is a confirmed fail (auto or human), the system composes a templated email to the MS and CCs their RM. It includes the photo itself, the VIN/stock context, which rubric items failed in plain language, and concrete reshoot instructions for that specific problem (e.g. "back up ~6 feet and shoot the front-driver 3-quarter angle so the full car fits"). Generic "reshoot this" emails get ignored; specific ones get acted on.

SUBJECT: Reshoot needed — [Year Make Model] · Stock #[####] · [Dealer]

Hi [MS first name],

The first photo for this vehicle needs a reshoot before it lists well:

  • Vehicle is cut off on the right (rear bumper out of frame)
  • Angle is closer to a flat side than the standard 3-quarter front

How to fix:
  • Step back ~6 ft and frame the full car with margin on all sides
  • Stand off the front-driver corner for the 3-quarter front angle

[ photo thumbnail ]   Reshoot & re-upload when you're next on the lot.

— Redline Merchandising QA (automated)   ·   RM: [RM name] cc'd

Architecture & Stack

Event-driven on AWS. New photo lands → screen it → route it → notify. No standing servers to babysit.

Data flow

[ Photo source ]  (DAM / S3 bucket / pipeline API — TBC w/ Redline)
       │  new first-photo event
       ▼
[ EventBridge ] ──► [ Lambda: ingest ]  pull image + VIN/stock + MS/RM mapping
       │
       ▼
[ Lambda/Batch: score ] ──► [ Bedrock vision-LLM + rubric ]
       │                          returns per-criterion verdict + confidence
       ▼
  ┌──────── confidence router ────────┐
  │ PASS (high)   → log to DynamoDB    │
  │ FAIL (high)   → SES reshoot email  │──► MS + RM
  │ BORDERLINE    → SQS review queue   │──► human dashboard → click = new label
  └────────────────────────────────────┘
       │
       ▼
[ DynamoDB log ] ──► [ Dashboard: daily ops + accuracy ]
                     [ labeled-data store → future fine-tune ]

Why this shape

It's event-driven and serverless, so it costs almost nothing when idle and scales to a daily spike of 2,000+ without provisioning. The backfill path (AWS Batch) is a one-time job that scores the historical photo set to build the validation/label set. The steady-state path (Lambda) handles each new photo as it arrives. The dashboard is a static front-end reading DynamoDB through a thin API — nothing exotic to run.

Build Plan

Phased so Redline sees a working screener fast, then we tune accuracy and close the loop. AI-assisted dev makes this genuinely quick — the gating item is photo-source access, not code.

Data & Access Needed

Almost all the risk-to-schedule is here, not in the build. The single most important item is read access to the photos.

Risks & Open Questions

The build is low-risk. The two things that can hurt us are model accuracy and getting clean access to the photos.

Cost to Own

Build is cheap and fast. The ongoing story is model-inference cost and a little accuracy tuning — not server maintenance.

The honest version: the cost to own this is not engineering hours after launch — there's very little to maintain. The two things that need ongoing attention are:

• Accuracy tuning. Periodically re-check precision/recall against the validation set, fold in the human-reviewer labels, and adjust the confidence band. This is light, occasional work — measured in hours per month, not a standing role — but it's the work that keeps MSs trusting the emails.
• Image-access integration. If Redline's photo source changes (new vendor, new pipeline), the ingest connector needs updating. This is the same dependency that gates the build, just over the system's lifetime.