Heliovulcan data & API

What problem this solves

Screening numbers get quoted. “~30 GWh/yr demand”, “+A$4.6M owner outcome” — once a figure leaves its report, nobody can tell whether it was a public EIS statement, a model output or an analyst guess. Heliovulcan publishes the registry itself: each claim carries its type (public_source, calculated, assumption…), its confidence, its limitations and its sources, and every JSON response links back to the human-readable page and methodology.

What's available today

The MVP covers one project — the Remote Mining Asset hybrid-energy Pre-DD screen:

• GET /api/v1/projects/remote-mining-asset.json — project entity: identity, location, technology, stats and links
• GET /api/v1/projects/remote-mining-asset/claims.json — the claim registry (14 claims)
• GET /api/v1/projects/remote-mining-asset/evidence.json — the evidence registry (6 objects, access dates and quality ratings)

These are static JSON files served over HTTPS — no authentication, no rate limits beyond the host's, stable URLs. Full field documentation: API docs · machine-readable description: openapi.json · discovery: /.well-known/api-catalog.

Reading the data honestly

• claim_type and confidence are part of the datum — a calculated / low value is a screening output, not a fact about the project;
• evidence marked unresolved means the source URL is not yet captured — the gap is published rather than papered over;
• every response includes canonical_url (the human page) and methodology_url — cite those alongside any figure.

Roadmap

The registry structure (project → claims → evidence) is designed to extend to further projects, facilities and datasets. OpenAPI-described static JSON is the current delivery; versioned under /api/v1/ so future serverless or MCP delivery can be added without breaking these URLs.

Human-readable entry points

• Remote Mining Asset project entity page
• Dataset landing page
• Methodology