Proposal: isolated environmental observation retrieval suite (12 tasks)
I'm Ziao Yang, a PhD candidate at Brandeis University. I'd like to contribute a new environmental-observation-retrieval-v0 suite, isolated from the released V1/V2 corpora.
The category would cover real public-data workflows: selecting the right monitoring location, observed versus predicted product, time window, units, datum/statistic, and requesting the resulting data. I would start with two representative tasks, then expand to 12 distinct workflows after scope approval, rather than make date-only variants.
Two pilot examples
- NOAA Boston 8443970: request six-minute observed water levels for 2025-09-12 through 2025-09-13, metric, GMT and MLLW. Source: https://tidesandcurrents.noaa.gov/waterlevels.html?id=8443970 .
- USGS Charles River at Waltham, USGS-01104500: select daily mean discharge (not continuous gage height), water year 2025 (2024-10-01 through 2025-09-30), and request CSV data. Source: https://waterdata.usgs.gov/monitoring-location/USGS-01104500/ .
What has actually been checked
I have operated the NOAA controls in Chrome and exported a 480-row historical CSV; its timestamps run from 2025/09/12 00:00 to 2025/09/13 23:54 and the header includes verified water level in metres. The USGS daily-discharge/date/mean selections have also been exercised in Chrome; final ZIP completion is not yet verified.
Reading the public site scripts exposed an important distinction: NOAA's final CSV is generated client-side from the table, whereas USGS fetches CSV before assembling a ZIP in the client. A correct HTTP request therefore does not by itself prove a final file was saved. For the initial suite I propose the explicit terminal outcome "configure and initiate the correct observation-data request": NOAA's observed-water-level JSON GET, and USGS's daily-series CSV GET. Final artifact completion would require an additional independent check and would not be claimed from interception alone.
I would validate wrong station, product, date range, unit, datum/statistic and default/preload requests as negative cases. Exact series IDs and interceptor filters would be locked only after testing in the official ClawBench harness; no such harness run or model performance claim is being made yet. Site API keys would not be copied into tasks or published evidence.
Scope and contribution credit
Does this distinct category fit the current contribution priorities, and is the isolated suite/request-outcome approach acceptable? If 12 reviewed tasks are accepted, could you confirm the relevant follow-up publication and individual co-author consideration under the new-category policy, plus any ongoing review obligations? I understand that ordinary PR credit and a co-author invitation are different.
Codex is acting on my behalf for implementation, browser operation, evidence checks and technical revisions, with that assistance disclosed. Please confirm what validation evidence you require for this workflow; I am not presenting the agent's browser actions as a human timing study.
I can provide the compact pilot specifications and validation evidence, then build the agreed suite without changing the published corpora.
Proposal: isolated environmental observation retrieval suite (12 tasks)
I'm Ziao Yang, a PhD candidate at Brandeis University. I'd like to contribute a new
environmental-observation-retrieval-v0suite, isolated from the released V1/V2 corpora.The category would cover real public-data workflows: selecting the right monitoring location, observed versus predicted product, time window, units, datum/statistic, and requesting the resulting data. I would start with two representative tasks, then expand to 12 distinct workflows after scope approval, rather than make date-only variants.
Two pilot examples
What has actually been checked
I have operated the NOAA controls in Chrome and exported a 480-row historical CSV; its timestamps run from 2025/09/12 00:00 to 2025/09/13 23:54 and the header includes verified water level in metres. The USGS daily-discharge/date/mean selections have also been exercised in Chrome; final ZIP completion is not yet verified.
Reading the public site scripts exposed an important distinction: NOAA's final CSV is generated client-side from the table, whereas USGS fetches CSV before assembling a ZIP in the client. A correct HTTP request therefore does not by itself prove a final file was saved. For the initial suite I propose the explicit terminal outcome "configure and initiate the correct observation-data request": NOAA's observed-water-level JSON GET, and USGS's daily-series CSV GET. Final artifact completion would require an additional independent check and would not be claimed from interception alone.
I would validate wrong station, product, date range, unit, datum/statistic and default/preload requests as negative cases. Exact series IDs and interceptor filters would be locked only after testing in the official ClawBench harness; no such harness run or model performance claim is being made yet. Site API keys would not be copied into tasks or published evidence.
Scope and contribution credit
Does this distinct category fit the current contribution priorities, and is the isolated suite/request-outcome approach acceptable? If 12 reviewed tasks are accepted, could you confirm the relevant follow-up publication and individual co-author consideration under the new-category policy, plus any ongoing review obligations? I understand that ordinary PR credit and a co-author invitation are different.
Codex is acting on my behalf for implementation, browser operation, evidence checks and technical revisions, with that assistance disclosed. Please confirm what validation evidence you require for this workflow; I am not presenting the agent's browser actions as a human timing study.
I can provide the compact pilot specifications and validation evidence, then build the agreed suite without changing the published corpora.