Worked productLogistics · cargo claims

A claims desk, built the whole way down.

Not a screen. A product — its own routes, its own status values, its own data, and its own reason for looking the way it does. This is what one brief produced, and what an audit found in it.

Preview interactive design
OperatorCargo claims adjusterone desk, one queue
The clockOne yearfrom delivery, and derived
Status25 valuesacross five declared sets
DataDeliberately hostilethe week-one cases
Work queue · $902,870.00 claimed and open, 12 claims of the 19 on the deskthe screen the day starts on
The screensIn the order the work happens

Each one answers a question the last one raised.

Nineteen registered routes across five destinations, and every one of them lands. Nothing here is a dead end drawn to fill a slot in a sitemap.

02The status set →
Screen 01

The claim, and what it is actually worth

The queue promises a payable figure; this is the screen that owes an answer for it. Claimed, less depreciation and betterment, salvage and the deductible, then a hard rule at the liability cap. No other screen subtracts anything.

  • $18,600.00 claimed, $7,400.00 of defensible adjustments, $11,200.00 assessed
  • The cap is the higher of 480 packages × 666.67 SDR and 9,600 kg × 2 SDR
  • On this container the two bases are sixteen times apart
/claims/:idrecord · reconciliation
Screen 02

Evidence, and the decision it permits

Four mandatory documents and one that is only supporting, so the count reads four of four against a five-row list. Nothing is ever deleted here: a document rejected as illegible stays on the file carrying its reason.

  • Requested, received and illegible as separate states
  • One predicate gates the row button, the queue headline and the nav badge
  • The delivery receipt is quoted, exception and all — “one pallet wet, carton damage”
/claims/:id/evidencechecklist · gated
Screen 03

Three outcomes, and the letter they write

Approve in full, approve in part, or reject with a reason from the list and a justification in writing. The customer’s letter builds from the figures being typed rather than from a description of them, and nothing is recorded until it is submitted.

  • $11,200.00 payable, comfortably inside a cap of $428,802.14
  • Decide alone up to $25,000.00 — the panel names the figure and the limit
  • Past it the surface does not change; the submit reads “Send for sign-off”
/claims/:id/decisiondecision surface
Screen 04

Somebody else’s queue, seen from the side that waits

Two decisions over the adjuster’s authority are with the claims manager, longest wait first. Nothing on this screen is hers to approve, and it says so — her two actions are to chase one or to take it back.

  • $127,560.00 waiting on a signature, 11 days on the oldest
  • Each row states what it is over authority by, not just its value
  • Taking one back reopens its assessment on her own desk
/signoffqueue · read-only
StatusA closed set with defined transitions

Status is data. Overdue is not.

Every value a claim can hold, declared once and stored. Time-barred is not among them: it is computed at render from the delivery date, and the enum file lists it under the values that are deliberately absent because they are derived.

03The awkward cases →
awaiting_documentsawaiting_surveyready_for_decisionawaiting_signoffescalated_legalapproved_awaiting_paymentpaidrejected
Eight values, two of them terminal, and one tone reserved for the state where the adjuster is the one being waited on. Rejected is deliberately neutral rather than a failure — turning a claim down is a decision the desk made and can defend. The settlement, the response, the recovery and every document carry their own sets: five fields, twenty-five values.
The dataWhat a client finds in week one

The fixtures are deliberately unkind.

Demo data arranged to look good proves nothing. These are the records that break a screen, and they were in the set from the first pass.

04The audit →
Case 01A payment the bank sent back
NaivelyThe claim reverts to unpaid, or $25,600.00 quietly leaves the pipeline and the stages stop adding up to what was approved.
HereThe claim stays paid — the decision was right and the customer was told — while the settlement moves to returned and rejoins the queue to be scheduled. The failure belongs to the payment, not to the claim.
Case 02An offer below the surveyed loss
NaivelyThe $34,000.00 offered is stored as recovered, and the recovery rate improves the moment somebody makes any offer at all.
HereOffered and recovered are separate fields. The rate is money-weighted over closed files only, and the screen says so — a file still being argued has not failed yet.
Case 03A payable figure that does not exist yet
NaivelyThe column renders $0.00, or an em dash, or quietly falls back to the amount claimed.
Here“Not assessed”. A claim the desk turned down reads “Nothing payable” instead — three states, three strings, and none of them a zero.
The auditRead after generation, before handoff

Every figure, traced back.

Each aggregate matched against the array it claims to summarise. It found a recovery holding its own copy of what the claim had paid — so when a liability cap bit and the settlement fell to meet it, the two figures disagreed for a build. This file stores neither of them now.

05Back to the top →
The mirror ledger · the claim owns the first figure, this file only follows ittraced

Reckon

One brief in.
A whole product out.

This is one of several. Each has its own routes, its own status values, and its own awkward cases waiting to be found.

Built for Claude Design · plain markdown · nothing to run