The bill of lading went digital and brought an event model with it

Written for ED-3 — the in-house supply-chain platform team — the platform engineer who can implement a spec without asking anyone.

One thesis: ocean freight is the one transport mode whose digital rails are open standards rather than vendor networks — DCSA publishes its track-and-trace and eBL specifications as Apache-2.0 OpenAPI on GitHub — and because UN/CEFACT's multimodal track-and-trace work explicitly adopted the EPCIS event model, compiling those rails onto the record is a standards bridge, not a vendor integration.

What DCSA standardized, and what it deliberately didn't

The Digital Container Shipping Association exists to do for container carriers what nobody's commercial incentive would: publish one API shape for the industry. The specifications live at dcsaorg/DCSA-OpenAPI, Apache-2.0, with reference implementations under the same license — a platform team can read, vendor, and implement them without a single commercial conversation. Track & Trace v2.2 is the most adopted line; v3.0-Beta restructures the event model and makes push subscriptions optional rather than assumed.

What DCSA deliberately did not build is a hosted API. The standard is the interface; the data comes from carriers implementing it. That census, from our verified matrix: Hapag-Lloyd runs a self-service developer portal (api-portal.hlag.com) on DCSA T&T 2.2; Maersk offers registration plus a sandbox at developer.maersk.com; CMA CGM ships the DCSA T&T 2.2.0 specification verbatim; MSC gates access behind a request form. One adapter against the standard, N carriers behind it — the implement-once economics that only exist because the spec is open.

The three event classes, placed honestly

DCSA T&T defines three event classes: Shipment events (document and booking lifecycle), Transport events (the vessel's arrivals and departures), and Equipment events (the container's gate-in, gate-out, load, discharge). The identifiers are transport-grain and openly specified: equipmentReference (ISO 6346 container numbers), carrierBookingReference and transportDocumentReference, voyage references, and UN/LOCODE-plus-facility codes for places.

Where does that sit relative to the record's custody grain? Exactly where carrier evidence always sits — the 214's lesson, applied to containers: an equipment gate-out at a destination terminal is transport-grain evidence corroborating a delivery expectation — it names a container, not the goods, parties, or an attested receiver. The difference from the parcel rails is that DCSA's events are structured, open-vocabulary evidence with real identifiers, which makes the join mechanical: the container number and transport document reference on the event match the same references carried on the despatch-advice side of the record. Evidence still, but evidence with a spec.

The eBL, and the compile to bol

The second half of the DCSA portfolio is the electronic bill of lading: the Issuance and Surrender APIs and the PINT interoperability standard that lets eBLs move between platforms. The eBL is the canonical B/L object — and CBV 2.0 §7.3 already reserved its name: bol is a core business-transaction type, defined in the same closed vocabulary as po and desadv. The compile is one reference:

{
  "type": "ObjectEvent",
  "action": "OBSERVE",
  "bizStep": "departing",
  "disposition": "in_transit",
  "quantityList": [
    { "epcClass": "urn:epc:class:lgtin:0614141.107346.LOT2026D", "quantity": 1200, "uom": "EA" }
  ],
  "bizTransactionList": [
    { "type": "bol", "bizTransaction": "urn:epc:id:gdti:0614141.00001.MBL773100" },
    { "type": "po", "bizTransaction": "urn:epc:id:gdti:0614141.00001.PO2210" }
  ]
}

The transport document reference that DCSA's events carry is the same reference the bol entry names — so every subsequent equipment event joins the record through an identifier both sides already agreed on. Core CBV fields, validated against the pinned official EPCIS 2.0 JSON schema on the way out: superset where the eBL carries more than the standard models, and conformant always.

The sentence UN/CEFACT wrote

The deepest fact in this post is one the freight world barely advertises. UN/CEFACT's Business Requirements Specification for Integrated Track & Trace in Multi-Modal Transportation (finalized September 2022) states its lineage outright: "UN/CEFACT adopted the model of EPCIS, originally defined by GS1" — including aggregation events as waypoints. And DCSA's track-and-trace work is UN/CEFACT-aligned with a published data mapping.

Read the chain end to end: the container carriers' open standard aligns to the UN's multimodal standard, and the UN's multimodal standard adopted the event model this record speaks natively. Freight's open rails do not need to be translated into the record's grammar; they were drafted leaning on it. What remains is engineering, not ontology: DCSA does not emit EPCIS documents itself, so the compile — reference joins, UN/LOCODE to GLN bridging for facility identity via the resolution layer, evidence placement — is the transaction layer's job, which is the job this site describes end to end.

Why this lands on a platform team's desk

Because it is the rare transport integration you can scope entirely from public artifacts. The spec is on GitHub under Apache-2.0; two of the four major carriers hand out keys self-serve; the event vocabulary is enumerable before you write a line. Against the gated alternative — visibility platforms whose APIs exist only inside an enterprise contract, and whose record is authoritative only because you joined their network — the DCSA lane is the one your team can implement, verify, and hold to a spec without asking anyone. The record it feeds is verifiable without joining anything, which is the whole family's one sentence, and the import story it unlocks — paperwork and custody on one spine — is where the executive conversation starts.

Ocean legs in your flows? Tell us which carriers — the adapter's per-carrier gate table grows in the order the answers arrive.

---

872 words. The access flow is at /get-access/; the family's event door is epcis.dev.