Home

Owner(s): CrowdPM Team | Last updated: 2026-03-08 | Status: Production

*Source: CrowdPM Platform — Image of a single data point. Map of Hardware Node. Accessed 2026-03-08.*

CrowdPM Platform is a crowd-sourced PM2.5 air-quality monitoring stack that securely ingests hyper-local sensor readings and presents them through an interactive WebGL map and operator dashboard.

Start here

Recommended reading order:

1. Project Overview & Goals
2. Requirements & Scope
3. System Design (with diagrams)
4. Developer Setup & Project Conventions
5. Demo Scripts
6. Deployment Guide
7. Release Plan & Notes (milestones---demos)
8. Handoff, Reflection, and Future Work

What CrowdPM Platform is

CrowdPM Platform is a full-stack system for collecting, processing, moderating, and visualizing crowd-sourced PM2.5 measurements.

At a high level, the platform consists of:

• a Firebase-native backend for device onboarding, ingest, batch processing, storage, moderation, and authenticated APIs;
• a React + Vite frontend that renders a Google Maps + deck.gl visualization and a user dashboard;
• a DPoP-based device authorization and pairing flow for nodes;
• Cloud Storage retention of raw ingest payloads alongside Firestore-backed processed measurements and batch metadata.

What the platform does today

The current repository and runtime surface support the following major capabilities:

• secure device pairing and activation;
• DPoP-bound device access tokens for ingest;
• raw ingest retention in Cloud Storage;
• shared batch processing into Firestore;
• owner views for batches and device data;
• anonymous public batch views for approved public data;
• moderation routes for submissions;
• user role management for moderators and super admins;
• a map-centric frontend with time-based playback behavior;
• local emulator-driven smoke tests and reproducible demo workflows.

Role model

The current project should be documented in terms of the roles that actually exist in code and API behavior:

• Guest: anonymous viewer of the public-approved feed.
• Authenticated user / device owner: signed-in human user who owns devices and can access their own data and dashboard flows.
• Moderator: trusted operator who can review submissions and see moderation-sensitive data.
• Super admin: highest-privilege operator who can manage users and broader administrative workflows.
• Device: non-human actor that completes the pairing flow, obtains access tokens, and submits measurements.

The wiki should not collapse everything into only Guest/User/Admin, because the current API surface distinguishes moderator and super-admin behavior.

Documentation model

This project uses a split documentation model:

• Wiki: top-level overview, scope, architecture, contributor onboarding, demo narrative, release notes, and handoff context.
• Repository /docs + README + config examples: operational runbooks, environment variable truth, emulator instructions, and release procedures.
• Source code: canonical implementation details for routes, claims, storage layout, and processing behavior.

When technical behavior changes, update the implementation first, then the repository docs, then the relevant wiki pages.

Key pages

Product and architecture

• Project Overview & Goals
• Requirements & Scope
• System Design (with diagrams)
• How We Use Deck.gl

Contributor onboarding and operation

• Developer Setup & Project Conventions
• Demo Scripts
• Deployment Guide
• Team Standards for Development
• Wiki Editing & File Naming Notes

Project management and historical record

• Decision Log (short design notes)
• Architecture Decision Records (ADRs)
• Release Plan & Notes (milestones---demos)
• Meeting Notes & Decisions Log
• Handoff, Reflection, and Future Work
• GenAI Usage Log & Citations

Canonical implementation references in the repo

Use these repository locations when verifying behavior:

• README.md for current feature summary, API surface, and local setup;
• docs/development.md for emulator-first local development and smoke testing;
• docs/demo.md for shared demo-environment deployment;
• docs/prod.md for production release procedure;
• frontend/.env.example and functions/.env.example for environment variables;
• functions/src/index.ts and functions/src/openapi.yaml for route registration and API contract.

*Source: Kaiterra (Air Academy) — “A Guide to Understanding Particulate Matter (PM)” image: “Particulate Matter Sizes.” Accessed 2026-02-10.*