blog · 2026-07-31 · written for: VC-7 — the Director of Solutions / Client Onboarding at a 3PL, where traceability clauses win competitive bids

A vehicle crosses the country: the full-family trace

One thesis: a single VIN, followed from a door-jamb scan to a released escrow payment, exercises every layer of the family — identity, events with an attested performer, transactions joined to custody — and vehicle logistics is where all three run against rails that already exist in production.

This is written for the seat that answers traceability clauses in bids for a living. Your willingness-to-pay logic is the most favourable in logistics: capability here is not cost avoided, it is revenue won — the clause you can answer hard that your competitor answers softly. Vehicle transport is worth your ten minutes even if you never move a car, because it is the cleanest end-to-end illustration of what a custody record with a performer looks like — and every element below generalizes to any high-value serialized unit you carry.

Step one: the scan is the identity layer

A carrier driver at pickup scans the door-jamb plate — Code 39, framed *…*, seventeen characters. The identity layer's work is pure and local: strip the framing, reject the I/O/Q charset violations, verify the ISO 3779 / 49 CFR 565.15 check digit with a typed failure surface (length | charset | checkdigit, with the exact expected position-9 character when it fails), and resolve. The decode rail behind it — auto.dev's production VIN API — returns the vehicle's build attributes, each one carried in the family's evidence grammar: value, source, timestamp. Not a directory listing; a record with receipts. The vehicle's identity is homed where it belongs — the government and the OEMs allocate VINs; the resolver serves resolution — and the linkset that comes back routes to every door the vehicle has: history, recalls, the original window sticker, valuation, transport, purchase.

That is the whole identity layer, and it runs today. What the scan starts is the interesting part.

Step two: custody events, with the grain done right

The move gets booked. From that moment, custody is event-sourced: an event at pickup, photo-documented and timestamped; an event at delivery, the same. The load-bearing design decision is the one incumbent systems get wrong — the two grains of the Who:

  • who is the attested observer: the carrier driver who stood at the vehicle, took the pickup photos, and performed the handover. A human, this time. On other legs it is an agent, or an embodied one.
  • capturedBy is the warrantor account: the carrier or broker whose account posted the event. The driver observes under an account the driver does not own.

Collapse those two and you destroy exactly the evidence a custody record exists to carry. Keep them separate and the record can answer the dispute questions that decide claims: who accepted the vehicle in what condition, under whose authority. Organisation grain — which legal entity was the carrier that week — is derived at read time from grant chains, never stamped onto the event, which is what keeps the record intact through carrier re-brokering and reorganisation. And the human appears at exactly the load-bearing steps: pickup signature, delivery acceptance, damage acknowledgment — a typed handoff, not a person haunting every API call. The observer vocabulary is id.org.ai's: Agent. Human. Thing.

Step three: the money joins the custody spine

The transaction layer reads the same event stream — one correlation spine, three layers deep. The booking writes a transaction reference; escrow funds against it; and the escrow release is triggered by the delivery-confirmed custody event. Not by an emailed PDF, not by a phone call — by the same attested, hash-identified event that recorded the physical handover, with the delivery photos and the accepting signature hanging off it. Title transfer follows on the same spine.

Read that as an RFP responder: the party paying for the move holds the record of the move — price, carrier, custody, condition — as one chain in which each link is a validated event with a named performer. When a shipper's clause asks "describe your chain-of-custody capability," the difference between a soft answer and a hard one is whether the record can be produced without joining anyone's network to read it, and whether it says who.

What this generalizes to

Nothing above is vehicle-specific except the scheme. Swap the VIN for an SGTIN on a pallet of pharmaceuticals, a serialized server rack, an aircraft part with an ILS tag — the shape holds: scan resolves identity locally; custody events carry an attested who distinct from capturedBy; the commercial settlement joins the custody spine by reference. Vehicles earn the flagship slot for one reason: the enrichment and decode rails already run in production, so the whole chain can be walked with real payloads rather than mockups. Where the observer is not human at all — the scan tunnel, the autonomous yard tractor — the same envelope carries it, which is the next post's subject.

Where to take this

If custody evidence is a line in your next tender, the worked chain above is the capability description to measure vendors against — including us. The full chain is a gated build: the identity layer's verbs run locally today, the vehicle enrichment rail is live at auto.dev, and the custody-and-settlement chain is the part we build with the operators it fits. Tell us about your book of business — the survey asks what you carry, which clauses you keep meeting, and where your record goes silent today. That last question usually answers itself: it goes silent at exactly the moment someone's hands touch the freight.

Keys open the network half of the verb set. Get an API key — say what arrives at your door, and the provisioning order follows the list.

We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.