Chapter 2: The SUI Framework

• The Five Criteria of a SUI
• Comparison with Existing Impact Frameworks
• The Parameterized SUI Protocol

The Five Criteria of a SUI

The Five Criteria of a SUI

A valid Scalable Unit of Impact must satisfy all five criteria simultaneously. Partial compliance — three criteria met, two not — does not produce a SUI. It produces an impact aspiration. The criteria are adapted from the IMP Five Dimensions of Impact (Impact Management Project, now Impact Frontiers) but operationalised at the per-application unit level rather than the portfolio level.

Criterion 1: Specificity (What)

Specificity requires three nested choices:

1. Domain selection: Which system is being changed? (Climate, Biodiversity, Water, Social equity, etc.)
2. Indicator selection: Which standardised indicator tracks the change? (IRIS+ code, TNFD metric, GRI indicator, or AIMM dimension)
3. Granularity selection: At what level of aggregation does the unit apply? (Per dose, per hectare, per session, per kWh, per tonne)

Test: Can you complete this sentence unambiguously? "One application of [product] produces [N] [units] of [IRIS+/TNFD indicator] in [defined system]."

Examples:

• PASS: "One hectare treated with Becaps biostimulant displaces 102.4 kg CO₂e of synthetic nitrogen fertiliser (IRIS+ PI5765 — GHG emissions avoided)"
• FAIL: "Our product helps farmers reduce their environmental footprint" (no taxonomy, no unit, no domain)

Criterion 2: Attribution (Contribution)

Attribution is the most technically demanding criterion and the most commonly ignored. It requires:

1. Counterfactual baseline: What outcome would occur in the absence of the product? (Business-as-usual scenario)
2. Attribution boundary: Which portion of the observed outcome change is caused by the enterprise versus other concurrent factors?
3. Temporal boundary: Over what time period is the attributed impact counted?

Common attribution errors:

• Gross vs. net reporting: Claiming 500 tonnes CO₂e avoided when the counterfactual would have avoided 200 tonnes anyway — the net is 300 tonnes
• Selection bias: Measuring impact only among customers who adopted the product successfully, ignoring drop-outs or partial adopters
• Displacement: An activity that reduces emissions in one location but increases them elsewhere (leakage) must account for the leakage in its SUI

Criterion 3: Quantifiability (How Much)

Quantifiability requires:

1. A numeric value with unit (e.g., 102.4 kg CO₂e, 47.3 kWh, 2.1 m³ water)
2. A measurement protocol specifying who measures, with what instrument, at what frequency
3. An uncertainty range or confidence interval — all physical measurements have uncertainty; hiding it is a red flag

The choice between physical and monetary units matters:

• Physical units (kg CO₂e, kWh, m³) are more verifiable and less subject to monetisation assumptions
• Monetary units (USD impact-weighted revenue per application) allow direct comparison with financial metrics but require additional assumptions about social cost of carbon or impact valuations
• Best practice: define the SUI in physical units; provide a monetary translation as supplementary information

Criterion 4: Verifiability

Verifiability has three components:

1. Independence: The verifier has no financial interest in the outcome they are verifying. Self-certification is not verification.
2. Evidence trail: The verifier can trace from the SUI claim back to the raw data source — sensor readings, satellite imagery, lab results, customer records — without relying on the enterprise's summaries.
3. Reproducibility: A second independent verifier, given access to the same SSOT, would reach the same conclusion within the stated uncertainty range.

The SSOT system that enables verifiability is described in detail in Chapter 3. In practice, verifiability is achieved through a three-tier pipeline: Ingest → Digital Twin → Conversion.

Criterion 5: Scalability

Scalability tests:

• Does the SUI definition change when the product is deployed in a new geography? (If yes, you may need geography-specific SUI variants — acceptable, but must be documented)
• Does the measurement cost per SUI decrease as volume grows? (Should be yes — a scalable SUI benefits from measurement infrastructure amortisation)
• Can the SSOT system handle N × volume without architectural changes? (A scalable SUI requires a scalable data infrastructure)

The Five-Criteria Matrix

Criterion	Key Question	Evidence Required	Failure Mode
Specificity	What changes?	Taxonomy link, unit definition	Vague outcome language
Attribution	Because of us?	Baseline, counterfactual methodology	Gross impact reporting
Quantifiability	How much?	Measurement protocol, uncertainty range	Directional claims without numbers
Verifiability	Can anyone check?	Independent auditor access, SSOT system	Self-certified data
Scalability	Works at scale?	Protocol stability, infrastructure plan	Pilot-only methodology

---

Next: Comparison with Existing Impact Frameworks — how SUI relates to IRIS+, AIMM, IMP, and others.

Comparison with Existing Impact Frameworks

Comparison with Existing Impact Frameworks

The SUI framework does not replace existing impact measurement standards — it operationalises them at the per-application unit level. Understanding how SUI relates to the major frameworks helps practitioners choose which standards to cite in their SUI definition and which verification protocols are compatible.

The Landscape of Impact Standards

