Version 1.0 · July 23, 2026 · Beta system description

Litterbug is a mobile application that promotes decentralized litter collection efforts. It combines camera-assisted litter logging, human review of machine-vision output, community building, and optional person-to-person incentives including tipping and litter collection bounties. Its purpose is to socially normalize litter collection and create a new form of environmentalism through micro-gig-ecology and economy.

Scope note. This paper describes the current beta architecture. Features marked experimental are under active validation. The product is not yet publicly released on the App Store.

Contents

1. Problem and design principles
2. Application tabs
3. Vision and recognition pipeline
4. Human review and model training
5. Data model and security
6. Community, sharing, and map workflows
7. Tips, bounties, and payouts
8. Limitations and roadmap
9. Privacy and responsible operation
10. AI development statement

1. Problem and design principles

Litter collection benefits people through improving our local environment, enhances human health via time spent outdoors and reductions in pollution (e.g., microplastics), and promotes community cohesion by encouraging positive interactions between people within neighborhoods. Litter is a tragedy of the commons, where the responsibility for litter collection is assumed by the government and contractors through tax dollars. While these efforts are substantial, they cannot address the continuous flow of litter into the environment, nor do they promote a society that feels responsbile for pollution or incentivized to enhance the environment they reside within. Litterbug addresses these problems by decentralizing, democratizing, and incentivizing litter collection.

• Shared stewardship is primary. Litterbug is designed to make local environmental care socially normalized.
• Technology supports society. The app helps people document what they collect.
• Community efforts are visible. Sessions, public posts, map spots, and leaderboards help neighbors, government, and industry support local litter collection.
• Incentives support action. Optional tips and bounties give communities tools to support litter collection with more incentives planned.

2. Application tabs

Scan

The Scan tab is the field workflow. A physical device camera feeds a frame processor; detections are tracked across frames before an item is promoted to a count. The scanner can attach a short-lived foreground location lookup, haptic feedback, a review image, and later OCR-derived brand information. The current native camera/model path is intentionally unavailable in iOS Simulator because it depends on native TensorFlow Lite components.

Train

The Train tab is the session and review workspace. It lists current-session items, summarizes container and brand counts, and presents an observation-review queue. A participant can correct container type, brand text, OCR text, bounding box, or resolution state; tag observations; and remove mistaken review records. Reviewed items award in-app training XP and contribute to badges and the Litterbug progression state.

Share

Share has Community and Leaderboard subtabs. Community supports posts, optional images, hashtags, reactions, session shares, cleanup-completion content, and weekly summaries. Session sharing can build a visual card with selected cleanup totals, route-style map context, and a location granularity selected by the user. Leaderboard rankings are derived from public aggregate cleanup totals; the interface can offer optional tips to eligible users.

Map

The Map tab uses foreground location and native maps to show community cleanup spots. A user may create a spot with a title, description, optional image, and location; another user can claim it, submit a completion, and move it through open, claimed, awaiting-validation, and done states. A poster may fund a bounty for a spot. Bounty release is tied to its workflow and payment state rather than a client-side promise.

Profile

Profile provides personal totals, cleanup history, badge and progression information, feedback, account controls, and payout controls. People receiving funds complete Stripe Connect onboarding in a browser-hosted Stripe flow. The screen can show available and pending balances, payout readiness, external-account status, payout schedule, and standard or instant cash-out options where Stripe and the account allow them.

3. Vision and recognition pipeline

The live detector is litterbug_v1, a TensorFlow Lite object-detection model with a 320 × 320 input and 18 upstream class indices. Nine usable litter labels are mapped to product-facing container types: cardboard; clear plastic bottle; crisp packet/wrapper; disposable plastic cup; drink can; glass bottle; paper cup; plastic straw; and polystyrene. Six malformed upstream labels and bottle-cap subparts are deliberately suppressed. The client also recognizes a broader correction taxonomy such as bags, cigarette litter, film, cutlery, foil, gloves, masks, fragments, and other.

