The Climate Analyst Data Logger Designer

Virtual Instrument Provisioning for Distributed Ecological Monitoring

Document ID: CNL-TN-2026-052
Version: 0.1 (Draft)
Date: April 16, 2026
Author: Michael P. Hamilton, Ph.D.
Affiliation: Canemah Nature Laboratory, Oregon City, Oregon

AI Assistance Disclosure: This technical note was developed collaboratively with Claude (Anthropic, claude-opus-4-6) via Cowork. Claude contributed to architectural synthesis across predecessor documents, system design analysis, and manuscript drafting. The author takes full responsibility for the content, accuracy, and conclusions.

Abstract

The YEA Labs Climate Analyst currently displays cached historical climate profiles and real-time weather conditions for 1,142 curated natural areas, but does not record continuous environmental data. This technical note specifies a Data Logger Designer — a wizard interface within the Climate Analyst that provisions virtual monitoring instruments for any curated place. The designer creates database records (sensor_platforms + monitoring_sources) that a single Galatea launchd collector discovers automatically on its next cycle, beginning hourly data ingestion without per-site daemon configuration. The architecture supports a three-tier instrument hierarchy: Tier 1 physical on-site stations (WeatherFlow Tempest, Ecowitt), Tier 2 nearby community stations (Weather Underground PWS network), and Tier 3 model-derived data (Open-Meteo). Multiple co-located instruments at different tiers provide data integrity through cross-validation and microclimate detection. The design builds on empirical findings from the weather API evaluation (CNL-TN-2026-023), the STRATA sensor plugin architecture (CNL-TN-2026-044), and the YEA Labs instrument suite (CNL-TN-2026-030), connecting them into an operational pipeline where database-as-configuration replaces per-site custom deployment.

1. Introduction

1.1 The Recording Gap

The YEA Labs Climate Analyst (CNL-TN-2026-030, Section 4.2) provides two data layers for any curated place: a 34-year historical climate profile cached from the Open-Meteo Historical API, and real-time current conditions via a two-tier source strategy (Weather Underground PWS first, Open-Meteo model fallback). Both layers are display-only. The historical data is fetched once and cached permanently in lookup_cache. The current conditions are fetched live on each page load and discarded.

This architecture serves the Climate Analyst's original purpose — characterizing the climatic identity of a place — but it does not create a continuous observational record. An ecologist returning to a site after six months cannot ask "what happened here in January?" because no data was recorded between visits. The Climate Analyst displays climate but does not observe it.

By contrast, the Macroscope's physical monitoring stations at Canemah Nature Laboratory and Owl Farm record continuous data streams to the macroscope database: Tempest readings every minute, Ecowitt readings every five minutes, BirdWeather detections continuously. These stations produce the temporal depth that STRATA's intelligence envelope (CNL-TN-2026-044) wraps with nine-window temporal analysis, narrative generation, and anomaly detection. The recording gap is the gap between what YEA displays and what STRATA can analyze.

The Data Logger Designer closes this gap by transforming the Climate Analyst from a display instrument into a provisioning instrument — one that creates virtual monitoring stations whose continuous data feeds become available to the full STRATA intelligence pipeline.

1.2 Precedent: The CNL Virtual Instrument

The Macroscope Nexus (MNG) Observatory at Canemah Nature Laboratory already operates a virtual Open-Meteo monitoring widget alongside physical Tempest and Ecowitt stations. This widget, implemented via the mw-strata.php endpoint, provides a two-layer display: a live Open-Meteo API call (cached for five minutes in /tmp/mw_cache/) and a daily archive read from the openmeteo_daily table when a macroscope_platform_id bridge exists in monitoring_sources.

However, the CNL virtual widget was provisioned manually — a row inserted into sensor_platforms, a corresponding monitoring_sources entry linking it to the CNL place, and a Galatea collector configured to populate openmeteo_daily. The Data Logger Designer generalizes this manual process into a self-service wizard that any curated place can use, with automatic collector discovery eliminating per-site deployment.

1.3 Scope

This specification covers the Data Logger Designer interface, the database provisioning pattern, the single-collector architecture, the multi-tier instrument hierarchy, and the integration points with STRATA's plugin contract. It does not cover the STRATA intelligence envelope itself (CNL-TN-2026-044), the MNG convergence plan (CNL-TN-2026-027), or the collector implementation details (which are operational plumbing, not architectural concerns).

2. Architecture

2.1 Design Principles