Standard	Owner	Primary Use	Granularity	Verification Requirement
IRIS+ 5.3b	GIIN	Impact indicator selection	Portfolio/fund	None mandated
IMP Five Dimensions	Impact Frontiers	Impact conceptualisation	Programme	None mandated
IFVI / Capitals Coalition	IFVI	Impact-weighted accounts	Enterprise	Recommended
IFC AIMM	IFC	MDB investment scoring	Project	IFC internal
EU Taxonomy	European Commission	Regulatory do-no-harm	Activity	Mandatory (DNSH)
TNFD	TNFD Secretariat	Nature-related disclosure	Enterprise/site	Recommended
60 Decibels	60dB	Beneficiary perception	Beneficiary	Independent (60dB team)
GRI Standards	GRI	Sustainability reporting	Enterprise	Recommended
SUI (CTH Framework)	CleantechHUB	Per-application unit definition and verification	Application	Mandatory (SSOT-backed)

SUI vs. IRIS+ (GIIN)

IRIS+ is the most widely used impact measurement framework globally, with over 10,000 indicators organised into sector-specific metric sets. IRIS+ tells you what to measure; SUI tells you how to verify it at the unit level.

Complementarity: Every SUI should reference an IRIS+ indicator (or TNFD/GRI equivalent) in its Specificity criterion. IRIS+ provides the taxonomy; SUI provides the per-application protocol.

Key gap SUI fills: IRIS+ 5.3b includes sector metric bundles (agriculture, energy, housing) but has no concept of a "per-application standard." A company using IRIS+ PI5765 (GHG emissions avoided) can report any number of tonnes avoided with no protocol for verifying the per-dose or per-hectare calculation. SUI closes this gap.

SUI vs. IMP Five Dimensions (Impact Frontiers)

The Impact Management Project's Five Dimensions — What, Who, How Much, Contribution, Risk — are the closest conceptual antecedent to the SUI criteria. The SUI framework directly adapts them:

IMP Dimension	SUI Criterion	SUI Addition
What	Specificity	Requires taxonomy link at application level
Who	(Embedded in Specificity)	SUI focuses on environmental outcomes; social "who" is contextual
How Much	Quantifiability	Requires per-application unit, not programme total
Contribution	Attribution	Requires documented counterfactual, not just claim
Risk	(Embedded in Verifiability)	SSOT system reduces impact risk by making claims auditable

IMP operates at the programme or portfolio level; SUI operates at the product application level. SUI is, in a sense, IMP operationalised for startup product teams.

SUI vs. IFC AIMM

The IFC's Anticipated Impact Measurement and Monitoring (AIMM) system scores investments on a 100-point scale across 29 sectors. It is the standard used by IFC and increasingly by other MDBs for investment decision-making.

Why SUI alignment with AIMM matters: A startup seeking IFC co-investment or IFC-backed blended finance must score above threshold on AIMM. AIMM's "Market Creation" and "Effects on People and Planet" components reward verifiable, sector-aligned impact measurement. A startup with a well-defined SUI can self-score on AIMM with significantly higher confidence — and can present the SSOT evidence trail to IFC reviewers.

SUI vs. EU Taxonomy

The EU Taxonomy Regulation defines environmentally sustainable economic activities and requires companies to demonstrate "substantial contribution" to one of six environmental objectives while meeting "Do No Significant Harm" (DNSH) criteria. Taxonomy alignment is increasingly a condition for accessing EU green finance instruments.

SUI as EU Taxonomy enabler: The EU Taxonomy requires quantitative, measurable environmental contributions — precisely what the SUI provides. A SUI aligned to EU Taxonomy criteria (e.g., climate change mitigation, circular economy) gives a startup a credible claim to Taxonomy-aligned revenue, unlocking access to EU Green Bond instruments and SFDR Article 9 fund investment.

SUI vs. TNFD

The Taskforce on Nature-related Financial Disclosures (TNFD) had 733+ adopters representing $22T AUM as of 2025. TNFD focuses on nature-related risks and dependencies, not just climate. The SUI framework is extensible to biodiversity and water outcomes using TNFD metrics (e.g., habitat restored per application, water quality index per treatment).

Where SUI Is Genuinely Novel

No existing framework combines all four of these properties simultaneously:

1. Per-application granularity (not programme or portfolio level)
2. Mandatory independent verification against a defined SSOT
3. Explicit financial instrument design interface (SUI as trigger metric)
4. Startup-native operationalisation (designed for companies with limited measurement infrastructure)

IRIS+ covers #1 in principle but not #2, #3, or #4. The EU Taxonomy covers #2 and #3 but operates at the activity level, not the product application level. SUI fills the gap between these frameworks and the financial instruments that want to use their outputs.

---

Next: The Parameterized SUI Protocol — how to formally specify and document a SUI.

The Parameterized SUI Protocol

The Parameterized SUI Protocol

A SUI is not fully defined until its parameters are documented. The Parameterized SUI Protocol is a structured specification format that captures everything needed to (a) communicate the SUI unambiguously, (b) instruct a verification auditor, and (c) design a financial instrument around it.

