Full title: iLEAP Technical Specifications, Version 1.1.0-draft.2,
changelog-dated 2026-06-15, retrieved 2026-10-01 from
https://specs.ileap.global/. Status tag: Living Document — i.e.
work-in-progress, not a Release and not a Consultation Draft. Versioning
follows SemVer; the document defines its own three-stage publication flow
(Living Document → Consultation Draft → Release), each of the latter two
getting a permanent URL under /TR/.
This is the first primary iLEAP source in the wiki. Until this ingest iLEAP was cited on seven pages and had no page of its own; see iLEAP for the standing entity page distilled from this document.
Why it was ingested
Martin Pompéry, 2026-10-01: “ingest in dein Wiki die iLEAP Tech Specs”. The
GitHub raw URL he first supplied
(ileap-initiative/specs/.../specs/index.bs) returns 404 — the repository is
not reachable under that path. He then pointed at the rendered latest version
at specs.ileap.global, which is what was saved and ingested.
What the document is
A technical specification — not a methodology. It states its method explicitly: it “works backwards” from business cases (§3) → data transactions (§4) → a data model (§6) → a wire protocol (§7), so that independent implementations (“host systems”) can exchange logistics emissions data without bilateral integration work.
Its normative methodological foundations sit elsewhere and are declared out of scope: ISO 14083:2023 and the GLEC Framework v3.1 (§1.1). The document announces a forthcoming alignment to GLEC v3.3. It also claims methodological interoperability with PACT Methodology v2 and v3.
Structure: §1 Introduction and scope · §2 Definitions · §3 Business cases (non-normative) · §4 Data transactions (non-normative) · §5 End-to-end example (non-normative) · §6 Data model · §7 HTTP REST API · §8 Conformance · Appendix A changelog · B examples · C conformance test cases (028 of them).
The five things that matter
1. v1.1.0 decouples iLEAP from PACT at the protocol layer
The headline change. v1.1.0 introduces the iLEAP standalone API —
/v1/ileap/shipments, /tocs, /hocs, /tad, /aed plus an OAuth2
client-credentials token endpoint — and makes it “the primary protocol for
data exchange” (§1.2). “A host system MUST implement the iLEAP standalone API
which is now the preferred option” (§7.1).
The PACT Data Exchange Protocol integration, which was how iLEAP data moved
until now (as a PACT ProductFootprint extension), is retained “for backward
compatibility and fallback purposes” and is “scheduled for removal with the
v2.0.0 release” (§1.2, Note). The stated reason: “Since April 1 2026, the v2
family of the PACT Technical Specifications, including [PACTDX], is sunset.
Consequently, the PACT-based API approach SHOULD only be used for backward
compatibility reasons” (§7.1).
Semantic interoperability is explicitly not claimed, only intended: “The editors of this specification strive to assert semantical interoperability with the PACT Technical Specifications with future releases” (§1.2, Note).
2. Data Transaction 4 / AggregatedReport — confidentiality answered by aggregation
New in v1.1.0-draft.1. The transaction exists so that a data owner can disclose totals without disclosing transport-chain-element detail. The spec names the motive directly (§3.4):
“A Transport Service Organizer or a Transport Service User requests emissions data from a Transport Operator or a Transport Service Organizer which decide to share an aggregated report instead of TCE-level data, due to privacy or competition concerns.”
And warns about the cost, in bold, in the document (§4.4):
“Aggregated Emissions Data is less granular than TCE-level data. Therefore, once Aggregated Emissions Data is exchanged, it is no longer possible to derive more granular (i.e., TCE-level) data from it, thereby affecting the all data exchanges downstream.”
No cryptographic or privacy-preserving mechanism appears anywhere in the document. See the confidentiality gap and coordination vs. bargaining failure for what this is evidence of.
3. Verification is out of scope, and conformance is syntactic
§1.3, out of scope, item 5: “Auditing and verification of actual emissions calculations beyond systems-level accreditation. Verification-related properties are expected to be included in future versions.”
§8, in bold: “Currently, iLEAP Conformance ensures interoperability and syntactic correctness. Future updates will extend coverage to include semantic correctness, ensuring that emissions calculations are performed accurately in end-to-end scenarios.”
Also out of scope: book-and-claim / market-based accounting (§1.3.6),
refrigerant emissions (§1.3.9), black carbon methodology (§1.3.2), detailed
GHG modelling parameters per ISO 14083 §13.4.3 and Annex M (§1.3.7), and
per-modality aggregated reporting per ISO 14083 §13.3 (§1.3.10 — partly
addressed since by AggregatedReport/perModeEmissions, which the §1.3 text
has not caught up with).
4. TAD — the SME on-ramp
Transport Activity Data lets a party that cannot calculate emissions (or is not in that business — a telematics provider, say) publish mass, distance, load factor, energy carriers and timestamps instead, leaving the calculation to a counterparty or a tool provider. The spec frames this as lowering the entry barrier for SMEs and as a collect-once/use-many efficiency (§3.3).
Conformance makes this load-bearing in one direction: to achieve iLEAP Emissions Data Conformance a host system is REQUIRED to be able to fetch TAD from another host system and generate TOC, HOC or ShipmentFootprint data from it (§8).
5. SINE runs the conformance and reference infrastructure
Conformance requires passing Automated Conformance Testing at
act.sine.dev (§8), alongside the 28 documented test cases and a
Bilateral Test against a second independent implementation. Worked
examples in the document call api.ileap.sine.dev. ⟨Inference: both hosts are
SINE-operated, which places SINE at the certification chokepoint of the
standard, not merely among its authors. The document does not say who operates
them.⟩
The data model in brief
Six main types in two categories (§6).
Emissions data, aligned to ISO 14083:
| Type | What it is |
|---|---|
TCE (Transport Chain Element) | One leg or one hub operation of a transport chain, with its emissions. Carries tocId xor hocId, and prevTceIds to encode the happens-before ordering of the chain. |
TOC (Transport Operation Category) | Emission-intensity profile for a class of transport services — mode, load factor, empty-distance factor, energy-carrier mix, temperature control, air shipping option, flight length, truck loading sequence. |
HOC (Hub Operation Category) | The same for hub/warehouse/transshipment operations. |
ShipmentFootprint | One shipment’s footprint: metadata plus a non-empty array of TCEs. Assembling ShipmentFootprints from every party in the chain reconstructs the Transport Chain. |
AggregatedReport (AR) | Totals over one or more shipments — totalActivity (tkm), co2eWTW (mandatory), co2eTTW, NOx, SOx, CH4, PM, optional perModeEmissions. Multiple shipments must share one transport contract and one Transport Service User. |
Activity data:
| Type | What it is |
|---|---|
TAD (Transport Activity Data) | One consignment, one leg, one mode — or one transshipment. Distance, mass, origin/destination, departure/arrival, mode, energy carriers, load factor. No emissions. |
Plus utility types: GLECDistance (actual / GCD / SFD), Location,
TransportMode, HubType, EnergyCarrier, EnergyCarrierType, Feedstock,
PackagingOrTrEqType, ModeSpecificReport, and a string-encoded Decimal.
Document health — what the spec says about itself
The published draft carries its own open issues in-line, which is worth recording because they mark where the standard is still soft:
- §7.3 Authentication: “Needs revision. In particular, we need to consider not demanding BasicAuth implementation with client credentials.”
- §8.1 Conformance Matrix: “Matrix needs revision.”
- §2.2 Auxiliary Definitions: “Needs revision.”
companyIdsonShipmentFootprint/TOC: “Community input needed on the preferred approach to encoding company identifiers: URN vs UUID.”- Three
ShipmentFootprintattributes (secondaryEmissionFactorSources,pactPds,comment) are marked “proposed attribute pending community input”. referencePeriodStart/referencePeriodEnd: “Needs revision.”packagingOrTrEqAmountis typed integer where it should be decimal — acknowledged, deferred to v2.- §4 still lacks a diagram covering Data Transaction 4; §5 lacks an end-to-end example for it; the §5 examples still use the deprecated PACT-based protocol.
What was not transcribed
Read but not carried onto wiki pages: the full attribute tables of TOC,
HOC, TCE and the utility data types (field-level reference); the complete
PACT↔iLEAP property mapping tables of §7.11.1–7.11.3; the 28 conformance test
cases of Appendix C; the JSON examples of Appendix B; the full changelog back
to v0.1.0 (2024-05-13). All remain in the source file for lookup.
Cross-references
- iLEAP — the entity page distilled from this document
- Pathfinder Network — the standard iLEAP is decoupling from
- The confidentiality gap in ledger-based carbon accounting —
AggregatedReportas the aggregation answer - Coordination failure vs. bargaining failure — iLEAP as a coordination case
- SINE Foundation — co-author; operator of the reference and conformance hosts
- PACT Methodology v3.0 (WBCSD, 2025) — the methodology iLEAP claims interoperability with
- The Carbon Accounting Landscape Review (ICC, 2026) — the external critique whose charges iLEAP self-documents
Sources
sources/standards/2026-10-01-ileap-technical-specifications-v1.1.0-draft.2.md(pandoc-converted Markdown twin — the citable file)sources/standards/2026-10-01-ileap-technical-specifications-v1.1.0-draft.2.html(immutable original as retrieved from https://specs.ileap.global/)