Summary

The Claims Engine ecosystem (both the KOI off-chain semantic layer and the forthcoming CLAMS CosmWasm contract for Ethereum interop) needs canonical schema definitions for Claims and Attestations. These should live in regen-data-standards alongside the existing CreditClassInfo, ProjectInfo, and Impact schemas — governed by the Framework Working Group.

Background

Currently, the KOI claims engine (gaiaaiagent/koi-processor, branch regen-prod) defines its own ad-hoc schema with no reference to framework.regen.network. The CLAMS contract (Spec B, Ethereum interop grant) needs a JSON-LD context document as a deliverable. These are converging on the same vocabulary problem from different directions.

The FWG already has the infrastructure to solve this:

• LinkML schemas that generate JSON-LD, JSON Schema, SHACL, and RDF/TTL
• Taxonomy enums for ActivityType, EnvironmentType, ImpactType
• A live SPARQL endpoint with CI/CD validation
• The rfs: / rft: namespace under framework.regen.network

Proposed Additions

1. schema/src/Claim.yaml — Claim class

A Claim represents a structured impact assertion linked to evidence and verification:

Suggested attributes (to be refined through FWG review):

• claimant → Entity (who makes the assertion)
• subject → reference to a project, location, or entity the claim is about
• statement → string (plain-language impact assertion)
• hasClaimType → ClaimType enum (see below)
• hasImpactType → existing ImpactType (links claims to the impact taxonomy)
• hasCreditClass → optional reference to a credit class
• evidence → list of evidence references (URIs)
• verificationStatus → VerificationStatus enum
• metadata → extensible key-value (quantity, unit, dates, SDGs, methodology)

2. schema/src/Attestation.yaml — Attestation class

An Attestation is a reviewer's judgment about a claim's veracity:

Suggested attributes:

• claim → reference to a Claim
• reviewer → Entity
• verdict → VerdictType enum (pending, approved, rejected, needs_info)
• rationale → string
• evidenceReviewed → list of evidence URIs examined

3. Taxonomy additions to schema/src/taxonomy.yaml

ClaimType enum — types of claims that can be made:

• ECOLOGICAL (impact claims about ecological outcomes)
• SOCIAL (impact claims about social outcomes)
• FINANCIAL (claims about financial instruments or returns)
• GOVERNANCE (claims about governance processes or decisions)
• BIOCULTURAL (composite claims spanning ecological + cultural dimensions — needed for PACTO)

VerificationStatus enum:

• SELF_REPORTED
• PEER_REVIEWED
• VERIFIED
• LEDGER_ANCHORED
• WITHDRAWN

VerdictType enum:

• PENDING
• APPROVED
• REJECTED
• NEEDS_INFO

4. Extend Entity.yaml

Add optional walletAddress attribute to bridge off-chain entity identities (KOI entity URIs) to on-chain identities (Regen/Ethereum addresses).

Why This Matters

• Spec B deliverable: The Ethereum interop grant requires a JSON-LD context. Building it on FWG schemas (vs. inventing a new context) gives it legitimacy and reusability.
• Cross-system coherence: KOI claims engine, CLAMS contract, and downstream consumers (PACTO, ASHA, Salmon Nation) all reference the same vocabulary.
• Governance path: Claim types become governed via the same FWG process (and eventually DAO DAO on-chain governance) as activity types and environment types.
• SPARQL queryability: Once claims conform to FWG schemas, the existing SPARQL endpoint can query across claims, projects, and credit classes.

Downstream Consumers

• KOI Semantic Claims Engine (gaiaaiagent/koi-processor)
• CLAMS CosmWasm Contract (Spec B, in design)
• PACTO Framework (biocultural crediting)
• ASHA, Salmon Nation
• RI Pod (regenerative investing — PAMEL-QB)
• Ethereum ecosystem (EAS attestations, Hypercerts)

Open Questions

• Should ClaimType be a flat enum or hierarchical (like ActivityType)?
• Should Claim reference Impact directly, or is hasClaimType + hasImpactType sufficient?
• What's the FWG's process for adding new schema classes vs. extending existing ones?
• Should this be a dedicated "Claims Schema Working Group" or handled within the existing FWG scope?

References

• FWG progress post: https://forum.regen.network/t/framework-working-group-progress-why-it-matters/532
• KOI Claims Engine V1 spec: gaiaaiagent/koi-processor/docs/claims-engine-v1.md (branch regen-prod)
• KOI Claims Engine V2 attestation design: gaiaaiagent/koi-processor/docs/claims-engine-v2-attestations.md
• Existing LinkML schemas: schema/src/ in this repo