Before/after rental inspection delta

A single damage check answers: "what damage does this photo show?". That's enough for one-shot intake — but for loans, rentals, test drives and press fleets, the real question is:

"What damage is new since this vehicle left our lot?"

Verdict Capture answers it with two inspection links for the same vehicle — a Delivery at handover and a Pickup at return — tied together by your reference_id. When the Pickup is submitted, it is compared with the Delivery view by view, and the result comes back on the inspection, in the inspection.submitted webhook, and in the PDF condition report.

The two-inspection flow

plaintext

  ┌─ Delivery ────────────────────┐        ┌─ Pickup ──────────────────────┐
  │ POST /api/v1/inspection-      │        │ POST /api/v1/inspection-      │
  │   sessions                    │        │   sessions                    │
  │ template: vehicle_handoff     │        │ template: vehicle_handoff     │
  │ stage: delivery               │        │ stage: pickup                 │
  │ reference_id: LOAN-48213      │        │ reference_id: LOAN-48213      │
  └───────────────┬───────────────┘        └───────────────┬───────────────┘
                  │ submitted                              │ submitted
                  ▼                                        ▼
           7 views + odometer  ───── paired by view ────►  compare
                                                           │
                                                           ▼
                        comparison: new damage per view, distance driven,
                        fuel change → outcome, PDF, inspection.submitted

Both inspections are ordinary inspection links. Nothing extra is needed to pair them beyond:

the same reference_id on both, and
stage: "delivery" on the first and stage: "pickup" on the second.

A pickup without a reference_id is rejected when you create it.

How the comparison works

When a Pickup is submitted, we look for the most recent submitted Delivery inspection on your account with the same reference_id. Then:

Pair the views. Each exterior and cabin view captured at both stages is paired by its slot — front with front, cabin_rear with cabin_rear. Damage close-ups are evidence on their own and are not paired, and the odometer view is read rather than compared.
Compare each pair as a pair. The Delivery photo and the Pickup photo of the same view are analyzed together, and only damage that is visible at Pickup and was not visible at Delivery is reported: new scratches, dents, chips, cracks, broken or missing parts, glass damage, and in the cabin new stains, tears, burns or items left behind.
Read the odometer and fuel. The Delivery and Pickup readings come from each inspection's odometer photo, and the distance driven is the difference.

Why pairs, not two lists

Comparing two independent damage lists — matching a box on one photo to a box on the other — breaks down as soon as the framing changes, and between a delivery and a pickup it always does: a different person, distance and angle. Looking at both photos of the same view together avoids that. The comparison is instructed to:

treat damage already visible at Delivery as not new, even when angle or lighting makes it look different;
ignore dirt, water, reflections, shadows, lighting, framing and camera angle;
not report damage as new on a part of the vehicle the Delivery photo doesn't show, and say so in notes instead;
mark a pair comparable: false when the two photos don't show the same view well enough to compare.

The result

The Pickup inspection's comparison:

json

{
  "status": "complete",
  "baseline_inspection_id": "6a1f3c52-8d0e-4b7a-9f21-3c5d7e9a0b14",
  "baseline_submitted_at": "2026-10-01T14:03:55.000Z",
  "views": [
    {
      "slot": "front",
      "label": "Front of vehicle",
      "baseline_verification_id": "ver_0Qw1...",
      "verification_id": "ver_7Kq2...",
      "comparable": true,
      "new_damage": [],
      "notes": "No change."
    },
    {
      "slot": "rear",
      "label": "Rear of vehicle",
      "baseline_verification_id": "ver_1Ab3...",
      "verification_id": "ver_9Tz4...",
      "comparable": true,
      "new_damage": [
        {
          "description": "Scratch about 4 inches long",
          "location": "rear bumper, left of the plate",
          "severity": "minor"
        }
      ],
      "notes": "New scratch on the rear bumper."
    },
    {
      "slot": "cabin_rear",
      "label": "Rear cabin",
      "baseline_verification_id": "ver_5Cd6...",
      "verification_id": "ver_8Ef9...",
      "comparable": false,
      "new_damage": [],
      "notes": "The pickup photo shows the front seats, not the rear cabin."
    }
  ],
  "new_damage_count": 1,
  "odometer": { "baseline": 18354, "current": 18766, "unit": "mi", "distance": 412 },
  "fuel": { "baseline": "3/4", "current": "1/2" },
  "computed_at": "2026-10-08T15:01:09.000Z"
}

Field	Notes
`status`	`pending` while it runs, then `complete`, `no_baseline` (no submitted Delivery with that `reference_id`), or `failed`. Only `complete` carries the fields below.
`baseline_inspection_id`	The Delivery inspection compared against.
`views[].new_damage`	Up to 10 items per view: `description`, `location`, and `severity` (`minor`, `moderate`, `severe`).
`views[].comparable`	`false` when the two photos couldn't be matched; that view's `new_damage` is empty.
`views[].error`	Present when that view couldn't be compared automatically (for example, a photo couldn't be loaded).
`new_damage_count`	Total new items across all views.
`odometer`	Delivery (`baseline`) and Pickup (`current`) readings, `unit`, and `distance` (Pickup minus Delivery). `null` fields when a reading is missing.
`fuel`	Fuel or charge level at Delivery and Pickup, as shown on the gauge.

Effect on the outcome

The Pickup's outcome becomes review, with a reason in outcome_reasons, when:

any view has new damage — "New damage since delivery: 1 item (Rear of vehicle)", or
any view is comparable: false — "Could not match to the delivery photo: Rear cabin".

Its review.status is then pending until someone records a decision with POST /api/v1/inspection-sessions/{id}/review or in the dashboard. The PDF condition report adds a Changes since delivery section with each view's result, the new items, Delivery and Pickup photos side by side for views with new damage, and the odometer and fuel change.

Practical rules

Submit the Delivery before the Pickup. The comparison looks for a submitted Delivery at the moment the Pickup is submitted. If there isn't one, status is no_baseline.
Use the same views at both stages. Views pair by slot, so use the same template (or the same required_shots) for Delivery and Pickup. A view captured at only one stage isn't compared.
One Delivery per reference. If you create several Delivery inspections for one reference_id, the most recently submitted one is the baseline.
Check comparison.status before you treat a pickup as clear. A failed or no_baseline comparison leaves the outcome based on the Pickup photos alone. A view with error set wasn't compared and doesn't count toward new_damage_count.

Honest limitations

New damage is a finding, not a verdict. It is an automated comparison of two photos. Have a person confirm it — that's what the review outcome and the review decision are for — before you bill anyone for it.
Only what both photos show. Damage on a part of the vehicle outside the Delivery photo isn't attributed to the loan period. Close-ups at Pickup are documented but not compared.
Per-view, not per-panel. Each new item carries a plain-language location, not a panel id or a bounding box. For per-panel damage on a single photo, see Detecting and grading damage.

What's next

Sending an inspection link — create the Delivery and Pickup inspections and read the result.
Generating PDF condition reports — the report that includes the changes since delivery.
Detecting and grading damage — the per-photo damage check behind each view.

What do you need to verify?