The spec does not replace the standards each sector already runs on. It gives them one canonical home. Implementers map to and from these standards at their edges, which is how a parcel API, an airline’s ONE Record server, an ocean carrier’s DCSA endpoints and a postal operator’s EDI can describe the same consignment without losing information. The mappings below are informative. Where a standard is normative for a sector (IATA for air cargo, UPU for posts), the spec’s object carries that standard’s identifiers verbatim in identifiers or carrier_metadata, and never renames them.

​
1. Identifiers

​
2. GS1 EPCIS 2.0 (events)

EPCIS is the closest existing standard to the spec’s event model. Device and route-run events map directly: Implementers with capability interop.epcis expose GET /v1/epcis/events (EPCIS 2.0 JSON-LD) and accept POST /v1/epcis/capture, so EPCIS repositories can subscribe without custom mapping.

​
3. IATA ONE Record (air cargo)

ONE Record is IATA’s linked-data model and API for air cargo. Mapping: An airline member of a network (chapter 21) can run its ONE Record server alongside, with the implementer synchronizing through its adapter layer. Both models are object-centric and URI-addressable, which keeps the mapping lossless.

​
4. DCSA (ocean)

​
5. UPU (postal)

​
6. Trade and customs

​
7. Where the spec goes beyond the standards

Each sector standard covers its own mode. The spec adds what sits between them:
  • One identity for a consignment across modes. A shipment that flies on ONE Record, sails on DCSA and is delivered by a van fleet stays one shipment, with one tracker, one journey and one custody chain.
  • Commercial lifecycle: rating, purchase, void, settlement. Most event standards stop at movement.
  • Access by role per shipment (chapter 23), so the same record can be shared safely between parties that each use a different standard.