More complex Policy Workflow Action - Aggregation about guardian HOT 9 CLOSED

The idea is that, at the moment, every time a sensor emits a signal, it creates a token. This may be the right behavior for some policies, but not for all of them. For example, there may be more complex flows such as aggregation of data. This needs to be a spike with Max. This ties into the conversation with DOVU (Seasonal over the course of time). We may need to get DOVU involved. We need one or two more examples. Wes would want to take Richards CET example with Automated Data, one of the supply side with manual data, so that we have multiple examples for this requirement. Adding Andrey and Max to then engage the DOVU team.

from guardian.

Need to go into more detail on soil organic carbon example @anvabr, additionally a collection bucket for txn should be possible as well for extreme high throughput use cases

from guardian.

After a brainstorming session with Wes and Max we established that there needs to be a capability to aggregate on the:

• temporal/calendar dimension:
  • establish the beginning of the period (date/time/calendar significant milestone such as the beginning of the month etc)
  • set a duration of the period or periodicity rule (such as monthly, weekly, etc)
  • count the occurrences of an event during each period
  • perform other arithmetic calculation, e.g translate the number of event occurrences into CO2 a volume in tons. I believe we already have math capability in there, for the MVP we would need to have hard-coded formulas/constants. For the future the constants will become variables sourced from an Oracle or other external system.
  • do an action (mint token) on the basis of the above
• cumulative dimension
  • count the occurrences of an event until it reaches a defined volume measure
  • perform other arithmetic calculation, such as translate the number of event occurrences into CO2 a volume in tons
  • do an action (mint token) on the basis of the above

Please see google calendar event settings for the repeat events for inspiration.

Furthermore, Policy language needs to be extended to support the functionality of mandating an MRV reporting period (from the sensor) such that:

• Policy can specify a temporal requirement for the receiving of the signal from the sensor (e.g. "every 15 minutes").
• Policy can specify what to do if the requirement above is not fulfilled for the period of time specified in the minting section (e.g. skip minting a token).

from guardian.

Next step is for Max to provide some real-life scenarios

from guardian.

A real-life example of this could be a company that generates electricity through natural gas combustion and is subject to the policy CFR 40 part 75. They install continuous emissions monitoring systems on their generator and according to the policy, they must have at least one data recording event every 15 minutes and translate this into hour averages. In addition, they must electronically report emissions quarterly. However, as long as we have data at the required intervals, the actual minting thresholds can be built into the Guardian policy based on either user preferences or whatever is ideal functionally. Such thresholds could be temporal (e.g., quarterly), or cumulative (every time a mtCO2e is generated). @anvabr Could we also have manual minting, i.e., the solution can track GHG emissions the user could manually trigger a minting of what has accumulated since the previous minting evet? Just a thought.

More information on CFR 40 Part 75 can be found in the attached document.
Doc_EPA CEMS CFR 40 Part 75 Requirements_9-21-21.docx

from guardian.

We need to consider what would the be the initial scope of the functionality, and what comes later (lesser of a priority). I would suggest manual minting is better left for a later stage.

from guardian.

One requirement that stands out in the above for me @Mpinnola is that of mandating an MRV reporting period, and then validating it. This was not reflected in my comment, will now be rectified.

from guardian.

So for the example above, I'm guessing the minimum functionality would be to: A) Specify temporal thresholds for receiving MRV data. B) Assess MRV data and project information against policy requirements. C) Specify temporal thresholds for verifying data and minting tokens (aka the monitoring period). So in other words, for example, programming it to receive data every 15 min. Then at the end of the monitoring/reporting period, perhaps every quarter, the data is verified by the root authority against the policy and tokens are minted.

These thresholds could be set in the policy, but then if policies are immutable, would every project under the same policy would be stuck with the same temporal thresholds? Or could the user define their own monitoring periods, as long as its complies with the policy requirements?

Just for clarification, in the case above, I believe as long as the sensor is recording data at a minimum of every 15 minutes, it could still send the data to the Guardian in bursts of say 1 per day (or whatever is most feasible technically), as long as the data received has data points for every 15 miniates. Does that make sense?

@anvabr Please let me know of this makes sense, is useful, or if I need to be thinking about this differently.

from guardian.

This epic was closed on March 18th

from guardian.