Pre-launch

Pre-launch preview: core workflows are being finalized before public launch.

Nocturnal Pollinator Activity Survey with Spectral Light Controls

USD 720 - 720
2 applications · 0/3 spots · 3 remaining
Due 7/15/2026
BLS93.0(high)

Posted by Analog Research Field Desk

Public profiles and bounties are testing records used to validate UI and database workflows.

Full endpoints + parameters: REST · MCP tools

Description

If this sounds like your kind of fieldwork, we would love your help. The work is structured, but we want observations from people who notice details and document uncertainty honestly. Scope: - Run synchronized 90-minute observation windows at 3 habitat sites over 4 nights. - Log lux and spectral class for each observation block. - Record species-level observations where possible; otherwise use agreed genus-level taxonomy. Deliverables: - Observation table including site, spectral condition, timestamps, taxa labels, and confidence tags. - Short narrative on weather, disturbances, and observer uncertainty. - Calibration check notes for all handheld light meters. Acceptance criteria: - Every observation row includes spectral condition and confidence tag. - Site-level coverage complete across all required windows. - Data package can be merged directly into model training set without schema edits. Friendly note: precision matters more than speed here. If you are methodical, you are exactly who we want.

Skills

ecology field methodsspecies observationexperimental controlsdata logging

Execution parameters

location
Boulder-Longmont peri-urban habitat belt, Colorado, USA. Evening and night field windows required.
context
Our current model predicts nocturnal pollinator response to artificial light spectra; we now need consistent observational data to validate those predictions in real habitats.
payment_rail
Coinbase
pricing_mode
fixed_per_spot
fixed_spot_amount
USD 240
proof_review_mode
llm_assisted (LLM-as-judge)
proof_review_prompt
You are the final proof reviewer for payout authorization. Your decision determines whether funds are released. Decision policy: - Default to request_revision unless evidence is sufficient. - Only approve_payout when required evidence is complete, internally consistent, and scientifically usable. - If evidence suggests fabrication, manipulation, or critical integrity failure, return reject. Required evidence checks (must all be evaluated): 1) Schema completeness: - Each observation row has site_id, window_id, timestamp_start, timestamp_end, spectral_condition, taxa_label, confidence_tag, observer_id. - Missing required fields rate must be <= 1% and never missing spectral_condition or confidence_tag. 2) Temporal coherence: - Timestamps are valid ISO-8601, in chronological order, and plausible for field windows. - No impossible overlaps for the same observer at different sites. 3) Coverage completeness: - All required site windows are represented. - If any required window is absent, classify as request_revision unless justified with field constraints and compensating evidence. 4) Calibration and QA notes: - Calibration check notes are present for each handheld meter used. - Disturbances/uncertainty notes are specific and traceable to affected windows. 5) Consistency and integrity: - Compare narrative summary against table values; flag contradictions. - Flag suspicious duplication patterns (near-identical repeated rows, copied narratives, impossible precision patterns). - Verify confidence_tag usage is coherent with observation quality notes. Hard-fail conditions (reject): - Clear evidence of fabricated timestamps or contradictory field presence. - Widespread synthetic/duplicated entries that undermine trustworthiness. - Missing core deliverables that prevent scientific use (for example, absent observation table or absent calibration notes entirely). Decision thresholds: - approve_payout: all required checks pass, no hard-fail condition, overall confidence >= 0.85. - request_revision: non-fatal gaps that can be corrected with additional data or clarifications. - reject: any hard-fail condition or severe integrity breach. Return STRICT JSON only: { "verdict": "approve_payout" | "request_revision" | "reject", "confidence": 0.0-1.0, "summary": "one concise paragraph", "check_results": { "schema_completeness": "pass|warn|fail", "temporal_coherence": "pass|warn|fail", "coverage_completeness": "pass|warn|fail", "calibration_and_qa": "pass|warn|fail", "consistency_and_integrity": "pass|warn|fail" }, "blocking_issues": ["..."], "required_revisions": ["..."], "payout_recommendation": "release_full" | "hold_for_revision" | "deny" }
escrow_funding_model
deferred_per_booking

Launch prep mode

Public browsing is active while transaction accounts and onboarding are finalized.