CitizenClimate — Data Integrity & Methodology Protocol

For Verification & Validation Bodies (VVBs) Document Version: April 2026

Summary for Auditors

Data Type	Deletable?	Timestamped?	Georeferenced?	Photo Evidence?	AI Verified?
Survey submissions	No	Yes	Per survey (required or optional)	Where configured	Species fields only
Faulty submissions	Archived only (with reason)	Yes	Preserved	Preserved	Preserved
Species observations	No	Yes	Yes	Yes	Yes
Grievances	No	Yes	No	Optional	No
SDG survey responses	No	Yes	Yes	Where configured	No
Biodiversity records	No	Yes	Yes	Yes	Yes
Media files	No	Yes (upload metadata)	Via parent submission	N/A	N/A

Key assurances for verification bodies:

Every record in the system has a creation timestamp that cannot be modified
No data is ever deleted — only archived with an auditable reason
GPS coordinates are captured at the device level at the time of field entry, not retrospectively
All AI species identifications are performed by independent third-party services and stored verbatim
Grievances are permanently recorded and cannot be suppressed by Project Developers
VVBs have direct read access to all project data — they do not rely on PD-generated reports
All data exports (CSV/JSON) include raw records, not just summaries

CitizenClimate is built on Google Firebase infrastructure (Firestore, Firebase Storage, Firebase Authentication, Cloud Functions). Data residency and Google Cloud audit logging apply in addition to the application-level protections described above.

Citizen Science App Track SDG community led dMRV biodiversity monitoring

1. What CitizenClimate Is

CitizenClimate is a digital Monitoring, Reporting and Verification (MRV) platform designed for nature-based carbon credit projects. It replaces paper-based field forms and manual data entry with a mobile app that works in remote areas without internet access.

The platform supports three user roles:

Community Members (CM) — field data collectors on the ground
Project Developers (PD) — organisations managing the carbon project
Verification & Validation Bodies (VVB) — independent auditors who review data

All three roles can see the same underlying records. VVBs have read access to everything: submissions, photos, AI species identifications, SDG scores, grievances, and biodiversity observations.

2. How Data Cannot Be Erased

All submitted data is stored in Google Cloud Firestore, a cloud database with the following permanent protections written into the system's security rules:

Submissions can never be deleted. The rule allow delete: if false is applied to every submission document. Not even administrators can remove a record from the database.
Survey templates can never be deleted or modified once created. They serve as the permanent version of the questions asked in the field.
Grievances can never be deleted. Once a community member raises a concern, it exists permanently in the system.
Photos and videos can never be deleted. Once uploaded to Firebase Storage, media files have no delete endpoint exposed in the application or its backend functions.
Forum posts can never be deleted.

The only action a Project Developer can take on a submission they believe to be erroneous is to archive it with a reason — explained in Section 3 below.

3. Faulty Data Is Archived, Not Deleted

If a Project Developer identifies a submission as problematic (e.g. a duplicate, a test entry, or a suspected error), they cannot delete it. Instead, they archive it. Archiving adds three new fields to the original, untouched record:

FieldPurpose
archivedBoolean flag marking the record as archived
archiveReasonThe stated reason for archiving, provided by the PD
archiveNotesAdditional context or notes

The original submission data, timestamp, location, photos, and answers are fully preserved. An archived submission is visible to VVBs with the archive reason attached. This means the audit trail shows exactly what was collected, why it was set aside, and who made that decision.

Community Members cannot archive their own submissions. Only Project Developers have this permission, and they cannot change the underlying data — only flag it.

4. All Data Is Timestamped

Every record in the system carries a submittedAt timestamp generated at the moment of submission:

Format: ISO 8601 (e.g. 2025-04-05T14:32:11.000Z) — a universal standard readable by any audit tool
Precision: Milliseconds
Source: The device clock at the moment the user taps Submit, captured before it leaves the app

Additional timestamps are recorded for:

EventTimestamp Field
Grievance raiseddateCreated (immutable)
Grievance reviewed by PDdateResponded (auto-set by system)
Grievance resolveddateResolved (auto-set by system)
Badge awardedawardedAt
Lesson completedcompletedAt
Media file uploadeduploadedAt (stored in file metadata)
Data exportedexportedAt

When data is collected offline (without internet), the device timestamp is captured at the moment of field entry. When the device reconnects and syncs, the original timestamp is preserved — the sync date is recorded separately. This means a VVB can see when a field observation was made versus when it reached the cloud.

5. All Data Is Georeferenced

