One VIN, four layers.

31 July 2026 · the launch journal

Vehicle transport is the cleanest possible demonstration of what this family of properties is, because one move touches every layer in sequence and each hand-off between layers is a checkable artifact, not a diagram arrow. A car gets scanned, moved, delivered, and paid for — and the practice that resells this story to its clients gets to show each step as output, not as promise. Here is the move, layer by layer.

Layer one: the scan becomes an identity — barcoding.dev

The driver scans the door-jamb plate: Code 39, star-framed as the symbology transmits it.

*1HGCM82633A004352*

The resolver's pipeline is exact: strip the *…* framing; reject the characters VIN grammar forbids (I, O, Q); validate the ISO 3779 check digit — position 9, computed over transliterated characters and positional weights. Failures are typed (length | charset | checkdigit), and a check-digit failure names the exact character position 9 should carry — resolver-grade errors, because a mis-keyed VIN caught at the scan costs nothing and a mis-keyed VIN in a title chain costs a season.

The validated VIN resolves on the Digital Link grammar — the same resolution shape as every GS1 scheme at barcoding.dev, applied to the non-GS1 scheme cars actually wear. One law governs it: serve, never home. NHTSA and the OEMs home VIN allocation; the resolver serves resolution. The VIN is the sameAs alias of a vehicle identity homed with id.org.ai and the auto.dev data plane behind it — the scan points at the record; it never mints a competitor to it. What comes back is the identity plus a linkset: history, recall status, valuation, logistics — each link carrying posted context or absent, never a brochure.

Layer two: custody becomes events — epcis.dev

Pickup. The driver photographs the car at the origin dealership; the app constructs the custody event the same way every scan becomes an event:

{ "type": "ObjectEvent",
  "eventTime": "2026-07-31T09:12:00.000Z",
  "eventTimeZoneOffset": "-05:00",
  "epcList": ["https://vin.company/1HGCM82633A004352#vehicle"],
  "action": "OBSERVE",
  "bizStep": "departing",
  "disposition": "in_transit",
  "readPoint": { "id": "urn:epc:id:sgln:0614141.00201.LOT-A" },
  "spine:who": "https://id.org.ai/human/driver-m-alvarez",
  "spine:evidence": [
    { "kind": "photo", "sha256": "e3b1c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" }
  ] }

Delivery is the mirror event — arriving, the destination readPoint, four more photo hashes — and both validate against the pinned official schema before leaving the phone, extensions projecting away cleanly (the conformance page holds the pins; npx epcis.dev validate --project holds the law, locally, today).

Look at the grain, because this is where disputes are won and lost. spine:who is the driver — the attested observer who stood in the lot and took the photos. spine:capturedBy is stamped by the door from the capture key: the carrier's account — the warrantor under whose authority the record entered the store. A driver observing under an account they do not own is not an edge case; it is the entire car-hauling industry, where the person at the vehicle works for a carrier working for a broker. Collapse the two fields and you have destroyed exactly the evidence the damage claim needs: who saw the car clean versus who stands behind the record saying so. The full argument is the performer pillar; the mandate ceremony by which the carrier deputizes the driver's app — bounded scope, expiry, a grant chain the record resolves through — is the deputization entry in this journal.

Each event's identity is its CBV 2.0 §8.9 content hash — computable by anyone from the event itself, which is the property layer three spends.

Layer three: money reads the record — transactions.dev

The move was booked against a transport order; the buyer's funds sit in escrow. The release condition is not a phone call, a portal click, or a PDF — it is a reference to the record:

EscrowReleased {
  transportOrder: "ord_7c31…",
  trigger: "delivery-confirmed",
  epcisEvent: "ni:///sha-256;9d4e1e23bd5b727046a9e3b4b7db57bd8d6ee684…?ver=CBV2.0"
}

The ledger entry names the delivery event by hash. Anyone auditing the payout recomputes the hash from the delivery event and checks the chain: scan → identity → custody → release, every link content-addressed. The document layer this rides on — orders, despatch context, settlement — is transactions.dev, and the join is designed into the standard itself: the transport order rides the event's bizTransactionList, so the money system and the custody system cite each other by identifiers, not by integration folklore.

Title transfer follows the same discipline: a ledger record referencing custody facts, not restating them.

Why one vendor per layer cannot tell this story

State it without adjectives. A barcode vendor stops at the decoded string; it has no custody record for the escrow to read. An EPCIS repository without performer grain records that the carrier's account captured both photos — which is the question in a damage dispute, unanswered. A payments platform without a content-addressed event record releases escrow on a webhook whose payload nobody can recompute. Each single-layer product terminates at exactly the boundary where the next question lives. The layering here is a mechanism: identity from the scan, evidence from the events, settlement from the evidence — each layer consuming the previous one's checkable output.

For the practice lead: this is the demo you run for a dealer group or a fleet client with their own VIN, on a phone, and every intermediate artifact survives scrutiny afterward — the typed VIN validation, the validated events, the hashes the release cites. The layers you can run locally today ship in the package: npx epcis.dev validate, hash, capture, and the MCP door for the agent seat (run it yourself).

To put a transport lane, a dealer intake, or a fleet's custody chain on the hosted spine — scan front-end, scoped capture keys, the ledger join — say what you will capture. The executive telling of the same story — evidence chains, not integrations — reads at visibility.cloud.