The SUI Parameter Set

Every SUI must specify the following eight parameters:

#	Parameter	Description	Example (Becaps)
1	SUI Name	A plain-language name that identifies the unit	Chemical Displacement per Hectare
2	Outcome Domain	The system being changed (taxonomy-linked)	Climate — GHG Emissions Avoided (IRIS+ PI5765)
3	Application Event	The specific company action that triggers one SUI	Application of 1 kg Becaps biostimulant to 1 hectare of cultivated land
4	Baseline Value	Counterfactual outcome in the absence of the intervention	220 kg N/ha synthetic fertiliser application (regional average, DANE 2023)
5	Observed Value	Measured outcome with the intervention	85 kg N/ha (average across 120 trial plots, 2023–2024)
6	SUI Magnitude	Net impact = Baseline − Observed, converted to outcome unit	135 kg N/ha displacement × 0.758 CO₂e/kg N = 102.4 kg CO₂e/ha
7	Uncertainty Range	95% confidence interval on the SUI magnitude	±12.3 kg CO₂e/ha (±12%)
8	Verification Protocol	How, when, and by whom the SUI is verified	Annual third-party LCA audit by certified GHG verifier; SSOT ingest from production batch records + soil lab reports

The SUI Specification Document

A complete SUI specification document contains the parameter set above plus the following supporting sections:

Section A: Taxonomy Mapping

Map the SUI to every relevant standard:

• IRIS+ indicator code(s) and description
• SDG target(s) (e.g., SDG 2.4, SDG 13.1)
• EU Taxonomy objective and activity code (if applicable)
• TNFD indicator (if nature-related)
• AIMM sector and dimension (if MDB investment is planned)

Section B: Baseline Documentation

For every SUI, the baseline must be documented with:

• Source of baseline data (peer-reviewed study, government statistics, industry survey)
• Year of baseline data and update frequency
• Geographic scope and representativeness
• Baseline degradation plan (what happens if the baseline changes — e.g., if synthetic fertiliser use declines nationally)

Section C: SSOT Architecture Summary

A brief description of the Single Source of Truth system that will hold the underlying data:

• Data sources feeding the SSOT (ERP records, IoT sensors, lab reports, satellite data)
• Data governance: who can write, who can read, what is immutable
• Audit trail: how a verifier accesses historical records
• Verification interface: the data export format provided to third-party auditors

Section D: Aggregation Rules

How individual SUI events are summed to produce period totals:

• Temporal aggregation (annual, quarterly, rolling 12-month)
• Geographic aggregation (by country, region, or global)
• Double-counting prevention (if a product is applied and then re-applied to the same area in the same period)
• Boundary conditions (minimum threshold for counting one SUI event)

The SUI Specification Template

SUI SPECIFICATION DOCUMENT
Version: 1.0
Company: [Name]
Date: [YYYY-MM-DD]
Author: [Name, Role]
Verifier (pending): [Name of planned third-party auditor]

═══════════════════════════════════════════
PARAMETER SET
═══════════════════════════════════════════

1. SUI Name: ___________________________________
2. Outcome Domain: _____________________________ 
   IRIS+ Code: ________________________________
   SDG Target: ________________________________
3. Application Event: __________________________
   Trigger condition: _________________________
   Unit of application: _______________________
4. Baseline Value: ____________________________ 
   Baseline source: ___________________________
   Baseline year: _____________________________
5. Observed Value: ____________________________
   Measurement method: ________________________
   Sample size / coverage: ____________________
6. SUI Magnitude: _____________________________
   Calculation: (Baseline - Observed) × [conversion factor]
7. Uncertainty Range: _________________________
   Confidence level: __________________________
8. Verification Protocol: ______________________
   Verifier type: _____________________________
   Verification frequency: ____________________
   SSOT access method: ________________________

═══════════════════════════════════════════
TAXONOMY MAPPING
═══════════════════════════════════════════
IRIS+:       [ ] PI5765  [ ] PI7685  [ ] Other: ______
EU Taxonomy: [ ] Mitigation  [ ] Adaptation  [ ] N/A
TNFD:        [ ] Yes (metric: _________)  [ ] N/A
AIMM:        [ ] Sector: _______  [ ] N/A

═══════════════════════════════════════════
VALIDATION SIGN-OFF
═══════════════════════════════════════════
Internal review by: ____________________
Date: __________________________________
External verification by: ______________
Date: __________________________________
Verification standard used: ____________

Living Document Protocol

The SUI specification is a living document that must be updated under the following conditions:

• When the product formulation or delivery mechanism changes materially
• When the baseline data source is updated (triggers recalculation of all prior SUI magnitudes, with appropriate notes)
• When the company expands to a new geography with a materially different baseline
• When the verification protocol changes (e.g., new verifier, new standard)
• At minimum annually, as part of the impact reporting cycle

---

Continue to Chapter 3: The SSOT Architecture — building the data infrastructure that makes SUI verification possible.