Database-as-configuration. Adding a monitoring instrument to a site is a database insert, not a deployment. No new cron jobs, no new collector scripts, no SSH sessions. The single collector discovers new platforms on its next cycle.

Instrument, not display. A monitoring instrument records continuous data to a database. If it only displays data on demand and discards it, it is a widget, not an instrument. The Data Logger Designer creates instruments.

Multi-platform by design. A site may have multiple co-located instruments at different tiers. This is a feature, not redundancy. Physical stations ground-truth virtual estimates. Nearby community stations provide independent verification. Model-derived data fills gaps when stations are offline. Cross-validation between tiers enables microclimate detection and data quality flagging.

Virtual sensors are first-class citizens. The STRATA plugin architecture (CNL-TN-2026-044, Section 9) established that a "sensor" is anything that produces timestamped observations in a known table schema. The plugin contract begins at the database table, not at the physical device. A virtual Open-Meteo instrument and a physical Tempest station are architecturally identical from STRATA's perspective.

2.2 Three-Layer Flow

┌─────────────────────────────────────────────────────┐
│  CLIMATE ANALYST — Data Logger Designer (Wizard UI)  │
│  User selects place → discovers available sources →  │
│  provisions instrument(s) → writes DB records        │
└──────────────────────┬──────────────────────────────┘
                       │ INSERT INTO sensor_platforms,
                       │            monitoring_sources
                       v
┌─────────────────────────────────────────────────────┐
│  GALATEA COLLECTOR (single launchd agent, hourly)    │
│  SELECT * FROM sensor_platforms                      │
│  WHERE platform_type IN ('openmeteo','wunderground', │
│        'tempest_api') AND status = 'active'          │
│  → iterate → fetch → INSERT INTO readings tables     │
└──────────────────────┬──────────────────────────────┘
                       │ Continuous data accumulates
                       v
┌─────────────────────────────────────────────────────┐
│  STRATA INTELLIGENCE ENVELOPE                        │
│  Plugin contract reads from same tables              │
│  → temporal analysis (9 windows)                     │
│  → narrative generation                              │
│  → SOMA anomaly detection                            │
│  → tool-calling endpoints for Claude                 │
└─────────────────────────────────────────────────────┘

Figure 1. Three-layer data logger provisioning flow. The wizard writes database records. The collector discovers them. STRATA wraps the resulting data with intelligence.

2.3 The Bridge Pattern

The architectural seam between YEA's place catalog and the Macroscope's sensor infrastructure is the monitoring_sources table in the macroscope_nexus database. This table already bridges curated places to sensor platforms:

• place_id (FK → yea_places.id) — which curated place this instrument monitors
• source_type — the platform type (openmeteo, wunderground, tempest_api)
• observer_class — physical, virtual, or human
• query_config (JSON) — platform-specific parameters (coordinates, station ID, API tier, variables to collect)
• macroscope_platform_id (FK → sensor_platforms.id) — bridge to the Macroscope sensor hierarchy

The Data Logger Designer writes to both sides of this bridge: a sensor_platforms row (identity, location, platform type) and a monitoring_sources row (the link to the curated place with collection configuration).

3. Instrument Tiers

3.1 Tier 1: Physical On-Site Stations

Physical instruments deployed at or near the monitoring site. These provide the highest-quality data but require hardware purchase, installation, and maintenance.

Currently supported:

• WeatherFlow Tempest — 1-minute readings, free API for station owners, 13 atmospheric variables
• Ecowitt GW1200B — 5-minute readings, local network push, indoor/outdoor temperature, humidity, soil moisture

Provisioning: A Tier 1 instrument requires the station's API credentials or device ID. The wizard prompts for hardware type and station identifier, validates connectivity, and provisions the platform.

Coverage: Currently limited to Canemah Nature Laboratory and Owl Farm. Expandable to any site where a collaborating station owner shares API access.

3.2 Tier 2: Nearby Community Stations

Weather Underground aggregates consumer weather stations from multiple hardware manufacturers (Tempest, Davis Instruments, Ambient Weather, Netatmo, Ecowitt) into a single queryable API. The free tier provides 1,500 API calls per day.

CNL-TN-2026-023 demonstrated that the WU location/near endpoint returns 9–10 community stations within 7 km of ecologically diverse test sites, including nine mountain stations at 5,300–6,400 feet near the James San Jacinto Mountains Reserve — the site where gridded weather products failed most severely. Temperature agreement between a calibrated Tempest and its nearest WU neighbor was within 1.4°F with identical dewpoint readings.

