# 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](https://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](https://id.org.ai) and the [auto.dev](https://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](/journal/scan-to-object-event/):

```json
{ "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/humans/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](/conformance/) 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 article](/epcis-who-performer-worker-agent/); 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](/journal/provision-agent-seat/) 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](https://transactions.dev), and the join is [designed into the standard itself](/business-transactions-in-epcis/): 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](/mcp/) for the agent seat ([run it yourself](/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](/get-a-key/?segment=integration). The executive telling of the same story — evidence chains, not integrations — reads at [visibility.cloud](https://visibility.cloud).

---

**Proof, not adjectives.** This build could not verify the gateway's test suite green, so no sentence on this page claims a passing run — the last verified run is recorded in the repository's own CI, not here. Live on this origin, no key: POST /translate, /validate, /hash. No conformance attestation has ever been issued. The dated ledger is /what-ships-today/.