Standards assessment for OpenFreytProtocol
Generated from
docs/research/2026-08-31-standards-assessment.md. Edit the canonical source file, not this page.
Date: 31 August 2026
Decision: No existing logistics standard becomes the canonical protocol. OpenFreytProtocol uses a small project-owned contract built on mature internet standards.
Selection criteria
Section titled “Selection criteria”A dependency should be used only when it is:
- publicly and easily accessible;
- implementable without membership or vendor permission;
- mature enough for production use;
- supported by practical tooling;
- appropriately scoped;
- compatible with rapid additive iteration;
- independent from one TMS or marketplace vendor.
“Open” means an openly available specification and usable implementation contract, not merely an open-source SDK around a proprietary service.
Comparison
Section titled “Comparison”| Candidate | Accessibility | Maturity | Road-capacity matching fit | Iteration speed | Disposition |
|---|---|---|---|---|---|
| Project-owned JSON/OpenAPI contract | 5/5 | Built on mature primitives | 5/5 | 5/5 | Canonical |
| OASIS UBL 2.4 | 5/5 | 5/5 | 2/5 | 2/5 | Optional document adapter |
| UN/CEFACT multimodal models | 4/5 | 5/5 | 3/5 | 1/5 | Terminology/code-list reference only |
| UN/EDIFACT | 4/5 | 5/5 | 2/5 | 1/5 | Legacy TMS adapter |
| GS1 EPCIS 2.0 | 5/5 | 4/5 | 1/5 matching; 4/5 visibility | 3/5 | Optional execution-evidence adapter |
| DCSA APIs | 5/5 | 4/5 | 1/5 for road exchange | 3/5 | Borrow API/governance patterns only |
| iSHARE/BDI | Public concepts; operational adoption is complex | Mixed by component | Trust layer, not exchange semantics | 1/5 | Principles only; no pilot dependency |
| eFTI/e-CMR | Sector/regulation oriented | Evolving/segment-specific | Documents, not matching | 1–2/5 | Future compliance adapter |
| Proprietary freight exchanges | Often restricted | Vendor-specific | Often functionally strong | 2/5 | Never canonical; avoid closed dependency |
Scores are architecture judgments for this use case, not claims of general standard quality.
Candidate notes
Section titled “Candidate notes”OASIS UBL 2.4
Section titled “OASIS UBL 2.4”UBL is a mature public standard for business documents, including transport-related documents. Its breadth and document orientation create substantial mapping overhead and do not naturally represent transient capacity offers, bilateral visibility and match negotiation.
Use when: a participant already exchanges UBL documents.
Do not use for: the internal broker model or minimum integration contract.
Official specification: https://docs.oasis-open.org/ubl/UBL-2.4.html
UN/CEFACT
Section titled “UN/CEFACT”UN/CEFACT provides internationally established semantics and code lists for trade and multimodal transport. The models are broad and less convenient for a small real-time API.
Use when: selecting stable terms or UN code lists.
Do not use for: implementing the entire reference data model.
Official standards overview: https://unece.org/trade/uncefact/mainstandards
UN/EDIFACT
Section titled “UN/EDIFACT”EDIFACT has deep deployment in established logistics environments and can be required by existing TMS installations. Partner-specific message profiles and legacy tooling make it expensive as a greenfield canonical protocol.
Use when: onboarding a participant with an existing IFTMIN/IFTSTA integration.
Do not use for: native PCX clients.
GS1 EPCIS 2.0
Section titled “GS1 EPCIS 2.0”EPCIS is a ratified standard for exchanging supply-chain visibility events across enterprises. It answers what happened, where, when and to which object; it does not define offers, demand, partner negotiation or match commitment.
Use when: importing execution/visibility evidence.
Do not use for: capacity discovery and matching.
Official specification: https://ref.gs1.org/standards/epcis/
DCSA demonstrates modern API governance and event patterns but is centered on container ocean shipping. Its domain semantics should not be transplanted into road-capacity exchange.
Use when: learning from API design, versioning and conformance practices.
Do not use for: PCX domain resources.
iSHARE and BDI
Section titled “iSHARE and BDI”These initiatives address trust, authorization, data sovereignty and federated logistics data sharing rather than the business payload required for matching capacity.
Use when: evaluating later federation or regulated trust requirements.
Do not use for: blocking the initial broker or requiring consortium-wide certification.
eFTI and e-CMR
Section titled “eFTI and e-CMR”These concern regulatory freight information and transport documentation. They are adjacent to execution but not a marketplace protocol.
Use when: linking accepted execution to compliant documents.
Do not use for: publishing and matching capacity.
Selected mature primitives
Section titled “Selected mature primitives”| Concern | Selection |
|---|---|
| Resource schemas | JSON Schema 2020-12 |
| HTTP API | OpenAPI 3.1 |
| Event envelope | CloudEvents |
| Event-channel documentation | AsyncAPI, optional |
| Authentication | OAuth 2.0 Client Credentials |
| Interactive identity | OpenID Connect where needed |
| HTTP errors | RFC 9457 Problem Details |
| Time | RFC 3339 and IANA time-zone names |
| Geography | GeoJSON RFC 7946 |
| Countries | ISO 3166-1 |
| Currency | ISO 4217 |
| Logistics locations | UN/LOCODE |
| Units | UNECE Recommendation 20/21 |
| Identifiers | UUIDv7 / RFC 9562 |
Resulting strategy
Section titled “Resulting strategy”OpenFreytProtocol owns only the narrow semantics needed for partner authorization, capacity offers, load requests, proposals, decisions and impact evidence. Everything else is either:
- a mature primitive;
- an opaque external reference;
- a versioned extension; or
- an optional boundary adapter justified by a real participant.
This avoids both Freyt lock-in and standards-driven overengineering.