Whitepaper
From number to proof
Documenting and verifying CO₂ calculations over time
A CO₂ result used in administrative systems must not be treated as an isolated number. The key question is whether it remains explainable, repeatable and technically verifiable later.
Whitepaper
From number to proof
Documenting and verifying CO₂ calculations over time
A CO₂ result used in administrative systems must not be treated as an isolated number. The key question is whether it remains explainable, repeatable and technically verifiable later.
Core argument
A CO₂ value on its own is not enough. For an individual user, a figure such as “324 kg CO₂e” may look sufficient at first glance. For public-sector organisations, universities, ministries, agencies, or larger institutions, it is not. In these settings, an emissions figure must not only be displayed; it must be justified, checked, repeated, documented, and remain understandable over longer periods of time.
The decisive question is therefore not only whether a value has been calculated, but how that value came about: Which input data were used? Which model was applied? Which version of the factors was valid at the time of calculation? Which assumptions were made? And can the calculation be run again later, or at least be fully explained?
This is where the difference emerges between a CO₂ calculation that merely produces a number and one that can serve as reliable evidence in digital administrative, reporting, and decision-making processes.
The problem: the number hides its own origins
CO₂ calculations often appear more objective than they really are. This is not because they are unreliable, but because every calculation depends on assumptions, models, factors, data states, and interpretation. A single result value hides these underlying conditions. It looks unambiguous, even though it can hardly be assessed meaningfully without context.
A value such as “324 kg CO₂e” only appears to answer the relevant question. In reality, many follow-up questions remain open: Is the figure CO₂ or CO₂e? Was an RFI factor included? Was the trip calculated as a direct flight or with stopovers? Which airport data were used? Was the flight distance calculated as great-circle distance, as an actual route, or with a generic detour factor? Was the calculation based on the current factor set or on a historical one?
Without this information, the figure may be useful for operational purposes, but it is only of limited value for audits, reporting obligations, comparisons, budget decisions, or strategic steering. The number then becomes an interface that conceals complexity instead of making it governable.
Why context matters
The importance of metadata becomes clear as soon as two apparently identical calculations produce different results. That can be entirely legitimate from a technical or methodological point of view. It becomes a problem only when it is no longer possible to understand why the results differ.
Example 1: Different factor sets
An organisation recalculates flight emissions in 2026 for travel that took place in 2024. If the API always uses the latest factor set, the result may differ from the original calculation. That is not necessarily wrong: factors are updated, scientific knowledge evolves, and models improve. But for a public-sector organisation, this creates an evidentiary problem if it remains unclear whether the difference results from new input data, a new model, or a new factor set.
Example 2: Changed calculation logic
The calculation logic itself may also change. A new API version may handle stopovers differently, represent travel classes in more detail, or include additional correction factors. From a methodological perspective, this may be progress. Organisationally, however, it is only unproblematic if it is clearly documented which version was used for which calculation.
Example 3: Changing providers
The problem becomes particularly visible when a provider is changed. If a domain system uses Provider A today and Provider B tomorrow, old values must not lose their meaning. A neutral integration layer must therefore not only receive results; it must also document the provider profile, model version, and data basis from which those results originate.
Time reference: emission values are not timeless
CO₂ values are often treated as if they were timeless facts. In reality, they are snapshots of a particular methodological and data-related state. For administrative processes, this time reference is central.
At least three points in time are relevant:
| Point in time | Meaning |
|---|---|
| Travel date | The period to which the emissions substantively relate. |
| Calculation date | The point in time at which the calculation was technically performed. |
| Data and model state | The state of the factors, models, airport data, and provider logic used for the calculation. |
These points in time must not be conflated. A trip from 2024 can be calculated in 2026, but with a factor set from 2025 or a model version from 2026. Without explicit metadata, it is no longer possible to determine later which state was actually used.
Versioning: what needs to be versioned
To keep a CO₂ value understandable over time, a single API version is not enough. Several layers that jointly determine the result need to be versioned.
| Layer | Why it matters | Example |
|---|---|---|
| API version | Describes the technical contract between client and server. | v1, v2, latest |
| Model version | Describes the domain-specific calculation logic. | ifeu-flight-model-2026.1 |
| Factor set | Describes the emissions, RFI, cost, or conversion factors used. | factors-2026-04 |
| Airport data | Describes master data such as IATA, ICAO, coordinates, and validity periods. | airports-2026-02 |
| Provider profile | Describes which functions a provider supports and which it does not. | provider-profile-atmosfair-compat-1 |
The key question is therefore not only: Which API was called? It is: Which concrete combination of interface, model, factors, master data, and provider capabilities produced this result?
Replayability: the calculation must be repeatable
Repeatability does not necessarily mean that a system must provide the exact same live endpoint forever. It means that a concrete calculation is documented in such a way that its result can later be reproduced or at least fully explained.
For this, an API response must contain more than the result value. It should return all relevant inputs, normalisations, versions used, and central intermediate results. Only then can a result become reliable evidence.
{
"status": "SUCCESS",
"calculation_id": "calc_2026_05_07_001",
"request": {
"departure": "FRA",
"arrival": "LHR",
"passenger_count": 1,
"travel_class": "Y",
"departure_date": "2026-04-25"
},
"normalized_input": {
"departure": {
"iata": "FRA",
"icao": "EDDF",
"lat": 50.0333,
"lon": 8.5706
},
"arrival": {
"iata": "LHR",
"icao": "EGLL",
"lat": 51.4700,
"lon": -0.4543
}
},
"versions": {
"api": "v1",
"model": "flight-model-2026.1",
"factors": "factors-2026-04",
"airports": "airports-2026-02",
"provider_profile": "calco2lato-default-1"
},
"result": {
"co2e_kg": 324.7,
"co2_without_rfi_kg": 108.2,
"rfi": 3.0,
"distance_km": 656
}
}Verifiability: the calculation must be auditable
Repeatability answers the question of whether a calculation can be reconstructed. Verifiability goes one step further: it asks whether a result is unchanged, clearly attributable, and technically controllable.
Especially in public and semi-public contexts, it is not enough merely to trust a result. It must be possible to see whether a response has been modified later, which service produced it, and whether the versions used can be referenced unambiguously.
Hashes
A hash can ensure that input data, normalised data, or results can be recognised again later. If the same canonical data structure is hashed again, the same hash must be produced. This creates a simple technical basis for comparability and evidence.
Signatures
A digital signature can additionally confirm that a result came from a particular provider or service and has not been modified since it was signed. This is particularly relevant when calculations are reused in reports, records, portals, or domain systems.
{
"verification": {
"canonicalization": "json-canonicalization-scheme",
"input_hash": "sha256:...",
"result_hash": "sha256:...",
"signed_at": "2026-05-07T10:31:00Z",
"key_id": "calco2lato-signing-key-2026-01",
"signature": "base64url:..."
}
}Response profiles: not every use case needs the same depth
Not every application needs the same level of detail. A web form for a quick estimate requires different information from an audit-ready administrative process. It therefore makes sense to define different response profiles.
| Profile | Purpose | Typical content |
|---|---|---|
| Minimal | Quick display of a result | CO₂e value, status, basic input data |
| Standard | Regular integration into domain software | Result, inputs, normalisation, key versions |
| Audit | Evidence and later review | Complete metadata, intermediate results, factor set, model version |
| Signed | Technically verifiable evidence | Audit profile plus hashes, signature, key ID, and signing timestamp |
The advantage of such profiles is that the API does not need to become artificially complex. Simple use cases remain simple. Demanding administrative and audit processes still receive the depth they require.
Requirements for API, library, and provider
From this perspective, clear requirements emerge for a CO₂ calculation infrastructure. They concern not only the API itself, but also libraries, provider profiles, and the organisational setting in which the calculation is used.
API
The API should not only accept inputs and return results. It should also disclose the basis of the calculation. This includes normalised inputs, versions used, central assumptions, intermediate results, and a stable mechanism for referencing calculations.
Library
A library should not only simplify calls. It should also make visible which capabilities a provider supports. Can the provider sign responses? Are multiple flights per request supported? Can factor sets be selected? Is there an audit profile? Such information should be available in machine-readable form.
Provider
Providers should clearly describe their models, factor sets, and supported functions. Not every provider has to support everything. What matters is that differences become visible and that integration decisions are not based on implicit assumptions.
Implementation path
A CO₂ calculation fit for public-sector use does not need to be implemented in one step. A staged approach is sensible, with each stage already delivering practical value.
| Stage | Goal | Result |
|---|---|---|
| 1 | Return result plus inputs | Calculations become easier to document. |
| 2 | Return normalised inputs | It becomes visible what was actually calculated. |
| 3 | Expose versions of API, model, factors, and master data | Calculations remain explainable over time. |
| 4 | Introduce response profiles | Different use cases receive the appropriate level of detail. |
| 5 | Add hashes and canonical representation | Results become technically comparable and auditable. |
| 6 | Support digital signatures | Calculations can be used as technical evidence. |
This path makes it possible to start quickly with a usable API without blocking later requirements for auditability and evidence.
Conclusion: from number to evidence
The central challenge is not to produce just any CO₂ value. The real challenge is to turn a calculation into reliable, explainable, and long-term usable evidence.
This is especially important for public institutions. They operate in structures in which decisions must be justified, processes documented, and results reviewed later. An isolated CO₂ value fits only poorly into such structures. It becomes suitable for administrative use only when its origins remain transparent.
A good CO₂ API should therefore not only deliver a number. It should deliver the path to that number: inputs, assumptions, versions, data states, intermediate results, and, where required, technical verification evidence. Only then does a number become a reliable component of digital administrative and reporting infrastructures.
Trust is not created by the CO₂ value alone, but by the ability to explain, repeat, and verify it later.
calco2la.to