Evidence Submission

This document describes the Evidence Submission feature, allowing Taskers to submit proof of work for their tasks.

1. Overview

Once a Tasker accepts a Referee’s request (or is matched), the Task enters a state where evidence can be submitted. The evidence consists of a text description and up to 5 image assets.

The submission process uses Cloudflare R2 for image storage and Supabase for metadata and status management.

2. Prerequisites

  • Task Lifecycle — Evidence is submitted within the context of an accepted Task Request.

3. Upload Sequence

The following sequence diagram illustrates the secure upload flow, including:

  1. Fetching Task details (to verify permissions).

  2. Generating a presigned URL via Edge Function (which securely holds R2 credentials and public domain logic).

  3. Direct upload to R2 (bypassing the application server for heavy lifting).

  4. Submitting metadata (including R2 keys and public URLs) to the database via a secure RPC.

Diagram

4. Key Components

4.1. Edge Function: generate-upload-url

  • Responsibility:

    • Validates user authentication and Task ownership.

    • Generates a unique R2 Object Key (evidence/…​).

    • Generates a recursive 10-minute Presigned PUT URL.

    • Constructs the public_url using the R2_PUBLIC_DOMAIN environment variable.

  • Security: Ensures only the Tasker can upload files for their specific task.

4.2. RPC: submit_evidence

  • Responsibility:

    • Validates that the Judgement status is awaiting_evidence or in_review.

    • Atomically transitions the Judgement status to in_review.

    • Inserts records into task_evidences and task_evidence_assets.

  • Concurrency: Uses database transactions to ensure data consistency.

4.3. Client: EvidenceRepository

  • Responsibility:

    • Orchestrates the flow: Pick Images → Get URL → Upload to R2 → Submit Metadata.

    • Handles connection to the Edge Function using the Supabase SDK (ensuring correct environment routing).

5. Notifications

When evidence is submitted or updated, a push notification is sent to the assigned Referee:

  • Insert (new submission) → notification_evidence_submitted_referee

  • Update (resubmission after rejection) → notification_evidence_updated_referee

This is handled by the on_task_evidences_upserted_notify_referee database trigger, which calls notify_event().

6. Evidence Timeout

If the Tasker fails to submit evidence before due_date, the system automatically handles detection and settlement:

  • Detection: A cron job (detect-evidence-timeouts, every 5 minutes) finds judgements in awaiting_evidence past the due date with no evidence, and sets their status to evidence_timeout.

  • Settlement: The on_evidence_timeout_settle trigger fires on status change, automatically settling points and granting the Referee a reward. See Payment & Reward Flow for settlement details.

  • Confirmation: The Tasker must still call confirm_evidence_timeout RPC to finalize. See Judgement — Confirm Evidence Timeout.

7. Related Links

  • Judgement — What happens after evidence is submitted (Referee approve/reject).

  • Task Lifecycle — Full lifecycle including evidence timeouts.