Raw detections are not immediately logged. The scanner applies a confidence threshold, dimensional sanity checks, and candidate limits; then links boxes over time using overlap, center distance, size, shape, and appearance continuity. An object must persist across multiple observations and a short dwell window before it counts. This lowers duplicate counts when a camera remains over one item, while special handling accommodates small or elongated objects such as straws. The scanner retains only a bounded number of active tracks and applies a cooldown/handoff policy before recognizing a new object.

Brand recognition is a separate, asynchronous path. A cropped region around an active object is sent to native OCR; text may update a recently logged item only inside a short attachment window. The app normalizes known aliases against a large brand lexicon. It also includes an experimental on-device TinyBERT-style named-entity-recognition model: 64-token BERT inputs (input_ids, attention_mask, token_type_ids) produce [1,64,3] logits for O, B-BRAND, and I-BRAND. This model is a developing enhancement, not a substitute for review. Table 1 summarizes the mobile-client and on-device-vision layers that support this pipeline.

4. Human review and model training

Machine output becomes useful training evidence only after human intervention. For each counted item, the review system can preserve a snapshot, detector summary, OCR text, scan context, corrected brand and container type, semantic bounding-box data, tags, and a resolution status. Deferred processing keeps intensive image and model work off the live scanning path and supports retrying interrupted uploads or review synchronization.

This structure separates two kinds of truth: the event record used to run the product and the richer evidence record used to assess and improve recognition. Corrections can be exported and curated into training datasets; model experiments are versioned independently of the app’s live counting model. The system’s gamification—XP, stages, collectible Litterbugs, and badges—rewards review participation, not a claim that every correction is automatically accepted into a future model. The backend and media layers supporting this workflow are summarized in Table 1.

5. Data model and security

Supabase Auth maintains account sessions. Profile data includes a username, aggregate item total, account timestamps, and limited Stripe identifiers/status fields. Core tables include authoritative litter items; sessions; reviewed observations; community posts, comments, and reactions; cleanup spots, claims, and completions; badge-related records; and payment/payout ledgers. Location, time, container type, confidence, and a nullable brand can be associated with a litter item.

The mobile client treats litter_items as the runtime source of truth. Richer images, OCR, corrections, and diagnostic artifacts are stored in a separate review path so the core session, profile, and leaderboard views do not depend on a slow model-processing job.

Postgres row-level security constrains user-owned reads and writes. Sensitive counters and payment fields are not client-writable. Payment operations use authenticated Edge Functions and Stripe secret keys held server-side; client code receives only the data needed to present a payment sheet or reflect status. Realtime subscriptions keep selected app views current without requiring a polling loop. Diagnostic scan-power tables can record device/build context, timing, battery/thermal signals, and error states during beta profiling. Table 1 identifies the backend technologies that implement these controls.

6. Community, sharing, and map workflows

Community content has explicit source types—ordinary user post, session share, cleanup spot, spot completion, or weekly summary—and can carry public media, hashtags, reactions, and moderation visibility. The map is designed for coordination rather than surveillance: foreground location is used when permission is granted, and a participant chooses what location precision to expose in a share. A map spot is public by design and should never be created for a sensitive location.

Badges recognize cumulative cleanup, training, and community milestones. They are a motivational layer, not a certification program. Leaderboard and weekly-summary data are aggregation views over cleanup activity; they do not independently verify disposal, location ownership, or the environmental condition of a place. The mobile client, backend, media, and device-service layers involved in these workflows are listed in Table 1.

7. Tips, bounties, and payouts

Litterbug supports optional USD tips and cleanup-spot bounties. The current beta permits values from $1.00 to $500.00 per payment. A payment starts in an in-app Stripe PaymentSheet with card support and, where configured, Apple Pay or Google Pay. Users cannot tip themselves. Stripe customer, card, bank, identity-verification, and destination-account details are handled by Stripe rather than stored as raw payment data by Litterbug.