Provisioning: The wizard queries api.weather.com/v3/location/near with the place's coordinates, presents candidate stations with distance, elevation, and elevation difference from the site. The user selects one or more stations. The wizard writes a sensor_platforms row with the WU station ID and a monitoring_sources row with observer_class: 'community' and query_config containing the station ID and collection parameters.

Elevation matching: The wizard computes elevation difference between the candidate station and the curated place. Stations within 100 m elevation difference are flagged as excellent matches; 100–300 m as acceptable; >300 m as cautionary. This directly implements the elevation-sensitivity finding from CNL-TN-2026-023, where grid products failed catastrophically because their effective elevation was 650+ meters below the actual station.

Coverage: Extensive in populated areas of North America and Europe. The James Reserve evaluation found community stations even in remote mountain settings. Coverage gaps exist primarily in uninhabited wilderness and developing regions.

3.3 Tier 3: Model-Derived Data (Open-Meteo)

Open-Meteo provides gridded weather data at ~1 km resolution with no API key required (free tier) or with enhanced access via the Pro tier. The Macroscope project has Pro tier access as a donation, eliminating rate limit concerns.

Open-Meteo offers two temporal modes relevant to the Data Logger Designer:

Current/Forecast API — Real-time conditions and 7-day forecast. Variables include temperature, humidity, wind, pressure, cloud cover, precipitation, solar radiation, soil temperature, and soil moisture. Update frequency approximately 15 minutes.

Historical API — Daily and hourly archive from 1940 to present (ERA5 reanalysis) or 1991 to present (higher-resolution models). Approximately 588 KB per place for a 34-year daily dataset.

Provisioning: The wizard automatically provisions an Open-Meteo instrument for any curated place — no station discovery required, since Open-Meteo covers the entire globe on a grid. The query_config JSON specifies the coordinate pair, desired variables, and temporal resolution (hourly recommended for the continuous record, daily for the climate archive).

Data quality: CNL-TN-2026-023 established that Open-Meteo (and equivalent gridded products) provide adequate temperature estimates at low-to-moderate elevations (±2°F) but degrade in complex terrain. The Data Logger Designer treats Open-Meteo as the universal fallback — always available, globally consistent, but lower fidelity than physical or community stations where those exist.

3.4 Multi-Tier Stacking

A site's climate monitoring power increases with each tier added:

The Data Logger Designer encourages multi-tier stacking by presenting all available tiers during provisioning. A user provisioning Open-Meteo for a site also sees nearby WU stations and can add them in the same wizard session.

4. The Single-Collector Pattern

4.1 Why One Collector

The naive approach to distributed monitoring creates a collector process per site — a cron job or launchd agent for each provisioned instrument. At 10 sites this is manageable; at 100 it becomes an operational burden; at 1,000 it is untenable. The Macroscope's current collector inventory on Galatea (documented in CLAUDE.md) already manages a dozen separate launchd daemons and agents, each with its own schedule, error handling, and log files.

The Data Logger Designer instead requires a single collector process on Galatea that iterates over all active platforms:

SELECT sp.id, sp.platform_type, sp.api_config, sp.latitude, sp.longitude,
       ms.query_config
FROM sensor_platforms sp
JOIN monitoring_sources ms ON ms.macroscope_platform_id = sp.id
WHERE sp.status = 'active'
  AND sp.platform_type IN ('openmeteo', 'wunderground', 'tempest_api')
ORDER BY sp.platform_type, sp.id

For each row, the collector dispatches to a platform-specific fetch function, retrieves the latest readings, and inserts them into the appropriate readings table (openmeteo_hourly, wunderground_readings, etc.) with INSERT IGNORE for idempotency.

4.2 Collection Schedule

The collector runs as a single launchd agent on Galatea with a 60-minute StartInterval. Each cycle takes seconds to minutes depending on the number of active platforms — API calls are lightweight and parallelizable by platform type.

4.3 Scaling Considerations

At 1,142 curated places, if every place had a Tier 3 Open-Meteo instrument, the hourly collection cycle would make 1,142 API calls. With Open-Meteo Pro tier access (no rate limits), this completes in approximately 5–10 minutes at 2–4 requests per second. Adding Tier 2 WU stations (perhaps 200–300 sites with suitable community coverage) adds another 300 calls within the free tier's 1,500/day budget at hourly resolution.

