Developer & designer (solo)
Adamastor
A solar land-assessment platform for mainland Portugal: 2–3 days of manual GIS cross-referencing compressed into a 30-second, fully-traceable site score. 95% deterministic geospatial engineering — the language model only writes the narrative, never the numbers.
The real challenge with “AI for renewables”
Most AI tools in the energy sector get the ratio wrong.
They lead with the model. They use the LLM to estimate distances, infer constraint overlaps, interpret slope data. They hallucinate numbers that end up in investment decisions. And then they wonder why adoption stalls at the demo stage.
The renewable energy industry has spent decades building regulatory frameworks, cadastral registers, and grid capacity datasets precisely so that these numbers don’t have to be estimated. They exist. They’re authoritative. They’re deterministic.
Adamastor uses them.
95% deterministic. 5% language model.
The platform runs seven geospatial computation services against authoritative national datasets. No inference. No approximation. No model-generated numbers.
Environmental constraint overlap is computed by intersecting the polygon against official DGT SRUP and ICNF registers — Rede Natura 2000, Reserva Agrícola Nacional (RAN), Reserva Ecológica Nacional (REN), national protected areas (RNAP). Either the parcel overlaps a protected zone or it doesn’t. That’s a spatial join, not a prompt.
Slope is extracted from Copernicus DEM GLO-30 using Horn’s method, in metres, in the correct national CRS (EPSG:3763 / PT-TM06). Pixels above threshold are counted. The result is a percentage. No language model touches this.
Grid proximity and hosting capacity come directly from the E-REDES Open Data portal — real substation coordinates, real capacity figures, updated from the source. The distance is a measurement. The capacity number is a database value.
Solar resource is modelled via PVGIS v5.3 from the JRC. The specific yield figure for that polygon, from that API, for that year. Not a regional estimate. Not a model’s best guess.
The 0–100 site score is an explicit weighted formula. Every input is traceable. Fatal flags — any Natura 2000 overlap, slope above threshold across more than the usable area limit — are boolean conditions that override the score entirely. The rationale is printed, line by line, in the report.
The AI’s job: receive that structured output and write a coherent paragraph about it. Answer operational questions using the numbers that were just computed. Nothing else.
This is not a limitation. This is the design.
The challenge this solves — and why it’s been unsolved
Land origination teams at solar developers have been running the same workflow for twenty years: pull environmental layers from QGIS, cross-reference agricultural reserve registers, open a substation capacity PDF from the grid operator, export a slope raster, paste everything into Excel, write a one-pager by hand.
Two to three days per candidate site. Most of those sites fail the first filter.
The bottleneck was never intelligence. It was integration — connecting authoritative data sources that were never designed to talk to each other, normalising coordinate systems, handling regional data chunking, building a scoring model that doesn’t break when a new protected area designation is added.
That’s the engineering. That’s the 95%.
Adamastor runs it in under 30 seconds. Draw a polygon. Seven services execute against pre-cached, R-tree indexed GeoPackages chunked by NUTS II region. The PVGIS call goes out. The E-REDES capacity figure is fetched. The score is computed. Claude writes the narrative from the JSON result.
The analyst who used to spend Tuesday through Thursday on a site that fails environmental review now knows in 30 seconds. They spend Thursday on the three sites that didn’t fail.
Three outputs, three audiences
Executive one-pager PDF — for investment committees. AI-authored narrative, key metrics, fatal flags, and site score. Claude summarises what was computed; it does not generate values.
Full technical report — for project management teams. Complete constraint breakdown, slope statistics, grid data with E-REDES attribution, solar resource curves, and the scoring rationale in full.
KMZ + GeoPackage — for GIS engineers. All computed layers, boundaries, and scored attributes bundled for round-trip enrichment into existing workflows.
Ask Adamastor
Beyond the automated report, the platform includes a conversational interface grounded strictly in the site’s computed data. “Which substation within 10 km has the highest hosting capacity?” returns a distance, a capacity figure, and a pin on the map. “What are the environmental risks on this parcel?” draws on the constraint flags from the analysis — not a generic answer, but one specific to that polygon.
The AI never reaches outside the collected data. It answers from what was computed.
Architecture
The backend is a FastAPI service doing serious geospatial computation: GeoPandas for polygon intersection, Rasterio for DEM processing, osmnx for OSM proximity, pvlib for solar modelling. Spatial data is chunked by NUTS II region (Norte, Centro, Lisboa, Alentejo, Algarve) with an R-tree spatial index and an LRU(2) region cache. All measurement in EPSG:3763. All I/O in WGS84. PDF generation via Jinja2 → Playwright → Chromium — no native dependency hell, consistent output across environments.
The frontend is Next.js 16 with Mapbox GL JS v3, TanStack Query, Zustand, and Tailwind v4. Analysis results stream via SSE. Three map themes swap via CSS custom properties at runtime. The conversational interface streams tokens from Claude, grounded strictly in the site’s computed data.
Claude handles two tasks: generating report narrative from structured JSON, and powering the Q&A interface. It receives a data object. It produces language. That boundary is enforced architecturally — the prompt does not contain raw geospatial layers, it contains computed results.
| Layer | Technologies |
|---|---|
| Backend | Python 3.12 · FastAPI · Pydantic v2 · GeoPandas · Shapely · Rasterio · pyproj · osmnx · pvlib · numpy · Playwright · Anthropic SDK · uv |
| Frontend | Next.js 16 · React 19 · TypeScript (strict) · Mapbox GL JS v3 · TanStack Query · Zustand · Tailwind v4 · Recharts · Framer Motion |
| Data | Copernicus DEM GLO-30 · E-REDES Open Data (CC BY 4.0) · DGT SRUP · ICNF · PVGIS v5.3 (JRC) · OpenStreetMap · CAOP 2025 |
| AI | Claude Sonnet (Anthropic) — narrative and conversational layer only |
The broader point
The renewable energy sector — and most regulated industries — already has the data infrastructure to answer most of its operational questions. Authoritative registers, official APIs, validated datasets built over decades of institutional effort.
The gap has never been the absence of intelligence. It has been the absence of integration.
The correct role for a language model in this stack is narrow and precise: translate structured, deterministic outputs into language that a project manager can read, an investment committee can act on, and a GIS engineer can verify. It does not estimate. It does not hallucinate. It summarises what was computed.
That’s the 5%. It’s genuinely useful. It’s useful because the 95% was done properly first.
Scope
Fully operational for mainland Portugal.
The underlying architecture is geography-agnostic. The spatial chunking, constraint-layer pipeline, and scoring framework make no assumptions specific to Portugal beyond the data sources. Extension to another European market is a data ingestion challenge, not a rebuild.