The current fee calculation is transparent but estimated at checkout: the intended recipient amount, a 1% platform fee, and an estimated domestic-card processing charge (2.9% plus $0.30, grossed up) form the displayed total. Stripe’s actual fee is reconciled afterward in the server ledger. Payment records retain kind, amount, total, platform fee, estimated and actual processor fee, PaymentIntent/charge/transfer identifiers, timestamps, and state such as requires-payment, processing, succeeded, released, refunded, or failed.

Funds for eligible recipients move through Stripe Connect. A recipient must complete Stripe onboarding and have required charges/payout capabilities enabled before funds can be released or withdrawn. The app exposes balance and payout health, while Stripe determines availability, account requirements, schedules, and whether instant payout is offered. A bounty is associated with a map spot and its completion/validation workflow; it is not an unconditional reward merely because a pin was created or claimed. In beta, payment systems may operate in Stripe test/sandbox mode. Table 1 summarizes the payment and backend layers that support these flows.

8. Limitations and roadmap

Vision models can fail because of occlusion, poor lighting, motion, crushed containers, unfamiliar packaging, object overlap, and domain shift. OCR may miss, misread, or over-read text. A detection or brand match should be understood as a suggestion with a confidence score, not proof. Human review, spatial/temporal tracking, and conservative count promotion mitigate errors but do not eliminate them.

Current work includes improving custom litter detection and brand extraction, measuring camera power use, strengthening correction-data provenance, refining community moderation and validation, and testing financial workflows before a public release. Litterbug’s success should be evaluated by reliable local usefulness, transparent limitations, and improved cleanup coordination—not only by raw object totals.

9. Privacy and responsible operation

Litterbug can process account information, camera frames, optional review images, foreground location, public community content, diagnostic data, and payment metadata. Public surfaces may show usernames, aggregate totals, posts, map pins, and media chosen for public sharing. Exact locations and images can be sensitive even when a cleanup is well-intentioned. Users should avoid posting homes, schools, workplaces, personal data, or unsafe locations.

The system uses Supabase for auth and backend data, Cloudflare R2 for object media, Stripe for financial activity, device platform services for camera/location/diagnostics, and Have I Been Pwned’s k-anonymity password check during signup. Litterbug does not sell personal information and does not use third-party advertising or cross-app tracking. For the full disclosures, rights, and retention terms, read the Privacy Policy.

10. AI development statement

Litterbug was developed through a human-led, LLM-assisted engineering process. The project’s creator directs the product purpose, feature priorities, architecture choices, policy language, financial model, and release decisions. They conduct device and field testing, inspect implementation changes, diagnose observed failures, and decide whether a proposed change is accepted, revised, deferred, or removed.

Large language models, including Codex, have been used as collaborative development tools: to discuss designs, draft and revise code and documentation, propose debugging hypotheses, organize implementation tasks, and translate human test feedback into candidate changes. Those suggestions are not treated as authoritative. The project record preserves iterative human feedback—for example, on-device scan behavior, review-screen usability, model quality, and Stripe test flows—and the implementation is adjusted and tested against that feedback.

This development assistance is distinct from Litterbug’s product models. The current beta uses on-device object detection, OCR, lexicon-based brand normalization, and an experimental compact brand-entity model. It does not use a generative LLM as a required live scanning, correction, payment, payout, moderation, or cleanup-validation decision-maker. An earlier LLM-based OCR-cleanup experiment was deliberately deferred after device testing found the available local runtimes unreliable; its outputs were removed from the active review flow. Human correction remains the mechanism for resolving uncertain observations.

As with any LLM-assisted software project, generated suggestions can be incomplete or wrong. Technical claims in this paper describe the implemented beta at the time of publication; code review, device testing, backend safeguards, and human judgment—not an LLM response alone—determine what is shipped. If a future release adds a cloud or generative-AI service to a user-facing workflow, Litterbug will document the change and update its privacy disclosures before release.