Turn a carbon footprint into a plan that holds up.

A measure is defined against actual lines, not an abstract category. The baseline is presented as a filterable table, and every dimension the footprint carries becomes a filter — scope, GHG Protocol category, legal entity, activity, source or energy vector, country, unit, emission-factor request, reporting period, plus any column specific to your own data model.

• Filters combine, and the count of matching lines updates continuously.
• Individual lines can then be included or excluded one by one, so a measure can be scoped to a single site or a single contract.
• The preview shows the quantity, emission factor and emissions of every candidate line, sortable on any dimension.

Whatever its label, every measure resolves to one of four operations. Each maps to a way abatement is actually engineered or contracted — and each is auditable.

A measure can also carry its own target year, which is what lets a plan read as a trajectory rather than a single-year swap.

Measures are held as an ordered list, because order changes results: a 20 % efficiency gain applied after an electricity switch does not yield the same tonnage as before it. Order is therefore part of the plan, not a display preference.

• Reorder by drag and drop; the plan is recomputed from the baseline on every change.
• Editing a measure's filters or parameters, or deleting it, triggers the same full replay.
• A measure that can no longer apply — an absolute reduction larger than what remains in its selection — is flagged for correction, never silently dropped.
• The complete action history is stored with the plan and travels into the export.

• Headline indicators — baseline, result at the target year, absolute and relative change, number of measures.
• Impact waterfall — one bar per measure in plan order, each carrying the Scope 1/2/3 totals before and after it. The replay, made visible.
• Breakdown table — before, after, delta and delta % grouped on up to three dimensions of your choosing (entity, then activity, then vector, for instance), so the plan reads from any organisational angle.
• Emissions over time — historical reporting years, the plan result at the target year, the target trajectory, and the business-as-usual projection as a reference envelope.

Four scenarios, side by side, by scope and by GHG Protocol category — any two mirrored against each other:

The business-as-usual side is read from the projection the calculation engine produced out of your own growth drivers; the target side from the target set itself. Neither is a rule of thumb applied to the baseline.

A plan can be linked to a target set built in step 3 — including SBTi-aligned targets with their coverage thresholds and 1.5 °C trajectories — or to a target created inline as a reduction percentage or an absolute cap. Once linked, the plan continuously reports its target total, its gap in tCO2e and the same gap as a percentage, recomputed on every change.

Recurring measures are stored as reusable library items — name, category, applicable scopes, transformation and default parameters. The library has two layers: a system catalogue maintained by Climact, and your own client layer, so an organisation accumulates its vocabulary of measures across plans, sites and years. Any measure built in a plan can be saved back to the library in one click.

A plan exports to a single Excel workbook built server-side: the baseline lines, the resulting lines after all measures, the full action history, and a summary of totals. Charts export individually as images for board packs. Because the export carries the row-level before and after, a verifier can reconstruct every figure without access to the platform.

• Results are order-dependent by design. The same measures in a different order produce different contributions per measure, and the same final total only when the measures are independent.
• The fixed-tonnage transformation distributes its volume pro-rata to each line's share of emissions; it cannot remove more than the selection contains, and says so when asked to.
• Scope allocation follows the GHG Protocol category carried by each line, so a measure touching several scopes reports its effect on each separately.
• Market-based and location-based are separate baselines. A plan is built on one of them, explicitly.

Users authenticate against Amazon Cognito. The API accepts only signed RS256 JSON Web Tokens, verified on every request against the pool's published keys, with issuer, audience, token type and expiry all checked server-side. No request is served on the strength of anything the browser asserts about itself.

Permissions are resolved server-side and delivered to the browser as a workspace manifest — the explicit list of what a user may see and do. The front end renders that manifest; it never derives permissions on its own. Four levels compose:

Entitlements are computed from your organisation's own access records rather than from group membership asserted by the client application, which keeps them auditable and reviewable user by user.

• All traffic is TLS-encrypted; the application is served over HTTPS only.
• Client data is stored and processed in the AWS eu-central-1 (Frankfurt) region.
• Production and test run as separate environments, each with its own database schema and its own storage prefix.
• Database credentials are held in AWS Secrets Manager — never in application code or configuration files.
• Row-level footprint and plan data is stored separately from the relational metadata, and is only ever served through the authenticated API.

The codebase undergoes periodic security and robustness reviews covering the front end, the API and the access layer, with findings tracked and prioritised. We answer security and data-protection questionnaires under NDA, and prefer to receive them early: it is the fastest way to establish precisely what the platform covers for your organisation, and what would need to be put in place.