The database growth is modest. Hourly Open-Meteo readings with 15 variables per row produce approximately 8,760 rows per place per year, or roughly 10 million rows per year across the full catalog. This is well within MySQL 8.4's operational range, comparable in scale to the existing tempest_readings table which accumulates 500,000+ rows per year from a single station at 1-minute resolution.

5. The Wizard Interface

5.1 User Flow

The Data Logger Designer integrates into the Climate Analyst as a panel or modal accessible from the instrument's sidebar. The wizard follows a four-step flow:

Step 1: Place Confirmation. Display the currently selected place with coordinates, elevation, and ecological context. Confirm this is the site to instrument.

Step 2: Source Discovery. Automatically query available data sources for the place's coordinates:

• Open-Meteo: always available (display as pre-selected Tier 3 baseline)
• Weather Underground: query location/near endpoint, present nearest stations with distance, elevation, elevation delta, hardware type
• Physical stations: check if any existing sensor_platforms rows match these coordinates (within ~50 km threshold)

Step 3: Instrument Selection. Present discovered sources as a checklist, grouped by tier. Each source shows:

• Station name/ID and hardware manufacturer
• Distance from site and elevation difference
• Data quality indicators (freshness, uptime if available)
• Estimated variables available

The user selects one or more sources. The wizard recommends multi-tier stacking with explanatory text about cross-validation benefits.

Step 4: Provisioning. For each selected source, the wizard:

• Creates a sensor_platforms row (or links to an existing one if the platform was already provisioned for another place)
• Creates a monitoring_sources row linking the platform to this place
• Sets status = 'active' so the collector discovers it on the next cycle
• Displays confirmation with expected first-data timestamp (next collector cycle)

5.2 Authentication

Provisioning creates database records on Galatea that trigger data collection. This is an administrative action, not a public feature. The wizard requires MNG authentication (the shared Macroscope session key system used by MNG and YEA).

5.3 Instrument Management

After provisioning, the Climate Analyst's sidebar shows active instruments for the current place with status indicators:

• Green: receiving data, latest reading within expected interval
• Yellow: stale data, latest reading older than 2× expected interval
• Red: no data received since provisioning
• Gray: instrument disabled (paused by user or admin)

An authenticated user can pause, resume, or remove instruments. Removal sets status = 'inactive' (soft delete); the collector skips inactive platforms.

6. Database Schema

6.1 sensor_platforms (macroscope database)

The existing sensor_platforms table in the macroscope database accommodates virtual instruments without schema changes:

6.2 monitoring_sources (macroscope_nexus database)

The existing monitoring_sources table bridges YEA places to Macroscope platforms:

6.3 Reading Tables

Each platform type writes to its own readings table, following the existing Macroscope pattern:

• openmeteo_hourly — Hourly readings keyed by (platform_id, recorded_at). Variables: temperature, humidity, wind speed/direction, pressure, cloud cover, precipitation, solar radiation, soil temperature, soil moisture.
• openmeteo_daily — Daily summaries keyed by (platform_id, date). Already exists for the CNL virtual widget.
• wunderground_readings — Hourly readings from WU PWS stations. Variables: temperature, humidity, dewpoint, wind, pressure, precipitation, solar radiation, UV.

The INSERT IGNORE pattern on the composite primary key (platform_id, recorded_at) provides idempotent writes — the collector can safely re-run without creating duplicates.

7. STRATA Integration

7.1 Plugin Contract Compatibility

Virtual instruments provisioned by the Data Logger Designer are fully compatible with the STRATA sensor plugin architecture (CNL-TN-2026-044). An Open-Meteo plugin declaration follows the standard contract:

return [
    'platform_type'    => 'openmeteo',
    'platform_name'    => 'Open-Meteo Grid Model',
    'domain'           => 'EARTH',
    'table'            => 'openmeteo_hourly',
    'timestamp_col'    => 'recorded_at',
    'platform_col'     => 'platform_id',
    'freshness_minutes' => 90,
    'observer_class'   => 'virtual',
    'metrics' => [
        'temperature_c' => [
            'label'     => 'Temperature',
            'unit'      => 'C',
            'type'      => 'instantaneous',
            'precision' => 1,
            'category'  => 'atmospheric',
            'narrative' => 'temperature',
            'soma_weight' => 1.0,
        ],
        'relative_humidity' => [
            'label'     => 'Humidity',
            'unit'      => '%',
            'type'      => 'instantaneous',
            'precision' => 0,
            'category'  => 'atmospheric',
            'soma_weight' => 0.8,
        ],
        // ... additional metrics
    ],
];

