SectorClimate tech, municipal planning
TypeAI-assisted planning workspace
AIRAG on PostgreSQL + pgvector, OpenRouter gateway
StackFastAPI, React, PostgreSQL, Redis, Auth0
StatusLive, public site at beta.qoralia.io
RoleBack end (FastAPI) and front end (React)
Qoralia — the platform's public home page, headed 'Simplified Climate Finance', with a preview of the control panel below

Context

City officials planning emission reductions worked from scattered spreadsheets and consultant reports. Finding interventions that could work, matching them to funding and modelling their CO₂ impact were three separate jobs, done in three separate places.

Qoralia brings them into one workspace, and AI is what makes the first two fast: the regulations, grant calls and intervention catalogues a planner has to read are too much to search by hand.

The hard part

A language model is good at finding candidate grants and interventions in a pile of regulations. It cannot be the thing that says a city qualifies. An official has to be able to defend that answer, and 'the model said so' is not a defence.

  • Answers have to come from the actual climate sources, not from what a model remembers.
  • Grant eligibility has to be traceable to a rule a person can check.
  • Every city's emissions data has to stay in its own workspace, and be checked before it counts.

How the AI works

The design rule is simple: the model suggests, rules decide. AI does the searching and the surfacing, where it is strong. Anything an official will be held to is decided by deterministic logic, where the answer is the same every time and can be explained.

Model calls go through OpenRouter, a multi-model gateway, rather than straight to one provider, so the platform is not tied to a single model or vendor.

Retrieval over climate sources (RAG)

Regulations, grant calls and intervention catalogues are embedded and stored in PostgreSQL with pgvector. A question is answered from the passages retrieved for it, so answers are grounded in the source documents rather than in the model's memory.

The model suggests, rules decide

The model surfaces candidate grants and interventions. A deterministic scoring step decides eligibility, and the interface shows which rule made the decision, so an official can trace the answer back and defend it.

The platform around it

  • Whole pathways, not single projects: cost, CO₂ impact and feasibility modelled across a full emission-reduction pathway.
  • Staged data import: bulk emissions data is staged and validated before it reaches the books.
  • A workspace per city: multi-tenant, with role-based access, so each team sees only its own data.
  • Auth0 sign-in and separate environments behind Nginx.
  • A FastAPI back end and a React front end.

Where it stands

Qoralia's public site is live at beta.qoralia.io. The workspace itself sits behind sign-in and holds each city's own data, which is why this page describes the architecture rather than showing it.

  • One workspace to find interventions, match funding and model CO₂ impact, instead of scattered spreadsheets and consultant reports.
  • Eligibility answers an official can trace back to a rule, not just a model's opinion.
  • Each city's team sees only its own data.

If you are adding AI to your product

The same split carries over to most business software: let the model search, summarise and draft, and keep anything a person has to sign off on — eligibility, pricing, approvals, compliance — in rules you can test and explain. It is the difference between an AI feature a team trusts and one they quietly stop using.

Attribution: Built by a Desert Launch engineer, who worked on Qoralia's FastAPI back end and React front end. The product, its brand and its results belong to Qoralia.

Adding AI to your product?

Search over your own documents, assistants that draft, and decisions people can trust — designed so the model helps and the rules stay in charge.

Get a Free Quote on WhatsApp