OpenAQ, Sensor.Community, Grafana.
Give those names to an agent and it is easy to get an apparently complete proposal: ingest the data, standardize the format, display charts. It fits almost any project with data sources and a visualization tool. The part that determines the actual work remains unstated.
OpenAQ provides near-real-time and historical air-quality data with metadata. Sensor.Community is a contributor-led environmental sensor network. Grafana queries and displays data. Their existing capabilities can be organized into different products. OpenAQ API, Sensor.Community, Grafana fundamentals
A historical ToWow candidate record proposed three paths for these tools: data adaptation, a discrepancy probe, and an air-quality atlas. All three were source-grounded but unvalidated designs. Following those candidates, this article asks how choosing a product changes the work that should happen next.
An adapter delivers a repeatable data path
An adapter’s user may already have an analytical method and simply want to stop handling another input format by hand. The first thing the adapter must deliver is a stable transformation result.
The meaningful work is field mapping: how the measured quantity is represented, which timestamp convention is used, how provenance survives, and what happens when a field is missing. A source field may have no destination equivalent. The adapter must explain where that information goes.
The first inspectable artifact can be small: one input sample, its transformed output, and a field-by-field mapping. The user should be able to take that output into the next step without reconstructing what the transformation program intended.
This path creates value by reducing repetitive integration work. Compare it with an existing connector or a short script: given the same input, which keeps the transformation correct with less effort, and how much needs repair when the source changes?
A discrepancy probe delivers records worth investigating
A discrepancy probe serves a different user: someone who already has data from both sides and wants to identify differences worth checking.
Its intermediate artifact might be a comparison table. The invented fields below illustrate the design; they are neither the projects’ actual API formats nor real observations.
| Record from source A | Record from source B | Conditions for comparison | Next action |
|---|---|---|---|
| A measurement at one location and time | The same type of measurement nearby at the same time | Same units, some distance between locations | Preserve distance and sampling conditions, then investigate the difference |
| An hourly average | An instantaneous value from one minute | Different time-aggregation rules | Obtain values on a matching time basis first |
| A value without equipment details | A value with equipment information | Missing context that could explain a difference | Investigate the metadata |
The table does something a chart alone cannot decide: it preserves why the records belong in the same comparison. Once a difference appears, the reader can ask whether it concerns the values themselves or the timing, location, equipment, and processing.
The design could start with one location and a short interval, retaining raw records, the mapping process, and reasons why some records could not be matched. The first goal is to let a user find an observation worth investigating. If the user must still clean everything again, the comparison table has failed to take on the main work.
Connecting Grafana is a presentation choice here. Defining the comparison relationship is the probe’s core. A good comparison table, inspected even in an ordinary spreadsheet, can test whether the direction is useful.
An atlas delivers an explanation that stands on its own
An atlas reader may neither maintain pipelines nor intend to investigate individual anomalies. They want to understand what changed at a location over a period of time.
An exportable snapshot therefore needs sufficient context: location, interval, measured quantity, units, sources, and the explanation needed to read the visual. Someone who saves the image and leaves the original system should still understand what it describes.
This changes the visualization work. A default dashboard suits an operator who continually adjusts filters. An atlas for others to read requires an author to choose a view, annotate consequential changes, and retain a route back to the original records. The screenshot is part of the deliverable; the explanation is too.
Start with one location and one time window, and give it to an intended reader. Observe what they understand and what they need to ask before adding interaction or extending the scope. Page count and chart count are further from the purpose than one accurate understanding.
Choose one intermediate artifact first
These three paths are compatible, but they need not start together. The adapter first produces a repeatable transformation. The probe produces investigable correspondences. The atlas produces a self-contained explanation. Each first step asks different things of code, data, and users.
The historical run later generated an inventory of documentation snapshots for the three projects, counting bytes, lines, headings, and hashes. That was material preparation; it had not acquired observation data. The next validation of each path should therefore begin with real inputs and intended users. Details of the historical artifact remain in the source record.
This is how concrete I want a proposal from a generative system to become: what is the first deliverable, who uses it for which next step, and what feedback would change our direction? At that point, a list of tool names starts becoming work we can actually advance.