This declaration enables the full STRATA intelligence envelope — temporal analysis across nine windows, domain-native narrative generation, SOMA anomaly detection, and auto-generated tool-calling endpoints — for every virtual instrument the Data Logger Designer creates. No per-instrument custom code.

7.2 Cross-Tier Validation

When multiple tiers are provisioned for a single place, STRATA can perform cross-tier validation as a derived analysis:

• Model-vs-station divergence: Compare Open-Meteo predictions against WU or Tempest actuals. Persistent divergence indicates microclimate effects (topographic sheltering, urban heat island, cold air pooling) that the model cannot resolve. This is exactly the bias characterization proposed in CNL-TN-2026-023, Section 8, but performed automatically and continuously rather than as a one-time experiment.

• Community-vs-physical calibration: Where both Tier 1 and Tier 2 exist, compute running bias statistics between the calibrated station and community neighbors. This extends the single-snapshot validation from CNL-TN-2026-023, Section 4.4 (Tempest vs. WU neighbor, 1.4°F agreement) into a continuous calibration record.

• Anomaly triangulation: When SOMA detects elevated free energy in a site's EARTH mesh, cross-tier comparison disambiguates between genuine atmospheric anomalies (all tiers agree something unusual is happening) and instrument artifacts (one tier diverges while others remain normal).

7.3 From Display to Observatory

The Data Logger Designer transforms the Climate Analyst from a Level 3 instrument view (CNL-TN-2026-030, Section 3.2) into something new — a provisioning interface that creates Level 1 data infrastructure. After provisioning, the Climate Analyst's display updates to show live instrument readings alongside the existing historical profile, creating a "past-and-present" view where the 34-year climate archive contextualizes the continuous monitoring record.

This integration closes the loop: the historical archive answers "what is the climate of this place?" while the provisioned instruments answer "what is happening at this place right now, and how does it compare to the historical norm?"

8. Implementation Plan

8.1 Phase 1: Open-Meteo Collector (Galatea)

Build the single-collector launchd agent on Galatea. Start with Open-Meteo only — the simplest platform (no authentication, global coverage, reliable API). Implement the sensor_platforms → openmeteo_hourly pipeline with INSERT IGNORE idempotency. Seed with the existing CNL virtual instrument to validate against the current openmeteo_daily data.

8.2 Phase 2: Wizard UI (Data, then Galatea)

Build the four-step provisioning wizard in the Climate Analyst. Implement Open-Meteo auto-provisioning first (always available, no discovery needed). Test by provisioning 5–10 curated places and verifying data appears in openmeteo_hourly on the next collector cycle.

8.3 Phase 3: Weather Underground Integration

Add WU station discovery to the wizard (Step 2). Implement wunderground_readings table and WU-specific fetch function in the collector. Budget API calls carefully against the 1,500/day free tier limit.

8.4 Phase 4: Multi-Tier Display

Update the Climate Analyst's display to show active instruments, live readings, and cross-tier comparisons. Implement the status indicators (green/yellow/red/gray) in the sidebar.

8.5 Phase 5: STRATA Plugin Registration

Create the openmeteo.plugin.php and wunderground.plugin.php declarations following the STRATA sensor plugin contract. Validate that STRATA's temporal analysis, narrative generation, and tool-calling endpoints work correctly with virtual instrument data.

8.6 Phase 6: Scale

Provision Open-Meteo instruments across the full 1,142-place catalog via a batch script (analogous to the enrich_places.py batch enrichment pipeline described in CNL-TN-2026-030, Section 5.1). Monitor collector cycle time and database growth. Add WU stations for sites with suitable community coverage.

9. Discussion

9.1 Instruments vs. Widgets

The distinction between an instrument and a widget is not pedantic — it determines what intelligence the platform can produce. A widget that fetches and displays current conditions supports a single question: "what is the weather right now?" An instrument that records continuous data supports temporal questions: "what happened last week?", "is this month warmer than usual?", "when did the frost start?", "how does this year compare to the 30-year mean?"

STRATA's nine-window temporal analysis (CNL-TN-2026-044, Section 4.1) is meaningless without recorded data to analyze. The intelligence envelope requires a continuous record. The Data Logger Designer creates that record.

9.2 The Homeowner Network

