> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# The carbon emissions and ESG footprint model

> How Devotel Orbit turns outbound usage into a per-channel CO2e estimate — the canonical channel factor table with per-factor provenance, the SMS segment-basis decision, the consolidated factor version stamp, and the deterministic CSV envelope.

# The carbon emissions and ESG footprint model

Devotel Orbit already records every outbound message and outbound voice minute
your account sends. The carbon footprint feature converts that usage into a
per-channel CO2 equivalent (CO2e) estimate, so ESG and procurement teams can
answer sustainability questionnaires without exporting raw traffic data to a
third-party calculator. This page explains the model behind those numbers:
where the emission factors live, how SMS is metered, why both API surfaces
agree, and what the exported CSV stamps into its header.

The task walkthrough — open the dashboard page, pick a window, download the
report — lives in the [Sustainability and ESG reporting
guide](/guides/sustainability-esg-reporting). This concept page owns the
**model**: what the factors are, where they come from, and why the math looks
the way it does. The guide owns the **task**; this page owns the reasoning.

***

## 1. Why a concept page in addition to the guide

Two different readers hit this feature. An operator wants to export a report —
that is the guide's job. An ESG auditor, a procurement reviewer, or your own
sustainability lead wants to know *why the number is what it is* before they
cite it in a filing — that is this page's job.

Three design decisions in particular are not obvious from the JSON response:

1. **One canonical factor table.** Every factor value the API returns comes
   from a single source-of-truth table, with the citation for each factor
   attached to it.
2. **SMS is metered per segment, with a message-count fallback.** A
   concatenated SMS is physically transmitted as N independent 160-character
   segments, so the estimate follows the segment count — and degrades
   gracefully when segment data was never recorded.
3. **Two wire surfaces, one factor set.** The modern `GET /analytics/carbon`
   endpoint and the legacy stats-side adapter deliberately keep different
   response shapes, but both read their factor values from the same table, so
   an exported figure never depends on which endpoint rendered it.

Each of those is expanded below.

***

## 2. The channel factor table

Every channel line in a report carries the factor it used (grams CO2e per
unit) and a human-readable `source` string naming where that factor comes
from. The table is intentionally small and auditable:

| Channel                                         | Basis   | Factor (g CO2e per unit) | Provenance                                                             |
| ----------------------------------------------- | ------- | ------------------------ | ---------------------------------------------------------------------- |
| SMS                                             | segment | ≈ 0.014                  | Berners-Lee, *How Bad Are Bananas?* — per-SMS estimate                 |
| Email                                           | message | ≈ 0.3                    | Same source, short transactional email figure                          |
| WhatsApp, RCS, Viber, Messenger, Telegram, push | message | ≈ 0.02                   | OTT/IP message — data-bearing payload over IP relay                    |
| Voice                                           | minute  | ≈ 0.3                    | VoIP transport — conservative midpoint of published mobile-call ranges |

Design properties that make this table defensible in an audit:

* **Per-factor provenance.** A factor with no citation is unjustifiable; a
  factor whose citation travels with it in every response and every CSV row is
  traceable. The `source` string is not decorative — it is what lets an
  auditor confirm the coefficient instead of taking it on faith.
* **Explicit estimation posture.** The figures are order-of-magnitude
  estimates derived from published per-unit factors, labelled as such on every
  surface. The disclaimer is part of the model, not a footnote: it states
  plainly that this is indicative ESG reporting, not a certified carbon audit.
* **A fallback factor for unknown channels.** A channel added to the platform
  before the table is updated still counts, at the generic IP-message factor
  (0.02 g CO2e per message). An unrecognised channel is never silently dropped
  from the footprint.
* **One estimate per unit basis.** Factors are expressed per `segment`
  (SMS), per `message` (email and OTT channels), or per `minute` (voice). The
  basis is part of the factor definition — you cannot apply a per-message
  factor to a per-minute unit without the report showing it.

***

## 3. SMS: segment-basis math and the graceful fallback

A concatenated (multipart) SMS is not one transmission. The handset and
network split it into N independent 160-character segments (153 when
continuation headers apply), each separately transmitted and separately
billed. The energy cost follows the same physics, so the SMS factor is
expressed **per segment**, and the SMS line multiplies the factor by the
segment count, not the message count.