Every data submission can carry GPS coordinates collected from the device at the time of submission. The system requests the highest available GPS accuracy from the device (navigation-grade, typically < 5 metres), with automatic fallback to lower accuracy if high precision is unavailable.

The following location data is captured and stored:

Latitude and longitude — stored as a GeoPoint object in Firestore, linked permanently to the submission
GPS accuracy in metres — captured alongside the coordinates so VVBs can assess the precision of each reading
Farm boundary polygons — where applicable, field teams trace the boundary of a plot, storing an ordered array of GPS waypoints
Route walkovers — transect surveys capture a continuous GPS track of the path walked during data collection

Location is required or optional per survey type, as configured by the Project Developer. When required, the system will not allow submission without a valid GPS fix. All coordinates are stored permanently and cannot be modified after submission.

Species observations (birds, plants, animals) also capture latitude and longitude at the point of detection, providing georeferenced evidence for each biodiversity record.

6. Photo and Video Evidence

The platform requires photographic evidence for designated survey fields. The following applies to all media:

Collection:

Photos and videos are taken in the field using the device camera or selected from the gallery
Image quality is configurable per survey field (low / medium / high resolution)
Multiple photos can be attached to a single field entry

Storage and linking:

Files are uploaded to Firebase Storage using a fixed path structure: submissions/{projectId}/{surveyId}/{submissionId}/{type}/{fieldName}-{timestamp}.{ext}
Every file is stored with metadata that permanently records: which submission it belongs to, which form field it was attached to, the original filename, the upload timestamp, and whether it came from an offline sync
The download URL is permanently embedded in the submission document

Immutability:

Files cannot be deleted through the application
The submission document cannot be updated to remove media URLs
Even if a submission is archived, all photos and videos remain fully accessible via their permanent URLs

VVBs reviewing a submission will see the photos inline and can download originals. The metadata attached to each file serves as a chain of custody record.

7. AI Species Identification

CitizenClimate uses AI services to identify species from photos and audio recordings. Identification is done through secure Cloud Function proxies — the AI services are never called directly from the app, and API keys are never exposed to end users.

Supported identification types:

CategoryInputAI Service
PlantsPhotoPlant.id (via Cloud Function)
BirdsAudio recordingBirdNET (via Cloud Function)
AnimalsPhotoAI service via Cloud Function
InsectsPhotoAI service via Cloud Function
MushroomsPhotoAI service via Cloud Function
Crop healthPhotoAI service via Cloud Function

What the AI returns:

Scientific name
Common name
Confidence score (0–100%)
IUCN conservation status (Least Concern through Extinct)
For birds: start and end time of the detected call within the audio, minimum confidence threshold of 25%
For plants: health assessment data

How results are stored: Each species observation is stored as a permanent record containing the scientific name, common name, category, observation count, IUCN status, the submission it came from, the timestamp of observation, GPS coordinates, observer name, and URLs to the supporting photos or audio.

Offline identification: If a field worker has no internet at the time of submission, the observation is saved locally with a status of ai_pending. When connectivity is restored, the AI identification is completed and the result is written permanently into the submission. The original observation timestamp — when the species was actually seen in the field — is preserved regardless of when identification occurs.

Rate limiting: To prevent abuse, each user is limited to 20 AI identification requests per minute. Usage is tracked per project with monthly credit allocations.

8. Anonymous Grievance Mechanism

Community members have a dedicated, protected channel to raise concerns about a project. The grievance mechanism works as follows:

Raising a grievance:

Any community member enrolled in a project can submit a grievance at any time
They provide a title and a description of their concern
A timestamp is automatically recorded at the moment of submission

What is stored permanently:

FieldMutable?
TitleNo — locked at creation
DescriptionNo — locked at creation
Date createdNo — locked at creation
CommunityNo — locked at creation
Status (Pending / Under Review / Resolved)Yes — PD can update
Resolution narrativeYes — PD can add
Date respondedAuto-set when PD reviews
Date resolvedAuto-set when resolved

Anonymity in practice: The grievance form does not display the submitter's name or email address to Project Developers or other community members. The community of origin is recorded (for project context) but individual identity is not shown on the grievance card. Community members can also upvote or downvote grievances — votes are aggregated so individual voting behaviour is not visible.

VVB access: VVBs can read all grievances across a project, including the full history of status changes and resolution responses. This provides an independent view of whether community concerns are being addressed in good faith and within a reasonable timeframe.

9. SDG Monitoring