CNL-TN-2026-023 documented a finding that inverts conventional expectations about environmental monitoring infrastructure: the Weather Underground PWS network provides denser spatial coverage than any purpose-built research network, deployed by homeowners who purchased consumer weather stations. The Data Logger Designer operationalizes this finding by making community stations first-class monitoring instruments within the Macroscope framework.

The cross-platform aggregation advantage of WU — a single API integrating Davis, Tempest, Ambient Weather, Netatmo, and Ecowitt hardware — means the Data Logger Designer can provision community instruments without knowing or caring what hardware the station owner chose. This is the architectural benefit TN-023 identified: hardware-agnostic integration through a community aggregation layer.

9.3 Scaling to the Catalog

The 1,142 curated places in the YEA catalog span six continents and 29 biomes. Provisioning all of them with Tier 3 Open-Meteo instruments is trivially automatable — a batch script that mirrors the existing place enrichment pipeline. The result would be 1,142 continuous hourly monitoring stations with zero hardware deployment, producing approximately 10 million readings per year.

This is not a replacement for physical instrumentation. Open-Meteo's model-derived data has known limitations in complex terrain (CNL-TN-2026-023, Sections 3.3–3.4). But it provides a global baseline against which physical and community instruments can be compared, and it transforms the entire YEA catalog from a collection of place descriptions into a distributed monitoring network.

9.4 The Collector as Infrastructure

The single-collector pattern means that adding a monitoring instrument to any place on Earth is a database transaction. No SSH sessions, no daemon configuration, no service restarts. The collector discovers new platforms because it queries the database, not because someone told it about a new station. This is database-as-configuration applied to environmental monitoring — the same principle that makes modern container orchestrators (Kubernetes, Nomad) scalable, applied to a LAMP stack with a launchd agent.

10. Conclusion

The Climate Analyst Data Logger Designer transforms YEA's place catalog from a static reference system into a distributed environmental monitoring network. By writing database records that a single collector discovers automatically, the designer eliminates per-site deployment complexity while supporting a three-tier instrument hierarchy that ranges from model-derived global coverage to calibrated physical on-site stations.

The architecture connects three predecessor systems: the empirical evaluation of weather data sources (CNL-TN-2026-023) provides the tiered source hierarchy and data quality expectations; the STRATA sensor plugin architecture (CNL-TN-2026-044) provides the intelligence envelope that wraps any registered sensor with temporal analysis, narrative generation, and anomaly detection; and the YEA Labs instrument suite (CNL-TN-2026-030) provides the user interface and place catalog. The Data Logger Designer is the operational bridge between them — the piece that turns evaluated data sources and designed architectures into continuously recording instruments.

The result is a system where provisioning a new monitoring station takes 30 seconds in a wizard, the first data arrives within an hour, and the full STRATA intelligence pipeline activates automatically. Intelligence as infrastructure, applied to the entire curated world.

References

[1] Hamilton, M. P. (2026). "Ground-Truthing the Sky: Evaluating Free Weather APIs and Community Station Networks Against Field Station Instruments for Citizen Science Ecological Monitoring." CNL-TN-2026-023, Canemah Nature Laboratory. https://canemah.org/archive/CNL-TN-2026-023

[2] Hamilton, M. P. (2026). "STRATA Sensor Plugin Architecture." CNL-TN-2026-044, Canemah Nature Laboratory. https://canemah.org/archive/CNL-TN-2026-044

[3] Hamilton, M. P. (2026). "YEA Labs: A Research Instrument Suite for Quantitative Ecological Analysis." CNL-TN-2026-030, Canemah Nature Laboratory. https://canemah.org/archive/CNL-TN-2026-030

[4] Hamilton, M. P. (2026). "STRATA 2.0: Distributed Intelligence Architecture." CNL-TN-2026-043, Canemah Nature Laboratory. https://canemah.org/archive/CNL-TN-2026-043

[5] Hamilton, M. P. (2026). "Macroscope/STRATA and MNG Convergence Plan." CNL-TN-2026-027, Canemah Nature Laboratory.

[6] Open-Meteo (2026). "Open-Meteo Weather API." https://open-meteo.com (accessed April 16, 2026).

[7] Weather Underground (2026). "PWS Network Overview." IBM / The Weather Company. https://www.wunderground.com/pws/overview (accessed April 16, 2026).

[8] WeatherFlow (2026). "Tempest Weather System." WeatherFlow-Tempest, Inc. https://weatherflow.com/tempest-weather-system/ (accessed April 16, 2026).

Document History