Digital Monitoring, Reporting & Verification for carbon-financed water treatment programs using Virridy’s Lume sensor
Under the Gold Standard dMRV Pilot Programme, Virridy has received pilot-level approval for a methodology deviation allowing the use of the Lume sensor for E. coli estimation in place of traditional laboratory-based sampling. This is a pilot approval — not a fully approved methodology change — meaning the deviation is authorized for evaluation under the pilot framework, subject to resolution of the Forward Action Requirements below and successful completion of the validation and verification process. The deviation applies to the methodology “Emission Reductions from Safe Drinking Water Supply” (Version 1.0), specifically for SDWS Parameter 18 (Microbial Drinking Water Quality).
Four Forward Action Requirements have been raised and must be addressed before the first verification:
The project developer must provide detailed protocols for sensor validation and calibration, including frequency of calibration checks, acceptable drift thresholds, and procedures for replacing or recalibrating sensors that fall outside tolerance.
Full documentation of the AI/ML model used for E. coli estimation must be provided, including training data sources, model architecture, validation results, accuracy metrics, and procedures for model retraining and version control.
A clear protocol must be established for integrating manual water quality sampling with the digital Lume sensor data. This should define when manual sampling is required as a complement or cross-check, and how discrepancies between manual and digital results are resolved.
The project developer should explore the applicability of SDWS Parameters 23 and 27 to the dMRV solution and provide a rationale for inclusion or exclusion of these parameters in the monitoring plan.
The companion Pilot Report (v0.2) compiles the resolved evidence for each Forward Action Requirement, based on Phase 1 paired Lume–CBT field samples from Rwanda (Amazi Meza) and Kenya (DRIP). The model and performance figures on this page follow the companion drinking-water paper (75 CBT samples, 194 sensor–CBT pairs). All four FARs are resolved. Open the Pilot Report & FAR Resolution Evidence →
The proposed dMRV solution integrates Virridy’s Lume sensor into a Safe Drinking Water Supply (SDWS) project — demonstrated in the team’s institutional water treatment project in Rwanda — to remotely and continuously monitor treatment-system operation and estimate treated water quality. By deploying a network of IoT-enabled fluorescence sensors at the point of consumption, the system provides near-real-time, high-resolution data on microbial drinking water quality (E. coli risk), replacing or augmenting traditional periodic manual sampling with automated, cloud-based reporting.
This dMRV approach digitizes critical aspects of water system use and water quality monitoring, making manual and periodic water sampling more cost effective and efficient with continuous, automated assessments. It also improves the verifiability and transparency of monitoring data, supporting compliance with Gold Standard certification requirements.
While microbial water quality is the central focus of this dMRV implementation, the plan also includes exploration of two additional measurement parameters enabled by the Lume system: monitored quantity of safe water treatment and estimated days of operation of the water treatment system.
The objectives of this project are: (i) Schools from rural communities have access to safe water and (ii) CO₂ emissions are avoided. This project will address critical access to safe water, whilst contributing to the avoidance of greenhouse gas emissions from the boiling of unsafe water.
The proposed dMRV solution integrates Virridy’s Lume sensor into a Safe Drinking Water Supply (SDWS) project — demonstrated in the team’s institutional water treatment project in Rwanda — to remotely and continuously monitor treatment-system operation and estimate treated water quality. By deploying a network of IoT-enabled fluorescence sensors at the point of consumption, the system provides near-real-time, high-resolution data on microbial drinking water quality (E. coli risk), replacing or augmenting traditional periodic manual sampling with automated, cloud-based reporting.
The primary challenge addressed by this dMRV solution is the lack of continuous, objective, and easily verifiable monitoring of microbial drinking water quality in carbon-financed water treatment programs.
Although the microbial water quality of treated water is not typically expected to indicate contamination, the absence of high-resolution data reduces the ability to validate performance over time. Conventional monitoring relies on infrequent grab samples that may not capture variability in treatment performance or contamination events.
This challenge is especially pronounced in household and institutional water treatment (HWT/IWT) programs like those in Rwanda, where water can be contaminated post-treatment due to improper use, filter degradation, or environmental factors. Without continuous data, it is difficult to provide high-confidence assurance that treated water consistently meets safety standards.
To close this gap, the proposed dMRV solution deploys Virridy’s Lume sensor to digitally monitor microbial water quality at the point of consumption. The approach is treatment-technology-agnostic: the same sensor and protocol monitor microbial water quality (and treated-water presence) at the point of consumption for any SDWS safe-water supply — filtration, chlorination, borehole, or piped distribution — with the Amazi Meza filtration program serving as the Phase 1 demonstration rather than a constraint on applicability.
By digitizing these MRV components, the solution provides a higher level of assurance that users are consistently receiving microbiologically safe water, reinforcing the validity of GHG reduction claims tied to the displacement of boiling.
The proposed dMRV solution leverages the Lume sensor to continuously estimate E. coli contamination at the point of consumption (the treated water from the project’s safe-water supply, such as a filtration or chlorination system) and transmits data via cellular networks to cloud-based dashboards for reporting and auditing.
The dMRV solution digitizes the monitoring, reporting, and partial verification components of the MRV framework. Sensor technology captures microbial water quality and water system uptime metrics, while cloud platforms handle data aggregation, analysis, and structured reporting for project developers and verifiers.
The Lume device collects microbial water quality data continuously in the safe-water storage of the treatment system (for example a gravity filter, a chlorination dispenser, or a treated-water tank). In some cases, the Lume will also collect data on the untreated water source. Data is stored locally on the device and transmitted over cellular networks to a secure cloud platform for aggregation and analysis.
Raw data collected by the Lume sensor undergoes processing in a right-censored linear regression (Tobit model). The model outputs quantification and prediction error of E. coli contamination risk aligned with WHO risk classifications. Automated dashboards present key metrics in real time, with alerts triggered for anomalies such as elevated contamination or extended sensor inactivity.
The system generates standardized reports summarizing microbial water quality performance (E. coli risk category in CFU/100mL) over defined intervals (e.g., daily, weekly). These reports are accessible via the cloud platform and can be exported for inclusion in Gold Standard monitoring and verification documentation.
The dMRV solution integrates multiple digital technologies to enable continuous, accurate, and verifiable monitoring of microbial drinking water quality.
The core data collection technology is an Internet of Things (IoT) sensor, the Lume, developed by Virridy. The Lume is a fluorescence sensor, measuring tryptophan-like fluorescence (TLF) at 273/350 nm excitation/emission wavelengths (Knopp et al., Water Research 302, 2026). TLF is a biological marker correlated with microbial activity and fecal contamination across groundwater, surface water, estuarine, and urban watershed environments globally. A right-censored linear regression (Tobit model) estimates E. coli contamination from fluorescence and turbidity data. The sensor also includes integrated turbidity and temperature sensors as well as a water presence detector to monitor system uptime and infer treatment volumes.
Data collected by the sensor is processed using a transparent right-censored linear regression (Tobit model) on log10(MPN+1), censored at the CBT upper limit of 100 MPN/100 mL. Fluorescence is corrected to 20 °C on the unit’s own temperature sensor. The model has four features: fluorescence relative to the unit’s clean-water baseline (F, natural-log difference), the natural log of the ratio of ToF to the baseline ToF (B), temperature relative to 20 °C (T), and F × T. The coefficients are shared by all units, with no unit-specific intercepts or slopes:
ŷ = 0.214 + 1.205 F + 5.264 B − 0.0064 T − 0.0150 F×T, σ̂ = 0.48
A sample is classified at or above 10 MPN/100 mL when the predicted concentration reaches 3.66 MPN/100 mL, and at or above 1 MPN/100 mL at 1.25. There is no machine learning or black-box inference; any third party can reproduce each prediction from a unit’s readings and its baseline.
The model was fitted to 194 sensor–CBT pairs from 3 units, forming 75 samples (40 in Rwanda, 35 in Kenya) over 12 sampling days. Each sample was predicted by a model fitted without that unit and without that day, the case of a newly deployed unit. At 10 MPN/100 mL the Lume detected 15 of 16 samples at or above the threshold and correctly classified 55 of 59 below it: balanced accuracy 0.93 (95% CI 0.76 to 0.98), positive predictive value 0.79 and negative predictive value 0.98. With the day held out for all units, balanced accuracy was 0.92. Of the 75 samples, 67 (89%) fell within ±0.92 log10 of the CBT result, and Willmott’s index of agreement was 0.82. Calibrating each unit against CBT results did not improve on the clean-water baseline; removing the ToF input lowered balanced accuracy to 0.72. Source: Knopp, Ecklu, Ross and Thomas, companion drinking-water paper; data at validation.thelume.ai/cbt.
All sensor data is transmitted to a secure cloud-based data platform that stores, aggregates, and organizes information by device, location, and time period. The platform provides secure, role-based access for project developers, verifiers, auditors, and other stakeholders.
Performance is influenced by dissolved organic carbon (DOC), humic-like fluorescence, turbidity, and temperature; fluorescent water with few culturable E. coli and clear water with culturable E. coli both disagree with a culture reference. Three of the four false alarms in the paper were rainwater tanks in Rwanda. The evaluation covers three units over 12 sampling days, with 16 samples at or above 10 MPN/100 mL, so sensitivity is imprecise (95% CI 0.60 to 1.00). It evaluated portable grab-and-read use; permanent in-line installation was not evaluated.
The technology has been prototyped, validated in the lab and deployed in various field conditions, including the application for the proposed dMRV application. It is around level 7 on the TRL scale.
This TRL level supports deployment across a significant portion of the market, especially in contexts requiring reliable, continuous, and remote monitoring of water systems. The system’s design is adaptable to other water project types (e.g., household water treatment, community water supply).
The solution incorporates mature digital data collection capabilities, including:
Additionally, the dMRV solution leverages advanced technologies to enable “smart” operations, including:
The dMRV solution applies to a specific subset of material GHG sources. Specifically, greenhouse gas emissions avoided through the consistent delivery of microbiologically safe drinking water that displaces the need for boiling.
The following MRV processes could be automated:
These MRV processes still require human intervention:
The digital technologies integrated into the dMRV solution include a physical IoT sensor device paired with a transparent estimation model that reports estimated E. coli contamination risk in near real time.
The Lume sensor is the key hardware component of the dMRV system. It is an IoT fluorescence-based E. coli sensor that can also estimate treatment-system use and treated-water volumes with a water presence sensor. Data gathered directly by the Lume sensor is transmitted to a remote and secure cloud-based data platform for processing with the estimation model.
The estimation model is the primary software in the dMRV system. It uses a right-censored linear regression (Tobit) to estimate E. coli concentration from raw sensor data. Input features are temperature-corrected fluorescence relative to the unit’s clean-water baseline, the ToF ratio to its baseline, temperature, and fluorescence × temperature. The coefficients are shared by all units; the clean-water baseline is the only per-unit term. The model is fully specified by an intercept and four coefficients, with no machine learning, decision trees or ensemble methods.
Model outputs are pulled into a dashboard that provides water quality data to accrediting agencies, municipalities, implementing partners, and other stakeholders. The system requires no consumables or lab infrastructure, enabling autonomous continuous monitoring at significantly lower operational costs than traditional methods.
The dMRV solution is protected by two issued U.S. patents:
This parameter is fully digitized, potentially replacing or at minimum increasing the efficiency and cost effectiveness of manual, periodic water quality testing. The Lume sensor captures near real time microbial quality measurements at the point of consumption, transmitted to a cloud platform for automatic analysis and reporting.
Lume includes internal water presence / absence sensors that can infer operational days based on system activity. While the sensor can autonomously estimate uptime, a more extensive field deployment will be needed to validate the accuracy and reliability of this method before it can be considered fully digitized.
This parameter is being evaluated as part of the dMRV plan. While the Lume may be able to track water flow events and link them to microbial safety data, further development is needed to validate volume estimation accuracy.
While routine maintenance and calibration are supported by automated alerts and diagnostics from the sensor, the actions themselves (e.g., cleaning, sensor replacement) are conducted by field technicians and documented manually in digital logs.
Although the proposed dMRV solution digitizes key monitoring and reporting activities, certain MRV tasks still require manual human involvement:
Why Required: Initial installation of the Lume device requires trained technicians to ensure proper installation and network connectivity.
Integration with Digital System: The installed sensor is logged manually and linked to the cloud-based platform.
Why Required: To maintain data accuracy, periodic physical inspection and maintenance of the sensor hardware is required (e.g., cleaning optical components, charging/replacing batteries).
Why Required: Manual water sampling using lab or field-based tests (e.g., membrane filtration or Compartment Bag Test) may be periodically conducted to validate the Lume’s automated microbial readings.
Integration with Digital System: Validation results are manually recorded and can be used to assess the performance of the estimation model.
Future Digitization: Future improvements could include integration of field kit results into the cloud dashboard and automated comparison with Lume data for real-time model refinement.
Why Required: While most data anomalies, such as sensor offline periods, are flagged automatically, human interpretation is needed to determine cause and whether corrective action is warranted.
The dMRV system combines automated and manual processes in a complementary manner to ensure verifiable monitoring of safe water delivery. Automated microbial monitoring and data transmission via the Lume sensor form the backbone of the system, generating continuous, time-stamped water quality data without the need for manual intervention.
Manual interventions, such as sensor maintenance and repairs, are triggered by automated alerts (e.g., sensor offline or abnormal readings). Alerts identify intervention requirements at designated thresholds and are logged to ensure traceability of manual actions.
Periodic water quality validation will be performed with field compartment bag tests. Time-stamped water quality data will be recorded by enumerators in mWater, a cloud-based data platform. Data will be used to validate and continuously improve the Lume estimation model.
SDWS 18 – Microbial Drinking Water Quality: Measured using the Lume sensor, which detects tryptophan-like fluorescence (TLF) as an estimate of E. coli contamination within the same error bounds as lab-based methods.
Reporting Structure: Web-based dashboard for real-time monitoring and historical data visualization.
Reporting Frequency:
Key Performance Indicators:
Traditional MRV methods rely on infrequent, single point-in-time, water quality testing, user surveys, or physical inspections, which introduce potential uncertainty and may fail to capture variability in system performance over time.
This high-frequency monitoring enables the detection of potential temporal trends in water quality and increases the likelihood of capturing contamination events if they occur. As a result, the dMRV system offers stronger assurance that claimed emission reductions are backed by reliable, continuous evidence of safe water delivery.
We anticipate having sensors installed continuously at a sample of water treatment systems, enabling at least 200× more daily samples than currently required in the Gold Standard methodology.
The dMRV system provides real-time access to performance data via secure cloud dashboards, enabling project developers, verifiers, and Gold Standard reviewers to evaluate project outcomes at any time. This reduces information asymmetry between project operators, auditors, and credit buyers.
By automating microbial monitoring, data transmission, and reporting, the system reduces the need for frequent field visits, lab testing, and manual data processing. This lowers the overall cost per data point while improving the confidence and resolution of MRV outputs.
Digitized water quality data provides a higher level of assurance to buyers and certification bodies that claimed emissions reductions are backed by verifiable, high-resolution water quality data.
| Metric | Traditional MRV | Lume-enabled dMRV | Improvement |
|---|---|---|---|
| Microbial sampling frequency | Quarterly to annual | Hourly or daily | 100×+ |
| Data completeness | Limited (discrete samples) | Continuous stream | Significantly improved |
| Human involvement | High | Low | Reduced cost & error |
| Auditability | Moderate (paper-based) | High (cloud-based, time-stamped) | Stronger transparency |
| GHG estimation confidence | Medium | High | Greater accuracy & conservativeness |
This dMRV solution proposes minor updates to the Gold Standard methodology titled “Emission Reductions from Safe Drinking Water Supply” (Version 1.0) to accommodate the integration of Virridy’s Lume digital monitoring technology.
Allow the use of automated microbial monitoring devices (e.g. the Lume) on a statistically random and valid sample of installed water treatment systems to replace or complement manual sampling for SDWS Parameter 18 (Microbial Drinking Water Quality).
The current methodology relies on periodic manual testing or indirect evidence of water quality. Automated, high-frequency measurements provide a higher resolution dataset that can detect performance fluctuations and contamination events in near real time, substantially improving data quality for emissions quantification.
The methodology’s core intent is to conservatively quantify GHG emission reductions resulting from reduced boiling of water for purification. The dMRV solution enhances this intent by providing stronger, more continuous evidence that water treatment systems are effectively delivering safe water — the foundational assumption behind the crediting of emissions reductions.
The quantification approach remains unchanged, but the underlying assumptions about technology performance are now supported by continuous digital evidence rather than periodic manual verification, improving overall confidence in credited emissions reductions.
The implementation of a digital MRV system introduces a range of technical, operational, and contextual risks. The table below outlines the key risks associated with the use of Virridy’s Lume device in the proposed dMRV application and corresponding mitigation strategies.
| Risk | Description | Mitigation |
|---|---|---|
| Connectivity & Data Transmission Failures | In areas with limited or unreliable cellular network coverage, real-time data transmission from the Lume sensor to the cloud platform may be interrupted. | Lume includes local data storage to buffer readings during outages. Data is automatically uploaded once connectivity is restored. Site selection considers network strength, and alternative communication protocols can be evaluated. |
| Sensor Malfunction or Calibration Drift | Over time, sensors may drift or malfunction, leading to inaccurate microbial readings. | The estimation model references each unit to its clean-water baseline, set at installation and re-set at each cleaning visit for installed units. Preventive maintenance schedules (lens cleaning), periodic field sampling for model validation, and remote sensor diagnostics are part of the solution. |
| Power Supply Interruptions | The Lume sensor may stop functioning due to depleted or damaged power sources (e.g., battery failure). | Low-power design with swappable, rechargeable batteries. Battery status is monitored remotely via diagnostics, and field teams are alerted to replace or recharge units before power loss. |
| Data Gaps & Incomplete Records | Equipment failure or transmission delays may result in missing data, affecting the completeness of the MRV dataset. | Automated data integrity checks and alerts. Gaps are investigated by field teams, and assumptions around data completeness are transparently documented during reporting. |
| Limited Local Maintenance Capacity | In rural deployment areas, limited technical expertise may delay troubleshooting or repairs. | Virridy’s local technicians are trained on installation, maintenance, and supported with remote diagnostics. |
| Cybersecurity & Data Privacy | Unauthorized access to cloud systems could compromise data integrity or violate privacy protocols. | Role-based access controls on the platform. No personally identifiable information is collected, minimizing privacy concerns. |
The proposed dMRV solution is designed for scalability across geographies and adaptable for other water project types and sectors. Its portable and compact design, use of cellular networks, and cloud-based data architecture make it suitable for a variety of deployment contexts.
The Lume device can be deployed across a wide range of institutional, household, or community water treatment systems. Scaling to additional regions is feasible wherever basic mobile connectivity is available, and the solution requires minimal on-site infrastructure.
The solution is not limited to institutional filter projects; it can be adapted to other water projects (e.g., community water supply, household water treatment). The sensor can be potentially customized for different deployment contexts and regulatory frameworks.
Per-site costs decrease significantly at scale due to economies of scale in hardware procurement, cloud hosting, and technician training. Automated data workflows reduce MRV transaction costs over time.
Initial capital for dMRV deployment is allocated within the broader project implementation budget. Additionally, the Lume sensor’s applicability across other sectors (e.g., environmental monitoring) creates potential for cross-subsidization and diversified funding sources.
Local technicians are trained to install, maintain, and troubleshoot Lume sensors, ensuring immediate on-the-ground capacity. However, the dMRV system is designed to be delivered as a subscription-based service, where Virridy provides ongoing hardware support, data management, cloud hosting, and model maintenance. This reduces the dependence on local technical expertise for system operation.
Virridy currently operates carbon credit projects across multiple countries in Sub-Saharan Africa:
The dMRV solution offers clear environmental benefits over conventional MRV approaches while maintaining a minimal footprint.
Please see:
The dMRV solution is designed to be low-maintenance, and accessible to users and stakeholders with minimal technical expertise.
The Lume dashboard provides real-time sensor telemetry, water quality classifications, and historical data visualizations:
Raw data can be accessed and reviewed through the cloud platform API or retrieved as .csv or .xlsx files from the Virridy team. To protect their integrity, raw data are never directly edited or used in their raw form for reporting. Instead, raw data are processed through the estimation model, which outputs water quality estimates and classifications for reporting.
E. coli estimates and categorization with the estimation model can be verified with the designated coefficients and features. The model is a closed-form Tobit regression with an intercept and four published coefficients shared by all units. Feature data are the sensor inputs used to predict E. coli: temperature-corrected fluorescence and the ToF turbidity proxy, each relative to the unit’s clean-water baseline, and temperature. All coefficients and feature data are available for verification by auditors.
Raw and processed data is available to an auditor. Non-conflicted third party academics at the University of Colorado Boulder and Colorado State University will provide an independent analysis of the model and approach.
The dMRV solution meets and in some instances exceeds MRV performance standards and IT/cybersecurity requirements set by Gold Standard and other certification bodies.
The system enables high-confidence certification by providing:
The platform follows current best practices in data security and privacy:
The dMRV solution is supported by a robust ecosystem of technical infrastructure, trained personnel, and expert partnerships that ensure reliable operation and long-term scalability.
Virridy provides technical support for the Lume sensor through a subscription-based service model. This includes:
This model ensures continued system performance while reducing the long-term technical burden on local project owners.
Local technicians and project staff are trained in:
The dMRV solution benefits from strategic collaborations, including:
This integrated support system ensures that the dMRV solution remains functional, auditable, and aligned with evolving certification and technology standards.
Lume sensor validation (Rwanda + Kenya) and permanent O&M installation on DRIP FUNDI piped systems in Kenya
This pilot deploys the Virridy Lume sensor in two phases. Phase 1 uses Lume in a mobile configuration to rapidly build a CBT-validated dataset, collecting paired water samples across the Amazi Meza program in Rwanda and the DRIP FUNDI program in Kenya. Phase 2 installs Lume permanently on a representative sample of DRIP FUNDI piped water systems in Kenya for continuous, program-level operations & maintenance monitoring and for SDWS 23/27 flow-parameter validation. (Phase 2 venue updated from the originally approved Amazi Meza, Rwanda; see the revision note in the Phase 2 section.)
Together, these phases establish the validation evidence required by the dMRV Pilot 14 approval and the operational infrastructure for scaled digital monitoring of the Amazi Meza program.
Rather than installing Lume sensors permanently at Amazi Meza schools for the validation phase — which would require extensive installation effort and repeated site visits to collect water samples — a mobile Lume configuration enables rapid, high-throughput data collection:
The Compartment Bag Test is the ideal reference method for this validation because:
Amazi Meza (“Clean Water” in Kinyarwanda) is Virridy’s school-based drinking water program in Rwanda. LifeStraw Community gravity-fed purifiers are installed in classrooms, providing safe drinking water to students without the need for boiling. The program is operated by Virridy Rwanda Ltd in partnership with the Rwanda Environmental Management Authority (REMA) and district governments, and is sustainably financed through carbon credit sales.
| Sample Point | Location | Expected Water Quality |
|---|---|---|
| Pre-treatment (source) | Source water inlet / raw (untreated) water before the treatment unit | Variable E. coli levels depending on source |
| Post-treatment (treated) | Treated water outlet from the treatment unit | <1 CFU/100mL (if filter intact and functioning) |
Deploy Lume sensors in a mobile (handheld) configuration across Rwanda (Amazi Meza) and Kenya (DRIP), collecting paired Lume readings and Compartment Bag Test samples at pre- and post-filtration points. This builds the CBT-validated dataset required for dMRV model calibration and satisfies FAR 1 (Sensor Validation) and FAR 2 (Model Documentation).
A Virridy Rwanda field team travels to schools with portable Lume sensors and CBT kits. At each school, two paired measurements are taken per classroom filter sampled:
Each school visit produces at minimum 2 paired Lume–CBT data points. Schools with multiple classroom filters can yield additional pairs per visit. The dataset grows rapidly compared to fixed-installation approaches.
| Parameter | Target |
|---|---|
| Schools visited | 80–120 |
| Paired samples per school (pre + post filtration) | 2–4 (depending on number of classroom filters) |
| Total paired Lume–CBT samples | 200–300 |
| Repeat visits (subset for temporal variability) | 15–25 schools |
| Total paired samples (incl. repeats) | 250–350 |
Phase 1 mobile validation is underway across two programs:
| Parameter | Actual |
|---|---|
| Sensors deployed | 3 — 50045 (Rwanda/Amazi Meza), 50053 (Kenya/DRIP), 50065 (both programs) |
| Date range | May 25 – June 11, 2026 |
| CBT records collected | 123 (11 excluded for protocol non-compliance or invalid result) |
| Paired CBT records | 110, forming 75 samples (40 Rwanda, 35 Kenya) over 12 sampling days |
| Sensor–CBT pairs | 194 (50045: 36, 50053: 52, 50065: 106) |
| Sampling type | Source (untreated) 33 + Treated (post-filtration/chlorination) 42 samples |
EP Nyakabungo, EP Nyakabuye, EP Rwishwima, plus warehouse test sites in Kicukiro and Kamonyi districts.
Isiolo County (Garbatula, Ngaremara), Turkana County (Loima, Turkana South, Turkana West).
| Metric | Value |
|---|---|
| Balanced accuracy (≥10 MPN), new sensor and new day | 0.93 (95% CI 0.76–0.98); 15/16 detected, 55/59 correct below |
| Balanced accuracy (≥10 MPN), day held out | 0.92 (95% CI 0.62–0.99) |
| Balanced accuracy (≥1 MPN), new sensor and new day | 0.73 (95% CI 0.53–0.86) |
| Within ±0.92 log10 of CBT | 67/75 (89%) |
| Willmott index of agreement | 0.82 |
| Same side of 10 MPN as CBT | 70/75 (repeat CBTs: 36/38) |
Live validation results: validation.thelume.ai/cbt
Record GPS coordinates, school name, number of classroom filters, filter serial numbers, and system status.
Collect water from the untreated source (raw water inlet before the treatment unit). Take Lume reading (60 seconds). Fill CBT bag from same source.
Collect water from the treated output (treatment-unit outlet). Take Lume reading (60 seconds). Fill CBT bag from same source.
Seal and label CBT bags (school ID, sample point, date/time). Incubate at ambient temperature for 24–48 hours. Read and record WHO risk category result.
Upload paired Lume–CBT data to cloud platform. Lume readings auto-sync; CBT results entered via mobile app with school ID linkage.
| Item | Quantity | Purpose |
|---|---|---|
| Lume sensor (mobile config) | 2 | Primary + backup for simultaneous pre/post sampling |
| CBT kits | 20–30 per day | 2–4 per school + duplicates + blanks |
| Sample collection bottles | 10 | Sterile 500mL bottles, reused after decontamination |
| GPS-enabled phone/tablet | 1 | School logging, photo documentation, CBT data entry |
| Incubation container | 1 | Portable insulated box for ambient-temp CBT incubation |
| Clean water reference | 1L | Daily Lume calibration check |
With two Lume sensors and efficient routing between schools, a field team can visit 8–12 schools per day, generating 16–36 paired Lume–CBT samples. A three-week field campaign yields 250–350 paired samples.
Each record in the validation dataset contains:
| Field | Source | Description |
|---|---|---|
| School ID | Field team | Unique identifier linked to Amazi Meza program database |
| GPS coordinates | Phone/tablet | Latitude/longitude of school |
| Sample point | Field team | Source (pre-treatment) or treated (post-treatment) |
| Treatment-unit serial number | Site metadata | Treatment-unit identifier (e.g., filter or chlorination dispenser) |
| Treatment-unit age / last maintenance | Program records | Days since installation or last backwash/replacement |
| Lume TLF intensity | Lume sensor | Tryptophan-like fluorescence (ppb) |
| Lume turbidity | Lume sensor | NTU reading from integrated sensor |
| Lume temperature | Lume sensor | Water temperature (°C) |
| CBT WHO risk category | CBT result | Low / Intermediate / High / Very High |
| CBT MPN estimate | CBT result | Most Probable Number E. coli per 100mL |
| Filter status | Field team | Operational / partially functional / non-functional |
| Classroom location | Field team | Classroom number or identifier within school |
| Timestamp | Auto | Date and time of sampling |
The originally approved Implementation Plan sited Phase 2 permanent installations at Amazi Meza schools in Rwanda. Based on the completed Phase 1 mobile validation (conducted across both Rwanda and Kenya), Virridy is updating this plan to site Phase 2 long-term installation validation on the DRIP FUNDI piped water systems in Kenya, because piped infrastructure is the appropriate setting to validate the SDWS 23 (volume) and SDWS 27 (operational days) flow parameters. This update is a request pending Gold Standard approval; the formal request is set out in Pilot Report v0.2. Amazi Meza (Rwanda) remains the approved host crediting programme.
Install Lume sensors permanently at a statistically representative sample of at least 20 DRIP FUNDI piped water systems in Kenya to provide continuous, program-level operations and maintenance monitoring, and to validate the SDWS 23 (volume) and SDWS 27 (operational days) flow parameters that piped infrastructure is best suited to demonstrate. This satisfies FAR 3 (Integration of Manual and Digital Processes) and establishes the operational dMRV infrastructure for ongoing carbon credit verification.
| Parameter | Value |
|---|---|
| Systems in program | DRIP FUNDI: ~200 boreholes / piped community water points serving ~120,000 people |
| Lume installations | At least 20 DRIP FUNDI sites (target 30–50 sensors) |
| Sample rate | ~10–25% of the DRIP FUNDI piped-system program |
| Selection criteria | County-level representation across the DRIP FUNDI service area (Isiolo, Turkana), mix of source water types and piped-system configurations, and urban/rural settings |
| Parameter | Method | O&M Application |
|---|---|---|
| Microbial water quality | TLF → Tobit regression → WHO risk category | Detect treatment failures, breakthrough, and contamination events |
| System uptime | Water presence/absence sensor | Track operational days, detect extended downtime or service interruptions (SDWS 27) |
| Treatment volume proxy | Water flow event counting | Estimate daily treated/dispensed water volume (SDWS 23) |
| Treatment integrity | Post-treatment TLF trending | Detect gradual treatment degradation, chlorination failure, or breakthrough |
| Phase | Activity | Duration | Deliverable |
|---|---|---|---|
| Phase 1 Mobile |
Logistics & team training | 1–2 weeks | Trained Virridy Rwanda field teams, equipment provisioned |
| Mobile sampling campaign across Amazi Meza schools | 3–4 weeks | 250–350 paired Lume–CBT samples | |
| Repeat visits at subset of schools | 1 week | Temporal variability data at 15–25 schools | |
| Analysis | Dataset compilation & QA | 1–2 weeks | Clean, validated dataset |
| CBT-based model development | 2–4 weeks | Trained categorical classification model, validation report | |
| Phase 2 Permanent |
Site selection & installation planning | 2 weeks | 30–50 selected schools across districts |
| Permanent Lume installations | 4–6 weeks | 30–50 sensors installed and transmitting | |
| Ongoing | Continuous O&M monitoring & model refinement | Ongoing | Real-time dashboards, periodic validation reports |
Total timeline: Phase 1 mobile validation completes in ~8–10 weeks. Phase 2 permanent installations follow over an additional 6–8 weeks. Full pilot operational within 4–5 months of launch.
The pilot generates evidence to close all four Forward Action Requirements raised during Pilot 14 approval:
| FAR | Requirement | Evidence from Pilot |
|---|---|---|
| FAR 1 | Sensor Validation & Calibration | 75 CBT samples (110 records, 194 sensor–CBT pairs) across source and treated waters in Rwanda and Kenya; replicate CBTs for 27 samples |
| FAR 2 | AI/ML Documentation | Shared-coefficient Tobit model, training data provenance, new-sensor-new-day validation, accuracy by WHO risk category |
| FAR 3 | Manual & Digital Integration | Phase 2 permanent sites demonstrate continuous digital monitoring with periodic manual CBT cross-checks during Virridy field visits to the DRIP FUNDI piped systems in Kenya |
| FAR 4 | SDWS 23 & 27 Exploration | Permanent installations evaluate water presence sensing for uptime (SDWS 27) and volume estimation (SDWS 23) |
Readiness of the Lume solution against the consultation draft of the Core Document Requirements for Digital MRV Solutions
Gold Standard has released for public consultation a Core Document, Requirements for Digital MRV Solutions, under which the VVB assesses a dMRV solution at each validation and verification in place of case-by-case pilot approval. Under clause 7.5, a solution approved under the pilot program, including Pilot 14, continues in operation and demonstrates conformity at the first verification after the requirements enter into force. Where a requirement has not been demonstrated, the affected data is treated as absent and substituted conservatively under clause 7.2.
The NOVA CERT dMRV technical validation (Version 1.0, 16 July 2026) was conducted under the pilot requirements. The first verification will be assessed against the new document. This section maps each requirement to the current state of the Lume solution, using the shared-coefficient model reported in the companion drinking-water paper (Knopp, Ecklu, Ross and Thomas), and sets out the work planned before that verification.
Clause numbers refer to the consultation draft. Status is as of October 2026.
| Clause | Current state of the Lume solution | Status |
|---|---|---|
| 3.2.1–3.2.3 | Every reading carries the device barcode and UTC sample time. The firmware, pipeline and model version are not yet stamped on each scored output. | Partial |
| 3.2.4 | The Notecard keeps a clock. Readings queued while offline are delivered with their original sample time and stored against it. | In place |
| 3.3 | Notehub event log for device activity. CBT exclusions and corrections recorded with a reason and the original value retained; history held in git. | Partial |
| 3.4 | Every raw reading is transmitted and retained in the cloud; no processing on the device. Model coefficients, paired records and analysis code published with the companion paper. | In place |
| 3.5 | Sensor-by-sensor gap logs produced for Phase 1. Availability from intended versus recorded observations is not yet computed per measurement point. | To do |
| 3.6.1–3.6.4 | Role-based access and automated backups in place. Periodic version check, database-level write protection and individual credentials to be demonstrated. | Partial |
| 3.6.6 | Full export of data, audit trail and version history in a non-proprietary format to be demonstrated. | To do |
| 3.6.7–3.6.10 | In-water test on both optical channels, GPS movement and offline flags operate. Limits not yet fixed in a deployment control statement. | Partial |
| 3.7 | Model coefficients are shared by all units. The per-unit configuration is the clean-water baseline. Configured level; baseline procedure for installed units to be stated. | Partial |
| 3.8 | Deployment control statement not yet written. | To do |
| 4.2 | Model evaluated for portable grab-and-read use in two programs. Permanent in-line installation not yet evaluated. | Partial |
| 4.4.2 | Performance reported with the sensor and the sampling day held out. Corroboration at installed units after coefficients are fixed still to come. | Partial |
| 4.5 | Residual sigma (0.48 log10) and the effect of each input reported. Not yet propagated to the SDWS 18 quantity. | Partial |
| 4.7 | Model form, coefficients, paired data and analysis code are public. | In place |
| 5.1, 5.4 | Changes tracked in git. Formal change log, covering the model changes since the approved Implementation Plan, to be created. | Partial |
| 5.2 | Change plan not yet written. | To do |
| 5.3 | Firmware updated over the air through Notehub. Authentication, failure handling and the update record to be documented. | Partial |
| 6.2.2 | Contracts with suppliers in the chain to be reviewed against the required terms. | To do |
| 7.2 | Substitution procedure for absent data to be implemented. | To do |
In the companion paper each sample is predicted by a model fitted without that unit and without that sampling day, the case of a newly deployed unit. At 10 MPN/100 mL the Lume detected 15 of 16 samples at or above the threshold and correctly classified 55 of 59 below it (balanced accuracy 0.93, 95% CI 0.76 to 0.98). The evaluation covers three units over 12 sampling days in three weeks, in two programs, with 16 samples at or above the threshold, and the model form was chosen on the same dataset.
Planned: CBT cross-checks at Phase 2 installed units, collected after the coefficients are fixed, as later-in-time corroboration reported at each verification.
The model coefficients are shared by all units, so a new unit needs no CBT calibration of its own. The only per-unit term is the clean-water baseline. In the paper, used as a portable instrument, the baseline was each unit’s readings in that day’s treated water. For a permanently installed unit the baseline will be set in clean water at installation and re-set at each scheduled cleaning visit. That use was not evaluated in the paper, so under clause 4.2.4 it is assessed before the data is relied on.
Planned: a change plan that names the baseline re-set at cleaning as an anticipated class of change, with the water used, the readings taken and the acceptance limits. The water must be verified clean: in the paper’s simulated treatment failure, a baseline moved half of the way toward each reading missed 5 of 16 exceedances.
The statement lists the controls the project operates for the assessed properties of the solution to hold. For Lume it will cover installation at the filter outlet; the cleaning interval and cap-handling procedure; the baseline set at installation and at each cleaning visit; CBT cross-check frequency; credential management; detection of device loss, failure and interference; the water types and turbidity and temperature ranges within which the model was evaluated; the plausibility limits below; and the action required on notice of a firmware change.
A control not completed within its interval makes that period’s data absent under clause 3.5.4, so each interval will be set at a frequency the field team can keep.
Current checks: a reading counts as in water only when both the fluorescence and ToF channels read below the unit’s own air/water split; GPS movement (warning at 100 m, alert at 500 m); and offline for more than 6 hours. For SDWS 18 the relevant interference is a sensor removed from the treated supply or placed in other water.
Planned: fix each unit’s air/water splits and the other limits in the deployment control statement before Phase 2 data is produced, treat flagged data as absent unless a documented investigation shows it is valid, and report the flagged proportion in each monitoring report.
Availability is computed per sensor from intended and recorded observations. The default thresholds are 90% and 80% over a 12-month lookback. Phase 1 was largely mobile, so intended observations were not defined; in Phase 2 the intended schedule is the configured sampling cadence. Battery life on battery-only units and the delivery of readings queued during long offline periods are the known causes of loss and are under test.
For SDWS 18 the conservative direction is a higher E. coli estimate, which lowers the certified quantity. A new Phase 2 sensor has no 12-month record, so under clause 7.2.6 its gaps take the methodology floor until that record exists.
Of 123 CBT records collected in Phase 1, 11 were excluded because the test did not follow protocol or gave an invalid result. One treated-outlet result was corrected from 48 to 0 MPN/100 mL when a replicate of the same filter, taken twelve minutes later, read 0. With the original 48 kept, balanced accuracy at 10 MPN/100 mL is 0.91 (15 of 17 detected, 54 of 58 correct below) against 0.93. Each monitoring report will state the proportion of values set by an operator and their net effect on the certified quantity.
Planned: demonstrate at the database layer that raw-reading tables reject update and delete operations; move exclusion and correction history from git to an append-only store; issue one credential per person and per system account; and run a scheduled check that the firmware and pipeline versions in operation match the recorded versions, with any mismatch flagging the affected data as not quality-assured.
On standardized inputs the model coefficients are 1.698 for the ToF ratio to baseline, 0.395 for fluorescence relative to baseline, −0.064 for the fluorescence × temperature term and −0.028 for temperature. Removing the ToF input lowers balanced accuracy for a new sensor on a new day from 0.93 to 0.72, so the health of the ToF channel will be a control in the deployment control statement. Planned: propagate the model residual (sigma 0.48 log10) to the SDWS 18 quantity.
Planned: a change log entry for each change to the creditable data chain, with date, components, version before and after, and reason. The first entries are the change from the gradient-boosted tree in the approved Implementation Plan to the 8-parameter Tobit model with per-sensor terms (April 2026), and from that model to the shared-coefficient model in the companion paper. For over-the-air firmware updates through Notehub, document how origin and integrity are confirmed before installation, what happens when an update fails, whether measurement pauses during installation, and keep a record of every attempted update.
Suppliers in the chain are Blues (Notecard and Notehub), the Pumphaus hosting provider, Cloudflare and mWater, together with any Virridy affiliate that supplies part of the solution. Each arrangement will be reviewed for access and audit rights for the VVB and Gold Standard, notification of changes and incidents, data export, continuity on termination, and a right of termination.
A solution provider may be recognized by Gold Standard for a specified solution core at a specified version, entered on a public register for up to three years. A VVB may then rely on the recognition and assess only the deployment. For Lume this would cover Amazi Meza (GS12240), the replicated Rwanda VPAs (GS23187, GS23556) and the DRIP program in Kenya (GS12223) under one assessment of the core. Shared coefficients make this simpler: every unit runs the same model, configured only by its baseline.
Once one verification on the Full Issuance Track has been completed with the solution in operation throughout, monitoring periods of 90 to 730 days may be verified and issued at up to 90% of the verified quantity, with the balance released at the next full verification. Phase 2 continuous monitoring is the precondition.
| Step | Deliverable | Clauses |
|---|---|---|
| 1 | Baseline procedure for installed units, evaluated before Phase 2 data is relied on | 4.2.4, 3.7 |
| 2 | Context of use with fixed permissible uses | 4.2, 3.6.8 |
| 3 | Deployment control statement | 3.8, 3.6.7 |
| 4 | Change plan, including the baseline re-set at cleaning | 5.2 |
| 5 | Change log covering the model changes since the Implementation Plan | 5.1, 5.4 |
| 6 | Version identifiers on every scored output; full data export | 3.2, 3.6.6 |
| 7 | Availability and substitution computed per sensor | 3.5, 7.2 |
| 8 | Database write protection, individual credentials, version check | 3.3, 3.6 |
| 9 | Uncertainty propagation to the SDWS 18 quantity | 4.5 |
| 10 | Phase 2 CBT cross-checks as later-in-time corroboration | 4.4.2, 4.9 |
| 11 | Supplier contract review | 6.2.2 |
Gold Standard invited views on specific provisions. Virridy’s positions from operating the Lume solution:
Lume readings queued during loss of connectivity arrive with their original sample time and are stored against it. We support 3.2.4(ii). Clause 3.2.4 could also state that a reading transmitted late counts as recorded when its sample time and sequence are intact, so that store-and-forward devices are not penalized under 3.2.4(iii) for transmission delay.
As a worked example for in-line water quality sensors: the Lume accepts a reading as in water only when both its fluorescence and time-of-flight channels read below the unit’s own air/water split, which catches a sensor lifted out of the supply; it flags GPS movement beyond 100 m and 500 m, which catches a sensor taken to another site; and it flags a unit offline for more than 6 hours. These limits are set per unit before deployment and stated in the deployment control statement.
Reference samples collected at deployed sites after a model’s coefficients are fixed are a different population from the data used to fit it, because they come from a later period the model has not seen. We ask that 4.4.2 state that such later-in-time reference samples qualify, so that the CBT cross-checks a program already runs can serve as corroboration.
Cellular, cloud and hosting suppliers offer standard terms that do not grant audit rights to the VVB or Gold Standard. A demonstrated full export under 3.6.6, retained by the Project Developer, could satisfy 6.2.2(iv) and (v) for such suppliers.
A newly installed sensor has no 12-month record, so 7.2.6 sends every gap in its first year to the methodology floor. A lookback equal to the sensor’s quality-assured record, with a stated minimum, would avoid penalizing expansion of a monitored network.
We support the 90% limit. Data quality is already handled by substitution under 7.2 and changes by 5.5.4, so the withheld 10% covers only the matters verified on the Full Issuance Track.
We support up to 24 months between physical site visits where a conforming solution covers every monitoring parameter, matching the 24-month Full Issuance Track cycle in 7.3.3.