# 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 MilestoneDigital Twin Requirement
< 1,000 SUI events/yearExcel/Python model with manual data input, annual validation
1,000–50,000 events/yearAutomated data pipeline from SSOT to model; semi-annual validation
50,000–1M events/yearReal-time or near-real-time computation; continuous monitoring; annual third-party audit
> 1M events/yearEnterprise-grade system with SOC 2 Type II certification; continuous auditing by major accounting firm
--- *Continue to Chapter 4: [Financial Mechanisms](#bkmrk-continue-to-chapter-) — how a verified SUI translates into reduced cost of capital.*