Most emissions calculators are a lookup table with a UI bolted on. You pick "diesel," the code fetches 2.51 kgCO₂e/litre from a factor table, multiplies by your input, done. I've built about a thousand of these. The refrigerant one broke the pattern, and the reason it broke is a small idea that's worth sharing if you ever model physical systems in code.

For refrigerant leakage, there is no emission factor to look up. The factor is the global warming potential of the gas itself.

Let me explain what that means and why it changed how I structured the data layer.

The 30-second domain primer

When a chiller or supermarket fridge leaks, the refrigerant gas escapes to atmosphere. Different gases trap different amounts of heat. We normalise that to GWP — Global Warming Potential — the warming caused by 1 kg of the gas relative to 1 kg of CO₂ over 100 years.

CO₂ has a GWP of 1. R-410A, a common air-conditioning refrigerant, has a GWP of 2,256. So one leaked kilogram of R-410A is climate-equivalent to 2,256 kg of CO₂ [source: IPCC AR6, WG1 Ch7]. That multiplier is the entire story.

The calculation is almost insultingly simple:

function refrigerantEmissions({ chargeKg, leakRatePct, gwp100 }) {
  const leakedMass = chargeKg * (leakRatePct / 100); // kg of gas
  return leakedMass * gwp100;                         // kg CO₂e
}

No factor table. No unit conversion gymnastics. Three numbers. So why did this one take longer to build than the combustion calculators that do need factor tables?

The actual hard part: the factor is a moving target with two valid values at once

Here's the trap. The IPCC publishes GWP values, and it revises them. AR5 (2014) said R-143a had a GWP of 4,470. AR6 (2021) says 5,810. That's a +30% shift in the answer for the exact same physical leak [source: IPCC AR5 / AR6 WG1].

And — this is the part that breaks naive data modelling — both values are still legally correct right now, depending on who's asking:

• EU CSRD reporting → AR6, mandatory.
• A 2019 baseline you set under AR5 → still AR5 until you rebaseline.

So the factor isn't a constant. It's a function of (gas, assessment_report). My first instinct — refrigerants["R-410A"].gwp — was wrong, because there is no single .gwp. There are two, and the correct one is a property of the user's reporting context, not the gas.

The data shape that actually works:

const refrigerants = {
  "R-410A": {
    label: "R-410A — Building / split AC (HFC blend)",
    gwp100: { ar6: 2256, ar5: 2088 },  // both live, caller picks
    fgasThreshold: true                 // GWP ≥ 2,500? (regulatory flag)
  },
  // ...50 more
};

The lesson generalises well beyond carbon: when your source of truth revises itself but the old version stays valid, the version is part of the key, not metadata you can flatten away. I've since refactored other calculators the same way.

The drift is not noise — and that's a UX decision, not a data one

For most emission categories, AR5 vs AR6 is sub-1% — genuinely ignorable. For refrigerants it isn't:

Source: IPCC AR5 (WG1 Ch8) and AR6 (WG1 Ch7) GWP-100 values.

A naive build just exposes a toggle and lets the number silently jump 30%. I think that's a quiet way to mislead a user who doesn't know the chemistry changed under them. So the engine computes the drift and surfaces it inline whenever |drift| ≥ 3% — the user sees "switching to AR6 adds X% on your gas mix" before they export anything.

That's a small rule, but it encodes a position I'll defend: a calculator that can produce two different right answers has a duty to tell you why they differ. Hiding it behind a toggle is technically correct and practically dishonest.

The leak rate is a default, and defaults are a trust contract

The other input — annual leak rate — comes from IPCC Tier 1 defaults by equipment class (Table 7.9 of the 2019 Refinement). Transport refrigeration's published range is 15% to 50%. That's enormous. I store the mid-range as the preset but treat it as explicitly provisional:

const equipmentDefaults = {
  "transport-refrigeration": { preset: 25, range: [15, 50] },
  "supermarket":             { preset: 20, range: [10, 35] },
  "chillers":                { preset: 8,  range: [5, 15]  },
  // ...
};

The engine never lets a default masquerade as a measurement. A measured, documented rate always overrides the preset, and the audit export records which basis was used. If you're building anything where users will be audited on your output, the single most valuable feature is provenance on every number — what it was, where it came from, and whether it was assumed or measured. That's worth more than any chart.

Where this lives

The full thing — all 51 refrigerants, the AR5/AR6 engine, the F-Gas regulatory flags, and an audit-mode export that hashes every result back to its source — is live on GreenCalculus. If you want to see the moving-target factor model in the wild, the Scope 1 refrigerant leakage calculator on GreenCalculus is the cleanest example of the pattern.

If you model physical or regulatory systems in code, the takeaway I'd leave you with: the hard part is rarely the arithmetic. It's that your authoritative source is itself versioned, sometimes contradictory, and always more nuanced than a single number. Build for that from day one and the refactor never comes.