Formalizing Impact Claims for Ecocerts Interoperability

[daviddao]

Overview

We need to establish a way to publish schemas for ecological impact claims within hypercert descriptions that makes them both human-readable and machine-parseable. Since temporal scope and geolocation are handled by the base hypercert specification, this focuses on structuring the actual impact claims and evidence in the description field.

Current Challenge

Hypercert descriptions currently allow free-form text, making it difficult to:

• Parse impact claims programmatically
• Compare impacts across different projects
• Link claims to verifiable evidence
• Enable machine validation of claims

Proposed Solution

An example of such format could look like this:

Description Format

---
impact_category: [biodiversity|carbon|water|soil|species|traditional_knowledge]
impact_claims:
  - metric: species_count
    value: 50
    unit: unique_species
    method: camera_trap_survey
  - metric: habitat_area
    value: 100
    unit: hectares
    method: satellite_imagery
evidence:
  - type: eas_attestation
    uid: "0x..."
  - type: ipfs_dataset
    cid: "Qm..."
  - type: sensor_feed
    url: "https://..."
methodology: |
  <markdown description of methods>
community_validation: |
  <markdown description of community process>
---

<human readable description here>

Impact Categories

Core categories with standard metrics:

1. Biodiversity

   • Species count
   • Habitat area
   • Ecosystem connectivity
   • Species diversity indices

2. Carbon

   • Sequestration amount
   • Prevention of emissions
   • Soil carbon content

3. Water

   • Water quality metrics
   • Flow restoration
   • Watershed health indices

4. Soil

   • Organic matter content
   • Erosion prevention
   • Microbial activity

5. Species Protection

   • Population counts
   • Breeding success
   • Habitat protection area

6. Traditional Knowledge

   • Knowledge preservation
   • Practice continuation
   • Community engagement

EAS Integration

To keep impact formats upgradable and forkable, we can decentralize the creation of the formats by publishing them to EAS. E.g. the above proposed format could be announced in EAS like this:

// Core format specification schema
schema EcologicalFormatSpec {
  version: string;           // Semver of format
  schemaIPFS: bytes32;      // IPFS hash of full YAML schema
  parentFormat: bytes32;     // Optional reference to parent format
  supportedCategories: string[];
  maintainer: address;       // Format specification maintainer
  name: string;
}

// Format extension registration
schema FormatExtension {
  baseFormat: bytes32;      // Reference to base format
  extendedFields: string[]; // New YAML fields added
  schemaIPFS: bytes32;      // IPFS hash of extended schema
  purpose: string;          // Description of extension purpose
  community: address;       // Extension maintainer
}

Discussion Points

1. Categories Standardization

   • What categories and subcategories should we include?

2. Metric Standardization

   • Should we allow custom metrics or stick to predefined ones?
   • How do we handle unit conversions and normalization?

3. Evidence Requirements

   • What's the minimum evidence needed per claim type?
   • How do we validate different evidence types?

4. Community Tools

   • What tools are needed to make this format accessible?
   • How can we simplify data entry while maintaining structure?

[holkexyz]

Proposed change 1: Split human readable description from impact claim

I would propose to keep the description in the ecocerts' metadata to a human readable description of the work and move the project's impact claim into an EAS attestation as a self-report/self-evaluation. This would also allow projects to update these attestations if new evidence arises.

Questions regarding impact claim

