The Digital Twin for Impact Verification

The Digital Twin for Impact Verification

The Digital Twin is the computational core of the SUI verification system. It is a version-controlled, auditable model that takes raw operational data as input and produces per-application SUI magnitudes as output. This page describes how to build, validate, and maintain a Digital Twin suitable for third-party impact verification.

What Goes Into the Digital Twin Model

1. The Impact Pathway Model

The impact pathway describes the causal chain from product application to environmental outcome. It answers the question: "Through what mechanism does one application of our product produce the claimed SUI magnitude?"

For a biostimulant company like Becaps:

Product application (1 kg biostimulant / ha)
    → Microbial inoculation (≥10¹¹ CFU/g colonise root zone)
    → Biological nitrogen fixation (BNF increases N availability)
    → Reduced synthetic N application requirement (−135 kg N/ha)
    → Avoided N₂O emissions from synthetic fertiliser production (×0.758 CO₂e/kg N)
    → Avoided N₂O emissions from soil application of synthetic N (×0.01 kg N₂O/kg N)
    → Total GHG displacement: 102.4 kg CO₂e/ha

Each arrow in this chain must be supported by either (a) peer-reviewed scientific literature, (b) field trial data from the company's own operations, or (c) certified emission factors from recognised sources (IPCC, EPA, DEFRA).

2. Emission Factors and Conversion Coefficients

The Digital Twin relies on external data — emission factors, conversion ratios, global warming potential values — that are updated periodically by standard-setting bodies. The model must:

• Specify the exact source and version for every external coefficient (e.g., "IPCC AR6 WGI Table 7.SM.7, GWP100 value for N₂O: 273 CO₂e")
• Implement version locking — historical SUI events use the factor version in effect at the time of calculation
• Trigger recalculation reviews when major updates are released (e.g., when IPCC publishes a new Assessment Report)

3. Baseline Model

The counterfactual baseline is a model in its own right. It specifies:

• The reference activity that would occur without the enterprise's product (e.g., "conventional synthetic nitrogen application at regional average rates")
• The data source and geographic scope of the baseline (e.g., DANE 2023 Colombia agricultural census)
• The temporal validity of the baseline (baselines degrade as markets change — a 2019 baseline for synthetic fertiliser use in a region that has since adopted sustainable agriculture practices will overstate impact)
• Baseline update triggers: conditions under which the baseline must be recalculated (e.g., if market penetration of competing biostimulants exceeds 20% in the region)

4. Uncertainty Model

Impact uncertainty has multiple sources, each of which must be quantified:

• Measurement uncertainty: Variability in field measurements (soil nitrogen content measured in 12 plots out of 500 ha — sampling error)
• Model uncertainty: Uncertainty in the emission factor values (IPCC provides ranges, not point estimates)
• Baseline uncertainty: The baseline is an average — individual farms may deviate significantly from the average
• Attribution uncertainty: The portion of observed N reduction attributable specifically to the biostimulant (vs. weather, management changes, etc.)

The Digital Twin propagates these uncertainties using Monte Carlo simulation or analytical uncertainty propagation and reports the combined 95% confidence interval on every SUI magnitude output.

Building the Digital Twin: Minimum Viable Version

For a pre-Series A startup, the minimum viable Digital Twin can be a well-structured, version-controlled Excel or Python model. The key requirements are:

1. Documented inputs: Every input cell or variable has a source citation
2. Auditable calculations: No black boxes — every formula is visible and reviewable
3. Version control: The model is stored in a git repository or equivalent with change history
4. Reproducibility: Given the same inputs, a second analyst running the model independently produces the same outputs within rounding error
5. Sensitivity analysis: The model includes a sensitivity analysis showing which inputs have the largest impact on the SUI magnitude

Digital Twin Validation

Before the Digital Twin is used for investor reporting or financial instrument design, it must be validated by an independent third party. Validation means:

1. Model review: The validator reviews the impact pathway logic, the source citations for all emission factors, and the baseline methodology
2. Calculation audit: The validator independently recalculates a sample of SUI events using the model and confirms they match the company's reported values
3. Field data audit: The validator reviews the raw field data (lab reports, IoT records) and confirms they match what was ingested into the model
4. Written validation statement: The validator issues a written statement (following ISAE 3000 or equivalent) confirming the model is fit for purpose

Scaling the Digital Twin

As the company scales, the Digital Twin must evolve from a spreadsheet model to a software system. Key milestones:

Scale Milestone	Digital Twin Requirement
< 1,000 SUI events/year	Excel/Python model with manual data input, annual validation
1,000–50,000 events/year	Automated data pipeline from SSOT to model; semi-annual validation
50,000–1M events/year	Real-time or near-real-time computation; continuous monitoring; annual third-party audit
> 1M events/year	Enterprise-grade system with SOC 2 Type II certification; continuous auditing by major accounting firm

---

Continue to Chapter 4: Financial Mechanisms — how a verified SUI translates into reduced cost of capital.