Development pipeline#
This roadmap describes active development directions. It is not a promise that the features are available in the current release. Experimental outputs must be labeled and kept separate from validated baseline results.
1. Tenure lands to MW workflow — in progress#
Objective: connect land-tenure information to technically feasible capacity so that suitable land can be summarized in megawatts while retaining tenure context.
Planned pipeline:
Ingest and validate tenure polygons, identifiers, rights categories, dates, source license, and jurisdiction-specific definitions.
Harmonize CRS and geometry, resolve overlaps explicitly, and intersect tenure with otherwise feasible wind and solar land.
Calculate eligible area by technology and apply documented capacity-density and setback assumptions to estimate MW.
Preserve both gross and net area, excluded area by reason, conversion assumptions, and uncertainty in machine-readable outputs.
Validate aggregate areas and sampled parcels against authoritative records.
The MW estimate is a screening result, not proof of land access, development rights, interconnection, consent, or project feasibility.
2. ERA6 preparation for higher-resolution cutout cells — planned research#
Objective: prepare the climate-data pipeline for a future ERA6 product and higher spatial resolution than current ERA5-based cutouts.
Because an operational product contract is not yet encoded in RESource, development must isolate the dataset adapter from the assessment logic. Work includes defining a versioned provider interface; preserving raw metadata; validating coordinates, calendars, units, accumulation periods, and timezone; making cutout resolution an explicit configuration value; and benchmarking storage, memory, download volume, resampling, and capacity-factor effects against ERA5.
Higher nominal resolution must not be described as higher accuracy until comparisons against observations and sensitivity tests support that conclusion.
3. Consultation flags in result metrics — planned#
Objective: add informational flags that help users recognize where consultation or further due diligence may be required before implementation decisions.
The result schema should use transparent source-specific fields rather than a single opaque score. Candidate fields include flag type, source layer and version, feature identifier, intersection area or distance, threshold, jurisdiction, confidence, retrieval date, and a human-readable explanation. Multiple flags must be retained; absence of a flag must not be interpreted as consultation clearance.
Flags are decision-support information only. They must not determine legal duties, replace engagement with Indigenous peoples, rights holders, communities, regulators, or landholders, or assert consent. Terminology and thresholds require jurisdictional and affected-party review before release.
Cross-cutting acceptance criteria#
Each pipeline addition requires documented provenance and licensing, configuration schema changes, deterministic unit tests, a small regional fixture, uncertainty and limitations, backward-compatible result migration where practical, and comparison against the current baseline before becoming a stable public feature.