1. Should a single attestation include one or potentially multiple metrics? In the former case the project would submit multiple EAS attestation, which could then be challenged individually by others. However, we might end up with many attestations.
2. Do we need to ensure that evidence like the sensor_feed is available? e.g. storing the evidence on IPFS in addition?
3. @daviddao can you say more about the `community_validation'? Is that an optional field for every metric?

Proposed change 2: Rename 6th impact category

Projects that interact with communities, but not with traditional knowledge don't have a good choice. Hence, I would propose to rename the sixth category:

6. Community & Traditional Knowledge
   • Knowledge preservation
   • Practice continuation
   • Community engagement

Alternatively, we could also just call it community, but we would lose the emphasis on traditional knowledge

[daviddao]

Thanks @holkexyz for these great suggestions! I really like the idea of moving impact claims into a machine-readable format through attestations that could be automatically derived from the human-readable description.

Some thoughts on this approach:

On Attestations & Descriptions

I think we need to carefully consider the relationship between attestations and descriptions:

• How do we ensure human-readable descriptions and attestations stay in sync?
• Who is responsible for updating both when changes occur?

One potential solution could be to have attestations automatically derived from structured data within projects or evaluators' internal protocols. This would help maintain consistency and reduce manual overhead.

On Individual Metric Attestations

Strongly agree that each metric should be its own attestation. This would:

• Simplify verification and challenges
• Enable more granular tracking of evidence
• Make it easier to update individual metrics as new data becomes available

On Evidence Requirements

For sensor data and other evidence sources:

• We could implement a tiered verification system
• Claims without associated data would be marked as "self-reported"
• Claims with verifiable data sources (IPFS, sensor feeds, etc.) could receive higher verification status
• This maintains flexibility while providing clear indicators of claim reliability

On Community Validation

The community review process could work by:

• Having communities review the hypercert
• Allowing them to reference specific impact attestations by ID in their review
• This creates a chain of verification without requiring changes to the original attestations

Agree with the proposed category rename to "Community & Traditional Knowledge" - this better captures the broader scope of community-related impacts.

[holkexyz]

Yes!

• One metric per attestation: I like that.
• Tiered verification system: Great, I think we can later expand on that, when evidence is just backed up on IPFS vs. it being fully traceable, e.g. via Cherty.
• Community validation: Yes, this makes sense to me in this way. So, it would not be an input for a single impact metric, but a separate attestation.

Question

• In my view, we would not have the same information in the human-readable description and in the attestation. The description would describe the work, e.g. taking care of a forest, doing agroforestry, etc. The evaluation of that, e.g. a biodiversity metric, would go in an attestation. Hence, we wouldn't need to keep them in sync. That is also why the description would see less updates. Does that make sense?

[daviddao]

I wanted to share a concrete example of how the separation between human-readable descriptions and attestations could work in practice.

Here's a simplified workflow example:

1. Hypercert Description (Human-Readable)

The hypercert would contain a clear, narrative description of the work:

{
  "name": "Forest Restoration Project - Zone A",
  "description": "This project focuses on restoring native forest ecosystems in the degraded areas of Zone A. We planted 100 indigenous tree species to enhance local biodiversity and create wildlife corridors. The project includes ongoing monitoring of tree growth and wildlife presence through camera traps."
}

2. Impact Attestations (Machine-Readable)

Each specific impact claim would be a separate attestation, allowing for individual updates and verification:

Tree Planting Attestation

{
  "schema": "0x123...schema1",
  "attestation": {
    "metric": "tree_count",
    "value": 100,
    "species_count": 12,
    "planting_date": 1705363200,
    "location_grid_ref": "E37.5-N4.2",
    "evidence_ipfs": "Qm...abc123",
    "methodology": "Manual planting with community involvement, 3x3m spacing"
  }
}

Biodiversity Impact Attestation

{
  "schema": "0x456...schema2",
  "attestation": {
    "metric": "species_count",
    "value": 15,
    "survey_method": "camera_trap",
    "survey_date": 1705795200,
    "evidence_ipfs": "Qm...def456",
    "confidence_level": 85
  }
}

3. Community Validation

The community validation would be its own attestation that references the specific claims being validated:

{
  "schema": "0x789...schema3",
  "attestation": {
    "validator": "0xabc...789",
    "attestation_refs": [
      "0x123...attest1",  // Tree planting attestation
      "0x456...attest2"   // Biodiversity attestation
    ],
    "validation_type": "on_site_verification",
    "comments": "Verified tree count and species identification. Camera trap data confirms biodiversity claims.",
  }
}

@holkexyz - Thoughts on this approach? We could potentially create a simple UI tool that helps projects create these attestations from their internal monitoring data. However there is a small danger that projects can write a completely different description than what their attestations are about e.g. "I planted 1 million trees" compared to attestation: "100 trees".

[s-adamantine]

@daviddao If the description and the attestation doesn't match, the evaluator should catch that, anyway, right?

[holkexyz]

Thanks for creating this example, very helpful for the conversation.

On the description vs attestations

• I see now how the description and attestation can be different. Sometimes this can be legitimate, e.g. 100 trees were planted, but not all survived, hence there is impact of 70 trees growing.
• For work that isn't finished, we should allow updating the metadata of the description.
• In addition to @s-adamantine 's point: Evaluators could run an algorithm that detects these differences. If a big difference is detected, the evaluator looks at it and decides if it is still legitimate or not. If it is not, the evaluator submits a negative attestation on the hypercert.

On the community validation

• I had in mind that the community validation is on the hypercert, e.g. the community validates that the work happened and had a positive impact from the community's subjective point of view. Seems like this is mutually exclusive to the community validating other attestations.

On the machine-readable attestations

• @daviddao: Would an additional human-readable comment make sense? Maybe optional? Could be used for users to understand what the attestation means. That of course creates a potential mismatch between data and comment, but I think those are detectable.

[satyam-mishra-pce]

So, it might be too early for me to contribute in the conversation. And forgive me already, if the following proposal doesn't make sense, because I am an early bird.

Dynamic link of description with attestations

There might be scenarios where the description is almost ever changing, and needs to be updated based on the latest impact statistics. For example consider the following description:

"We prevented 200 trees from getting chopped off in the last 45 days."

The creator of the evaluator, would not be able to come and update the statistics everyday. And the same holds true for the evaulator, as the evaluation would be a daily manual process.

So, can we think of a way of using placeholders in the description, like:

{
    "description": "We prevented {{trees_prevented}} trees from chopping in the last {{duration_days}} days."
}

And these placeholders, would gain the value from either the attestations or an entirely new property, descriptionPlaceholders or descriptionVariables that holds an array of variables being used in the description. For example:

{
    "descriptionVariables": [
        {
            "name": "trees_prevented",
            "source": "ipfs://TreePreventionProof" // Or some other dynamic source
        }
     ]
}

A complete example, for using it with the attestations itself, would somewhat look like:

{
  "description": "We prevented {{trees_prevented}} trees from chopping in the last {{duration_days}} days.",
  "attestations": [
    {
      "type": "proof",
      "name": "trees_prevented",
      "source": "ipfs://TreePreventionProof"
    },
    {
      "type": "proof",
      "name": "duration_days",
      "source": "ipfs://DurationDaysProof"
    }
  ]
}

Updation

For the frequency of the updation of description, based on the proofs, we can probably add another property that would let the creator choose the frequency ranging from 12 hours to 1 year or whatever feels appropriate. This updation may further be manualized via an evaluator every time, or on ocassional basis.

Validation of the IPFS or other data source

A problem that I see with this proposal, is the authenticity of the source, which is questionable. Maybe, a limit to use only blockchain based sources, with a one time evaluation of the source, (if possible) would make sense here.

That's all. :-)

[holkexyz]

Thank you @satyam-mishra-pce, it's never too early to contribute to an exploratory discussion, much appreciated.

Separation of fixed description and additional updates

In your example it could make sense to keep the work description on a higher level, which won't change. This way someone who buys the hypercerts, knows what they buy. Then the updates on the work can be done via a self-report feature (based on EAS). We are currently implementing this as a "Creator's feed", so that the creator of a hypercert can update the owners of the hypercert as often as they want.

The idea would be:

• Keep the description stable, such that what buyers buy doesn't change over time
• Update via self-reports, such that the newest information are included

Mutable metadata based on EAS

However, I also believe that there are use cases where we want to have mutable metadata. For those cases, it makes sense to base it fully on EAS. An updated description would then be a new attestation that replaces the old one, but keeps the log, such that we can trace back the updates. I think @bitbeckers might be the best person to introduce this idea more fully and technically.

[MontyBryant]

hey hey, just had great conversations with @daviddao @s-adamantine and wanted to bring the idea of leveraging Common Impact Data Standard (CIDS) to structure the impact data being collected, and EBF to provide a way of representing the ecological impacts of each Ecocert according to the six fundamental outcomes (Air, Water, Soil, Biodiversity, and Carbon).

To get a good overview of CIDS, would highly recommend digging in to this page and each of the reports 👉 Linking impact data: How a data ontology can ease impact data collection and analysis

• Part 1: “What is an impact data ontology?”
• Part 2: “The problems that an impact data ontology can solve if widely adopted”
• Part 3: “The Common Impact Data Standard: an impact data ontology”
• Part 4: “Realizing the potential”

For other documentation relating to Common Approach and CIDS check out: Common Approach Document Library. This also includes more detailed technical specs for CIDS 'Common Impact Data Standard: Version 3.0 (document)'

Essentially I imagine CIDS as the way to structure the provided evidence for each claim according to globally recognised ways to communicate impact (Activities, Outputs, Indicators, Outcomes etc.) and then making this data interoperable with other platforms and networks (e.g. Karma GAP, ReFi DAO, Kolecktivo etc.. etc..).

I am thinking that each of the activities or various parts in the CIDS data structure could then be minted as an EAS attestation, and then this data could be used to auto-populate a hypercert / ecocert which would act as the claim of creating / achieving EBF outcomes (i.e. impact).

Look forward to discussing and jamming further!

[MontyBryant]

Also worth mentioning that in collab with Jon Ruth, we built this tool: impactscribe.xyz/ for projects to be able to go through a question set that collects a whole bunch of data. This data can be used to understand and interact with a projects EBF impact and generate a rich dashboard such as: https://lexiconofimpacts.com/coastal-restoration/impact-report/.

The idea from here could be to structure the EBF data that is collected through the survey in CIDS and then once a project goes through the process they can generate the sexy impact / dashboard to be able to visually explain and showcase the impact + ecocerts for the funding and valuation of the impact 🌱

[holkexyz]

@MontyBryant I definitely resonate with the thinking. Thank you.

Do you have an example MVP how an attestation for some work that is captured by a hypercert could look like?

[daviddao]

We are currently thinking of the impact attestations around an ecocert as an ecosystem of attestations around evidence and addresses. Our first reference implementation will be at https://github.com/GainForest/ecocertain

We will follow as a basis https://www.hypercerts.org/docs/developer/attestations but extend it with some of the ideas discussed in this thread