This is also why the SMS line reports both numbers: `units` is the segment
count the factor was applied to; `messages` is the message count for context.
A 390,000-message month that carried 410,000 segments is estimated on
410,000 units.

The fallback covers the honest case: some providers, and some older traffic,
never record segment counts — the field is zero. Estimating zero emissions
for traffic you demonstrably sent would be worse than a coarser estimate, so
when the segment count is absent the message count is used instead. The
consequence is a known, bounded inaccuracy: multipart sends from those
providers are counted as if single-segment, which under-rather than
over-estimates. That trade-off is deliberate, and it is exactly the caveat an
auditor should see stated rather than discover.

Voice has the analogous rule in the other direction: it is metered per
connected **minute**, never per message, and its minutes come from call
records rather than the message store — so a stray voice-tagged message row
never double-counts against the voice line.

***

## 4. Why two wire surfaces had to merge

The feature historically appeared on two API surfaces:

* `GET /analytics/carbon` — the current per-channel report: basis-aware
  lines, per-factor provenance, totals in grams and kilograms.
* `GET /stats/analytics/carbon` — an older stats-side adapter with a
  different envelope (camelCase per-channel lines, a `per_channel` /
  `total_gco2e` shape, its own CSV column set) that existing dashboard
  widgets and integrations already consume.

Early on, those two surfaces each maintained their own factor table, and the
tables disagreed — on voice, by more than an order of magnitude. The same
procurement-questionnaire figure then depended on which endpoint happened to
render it, which is the one property an ESG number must never have.

The consolidation keeps both wire shapes — the stats adapter's consumers were
not breaking-changed — but moves **every factor value** into the single
canonical table behind `GET /analytics/carbon`. The legacy adapter re-derives
its numbers from that table instead of maintaining its own. Both surfaces now
also stamp the same methodology tag, `factors_version:
2026-06-orbit-v1`, onto every report, so a figure exported from either
endpoint is reproducible against one known factor set and the two surfaces
always reconcile. When a coefficient is revised, the version bumps in exactly
one place and every downstream report cites it.

***

## 5. Scope: why only outbound counts

The footprint answers one question: *what emissions did the platform cause on
your behalf?* That is outbound traffic — messages your account sends and
voice minutes your account originates.

Inbound replies are the counterparty's send volume, not yours; counting them
would charge you for traffic your organisation did not initiate. Treat the
report as the outbound slice of a Scope 3 estimate: defensible, reproducible,
and explicitly not your organisation's full Scope 3 inventory. Say so when you
cite it — the label the report carries is designed to be quoted alongside the
figures, not stripped off.

***

## 6. The deterministic CSV envelope

The export endpoint renders the same report as a self-describing CSV, built
deterministically so the same window always produces the same file. Its
envelope is part of the contract:

* **Leading `#` comment lines** carry the report title, the exact period the
  figures cover, the methodology version, and the full estimation disclaimer.
  Spreadsheet importers ignore `#` lines when parsing data, so the header
  survives the trip into an auditor's workbook intact — the file stands on
  its own when detached from the platform.
* **A fixed column set** — `channel`, `basis`, `units`, `messages_or_calls`,
  `factor_g_co2e_per_unit`, `co2e_grams`, `co2e_kg` — followed by one row per
  channel (highest-emitting first) and a closing `TOTAL` row.
* **The disclaimer in the header, on purpose.** Because the disclaimer travels
  inside the file, a report forwarded through a procurement chain still states
  its own estimation posture at every hand-off.

Channels with zero outbound volume in the window are omitted from both the
JSON and the CSV, so the breakdown only shows surfaces you actually used.

***

## Related

* [Sustainability and ESG reporting guide](/guides/sustainability-esg-reporting)
  — open the dashboard page, scope the window, and export the report.
* [Analytics API endpoints](/api-reference/endpoints/analytics) — the
  `GET /analytics/carbon` and export endpoint reference.
* [The analytics pipeline](/concepts/analytics-pipeline) — how usage
  telemetry aggregates into the read models this report queries.
* [Channel cost rollup vs the billing ledger model](/concepts/cost-channel-rollup-model)
  — the same aggregate-vs-ledger distinction for spend, including the SMS
  segment-attribution rule this model shares.