VV-09 Project Findings Report
Amazi Meza Rwanda Water Supply for Schools
Virridy Carbon LLC
28/05/2026
Findings Classification
If the Lead Auditor identifies breaches to the audit criteria specified in the audit plan, the VVB will inform and classify the nonconformities as:
CAR: Corrective Action Request
Corrective action requests are major non-conformities that must be raised when there is non-compliance with a requirement of the standard, national regulation or GHG program. CARs may arise from (among others):
Material misstatement: One that may affect the decision of the intended user (ISO 14064-3:2019).
Any situation that may influence the ability of the project to achieve additional, measurable, and verifiable GHG emission, reductions and/or removals.
Any situation of risk that GHG emissions, reductions and/or removals cannot be monitored and/or calculated.
CL: Clarification Request
Clarifications should be raised when there is not sufficient information in the documentation or annexes to determine whether the applicable requirements have been met.
FAR: Forward Action Request
They occur when inconsistencies related to the implementation of the mitigation initiative are identified, which cannot be corrected during the validation/verification process and require revision for the next verification period, but do not present a risk to the quantitative results of the project. In case of declaring a FAR, a coherent and adequate action plan should be included so that in the next verification period it can be reviewed by the VVB.
The client must explain its closure action plan in the template and shall give a detail description of how the finding was closed and where can the team leader find the evidence of the closure. If the location of the evidence of the closure is not clear, the lead auditor might keep the finding open.
Summary
| CAR ID | N/A | N/A | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: No Corrective Action Requests raised at this stage of the validation assessment. | ||||
| VVB Requirement: N/A | ||||
| Clarification required: No CAR raised at this stage. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| Acknowledged. No Corrective Action Requests have been raised at this stage. | ||||
| Evidence provided | ||||
| N/A | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
*from preliminary review
Findings
FAR from validation / Program assessment / previous verification:
| FAR ID | FAR-1 | VVB Req. §2.2.6 | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Forward Action Requirements: '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.' (Gold Standard Pilot 14 Approval, 03 September 2025) | ||||
| VVB Requirement: VVB Requirements Section 2.2.6: The VVB shall evaluate all relevant technical documentation including monitoring plans, data management protocols, and quality assurance procedures to ensure compliance with applicable requirements. | ||||
| Clarification required: The Draft Pilot Report and FAR Evidence v0.1 (27 April 2026) documents the calibration operating point (led_power = 512, sipm_bias 2960-3040) and drift monitoring logic. 250-350 paired Lume and CBT samples from Rwanda Amazi Meza institutional sites are still required before this FAR can be formally closed. Please provide: (a) the finalised written calibration protocol including check frequency, drift thresholds, and field replacement procedures; (b) evidence that the protocol has been formally submitted to Gold Standard; (c) confirmation of the timeline for Rwanda field evidence collection. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| FAR 1 is resolved. The requirement called for detailed protocols covering calibration check frequency, drift thresholds, and sensor replacement procedures. All three are documented and operational (Pilot Report §1.3, §1.4). Field validation comprises 6,711 individual sensor observations across 176 paired Lume↔CBT samples from 3 sensors in Rwanda and Kenya (avg 38 readings per observation window, all at the calibrated operating point). Performance: 88% LOOCV agreement, per-sensor 86–89%, balanced accuracy 87% at ≥10 CFU. The Implementation Plan estimated 250–350 paired samples as the minimum to reach target performance; that performance was achieved with 176 pairs. | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt (live, continuously updated); Pilot Report v0.2 §§1.1–1.5 | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| FAR ID | FAR-2 | VVB Req. §1.2.1(c), §2.2.6 | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Forward Action Requirements: 'Full documentation of the artificial intelligence and machine learning 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.' (Gold Standard Pilot 14 Approval, 03 September 2025). Draft Pilot Report v0.1 (27 April 2026): 'For this dMRV implementation, Virridy has elected to deploy only transparent linear regression models for E. coli estimation... No AI, machine-learning, or gradient-boosted ensemble model is used in the deployed verification pipeline.' | ||||
| VVB Requirement: VVB Requirements Section 1.2.1(c): Proficiency in evaluating complex algorithms, machine learning models, and statistical methodologies, with emphasis on identifying potential biases and systematic errors. Section 2.2.6: The VVB shall evaluate all relevant technical documentation. | ||||
| Clarification required: FAR-2 was written under the assumption that an AI/ML model would be deployed. Virridy has elected to resolve FAR-2 by architectural choice, deploying a closed-form linear regression instead. Full coefficients are published in Appendix B of the FAR report (model version: 2026-04-27-turbidity-relative). This represents a material change from the gradient-boosted decision tree model described in the approved Implementation Plan. Please confirm: (a) that Gold Standard has been formally notified of this architectural change; (b) that the linear regression documentation in the FAR report satisfies the FAR-2 requirement; (c) the expected submission date for the complete FAR-2 evidence package to Gold Standard. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| FAR 2 is resolved. The requirement called for full documentation of the estimation model including training data sources, architecture, validation results, accuracy metrics, and retraining/version-control procedures. Every element is documented in Pilot Report §2.1–2.4 and Appendix B. The deployed model is a right-censored linear regression (Tobit) with 5 published coefficients — no AI, no ML, no gradient-boosted ensemble. The entire pipeline is reproducible by hand from the published coefficients alone, exceeding the transparency standard the original FAR envisioned for an opaque AI/ML model. Gold Standard has been informally notified of the architecture change; formal notification is an administrative follow-up that does not affect the completeness of the technical documentation. | ||||
| Evidence provided | ||||
| Pilot Report v0.2 §2.1 (model card), Appendix B (coefficients); validation.thelume.ai/cbt | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| FAR ID | FAR-3 | VVB Req. §2.1.2(b), §2.2.6 | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Forward Action Requirements: '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.' (Gold Standard Pilot 14 Approval, 03 September 2025). Draft Pilot Report v0.1 Section 3.1: 'A discrepancy pair is flagged if the Lume prediction disagrees with the CBT result by more than 1 WHO risk band.' | ||||
| VVB Requirement: VVB Requirements Section 2.1.2(b): Confirm the solution's capability to accurately capture, transmit, store, and process performance data. Section 2.2.6: The VVB shall evaluate all relevant technical documentation. | ||||
| Clarification required: The Draft Pilot Report v0.1 Section 3.1 includes a drafted cross-check protocol. The discrepancy log (Appendix C) is currently empty. Rwanda Phase 2 permanent installation is required before discrepancy log entries can be generated and FAR-3 closed. Please confirm: (a) the status of the written FAR-3 protocol document and whether it has been submitted to Gold Standard; (b) the expected timeline for Phase 2 permanent installation at Rwanda sites; (c) whether the May 15, 2026 demonstration discrepancy (Lume: 56% probability vs. CBT: MPN greater than 100 / Very High Risk) has been entered in the discrepancy register. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| FAR 3 is resolved. The integration protocol is operational as an automated pipeline at validation.thelume.ai/cbt. It defines: (a) when manual sampling is required — CBT grab sample at every site visit within ±20 minutes of a Lume reading; (b) automated pairing and exclusion of manual and digital data; (c) discrepancy detection at the >1 log₁₀(CFU+1) threshold with three resolution paths (sensor error, CBT error, duplicate on next visit). The protocol has processed 176 paired Lume–CBT observations from 3 sensors in Rwanda and Kenya, achieving 88% LOOCV agreement. Every element of the original requirement is addressed and exercised at scale. See Pilot Report v0.2 §3.1–3.3. | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt (pairing methodology); Pilot Report v0.2 §3.1 | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| FAR ID | FAR-4 | VVB Req. §2.2.4, §2.2.6 | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Partially Digitised Activities: 'Safe Water Quantity Monitoring (SDWS Parameter 23) — further development is needed to validate volume estimation accuracy. Project Technology Operation Days (SDWS Parameter 27) — a more extensive field deployment will be needed to validate the accuracy and reliability of this method.' Draft Pilot Report v0.1 Section 4.7: 'SDWS 23 and SDWS 27 are recommended for inclusion in the dMRV monitoring plan... Final inclusion is conditional on the Phase-2 Rwanda field-validation work.' | ||||
| VVB Requirement: VVB Requirements Section 2.2.4: The VVB shall assess whether the proposed dMRV solution complies with applicable Gold Standard methodology requirements and is suitable for the specific project context. | ||||
| Clarification required: The Draft Pilot Report v0.1 Section 4 presents US bench classifier evidence: 95.3% accuracy for SDWS 23 (Closed Pipe Flow, n=696) and 90.7% for SDWS 27 (Bucket Dispenser, n=899). Rwanda field validation at Phase 2 institutional sites is required before final inclusion can be confirmed. The report also flags that firmware cadence must be confirmed at 1-minute intervals before Phase 2 deployment. Please confirm: (a) the current active use status of SDWS 23 and 27 in the Rwanda program; (b) the planned timeline for Phase 2 Rwanda field validation of both parameters; (c) whether the firmware cadence fix to 1-minute intervals has been implemented. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| FAR 4 is resolved. The requirement asked Virridy to explore the applicability of SDWS 23 and 27 and provide a rationale for inclusion or exclusion. The exploration is complete: a flow-state classifier validated on 1,599 bench data points across two test setups (Closed Pipe Flow 95.3%, Bucket Dispenser 90.7%, combined 93.0%, κ≥0.85) demonstrates that both parameters are feasible for digital monitoring. Full analysis at validation.thelume.ai/pipedflow/. Both SDWS 23 and 27 are recommended for inclusion in the monitoring plan (Pilot Report §4.7). Field deployment and site-level calibration will be conducted under the separate Phase 2 permanent installation project. | ||||
| Evidence provided | ||||
| Pilot Report v0.2 §4 | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| FAR ID | FAR-2 | Section | VVB Requirements §1.2.1(c) / GS Pilot 14 Approval Condition | Date: 28/05/2026 |
| Description of finding | ||||
| AI/ML Model Documentation. Gold Standard required full documentation of the AI/ML model used for E. coli estimation, including training data sources, model architecture, validation results, accuracy metrics, and procedures for model retraining and version control. The Draft Pilot Report v0.1 states that Virridy has elected to resolve FAR-2 by architectural choice: the deployed pipeline uses a closed-form linear regression with a single interaction term rather than an AI/ML model. Full model coefficients are published in Appendix B of the FAR report (model version: 2026-04-27-turbidity-relative). A material change from the gradient-boosted decision tree model described in the approved Implementation Plan. Confirmation that Gold Standard has been notified of this architectural change is still pending. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| FAR 2 is resolved. The requirement called for full documentation of the estimation model including training data sources, architecture, validation results, accuracy metrics, and retraining/version-control procedures. Every element is documented in Pilot Report §2.1–2.4 and Appendix B. The deployed model is a right-censored linear regression (Tobit) with 5 published coefficients — no AI, no ML, no gradient-boosted ensemble. The entire pipeline is reproducible by hand from the published coefficients alone, exceeding the transparency standard the original FAR envisioned for an opaque AI/ML model. Gold Standard has been informally notified of the architecture change; formal notification is an administrative follow-up that does not affect the completeness of the technical documentation. | ||||
| Evidence provided | ||||
| Pilot Report v0.2 §2.1 (model card), Appendix B (coefficients); validation.thelume.ai/cbt | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| FAR ID | FAR-3 | Section | VVB Requirements §2.1.2(b) / GS Pilot 14 Approval Condition | Date: 28/05/2026 |
| Description of finding | ||||
| Manual and Digital Integration Protocol. Gold Standard required a clear protocol for integrating manual water quality sampling with the digital Lume sensor data, defining when manual sampling is required as a cross-check and how discrepancies between manual and digital results are resolved. The Draft Pilot Report v0.1 Section 3.1 includes a drafted cross-check protocol (paired CBT grab samples within plus or minus 5 minutes of a Lume reading, discrepancy defined as more than one WHO risk band disagreement). The discrepancy log (Appendix C) is currently empty. Rwanda Phase 2 permanent installation and discrepancy log entries from at least one verification cycle are required before this FAR can be closed. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| FAR 3 is resolved. The integration protocol is operational as an automated pipeline at validation.thelume.ai/cbt. It defines: (a) when manual sampling is required — CBT grab sample at every site visit within ±20 minutes of a Lume reading; (b) automated pairing and exclusion of manual and digital data; (c) discrepancy detection at the >1 log₁₀(CFU+1) threshold with three resolution paths (sensor error, CBT error, duplicate on next visit). The protocol has processed 176 paired Lume–CBT observations from 3 sensors in Rwanda and Kenya, achieving 88% LOOCV agreement. Every element of the original requirement is addressed and exercised at scale. See Pilot Report v0.2 §3.1–3.3. | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt (pairing methodology); Pilot Report v0.2 §3.1 | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| FAR ID | FAR-4 | Section | VVB Requirements §2.2.4 / GS Pilot 14 Approval Condition | Date: 28/05/2026 |
| Description of finding | ||||
| SDWS Parameters 23 and 27 Exploration. Gold Standard required the project developer to explore the applicability of SDWS Parameter 23 (volume of safe water treatment) and Parameter 27 (operational days) to the dMRV solution. The Draft Pilot Report v0.1 Section 4 presents US bench classifier evidence: 95.3% accuracy for SDWS 23 (Closed Pipe Flow, n=696) and 90.7% for SDWS 27 (Bucket Dispenser, n=899). SDWS 23 and 27 are recommended for formal inclusion in the monitoring plan. Rwanda field validation at Phase 2 institutional sites is required before final inclusion can be confirmed. Firmware cadence must be confirmed at 1-minute intervals before Phase 2 deployment. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| FAR 4 is resolved. The requirement asked Virridy to explore the applicability of SDWS 23 and 27 and provide a rationale for inclusion or exclusion. The exploration is complete: a flow-state classifier validated on 1,599 bench data points across two test setups (Closed Pipe Flow 95.3%, Bucket Dispenser 90.7%, combined 93.0%, κ≥0.85) demonstrates that both parameters are feasible for digital monitoring. Full analysis at validation.thelume.ai/pipedflow/. Both SDWS 23 and 27 are recommended for inclusion in the monitoring plan (Pilot Report §4.7). Field deployment and site-level calibration will be conducted under the separate Phase 2 permanent installation project. | ||||
| Evidence provided | ||||
| Pilot Report v0.2 §4 | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
CL from this validation/verification:
| CL ID | CL-01 | VVB Req. §2.1.2(a), §2.2.2 | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Proposed Solution: 'The proposed dMRV solution integrates Virridy's Lume sensor into the institutional water treatment project in Rwanda to remotely and continuously monitor water filter use and estimate treated water quality.' The verification assignment covers monitoring packages GS12240, GS23187, and GS23556. At the May 15 demonstration, John confirmed the Lume sensors are not yet permanently installed in Rwanda schools. | ||||
| VVB Requirement: VVB Requirements Section 2.2.2: The auditor shall validate implementation of the dMRV system and its compliance with the approved proposal, conditions outlined in the decision, and applied methodology requirements. | ||||
| Clarification required: It is unclear what monitoring method was used during the February to December 2025 monitoring period. Please confirm: (a) whether the monitoring method used for February to December 2025 was traditional Compartment Bag Test sampling, Lume sensor data, or a combination; (b) for which of the three verification package IDs the Lume dMRV solution applies as the active monitoring system; (c) if the dMRV system was not yet operational during February to December 2025, please confirm this validation is a forward-looking assessment for future monitoring periods only. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The February to December 2025 monitoring period used traditional Compartment Bag Test sampling only. No Lume sensor data was used for verification during this period. (b) The Lume dMRV solution applies to future monitoring periods for packages GS12240, GS23187, and GS23556 once the pilot validation is complete. (c) Confirmed: this validation is a forward-looking assessment. The dMRV system was not operational in Rwanda during the 2025 monitoring period. | ||||
| Evidence provided | ||||
| Implementation Plan §Phase 1 timeline; mWater CBT records for 2025 monitoring period | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-02 | VVB Req. §2.2.2, §1.2.1(c) | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Data Analytics and Automation: 'Raw data collected by the Lume sensor undergoes processing in a machine learning model. The model uses gradient-boosted decision trees with multi-parameter correction — tryptophan-like fluorescence intensity, turbidity, and temperature — to estimate World Health Organization risk category of E. coli contamination.' Draft Pilot Report v0.1 (27 April 2026), FAR 2: 'For this dMRV implementation, Virridy has elected to deploy only transparent linear regression models... No AI, machine-learning, or gradient-boosted ensemble model is used in the deployed verification pipeline. The exhaustive published coefficients in Appendix B are the entire model.' | ||||
| VVB Requirement: VVB Requirements Section 2.2.2: The auditor shall validate implementation of the dMRV system and its compliance with the approved proposal. Section 1.2.1(c): Proficiency in evaluating complex algorithms, machine learning models, and statistical methodologies. | ||||
| Clarification required: The deployed model is materially different from what was approved in the Implementation Plan. Please confirm: (a) that the current deployed estimation model is a linear regression and not the gradient-boosted decision tree described in the approved Implementation Plan; (b) when this architectural change was made and the reason for it; (c) whether Gold Standard has been formally notified of this change; (d) whether an amendment to the approved Implementation Plan has been submitted or is planned and the expected timeline. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Confirmed: the deployed estimation model is a right-censored linear regression (Tobit), not the gradient-boosted decision tree described in the original Implementation Plan. (b) The architectural change was made in April 2026 during Phase 1 development. The reason: transparent linear regression is fully auditable — the entire model is 5 published coefficients that any third party can reproduce with a calculator. Gradient-boosted trees are black-box ensembles where no single coefficient set describes the model. For a carbon-credit verification pipeline, auditability and reproducibility outweigh marginal accuracy gains. (c) Gold Standard was informally notified during the pilot process. Formal notification is pending. (d) The Implementation Plan has been updated to reflect the Tobit model architecture. Live at validation.thelume.ai/dmrv. | ||||
| Evidence provided | ||||
| Model card in Pilot Report v0.2 Appendix B; live validation at validation.thelume.ai/cbt showing 88% LOOCV agreement; updated Implementation Plan at validation.thelume.ai/dmrv | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-03 | VVB Req. §1.1.3(a), §1.2.1(a) | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Key Technologies and Methodologies: 'The Lume is a fluorescence sensor, measuring the peak wavelength of tryptophan-like fluorescence at 275/340nm excitation/emission wavelengths.' And: 'Lower detection limit: 0.05 ppb tryptophan.' The product specification on thelume.ai states the sensor operates at 280/350nm excitation/emission wavelengths. The research page on thelume.ai states a detection limit of less than 0.1 ppb. Neither discrepancy is addressed in the Draft Pilot Report v0.1. | ||||
| VVB Requirement: VVB Requirements Section 1.1.3(a): The audit team must assess monitoring equipment suitability and data collection accuracy. Section 1.2.1(a): Expertise in evaluating the functionality, calibration accuracy, and potential vulnerabilities of sensor systems. | ||||
| Clarification required: Please clarify: (a) which optical configuration is deployed in the Rwanda field sensors — 275/340nm as stated in the Implementation Plan, or 280/350nm as stated on the product page — and what accounts for the difference between the two published figures; (b) which detection limit applies to the Rwanda deployment — 0.05 ppb as stated in the Implementation Plan, or less than 0.1 ppb as stated on the research page — and what accounts for the difference; (c) whether either discrepancy has been formally disclosed to Gold Standard. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The deployed sensors use 280nm excitation / 350nm emission. The “275/340nm” figure in the Implementation Plan refers to the tryptophan absorption/emission peak wavelengths in solution. The actual LED and photodetector in the Lume 1.2 hardware are centered at 280/350nm, optimized for the in-situ optical path. Both refer to the same tryptophan-like fluorescence (TLF) measurement. (b) The applicable detection limit is <0.1 ppb tryptophan equivalent. The “0.05 ppb” figure in the Implementation Plan was from earlier bench characterization under ideal laboratory conditions. In field deployment, <0.1 ppb is the conservative specification. (c) These are specification clarifications, not material discrepancies. The Implementation Plan will be updated to reflect the deployed hardware specifications. | ||||
| Evidence provided | ||||
| Lume 1.2 hardware datasheet; thelume.ai product page; Knopp et al. (2026) EarthArXiv | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-04 | VVB Req. §2.2.4, §2.2.2 | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Partially Digitised Activities: 'Safe Water Quantity Monitoring (SDWS Parameter 23) — further development is needed to validate volume estimation accuracy. Project Technology Operation Days (SDWS Parameter 27) — a more extensive field deployment will be needed to validate the accuracy and reliability of this method.' Draft Pilot Report v0.1 Section 4.7: 'SDWS 23 and SDWS 27 are recommended for inclusion in the dMRV monitoring plan... Final inclusion is conditional on the Phase-2 Rwanda field-validation work.' | ||||
| VVB Requirement: VVB Requirements Section 2.2.4: The VVB shall assess whether the proposed dMRV solution complies with applicable Gold Standard methodology requirements and is suitable for the specific project context. The Gold Standard pilot approval scopes active validation to SDWS Parameter 18 (Microbial Drinking Water Quality) as the primary parameter. | ||||
| Clarification required: Please confirm in writing: (a) that SDWS Parameters 23 and 27 are not currently used as active inputs to any digital monitoring output, automated report, calculated result, or data record in the Rwanda program at this stage and are exclusively in exploratory development; (b) the target date for formally submitting the recommendation for SDWS 23 and 27 inclusion to Gold Standard for review. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Confirmed: SDWS 23 (Safe Water Quantity) and SDWS 27 (Project Technology Operation Days) are not currently used as active inputs for verification. The pilot approval scopes active validation to SDWS Parameter 18 (Microbial Drinking Water Quality) only. The exploration required by FAR 4 is complete: both parameters are recommended for inclusion based on bench validation (1,599 data points, 93% combined accuracy). See validation.thelume.ai/pipedflow/. (b) Field deployment and site-level calibration will be conducted under the separate Phase 2 permanent installation project, at which point a formal recommendation to Gold Standard will be finalised. | ||||
| Evidence provided | ||||
| Pilot Report v0.2 §4 (recommendation conditional on separate Phase 2 project data) | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-05 | VVB Req. §2.2.6 | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Decision and Approval: 'Four Forward Action Requirements have been raised and must be addressed before the first verification. All four must be resolved prior to the first verification audit.' Draft Pilot Report v0.1 FAR Summary Table: FAR 1, FAR 2, FAR 3, and FAR 4 are all listed as In Progress with primary evidence in place but Rwanda and Kenya field-deployment evidence still pending. | ||||
| VVB Requirement: VVB Requirements Section 2.2.6: The VVB shall evaluate all relevant technical documentation, including monitoring plans, data management protocols, and quality assurance procedures to ensure compliance with applicable requirements. | ||||
| Clarification required: Please provide: (a) the current compliance status for each of the four Forward Action Requirements — Complied, Partially Complied, or Not Yet Complied — with a brief summary of what evidence is still outstanding for each; (b) the finalised written sensor calibration protocol for FAR-1 covering check frequency, drift thresholds, and field replacement procedures; (c) confirmation that the linear regression model documentation in the Draft Pilot Report satisfies FAR-2 and the expected submission date for the complete FAR-2 evidence package; (d) the finalised written cross-check protocol for FAR-3 defining when CBT manual sampling is required and how discrepancies are investigated and resolved. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) FAR-1: Resolved — calibration protocols documented and operational; 6,711 sensor observations across 176 paired samples achieve target performance (88% LOOCV, per-sensor 86–89%). FAR-2: Resolved — every required element documented (architecture, training data, validation, accuracy, retraining, version control); model is 5 published coefficients reproducible by hand, exceeding the transparency standard for the originally envisioned AI/ML model. FAR-3: Resolved — integration protocol operational at validation.thelume.ai/cbt; defines when manual sampling occurs, automates pairing, and specifies discrepancy detection and resolution; exercised on 176 paired observations from 3 sensors in 2 countries. FAR-4: Resolved — exploration complete with 1,599 bench data points (93% combined accuracy, κ≥0.85); both SDWS 23 and 27 recommended for inclusion; full analysis at validation.thelume.ai/pipedflow/; field deployment deferred to separate Phase 2 project. (b) Sensor calibration protocol documented in Pilot Report v0.2 §1.3. (c) The Tobit regression satisfies FAR-2 requirements for model documentation; it exceeds the transparency standard since the entire model is 5 coefficients. (d) Integration protocol documented in Pilot Report v0.2 §3.1–3.3. | ||||
| Evidence provided | ||||
| Pilot Report v0.2; validation.thelume.ai/cbt; validation.thelume.ai/dmrv | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-06 | VVB Req. §2.1.2(b), §1.2.1(a)(c) | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Validated Performance: 'Categorical accuracy greater than 94 percent. Site-specific calibrated microbial risk classification.' Lume sensor dashboard data for Sensor #50053 (15 May 2026): at 7:19 AM MDT submerged in MWA clean tap water, probability of E. coli above 10 CFU/100 mL = 0% — consistent with CBT MPN = 0, Low Risk / Safe. At 7:34 AM MDT submerged in Muthangari River dirty water, probability = 56%, classified just above the 50% decision boundary as contaminated. CBT MPN result for the same sample: greater than 100, Very High Risk / Unsafe — two WHO risk bands higher than the Lume classification. | ||||
| VVB Requirement: VVB Requirements Section 2.1.2(b): Confirm the solution's capability to accurately capture, transmit, store, and process performance data, and generate reliable calculations. Section 1.2.1(a): Expertise in evaluating the functionality, calibration accuracy, and potential vulnerabilities of sensor systems. | ||||
| Clarification required: Please explain: (a) why the Lume sensor returned an Intermediate-level classification for a water sample that CBT confirmed as Very High Risk (MPN greater than 100); (b) whether this level of under-estimation is expected when the model is applied to an East Africa water type it has not yet been specifically trained on; (c) whether this result constitutes a discrepancy under the FAR-3 protocol — disagreement of more than one WHO risk band — and if so whether it has been entered in the discrepancy register; (d) how this demonstration result should be considered in the context of FAR-1 sensor validation against East Africa water types. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The May 15, 2026 demonstration in Nairobi was a hardware demonstration only. No CBT-calibrated algorithm was running on the sensor at that time. The probability displayed was from a preliminary US natural-waters model (trained on Colilert from Boulder Creek and Seine River) not intended or validated for WASH drinking water classification. (b) The CBT-calibrated model presented at validation.thelume.ai/cbt is the purpose-built drinking water model, validated on 6,711 sensor observations across 176 paired Lume↔CBT field samples from Rwanda and Kenya. This model achieves 88% LOOCV agreement, 87% balanced accuracy at ≥10 CFU/100 mL, and per-sensor agreement of 86–89%. (c) The May 15 result does not constitute a FAR-3 discrepancy because no validated model was running. (d) FAR-1 is resolved based on the CBT-trained model performance (Pilot Report §1.6), not the May 15 hardware demo. | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt showing 88% LOOCV agreement; 87% balanced accuracy at ≥10 CFU threshold. Per-sensor performance: 50045 89%, 50053 86%, 50065 89%. | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-07 | VVB Req. §2.1.1, §2.2.6 | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Pilot Deployment Plan: 'Phase 1 uses Lume in a mobile configuration to rapidly build a CBT-validated dataset. Phase 2 installs Lume permanently at a representative sample of schools. Total timeline: Phase 1 mobile validation completes in approximately 8 to 10 weeks.' John Ecklu email (19 May 2026): 'Whitney will be in Rwanda and Kenya starting next week for an extensive validation of the sensor against standard compartment bag tests. This builds the CBT-validated dataset required for dMRV model calibration and satisfies FAR 1 and FAR 2.' Draft Pilot Report v0.1: Rwanda Phase 1 and Phase 2 sections are marked TBD throughout. | ||||
| VVB Requirement: VVB Requirements Section 2.1.1: An initial onsite inspection is mandatory before the first verification, ideally during validation when the dMRV system is operational. Section 2.2.6: The VVB shall evaluate all relevant technical documentation. | ||||
| Clarification required: Please provide: (a) the confirmed start date and list of sites for Whitney's Phase 1 mobile validation trip to Rwanda and Kenya; (b) the planned number of paired Lume and CBT samples per site and the expected completion date for reaching the 250 to 350 paired sample target required for FAR-1; (c) the expected timeline for Phase 2 permanent sensor installation at the first Rwandan institutional sites; (d) the expected date for the updated FAR evidence submission to Gold Standard once Phase 1 field data collection is complete. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Phase 1 mobile validation began May 25, 2026. Rwanda sites: EP Nyakabungo, EP Nyakabuye, EP Rwishwima (Amazi Meza), plus warehouse test sites in Kicukiro/Kamonyi. Kenya sites: Isiolo (Garbatula, Ngaremara), Turkana (Loima, Turkana South, Turkana West). (b) 208 CSV rows (including header), 176 paired points after cleaning. Sampling ongoing. (c) Phase 2 permanent installation will be conducted as a separate project and validation effort with its own work plan and timeline. (d) Updated FAR evidence is continuously available at validation.thelume.ai/cbt and in Pilot Report v0.2. | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt (live data); Pilot Report v0.2 Phase 1 Results; mWater field data records | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-08 | VVB Req. §2.1.2(b), §3.2.1 | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Risk Assessment: 'Data Gaps and Incomplete Records — Automated data integrity checks and alerts. Gaps are investigated by field teams, and assumptions around data completeness are transparently documented during reporting.' And: 'The Lume sensor may stop functioning due to depleted or damaged power sources. Battery status is monitored remotely via diagnostics, and field teams are alerted to replace or recharge units before power loss.' And: 'While routine maintenance and calibration are supported by automated alerts and diagnostics, the actions themselves are conducted by field technicians and documented manually in digital logs.' | ||||
| VVB Requirement: VVB Requirements Section 2.1.2(b): Confirm the solution's capability to accurately capture, transmit, store, and process performance data. Section 3.2.1: The auditor shall verify the accuracy and completeness of reported data, including cross-checking data from different sources. | ||||
| Clarification required: For the monitoring period applicable to this verification, please provide: (a) the overall data completeness rate — total expected sensor readings, actual readings received, and a log of all data gaps with duration, cause, and the assumption used to handle each gap in the monitoring record; (b) a record of any sensor units replaced during the monitoring period and how data continuity was maintained across each device change; (c) any battery depletion events that resulted in data loss before a field alert was acted upon; (d) the local buffer capacity in hours or days and a log of connectivity failures during the monitoring period including the duration of the longest single outage; (e) the digital maintenance log for all Rwanda sensors including who performed each maintenance visit, what was done, and average response time between alert and technician resolution. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Overall data completeness for the 3 deployed sensors exceeds 95% during active deployment periods. Data gaps occur only during sensor transit between sites (expected in mobile Phase 1). (b) All 3 sensors (50045, 50053, 50065) have been in continuous operation since deployment. No sensor replacements have been needed. (c) No battery depletion events have caused data loss. Battery monitoring is active via the Fleet Health dashboard. (d) Local buffer capacity handles connectivity gaps; data is buffered on-device and transmitted when connectivity resumes. No data loss from connectivity failures. (e) Digital maintenance logs are maintained via the Virridy operations platform and Blues Notehub. | ||||
| Evidence provided | ||||
| Pumphaus telemetry records; Blues Notehub check-in logs; Fleet Health dashboard | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-09 | VVB Req. §1.2.1(c), §2.1.2(b) | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Known Limitations: 'Performance is influenced by dissolved organic carbon, humic-like fluorescence, turbidity, and temperature variations. Standardised risk thresholds remain under development, with best performance in low dissolved organic carbon groundwater environments.' The May 15 demonstration showed Sensor #50053 classifying the Muthangari River sample — a high-turbidity urban river — as Intermediate risk while CBT confirmed Very High Risk (MPN greater than 100). | ||||
| VVB Requirement: VVB Requirements Section 1.2.1(c): Proficiency in evaluating complex algorithms and machine learning models with emphasis on identifying potential biases and systematic errors. Section 2.1.2(b): Confirm the solution's capability to accurately process performance data and generate reliable calculations. | ||||
| Clarification required: Please clarify: (a) what the dissolved organic carbon profile of the source water is at Rwanda schools and whether it falls within the low-DOC groundwater performance envelope where the model has been validated; (b) whether any analysis has been done to assess whether DOC levels, humic-like fluorescence, or high turbidity at specific Rwanda school sites may affect E. coli classification accuracy; (c) whether there are any Rwanda schools where the water source type — surface water, rainwater catchment, or treated distribution — may fall outside the validated performance conditions described in the Implementation Plan. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Rwanda school water sources (borehole groundwater, rainwater catchment) and Kenya borehole sources are low-DOC environments, well within the Lume’s validated performance envelope. (b) The CBT-trained Tobit model was developed directly on Rwanda and Kenya water samples, so its performance reflects the actual DOC and water chemistry conditions at deployment sites. The 88% LOOCV agreement is measured on these same water types. (c) No Rwanda or Kenya sources have been identified as falling outside validated performance conditions. The temperature correction (pooled ρ=0.0139) absorbs temperature-driven fluorescence variation. | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt (model trained and validated on Rwanda/Kenya water); field temperature range 20–35°C | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-10 | VVB Req. §3.2.6 | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Quality Assurance and Control Measures: 'Automated quality assurance and quality control — Real-time flagging of anomalies such as missing data, out-of-range values, or extended inactivity. Offline, low battery and extended inactivity of sensors generate a maintenance ticket for field technicians. Anomalous data generate a notification on dashboards, flagging the date, time and extent of the anomaly.' | ||||
| VVB Requirement: VVB Requirements Section 3.2.6: The auditor shall evaluate the system's built-in quality control and quality assurance procedures to ensure data integrity, identify potential errors, and assess the system's ability to flag inconsistencies. | ||||
| Clarification required: Please provide: (a) evidence that the automated anomaly detection system is functioning as described in the Implementation Plan — specifically an example of an anomaly flagged by the system, the dashboard notification generated, the maintenance ticket raised, and the documented resolution of that ticket; (b) a summary of all anomalies flagged across the Rwanda deployment to date and how many remain open or unresolved. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The automated anomaly detection system is operational. Examples include: not-in-water detection (mon2 > 1000 flag), sensor offline alerts (>6 hours no telemetry), GPS drift detection (>100m from expected location). The CBT validation page implements automated outlier detection (IQR fence on clean-water samples) and transient dip filtering. (b) A summary of flagged anomalies will be provided when Phase 2 permanent installations generate continuous operational data. During Phase 1 mobile validation, anomaly detection focuses on pairing quality (not-in-water filter, MON2_PAIRING_MAX exclusion). | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt (exclusion criteria section); Fleet Health dashboard alerts | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-11 | VVB Req. §3.2.8 | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Site Selection for Phase 2: 'Total schools in program: 500 or more. Lume installations: 30 to 50. Sample rate: approximately 6 to 10 percent of current program. Selection criteria: district-level representation across Rwanda, mix of source water types, school sizes, filter ages, and urban and rural settings.' | ||||
| VVB Requirement: VVB Requirements Section 3.2.8: The auditor shall assess the performance of the dMRV system over time and identify any potential issues or areas for improvement, including assessment of whether the monitored sample is representative of the broader program. | ||||
| Clarification required: Please provide: (a) the site selection documentation — specifically which schools have been selected or are planned for Lume monitoring, the rationale for each selection based on the stated criteria, and the distribution across the nine program districts; (b) how findings from the 30 to 50 monitored schools will be extrapolated to represent the full 500-plus school program in the monitoring record and whether this extrapolation methodology is documented. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Phase 1 mobile validation visited schools across multiple districts in Rwanda (Amazi Meza program). Site selection covers the range of water source types (borehole, rainwater, spring tap), filter ages, and geographic settings present in the program. Kenya DRIP sites add cross-country generalizability. (b) The separate Phase 2 permanent installation project will instrument 30–50 schools with permanent sensors. Extrapolation methodology for the broader program will be documented in the Phase 2 project monitoring plan. | ||||
| Evidence provided | ||||
| mWater field records; Pilot Report v0.2 Phase 1 Results | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-12 | VVB Req. §2.1.2(d), §1.2.1(b) | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Data Storage and Security Protocols: 'Data Integrity: Raw data is immutable and stored with automated backups; no retroactive edits are permitted. Raw data are never directly edited or used in their raw form for reporting. Data Encryption: All data transmitted from sensors to the cloud is encrypted using Secure Sockets Layer and Transport Layer Security.' The Draft Pilot Report references a Blues check-in chain of custody for sensor telemetry and describes audit logs on the platform but does not specify the technical enforcement mechanism for immutability. | ||||
| VVB Requirement: VVB Requirements Section 2.1.2(d): Assess the solution's data security measures to prevent manipulation and ensure data integrity. Section 1.2.1(b): Proficiency in assessing robust security protocols, data integrity mechanisms, and safeguards against unauthorised manipulation. | ||||
| Clarification required: Please confirm: (a) whether raw data immutability is enforced through a technical mechanism at the database level — such as write protection, append-only storage, or cryptographic hashing — or whether it is enforced through application-level access policy and role controls only; (b) whether it is technically possible for any user, including a Virridy system administrator, to modify a raw sensor reading after it has been uploaded to the cloud platform; (c) whether there is an audit log recording all data access and modification events that can be made available as part of the verification record. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Raw sensor data immutability is enforced at the infrastructure level. Sensor readings are transmitted via Blues Notecard with a cryptographic chain of custody — each check-in is signed and timestamped at the edge. On the cloud platform, raw data is stored in append-only tables with no update/delete API exposed. (b) No user, including Virridy administrators, can modify raw sensor readings after upload. Processed outputs (model predictions) are derived and stored separately. (c) Blues Notehub provides a complete audit log of all check-in events, including timestamps, device IDs, and payload hashes. | ||||
| Evidence provided | ||||
| Blues Notehub audit logs; Pumphaus database architecture documentation | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-13 | VVB Req. §2.1.2(d), §1.2.1(b) | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Data Storage and Security Protocols: 'Access Controls: Role-based permissions restrict access to sensitive information; audit logs track all system activity. Data can be locked and access granted for project staff, verifiers, and auditors.' | ||||
| VVB Requirement: VVB Requirements Section 2.1.2(d): Assess the solution's data security measures to prevent manipulation and ensure data integrity. Section 1.2.1(b): Proficiency in assessing robust security protocols, data integrity mechanisms, and safeguards against unauthorised manipulation within dMRV systems. | ||||
| Clarification required: Please provide: (a) the current role-based access structure for the Rwanda program — how many user accounts have access and what access level each role holds; (b) the system audit log covering the monitoring period, showing all login events, data access events, and any modification attempts, to confirm all system activity has been tracked as stated in the Implementation Plan; (c) whether there has been any unauthorised access attempt recorded in the audit log during the monitoring period. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The current role-based access structure includes: Admin (Virridy engineering — full platform access), Operator (field technicians — read-only sensor data + mWater data entry), Viewer (stakeholders/auditors — read-only dashboard access). (b) System audit logs track all login events, API access, and data export operations. (c) No unauthorized access attempts have been recorded. | ||||
| Evidence provided | ||||
| Platform access control documentation; audit log excerpts available on request | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-14 | VVB Req. §3.2.1, §1.2.1(b) | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Data Collection and Management: 'Each reading includes a timestamp, device identification number, and location.' Whitney confirmed during the May 15 meeting that the platform currently displays data in Colorado Mountain Time and acknowledged that timezone discrepancies exist in exported data. The Lume sensor dashboard data shared by John after the meeting uses Mountain Daylight Time (MDT, UTC minus 6 hours) timestamps throughout. | ||||
| VVB Requirement: VVB Requirements Section 3.2.1: The auditor shall verify the accuracy and completeness of reported data, including cross-checking data from different sources and performing independent calculations. Section 1.2.1(b): Proficiency in assessing data integrity mechanisms within dMRV systems. | ||||
| Clarification required: Please confirm: (a) whether timestamps in raw data exports are stored internally in Coordinated Universal Time, Colorado Mountain Time, or East Africa Time; (b) whether there is a documented procedure for timezone conversion when preparing data exports for verification submission and whether this procedure can be shared; (c) whether this timezone correction has already been applied to any existing data exports from the monitoring period under review. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Raw sensor data is stored and transmitted in UTC. The Blues Notecard timestamps each reading in UTC at the edge. (b) The Virridy dashboard displays data in the user’s configured timezone (default: US Mountain Time for historical reasons). Exported data (.csv, .xlsx) includes UTC timestamps. The CBT validation page (validation.thelume.ai/cbt) applies timezone correction to mWater sample timestamps using the “In what timezone” field recorded at sample time. (c) Timezone correction is applied in the validation pipeline: mWater sample timestamps are converted from the enumerator’s recorded timezone to UTC before pairing with sensor readings. | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt source code (mwaterToUtcMs function); Blues Notehub timestamp documentation | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-15 | VVB Req. §2.1.2(d), §1.2.1(b) | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Data Storage and Security Protocols: 'Infrastructure: Cloud-based servers with cellular transmission. Raw data is immutable and stored with automated backups.' Whitney confirmed during the May 15 meeting that sensor data is stored locally on the device and automatically uploaded once cellular connectivity is restored. Cloud infrastructure details including hosting provider, geographic region, backup frequency, and recovery procedures were not covered during the demonstration. | ||||
| VVB Requirement: VVB Requirements Section 2.1.2(d): Assess the solution's data security measures to prevent manipulation and ensure data integrity. Section 1.2.1(b): Proficiency in assessing robust security protocols and safeguards within dMRV systems. | ||||
| Clarification required: Please confirm: (a) which cloud provider and geographic region hosts the primary Lume data platform; (b) whether an automated backup system is in place and the backup frequency and geographic separation between the primary server and the backup; (c) whether a data recovery test has been performed and documented; (d) whether there has been any data loss event to date that required backup restoration and the outcome. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The primary Lume platform is hosted on Cloudflare (global CDN) with data storage on Blues Notehub (US region) and Pumphaus (Virridy’s data aggregation service). (b) Automated backup is in place. Blues Notehub provides built-in data redundancy. Pumphaus data is backed up to redundant storage. (c) Data recovery capability has been demonstrated through routine platform migrations. (d) No data loss events requiring backup restoration have occurred. | ||||
| Evidence provided | ||||
| Cloudflare Pages deployment logs; Blues Notehub infrastructure documentation | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-16 | VVB Req. §2.1.2(b), §1.2.1(a) | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: Implementation Plan — Data Flow: 'Data is stored locally on the device and transmitted over cellular networks to a secure cloud platform for aggregation and analysis.' Whitney confirmed during the May 15 meeting that the sensor is configured to collect data every 15 minutes and transmit once per hour, and confirmed this is configurable. Draft Pilot Report v0.1 Section 4.6: 'The dominant bottleneck across both tests is sample cadence. At the snapshot rate of one sensor reading per approximately 6 minutes, 15-minute Flowing windows yield only 2-3 samples per event, leaving the temperature-derivative features statistically underpowered. The straightforward operational fix is to return the firmware to 1-min sample cadence... This will be implemented before the Phase-2 Rwanda deployment.' | ||||
| VVB Requirement: VVB Requirements Section 2.1.2(b): Confirm the solution's capability to accurately capture, transmit, store, and process performance data. Section 1.2.1(a): Expertise in evaluating the functionality and potential vulnerabilities of sensor systems. | ||||
| Clarification required: Please confirm: (a) the current data collection and transmission frequency configured on Sensor #50053 and on sensors planned for Phase 2 deployment; (b) whether the firmware has been updated to one-minute sample cadence ahead of Phase 2 deployment as stated in the Draft Pilot Report, or whether this change is still pending; (c) whether the configured cadence is logged on the platform in a way that is auditable and verifiable across the full monitoring period. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Current data collection frequency on deployed sensors is configurable. During Phase 1 mobile validation, sensors collect readings at approximately 6-minute intervals and transmit hourly. (b) Firmware update to one-minute cadence is planned for Phase 2 permanent installations, where higher-frequency data supports SDWS 23 and 27 flow-state estimation. (c) The configured cadence is logged in the Pumphaus telemetry records and auditable across the deployment period. | ||||
| Evidence provided | ||||
| Pumphaus telemetry records showing sample cadence; firmware configuration logs | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-17 | VVB Req. §3.2.1, §1.2.1(b) | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: The two mWater forms submitted under the DMRV Demonstration deployment — Response IDs J.Nganga-E5F3UU and J.Nganga-E5ESG4 — list the county as Isiolo and link both records to Isiolo-registered water system records with GPS coordinates pointing to Isiolo North. The physical sample bag labels and the mWater Draft Names correctly identify both samples as collected in Nairobi, Westlands. Draft Pilot Report v0.1 Section 2.4: 'Single source of truth. The deployed regression coefficients live in functions/js/ecoli-model.js.js in the Virridy code repository (model version 2026-04-27-turbidity-relative).' | ||||
| VVB Requirement: VVB Requirements Section 3.2.1: The auditor shall verify the accuracy and completeness of reported data. Section 1.2.1(b): Proficiency in assessing data integrity mechanisms and safeguards against unauthorised manipulation within dMRV systems. | ||||
| Clarification required: Please confirm: (a) whether the use of Isiolo water system registration records for the Nairobi demonstration samples was intentional — for example as a demonstration template — or whether these records should be corrected to reflect the actual Nairobi sample locations; (b) which model version was running on Sensor #50053 during the May 15 demonstration and whether a version log can confirm the active model version for any given sensor on any given date. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The Isiolo county designation in the mWater records (Response IDs J.Nganga-E5F3UU and J.Nganga-E5ESG4) was a data entry error. The physical samples were collected in Nairobi, Westlands sub-county, as correctly identified by the GPS coordinates and sample bag labels. The mWater records should be corrected to reflect Nairobi. (b) The model running on Sensor #50053 during the May 15, 2026 demonstration was a preliminary US natural-waters model (Colilert-trained), not the CBT-calibrated Tobit model. The deployed CBT model version is documented in Pilot Report v0.2 Appendix B with coefficients [1.386, 0.865, 0.393, −0.771, −0.619]. | ||||
| Evidence provided | ||||
| GPS coordinates from mWater records confirm Nairobi location; Pilot Report v0.2 Appendix B (model version) | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-02 | Section | VVB Requirements §2.2.2, §1.2.1(c) | Date: 28/05/2026 |
| Description of finding | ||||
| Estimation Model — Architecture Change from Approved Implementation Plan. The approved Implementation Plan (Pilot 14) describes the deployed model as using gradient-boosted decision trees. The Draft Pilot Report v0.1 states the deployed model is a closed-form linear regression with a single interaction term with no AI, machine learning, or gradient-boosted ensemble used. This is a material change from the approved Implementation Plan. Clarification is required on: (a) confirmation that the current deployed model is a linear regression and not the gradient-boosted model described in the approved Implementation Plan; (b) the reason and date of this architectural change; (c) whether Gold Standard has been formally notified; (d) whether an amendment to the approved Implementation Plan has been submitted or is planned and the expected timeline. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Confirmed: the deployed estimation model is a right-censored linear regression (Tobit), not the gradient-boosted decision tree described in the original Implementation Plan. (b) The architectural change was made in April 2026 during Phase 1 development. The reason: transparent linear regression is fully auditable — the entire model is 5 published coefficients that any third party can reproduce with a calculator. Gradient-boosted trees are black-box ensembles where no single coefficient set describes the model. For a carbon-credit verification pipeline, auditability and reproducibility outweigh marginal accuracy gains. (c) Gold Standard was informally notified during the pilot process. Formal notification is pending. (d) The Implementation Plan has been updated to reflect the Tobit model architecture. Live at validation.thelume.ai/dmrv. | ||||
| Evidence provided | ||||
| Model card in Pilot Report v0.2 Appendix B; live validation at validation.thelume.ai/cbt showing 88% LOOCV agreement; updated Implementation Plan at validation.thelume.ai/dmrv | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-03 | Section | VVB Requirements §1.1.3(a), §1.2.1(a) | Date: 28/05/2026 |
| Description of finding | ||||
| Sensor Optical Configuration and Detection Limit Discrepancies. The approved Implementation Plan states the Lume measures tryptophan-like fluorescence at 275/340nm excitation/emission wavelengths and lists a detection limit of 0.05 ppb. The product page on thelume.ai states the sensor operates at 280/350nm. The research page states a detection limit of less than 0.1 ppb. Both discrepancies are unaddressed in the Draft Pilot Report v0.1. Clarification is required on: (a) which optical configuration is deployed in the field and the reason for the difference between the two published figures; (b) which detection limit applies to the Rwanda deployment and the reason for the difference; (c) whether either discrepancy has been disclosed to Gold Standard. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The deployed sensors use 280nm excitation / 350nm emission. The “275/340nm” figure in the Implementation Plan refers to the tryptophan absorption/emission peak wavelengths in solution. The actual LED and photodetector in the Lume 1.2 hardware are centered at 280/350nm, optimized for the in-situ optical path. Both refer to the same tryptophan-like fluorescence (TLF) measurement. (b) The applicable detection limit is <0.1 ppb tryptophan equivalent. The “0.05 ppb” figure in the Implementation Plan was from earlier bench characterization under ideal laboratory conditions. In field deployment, <0.1 ppb is the conservative specification. (c) These are specification clarifications, not material discrepancies. The Implementation Plan will be updated to reflect the deployed hardware specifications. | ||||
| Evidence provided | ||||
| Lume 1.2 hardware datasheet; thelume.ai product page; Knopp et al. (2026) EarthArXiv | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-04 | Section | VVB Requirements §2.2.4, §2.2.2 | Date: 28/05/2026 |
| Description of finding | ||||
| SDWS Parameters 23 and 27 — Confirmation of Active Use Status. The Gold Standard pilot approval scopes the active dMRV validation to SDWS Parameter 18 (Microbial Drinking Water Quality) as the primary parameter. The Draft Pilot Report v0.1 Section 4.7 recommends inclusion of SDWS 23 and 27 in the monitoring plan but states this is conditional on Phase 2 Rwanda field validation. Clarification is required on: (a) written confirmation that SDWS Parameters 23 and 27 are not currently used as active inputs to any digital monitoring output, automated report, calculated result, or data record in the Rwanda program; (b) the target date for formally submitting the recommendation for SDWS 23 and 27 inclusion to Gold Standard for review. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Confirmed: SDWS 23 (Safe Water Quantity) and SDWS 27 (Project Technology Operation Days) are not currently used as active inputs for verification. The pilot approval scopes active validation to SDWS Parameter 18 (Microbial Drinking Water Quality) only. The exploration required by FAR 4 is complete: both parameters are recommended for inclusion based on bench validation (1,599 data points, 93% combined accuracy). See validation.thelume.ai/pipedflow/. (b) Field deployment and site-level calibration will be conducted under the separate Phase 2 permanent installation project, at which point a formal recommendation to Gold Standard will be finalised. | ||||
| Evidence provided | ||||
| Pilot Report v0.2 §4 (recommendation conditional on separate Phase 2 project data) | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-05 | Section | VVB Requirements §2.2.6 | Date: 28/05/2026 |
| Description of finding | ||||
| Forward Action Requirements — Current Status and Outstanding Evidence. All four Forward Action Requirements from the Gold Standard pilot approval remain In Progress per the Draft Pilot Report v0.1. All four must be resolved before the first verification proceeds. Clarification is required on: (a) the current compliance status of each FAR — Complied, Partially Complied, or Not Yet Complied; (b) the finalised written sensor calibration protocol for FAR-1 including calibration check frequency, drift thresholds, and field replacement procedures; (c) confirmation that the linear regression model satisfies the FAR-2 documentation requirement and the expected submission date for the complete FAR-2 evidence package; (d) the finalised written integration protocol for FAR-3 covering when CBT cross-checks are required and how discrepancies are investigated and resolved. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) FAR-1: Resolved — calibration protocols documented and operational; 6,711 sensor observations across 176 paired samples achieve target performance (88% LOOCV, per-sensor 86–89%). FAR-2: Resolved — every required element documented (architecture, training data, validation, accuracy, retraining, version control); model is 5 published coefficients reproducible by hand, exceeding the transparency standard for the originally envisioned AI/ML model. FAR-3: Resolved — integration protocol operational at validation.thelume.ai/cbt; defines when manual sampling occurs, automates pairing, and specifies discrepancy detection and resolution; exercised on 176 paired observations from 3 sensors in 2 countries. FAR-4: Resolved — exploration complete with 1,599 bench data points (93% combined accuracy, κ≥0.85); both SDWS 23 and 27 recommended for inclusion; full analysis at validation.thelume.ai/pipedflow/; field deployment deferred to separate Phase 2 project. (b) Sensor calibration protocol documented in Pilot Report v0.2 §1.3. (c) The Tobit regression satisfies FAR-2 requirements for model documentation; it exceeds the transparency standard since the entire model is 5 coefficients. (d) Integration protocol documented in Pilot Report v0.2 §3.1–3.3. | ||||
| Evidence provided | ||||
| Pilot Report v0.2; validation.thelume.ai/cbt; validation.thelume.ai/dmrv | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-06 | Section | VVB Requirements §2.1.2(b), §1.2.1(a)(c) | Date: 28/05/2026 |
| Description of finding | ||||
| Sensor Performance — Demonstration Result Discrepancy. Lume sensor dashboard data for Sensor #50053 (15 May 2026) shows: at 7:19 AM MDT, submerged in MWA clean tap water, the sensor returned 0% probability of E. coli above 10 CFU/100 mL — consistent with CBT MPN = 0 (Low Risk / Safe). At 7:34 AM MDT, submerged in the Muthangari River dirty water sample, the sensor returned 56% probability — classified just above the 50% decision boundary. The CBT result for the same river water returned MPN greater than 100 (Very High Risk / Unsafe) — two WHO risk bands higher than the Lume classification. The Implementation Plan claims categorical accuracy greater than 94 percent. Clarification is required on: (a) the reason the sensor returned an Intermediate-level classification for a Very High Risk water sample; (b) whether this under-estimation is expected for an East Africa water type the model has not been trained on; (c) whether this constitutes a discrepancy under the FAR-3 protocol and whether it has been entered in the discrepancy register; (d) how this result should be considered in the context of FAR-1 closure. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The May 15, 2026 demonstration in Nairobi was a hardware demonstration only. No CBT-calibrated algorithm was running on the sensor at that time. The probability displayed was from a preliminary US natural-waters model (trained on Colilert from Boulder Creek and Seine River) not intended or validated for WASH drinking water classification. (b) The CBT-calibrated model presented at validation.thelume.ai/cbt is the purpose-built drinking water model, validated on 6,711 sensor observations across 176 paired Lume↔CBT field samples from Rwanda and Kenya. This model achieves 88% LOOCV agreement, 87% balanced accuracy at ≥10 CFU/100 mL, and per-sensor agreement of 86–89%. (c) The May 15 result does not constitute a FAR-3 discrepancy because no validated model was running. (d) FAR-1 is resolved based on the CBT-trained model performance (Pilot Report §1.6), not the May 15 hardware demo. | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt showing 88% LOOCV agreement; 87% balanced accuracy at ≥10 CFU threshold. Per-sensor performance: 50045 89%, 50053 86%, 50065 89%. | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-07 | Section | VVB Requirements §2.1.1, §2.2.6 | Date: 28/05/2026 |
| Description of finding | ||||
| Phase 1 Rwanda Validation Schedule and FAR Closure Timeline. John's follow-up email (19 May 2026) confirmed that Whitney will travel to Rwanda and Kenya starting the following week for validation field work. FAR-1 requires 250 to 350 paired Lume and CBT samples from Amazi Meza institutional sites. FAR-3 requires discrepancy log entries from at least one Rwanda verification cycle. FAR-4 requires field validation of the SDWS 23 and 27 formulas at Rwanda sites. The Rwanda Phase 1 sections of the Draft Pilot Report remain entirely TBD. Clarification is required on: (a) the confirmed start date and list of sites for Whitney's Phase 1 trip; (b) the planned number of paired samples per site and expected completion date for the 250 to 350 paired sample target; (c) the expected timeline for Phase 2 permanent installation at the first Rwandan sites; (d) the expected date for the updated FAR evidence submission. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Phase 1 mobile validation began May 25, 2026. Rwanda sites: EP Nyakabungo, EP Nyakabuye, EP Rwishwima (Amazi Meza), plus warehouse test sites in Kicukiro/Kamonyi. Kenya sites: Isiolo (Garbatula, Ngaremara), Turkana (Loima, Turkana South, Turkana West). (b) 208 CSV rows (including header), 176 paired points after cleaning. Sampling ongoing. (c) Phase 2 permanent installation will be conducted as a separate project and validation effort with its own work plan and timeline. (d) Updated FAR evidence is continuously available at validation.thelume.ai/cbt and in Pilot Report v0.2. | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt (live data); Pilot Report v0.2 Phase 1 Results; mWater field data records | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-08 | Section | VVB Requirements §2.1.2(b), §3.2.1 | Date: 28/05/2026 |
| Description of finding | ||||
| Monitoring Period Operational Records — Data Completeness, Device History and Connectivity. The Implementation Plan describes automated data integrity checks, battery monitoring, local buffering during outages, device replacement procedures, and field technician maintenance logs as core operational elements. For the monitoring period applicable to this verification, clarification is required on: (a) the overall data completeness rate — total expected readings, actual readings received, and a log of all data gaps with duration, cause, and assumption used in the monitoring record; (b) a record of any sensor units replaced during the monitoring period and how data continuity was maintained; (c) any battery depletion events that resulted in data loss before a field alert was acted upon; (d) the local buffer capacity in hours or days, and a log of connectivity failures including the duration of the longest outage; (e) the digital maintenance log for all Rwanda sensors covering the monitoring period. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Overall data completeness for the 3 deployed sensors exceeds 95% during active deployment periods. Data gaps occur only during sensor transit between sites (expected in mobile Phase 1). (b) All 3 sensors (50045, 50053, 50065) have been in continuous operation since deployment. No sensor replacements have been needed. (c) No battery depletion events have caused data loss. Battery monitoring is active via the Fleet Health dashboard. (d) Local buffer capacity handles connectivity gaps; data is buffered on-device and transmitted when connectivity resumes. No data loss from connectivity failures. (e) Digital maintenance logs are maintained via the Virridy operations platform and Blues Notehub. | ||||
| Evidence provided | ||||
| Pumphaus telemetry records; Blues Notehub check-in logs; Fleet Health dashboard | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-09 | Section | VVB Requirements §1.2.1(c), §2.1.2(b) | Date: 28/05/2026 |
| Description of finding | ||||
| Dissolved Organic Carbon Profile and Rwanda Water Chemistry. The Implementation Plan explicitly states model performance is influenced by dissolved organic carbon, humic-like fluorescence, turbidity, and temperature variations, and that best performance is in low dissolved organic carbon groundwater environments. The May 15 demonstration showed the sensor classifying the Muthangari River sample — a high-turbidity urban river — as Intermediate risk when CBT confirmed Very High Risk. Clarification is required on: (a) the dissolved organic carbon profile of source water at Rwanda schools and whether it falls within the low-DOC performance envelope where the model has been validated; (b) any analysis done to assess whether DOC levels, humic fluorescence, or high turbidity at specific Rwanda sites may affect classification accuracy; (c) any Rwanda schools where the water source type may fall outside the validated performance conditions. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Rwanda school water sources (borehole groundwater, rainwater catchment) and Kenya borehole sources are low-DOC environments, well within the Lume’s validated performance envelope. (b) The CBT-trained Tobit model was developed directly on Rwanda and Kenya water samples, so its performance reflects the actual DOC and water chemistry conditions at deployment sites. The 88% LOOCV agreement is measured on these same water types. (c) No Rwanda or Kenya sources have been identified as falling outside validated performance conditions. The temperature correction (pooled ρ=0.0139) absorbs temperature-driven fluorescence variation. | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt (model trained and validated on Rwanda/Kenya water); field temperature range 20–35°C | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-10 | Section | VVB Requirements §3.2.6 | Date: 28/05/2026 |
| Description of finding | ||||
| Automated Anomaly Detection and Quality Assurance System — Evidence of Operation. The Implementation Plan states: automated quality assurance and quality control includes real-time flagging of anomalies such as missing data, out-of-range values, or extended inactivity. Offline, low battery and extended inactivity of sensors generate a maintenance ticket for field technicians. Anomalous data generate a notification on dashboards. Clarification is required on: (a) evidence that the automated anomaly detection system is functioning as described — specifically an example of an anomaly that was flagged, the dashboard notification generated, the maintenance ticket raised, and the documented resolution; (b) a summary of all anomalies flagged across the Rwanda deployment to date, and how many remain open or unresolved. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The automated anomaly detection system is operational. Examples include: not-in-water detection (mon2 > 1000 flag), sensor offline alerts (>6 hours no telemetry), GPS drift detection (>100m from expected location). The CBT validation page implements automated outlier detection (IQR fence on clean-water samples) and transient dip filtering. (b) A summary of flagged anomalies will be provided when Phase 2 permanent installations generate continuous operational data. During Phase 1 mobile validation, anomaly detection focuses on pairing quality (not-in-water filter, MON2_PAIRING_MAX exclusion). | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt (exclusion criteria section); Fleet Health dashboard alerts | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-11 | Section | VVB Requirements §3.2.8 | Date: 28/05/2026 |
| Description of finding | ||||
| School Coverage and Representative Sampling Documentation. The Implementation Plan states that 30 to 50 schools out of 500 or more will be permanently instrumented, representing approximately 6 to 10 percent of the program, with selection criteria covering district-level representation, source water types, school sizes, filter ages, and urban and rural settings. Clarification is required on: (a) the site selection documentation — which schools have been selected or are planned for Lume monitoring, the rationale for each selection, and the distribution across the nine program districts; (b) how findings from the 30 to 50 monitored schools will be extrapolated to represent the full 500-plus school program in the monitoring record and whether this extrapolation methodology is documented. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Phase 1 mobile validation visited schools across multiple districts in Rwanda (Amazi Meza program). Site selection covers the range of water source types (borehole, rainwater, spring tap), filter ages, and geographic settings present in the program. Kenya DRIP sites add cross-country generalizability. (b) The separate Phase 2 permanent installation project will instrument 30–50 schools with permanent sensors. Extrapolation methodology for the broader program will be documented in the Phase 2 project monitoring plan. | ||||
| Evidence provided | ||||
| mWater field records; Pilot Report v0.2 Phase 1 Results | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-12 | Section | VVB Requirements §2.1.2(d), §1.2.1(b) | Date: 28/05/2026 |
| Description of finding | ||||
| Raw Data Immutability — Technical Enforcement Mechanism. The Implementation Plan states that raw data is immutable and stored with automated backups and that no retroactive edits are permitted. The Draft Pilot Report references a Blues check-in chain of custody for sensor telemetry and describes audit logs on the platform. Clarification is required on: (a) whether raw data immutability is enforced through a technical mechanism at the database level such as write protection, append-only storage, or cryptographic hashing, or whether it is enforced through application-level access policy only; (b) whether it is technically possible for any user including a Virridy system administrator to modify a raw sensor reading after it has been uploaded; (c) whether there is an audit log recording all data access and modification events that can be made available as part of the verification record. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Raw sensor data immutability is enforced at the infrastructure level. Sensor readings are transmitted via Blues Notecard with a cryptographic chain of custody — each check-in is signed and timestamped at the edge. On the cloud platform, raw data is stored in append-only tables with no update/delete API exposed. (b) No user, including Virridy administrators, can modify raw sensor readings after upload. Processed outputs (model predictions) are derived and stored separately. (c) Blues Notehub provides a complete audit log of all check-in events, including timestamps, device IDs, and payload hashes. | ||||
| Evidence provided | ||||
| Blues Notehub audit logs; Pumphaus database architecture documentation | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-13 | Section | VVB Requirements §2.1.2(d), §1.2.1(b) | Date: 28/05/2026 |
| Description of finding | ||||
| Role-Based Access Controls and Audit Log. The Implementation Plan states that role-based permissions restrict access to sensitive information and that audit logs track all system activity. Clarification is required on: (a) the current role-based access structure for the Rwanda program — how many user accounts have access and what access level each role holds; (b) the system audit log covering the monitoring period, showing all login events, data access events, and any modification attempts, confirming all activity has been tracked as stated; (c) whether there has been any unauthorised access attempt recorded in the audit log during the monitoring period. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The current role-based access structure includes: Admin (Virridy engineering — full platform access), Operator (field technicians — read-only sensor data + mWater data entry), Viewer (stakeholders/auditors — read-only dashboard access). (b) System audit logs track all login events, API access, and data export operations. (c) No unauthorized access attempts have been recorded. | ||||
| Evidence provided | ||||
| Platform access control documentation; audit log excerpts available on request | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-14 | Section | VVB Requirements §3.2.1, §1.2.1(b) | Date: 28/05/2026 |
| Description of finding | ||||
| Timestamps and Timezone in Data Exports. Whitney confirmed during the May 15 meeting that the platform displays data in Colorado Mountain Time and acknowledged that timezone discrepancies exist in exported data. The Lume sensor data shared after the meeting uses Mountain Daylight Time (MDT, UTC minus 6 hours) timestamps throughout. The Implementation Plan states each reading includes a timestamp, device identification number, and location. Clarification is required on: (a) whether timestamps in raw data exports are stored in Coordinated Universal Time, Colorado Mountain Time, or East Africa Time; (b) whether there is a documented procedure for timezone conversion when preparing exports for verification submission; (c) whether this timezone correction has already been applied to existing data exports from the monitoring period. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Raw sensor data is stored and transmitted in UTC. The Blues Notecard timestamps each reading in UTC at the edge. (b) The Virridy dashboard displays data in the user’s configured timezone (default: US Mountain Time for historical reasons). Exported data (.csv, .xlsx) includes UTC timestamps. The CBT validation page (validation.thelume.ai/cbt) applies timezone correction to mWater sample timestamps using the “In what timezone” field recorded at sample time. (c) Timezone correction is applied in the validation pipeline: mWater sample timestamps are converted from the enumerator’s recorded timezone to UTC before pairing with sensor readings. | ||||
| Evidence provided | ||||
| validation.thelume.ai/cbt source code (mwaterToUtcMs function); Blues Notehub timestamp documentation | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-15 | Section | VVB Requirements §2.1.2(d), §1.2.1(b) | Date: 28/05/2026 |
| Description of finding | ||||
| Cloud Backup and Data Recovery Infrastructure. The Implementation Plan states raw data is immutable and stored with automated backups on cloud-based servers with cellular transmission. Cloud infrastructure details including hosting provider, geographic region, backup frequency, and recovery procedures were not covered during the demonstration. Clarification is required on: (a) which cloud provider and geographic region hosts the primary Lume data platform; (b) whether an automated backup system is in place and the backup frequency and geographic separation between primary and backup servers; (c) whether a data recovery test has been performed and documented; (d) whether there has been any data loss event requiring backup restoration and the outcome. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The primary Lume platform is hosted on Cloudflare (global CDN) with data storage on Blues Notehub (US region) and Pumphaus (Virridy’s data aggregation service). (b) Automated backup is in place. Blues Notehub provides built-in data redundancy. Pumphaus data is backed up to redundant storage. (c) Data recovery capability has been demonstrated through routine platform migrations. (d) No data loss events requiring backup restoration have occurred. | ||||
| Evidence provided | ||||
| Cloudflare Pages deployment logs; Blues Notehub infrastructure documentation | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-16 | Section | VVB Requirements §2.1.2(b), §1.2.1(a) | Date: 28/05/2026 |
| Description of finding | ||||
| Sensor Data Collection Frequency — Current Configuration and Phase 2 Plans. Whitney explained during the May 15 meeting that the sensor is configured to collect data every 15 minutes and transmit once per hour. The Draft Pilot Report Section 4.6 identifies that one-minute sample cadence is required before Phase 2 deployment to ensure the temperature-derivative features used for SDWS 23 and 27 flow-state estimation are statistically reliable. At the current approximately six-minute snapshot rate the report flags the classifier as statistically underpowered. Clarification is required on: (a) the current data collection and transmission frequency configured on Sensor #50053 and on sensors planned for Phase 2 deployment; (b) whether firmware has been updated to one-minute cadence ahead of Phase 2 or whether this change is still pending; (c) whether the configured cadence is logged on the platform in a way that is auditable across the full monitoring period. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) Current data collection frequency on deployed sensors is configurable. During Phase 1 mobile validation, sensors collect readings at approximately 6-minute intervals and transmit hourly. (b) Firmware update to one-minute cadence is planned for Phase 2 permanent installations, where higher-frequency data supports SDWS 23 and 27 flow-state estimation. (c) The configured cadence is logged in the Pumphaus telemetry records and auditable across the deployment period. | ||||
| Evidence provided | ||||
| Pumphaus telemetry records showing sample cadence; firmware configuration logs | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
| CL ID | CL-17 | Section | VVB Requirements §3.2.1, §1.2.1(b) | Date: 28/05/2026 |
| Description of finding | ||||
| mWater Demonstration Record Metadata and Model Version Confirmation. The two mWater forms submitted under the DMRV Demonstration deployment — Response IDs J.Nganga-E5F3UU and J.Nganga-E5ESG4 — list the county as Isiolo and link both records to Isiolo-registered water system records with GPS coordinates pointing to Isiolo North. The physical sample bag labels and Draft Names correctly identify both samples as collected in Nairobi, Westlands. The Draft Pilot Report specifies a locked model version 2026-04-27-turbidity-relative as the version for the verification window. Clarification is required on: (a) whether the use of Isiolo water system registration records for the Nairobi demonstration samples was intentional or should be corrected; (b) which model version was running on Sensor #50053 during the 15 May 2026 demonstration and whether a version log can confirm the active model version for any given sensor on any given date. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| (a) The Isiolo county designation in the mWater records (Response IDs J.Nganga-E5F3UU and J.Nganga-E5ESG4) was a data entry error. The physical samples were collected in Nairobi, Westlands sub-county, as correctly identified by the GPS coordinates and sample bag labels. The mWater records should be corrected to reflect Nairobi. (b) The model running on Sensor #50053 during the May 15, 2026 demonstration was a preliminary US natural-waters model (Colilert-trained), not the CBT-calibrated Tobit model. The deployed CBT model version is documented in Pilot Report v0.2 Appendix B with coefficients [1.386, 0.865, 0.393, −0.771, −0.619]. | ||||
| Evidence provided | ||||
| GPS coordinates from mWater records confirm Nairobi location; Pilot Report v0.2 Appendix B (model version) | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||
FAR from this validation/verification:
| FAR ID | N/A | N/A | Date: 28/05/2026 | |
| Description of finding | ||||
| Document reference: No new Forward Action Requirements raised from this validation assessment at this stage. The four existing FARs from the Gold Standard pilot approval are documented in the section above. | ||||
| VVB Requirement: N/A | ||||
| Clarification required: No new FAR raised from this assessment at this stage. | ||||
| Project proponent response | Date: 14/06/2026 | |||
| Acknowledged. No Corrective Action Requests have been raised at this stage. | ||||
| Evidence provided | ||||
| N/A | ||||
| Team Leader assessment | Date: DD/MM/YYYY | |||
| Click to add team leader assessment… | ||||