The platform supports structured data collection aligned to the UN Sustainable Development Goals. Each survey can be tagged to a specific SDG (1–17), with fields and scoring weights configured by the Project Developer.

How scoring works:

Each survey field has a set of response options, each assigned a score (0–100)
Fields have relative weights (e.g. a field with weight 2 contributes twice as much as a field with weight 1)
The final submission score is the weighted average of all field scores

This produces a single numeric SDG score per submission, per survey

What is tracked over time:

Scores are tracked by calendar year, allowing year-over-year comparison
The system calculates whether a community's average score has improved or declined compared to the previous year
Community-level averages are calculated separately, so a VVB can see performance broken down by community within a project
All raw submission data (individual question responses, not just totals) is stored and exportable

Export formats: SDG data can be exported as CSV or JSON, including:

Summary metrics
Yearly trend data
Community-by-community breakdown
Full raw submission detail (every question and answer)

All SDG submissions follow the same immutability rules as standard submissions. Once a score is recorded, it cannot be altered.

10. Biodiversity Monitoring

The platform includes a full biodiversity monitoring module that goes beyond simple species lists.

What is tracked:

Birds, plants, animals, insects, and mushrooms
Scientific name, common name, and IUCN conservation status for each species
Observation counts per species (multiple sightings tracked individually)
GPS coordinates per observation
Photos and/or audio recordings as evidence
The name of the field observer who made the identification
The submission it originated from

Diversity indices calculated: The system automatically computes recognised scientific metrics from the raw observation data:

IndexWhat it measures
Species RichnessTotal number of unique species
Simpson's IndexProbability that two random individuals belong to different species
Shannon-Wiener IndexSpecies diversity accounting for evenness
Pielou's EvennessHow evenly individuals are distributed across species
BII ProxyBiodiversity Intactness Index estimate
Alpha DiversityMean species richness per submission point
Beta DiversitySimilarity between communities (Sørensen index)
Gamma DiversityTotal unique species across the entire project
Endangered species: Any species with an IUCN status of Vulnerable (VU), Endangered (EN), Critically Endangered (CR), Extinct in the Wild (EW), or Extinct (EX) is automatically flagged and counted in a dedicated endangered species total.

Immutability: Every species observation is permanently linked to its parent submission. Observations cannot be deleted. If a submission is archived, its species data remains in the biodiversity record. This means the biodiversity dataset grows monotonically — records are never removed, only added.

11. Offline-First Data Collection

A key design principle is that CitizenClimate works in remote areas with no mobile signal. When offline:

Surveys are pre-loaded to the device and available without internet
Submissions are saved to a local encrypted database on the device, with the field timestamp recorded at the moment of entry
Photos and media are stored locally pending upload
All pending submissions are visible to the field worker on a Sync Status screen showing which records are awaiting upload

When the device reconnects:

All pending submissions are uploaded in order
Media files are uploaded first; their URLs are then embedded in the submission
Badges and points are awarded retroactively
The sync event is logged with timestamp, submission ID, survey name, and success or failure status

The sync history is retained on the device (last 50 events). Failed syncs are shown to the user and can be retried.

Summary for Auditors

Data Type	Deletable?	Timestamped?	Georeferenced?	Photo Evidence?	AI Verified?
Survey submissions	No	Yes	Per survey (required or optional)	Where configured	Species fields only
Faulty submissions	Archived only (with reason)	Yes	Preserved	Preserved	Preserved
Species observations	No	Yes	Yes	Yes	Yes
Grievances	No	Yes	No	Optional	No
SDG survey responses	No	Yes	Yes	Where configured	No
Biodiversity records	No	Yes	Yes	Yes	Yes
Media files	No	Yes (upload metadata)	Via parent submission	N/A	N/A

Key assurances for verification bodies:

Every record in the system has a creation timestamp that cannot be modified
No data is ever deleted — only archived with an auditable reason
GPS coordinates are captured at the device level at the time of field entry, not retrospectively
All AI species identifications are performed by independent third-party services and stored verbatim
Grievances are permanently recorded and cannot be suppressed by Project Developers
VVBs have direct read access to all project data — they do not rely on PD-generated reports
All data exports (CSV/JSON) include raw records, not just summaries

One App,
Many Uses

CitizenClimate is a mobile app for collecting environmental data in the field. It's used by communities, project developers, and independent auditors to monitor nature-based carbon credit projects — tracking things like biodiversity, land use, community wellbeing, and SDG (UN Sustainable Development Goal) progress. Think of it as a structured field notebook that syncs to the cloud, works offline, and rewards participation.