iLEAP is an open technical standard for exchanging logistics GHG emissions data between companies and IT systems. It is the logistics-sector sibling of PACT: where PACT standardises the exchange of product carbon footprints, iLEAP standardises the exchange of transport- and hub-level emissions along a transport chain.
Established 2025 by the SINE Foundation together with the Smart Freight Centre, under the banner of an “Internet of Emissions Data” open to everyone (per Tell Münzing’s LinkedIn profile, the only source for the founding framing — see SINE Foundation). Adoption figure on record: “15+” companies, from the Hypothesenpapier, which files it among the wiki’s complaints about missing adoption metrics — a round number with no case studies behind it.
The technical substance below comes from the first primary source in the wiki: iLEAP Technical Specifications v1.1.0-draft.2 (2026).
What the standard actually is
A wire protocol plus a data model, deliberately not a methodology. Its methodological foundations are borrowed and declared out of scope: ISO 14083:2023 and the GLEC Framework v3.1 (alignment to GLEC v3.3 announced). iLEAP’s own contribution is the plumbing — how a shipper pulls emissions data out of a carrier’s system without a bilateral integration project.
The specification is built by working backwards from four business cases:
- Quantification of (avoided) emissions — a shipper wants the real, primary-data emissions of a shipment, not a model.
- Procurement of carbon-efficient logistics services — emission intensities at the TOC/HOC level, so carbon-efficiency can enter a tender.
- Emissions calculation from transport activity data — for operators who cannot calculate emissions at all; they publish activity data instead.
- Aggregated emissions reporting — totals, including to public authorities.
Each maps to one of four data transactions, and each transaction to endpoints and types.
The data model in one table
| Type | Role |
|---|---|
TCE | One leg or one hub operation, with its emissions. Chain order encoded by prevTceIds. |
TOC / HOC | Emission-intensity profiles for a class of transport / hub operations. |
ShipmentFootprint | One shipment = metadata + array of TCEs. Collecting these from every party reconstructs the transport chain. |
AggregatedReport | Totals over one or more shipments, no chain detail. |
TAD | Activity data only — mass, distance, mode, energy carriers, timestamps. No emissions. |
Full field-level detail stays in the source summary and the source file.
v1.1.0: the split from PACT
The single most consequential fact in the current draft. Until v1.1.0,
iLEAP data travelled as an extension inside a PACT ProductFootprint, over
the PACT Data Exchange Protocol. v1.1.0 introduces a standalone iLEAP API
(/v1/ileap/shipments, /tocs, /hocs, /tad, /aed, plus an OAuth2
client-credentials token endpoint), declares it the primary protocol, makes
implementing it mandatory for conformance, and schedules the PACT integration
for removal in v2.0.0.
The stated cause is PACT’s own lifecycle: the PACT v2 specification family was sunset on 1 April 2026, so the protocol iLEAP had been riding on no longer exists as a live target.
What survives of the relationship: a mapping table (§7.11) so iLEAP types can
still be embedded in a PACT ProductFootprint; an identical authentication
flow; and a claim of methodological interoperability with PACT Methodology
v2 and v3. What is explicitly not claimed is semantic interoperability —
the editors “strive to assert” it “with future releases”.
⟨Inference: two standards SINE co-built are separating at the protocol layer for reasons internal to PACT’s release management, not from any disagreement on substance. The strategic question this raises for SINE — whether the “Internet of Emissions Data” ends up as one network or as sector-specific networks with mapping tables between them — is not addressed by the document and is not resolved in this wiki.⟩
Confidentiality: the AggregatedReport answer
Data Transaction 4, new in v1.1.0, exists so a party can disclose totals instead of transport-chain detail — and the specification names the reason without euphemism: parties “decide to share an aggregated report instead of TCE-level data, due to privacy or competition concerns” (§3.4).
Two things follow, and they pull in opposite directions.
- Confidentiality is acknowledged as a live blocker in the logistics exchange layer, not as an abstract design requirement. This is the thing the ICC Review’s Criterion B states and then drops; iLEAP has to ship a mechanism because the carriers will otherwise not send the data.
- The mechanism chosen is aggregation — one of the three means ICC names (permissioned access, aggregation, data minimisation), and the lossiest. The spec says so itself, in bold: once the aggregate 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” (§4.4). The confidentiality of one party is bought with the granularity of everyone below it in the chain.
No cryptographic or privacy-preserving mechanism appears anywhere in the document — no selective disclosure, no secure computation, no proofs. See coordination vs. bargaining failure: this is a second, sharper instance of the pattern already recorded there. ⟨Inference: and a more interesting one than PACT, because here the confidentiality constraint is stated and still does not pull the cryptographic instrument into the design. The constraint was traded away instead of solved — which is either evidence that the market will accept lossy answers, or the clearest available statement of the gap SINE’s distinctive technology is supposed to fill. The document cannot tell us which.⟩
What iLEAP does not do
Out of scope, by the specification’s own §1.3 and §8:
- Emissions calculation methodology — ISO 14083 and GLEC own that.
- Auditing and verification of actual calculations, beyond systems-level accreditation. Deferred to future versions.
- Semantic correctness. §8, in bold: conformance “ensures interoperability and syntactic correctness”; whether the numbers are right end-to-end is a future extension.
- Book-and-claim / market-based accounting, refrigerant emissions, black carbon methodology, detailed GHG modelling parameters, cable car and pipeline modes.
- Contracts and the legal aspects of data exchange between the parties.
⟨Inference: items 2 and 3 are precisely the charges the ICC Review levels at PACT — exchange without accountable quantities, inherited quantification latitude — here self-documented by iLEAP rather than alleged from outside. The same structural position therefore applies: iLEAP is an exchange layer, and the layer above it, where a number becomes accountable, is unclaimed.⟩
Conformance — and where SINE sits in it
Two kinds, incrementally adoptable:
- iLEAP Emissions Data Conformance — the full emissions path, and
additionally REQUIRED: the host system must be able to fetch
TADfrom another host system and generateTOC/HOC/ShipmentFootprintfrom it. - iLEAP Activity Data Conformance — the
TADpath only, the SME on-ramp.
Conforming requires three things: implementing the normative statements,
passing Bilateral Testing against a second, independently built
implementation, and passing Automated Conformance Testing at
act.sine.dev. Worked examples in the specification call
api.ileap.sine.dev.
⟨Inference: the conformance gate and the reference implementation both run on SINE infrastructure. That is a stronger position than authorship — whoever operates the test harness decides what “conformant” means in practice. The document does not state who operates these hosts; the domain is the only evidence.⟩
Where iLEAP sits in SINE’s portfolio
- One of the three standards SINE is repeatedly credited with across the wiki: Data Commons (2022) → PACT (2023) → iLEAP (2025). See Tell Münzing and the GIZ tender dossier, where this track record is the credential offered.
- Classified on coordination vs. bargaining failure as a coordination case, same shape as PACT: everyone wants comparable logistics emissions data, no single carrier can impose a method, the cryptography is not load-bearing. This source is the first primary evidence for that classification rather than an assumption from PACT’s shape.
- Named in CCTI as one of the sectors SINE already works in, and as the contrast case: PACT/iLEAP address coordination failure, CCTI addresses bargaining failure.
Open
- No Smart Freight Centre primary source. The co-founder of the standard has no page and no ingested document; the partnership is known only from a LinkedIn profile and this specification’s definitions section.
- No adoption evidence. “15+” companies, unsourced beyond the Hypothesenpapier. The specification lists no implementers; conformance submissions go to the authors privately (§8.3).
- Current status is a draft. v1.1.0-draft.2 is a Living Document; the last
stable Release is v1.0.0 (2025-05-27). The standalone protocol, Data
Transaction 4 and
AggregatedReport— i.e. everything new above — are not yet in a stable release. - The specification carries its own unresolved issues in-line — authentication “needs revision”, the conformance matrix “needs revision”, company-identifier encoding is open to community input. See the source summary.
Cross-references
- Interoperability profile — what iLEAP is, and what riding inside PACT as an extension cost ⟨2026-11-06⟩
- Agent protocol interoperability — the PACT/iLEAP wire history read as evidence against the O(n) claim made for agent-protocol gateways ⟨2026-10-26⟩
- iLEAP Technical Specifications v1.1.0-draft.2 (2026) — the source summary
- Pathfinder Network — the sibling standard, now decoupling
- The confidentiality gap in ledger-based carbon accounting
- Coordination failure vs. bargaining failure
- Data Commons
- SINE Foundation
- Tell Münzing
- CCTI
- The Carbon Accounting Landscape Review (ICC, 2026)
Sources
sources/standards/2026-10-01-ileap-technical-specifications-v1.1.0-draft.2.md— the only primary iLEAP source in the wiki- Founding, partner and adoption claims: LinkedIn profile per SINE Foundation and Hypothesenpapier