Inspiration
Driven by our experiences, observations, and desire to contribute meaningfully to sustainable development, we knew we wanted to build something with broad and tangible impacts across multiple Sustainable Development Goals (SDGs).
The initiative needed to be accessible (implementation- and funding-wise), offering clear, immediate benefits to participants while being sustainable and scalable.
Improving Cookstoves stood out for its direct and multi-faceted benefits. By upgrading from inefficient to efficient cookstoves, communities could see immediate health improvements through reduced exposure to harmful emissions. This change also promises environmental benefits from decreasing deforestation and carbon emissions. Furthermore, the time savings from the reduced need for fuel collection and length of cooking activities offer a path towards gender equality by lessening the burden on women and girls, freeing up their time for educational and economic opportunities.
The SDVM001 Improved Cookstove methodology was chosen from the three we compared for several reasons, including its comprehensive yet flexible approach that allows project proponents to develop a program to fit specific community needs. Project proponents can make claims, generate additional assets, and obtain a label for other generated assets. This level of flexibility makes it a useful designation to facilitate the comparison of impacts across projects reviewed or listed by different registries.
We aim to create a scalable and replicable model that can bring audibility to and provide a systematic way of monitoring the impact of the half billion funding target from the World Bank earmarked to help people gain access to clean cooking, as well as encourage and guide similar initiatives, ultimately driving a broader shift towards holistic sustainability.
What it does
We've created a workflow in the Guardian that enables project proponents to describe, list, validate, register, monitor, and verify projects that qualify under the SDVM001 - Methodology for Time Savings from Improved Cookstoves (ICS). For projects that generate SD VISta Assets, project proponents may also request a token issuance. While we have already developed the schemas to incorporate the generation of additional SD VISta Assets as well as claims and labels, a detailed workflow that also allows the project proponent to request and receive tokens to indicate these additional achievements would be implemented as an enhancement in phase 2.
How we built it
After we selected the SDVM001 Metholdogy, we started diving into the system. We started from scratch, working our way through setting up our own instance of the guardian. After many attempts, we successfully had an instance up and running.
Shortly afterward, we found a post noting that we could leverage Managed Guardian Services. We switched to managed services to reduce the number of variables to dissect in troubleshooting and testing.
Once we migrated to Managed Guardian Services, we started to build the schemas in spreadsheets by downloading the template from the system and testing smaller uploads. In parallel, we started building the policy workflow.
After uploading the final spreadsheet, we finalized the workflow and started to populate it with the schemas. However, we noticed that the system was not recognizing the parameters indicating visibility and ran into several challenges with being able to view or select schemas. Eventually, we decided to start fresh -- create a new instance and manually enter each schema into a newly created policy.
The sixth time was the charm. After everything had been entered and the policy workflow replicated, we successfully connected the finalized schemas and created the demo of our project.
Challenges we ran into
Like any project, we encountered several challenges along the way. From navigating the complexities of policy requirements to ensuring compatibility with the Guardian platform, we faced technical and logistical hurdles that required creative problem-solving, unwavering perseverance, and a healthy dose of humor. Each hurdle we overcame strengthened our resolve and deepened our collective expertise, helping us make the last push before submission.
The biggest obstacles that resulted in the most difficult decisions were the visibility of a schema and the ability to select schemas. On the final day, when we went to record our demo video, we discovered that a number of links broke. We immediately went into the policy and painstakingly reconnected everything we could. However, we ran into several instances where either the schema we needed was not visible for selection, or it was visible but not “selectable.” The schemas had not been moved, edited, or deleted.
After more than a handful of hours troubleshooting — exporting, importing, leveraging the wizard, and applying manual fixes — we decided to revert to an earlier version of the policy with simplified schemas and use it as our submission.
Accomplishments that we're proud of
This project has been the perfect test of our adaptability, resilience, and ingenuity under pressure. Both of us were exploring an area and using an application that neither of us had previous experience with. Yet, we never lost our sense of humor through the ups and downs. While a few accomplishments stood out along the way, the ones we are most proud of are:
The speed at which we created a comprehensive policy incorporating complex data collection into the schemas. Having only met a little after mid-February, we soon realized how tight the timeline was to build a comprehensive, functioning policy in the Guardian in less than a month and a half. Even after, or maybe even because of, some early setbacks, we dug in even more. We were determined to achieve what we both committed to. By the end of the project, we had created three working versions of the policy. And luckily so, because we had to revert to one of the older versions.
We did not let the sunk cost fallacy get in the way of submitting a working policy (eventually). When faced with the final challenge of finding out that links to our finalized policy that had worked earlier in the day no longer functioned later that night, just as we were getting ready to record the demo video, we rallied -- hard forking from our anticipated excitement about submission to laser-focused execution of checking line-by-line for errors. Unfortunately, no matter what we tried, the schemas we could see remained hidden from the dropdown list or unable to be selected. One hour went by, then two, then three. Nothing worked. We made what we thought was the hardest decision at midnight. We decided to start start from scratch again in a new tenant. Unfortunately, to our surprise, this didn't solve the issue. Eventually, we voted to let go of 12 hours of work to improve schemas and submit an earlier version of the policy.
What we learned
With such a long list of learnings for us to choose from, it's hard to decide where to start. Perhaps beyond practical takeaways (how to use Guardian, how to turn policies into workflows, etc.), the most surprising learning may have been the impact that something as simple as a cookstove can have on health, environment, gender equality, and economic prosperity. With reports showing $2.5 billion-plus people globally relying on traditional biomass for cooking and heating and figures as high as 4 million premature deaths annually due to household air pollution, disproportionately affecting women and children in low-income countries, the potential for positive impact on the climate and wellbeing is significant.
In this modern world with the ever-growing number of complex, high-tech, industry-inventing technologies, it's easy to forget that sometimes the most seemingly basic changes can deliver outsized impacts.
What's next for Sustainable Cooking Solutions
Moving forward, we have outlined a roadmap for phase two and beyond, encompassing a series of enhancements and refinements to further improve the efficacy and accessibility of our solution.
Our first priority is to seamlessly integrate the IEE workflow into the project. Given the outsized impact of enhanced data security, immutability, and transparency on a tradable asset, we prioritized the completion of the VVB (Validation/Verification) workflow in phase one.
In parallel, we would add assessor licensing, a crucial step towards bringing the end-to-end VVB and IEE experience on-chain and not only enhance trust, security, and auditability, but also provide a more seamless, consistent experience.
To further enhance user experience, we plan to segregate workflows into different tabs for project proponents by project by phase. This intuitive design change will make it easier to locate documents and follow the status of their project(s).
Additionally, we would migrate all commentary during public commentary periods from off-chain sources to Hedera's Guardian platform. This milestone represents a significant step towards fully transitioning the SD VISta workflow onto a DLT, enhancing transparency and accessibility.
Looking ahead, we hope for the development of auto-calculated fields into the Guardian platform, which would enable us to streamline our schemas and bring impacts and benefits calculations on-chain.
In addition to tech-related developments, we are keenly aware of the importance of legal and regulatory considerations. We would like to gain a deeper understanding of the legal landscape surrounding tradable SD VISta assets. Should any relevant insights emerge, we would work to incorporate them into our token request and issuance processes.
In summary, our roadmap prioritizes user experience, technological advancements, and regulatory compliance.
Built With
- managedguardianservice
Log in or sign up for Devpost to join the conversation.