AI that lives in the community, not the cloud.

Not yet. For the first deployments a community needs working basics: safe water supply, sanitation, and electricity that is either on the grid or a stable local system we can add to. It also needs a recognised way of making decisions together, such as a council, cooperative or association, and it needs to invite us. These are the conditions where the node can help straight away instead of waiting on infrastructure we cannot provide.

They need infrastructure first, and that is not what we build. We would be doing them a disservice by putting a computer in before a well. We plan to work alongside organisations that build water and energy systems, and to bring nodes to those communities once the basics are in place. We say this plainly so nobody mistakes us for a fix for missing infrastructure.

Small enough to know well and large enough for shared resources to matter: roughly a few hundred to a couple of thousand people. Big enough to measure real results, small enough that every household can take part.

It is a strong candidate, with many organised rural communities and cooperatives, but it is not fixed. We will go wherever a community meets the criteria, invites us, and has local partners who can support the work over years.

That risk is real, which is why the process starts with an invitation and months of listening before anything is installed. The community owns the hardware, sets the rules, chooses what the software does and can switch it off. If they decide it is not for them, they keep the equipment.

Yes, for the jobs a community needs. Today's open models run well on a few GPUs: answering questions in the local language, summarising meetings, forecasting water and energy, planning harvests and schedules. These tasks do not need the giant models that power chatbots in the cloud.

Cloud AI needs reliable internet, sends a community's private life to companies abroad, and can be priced up or switched off by someone else. A local node keeps working when the connection or the grid fails, keeps data where it belongs, and costs the same next year as this year.

Residents connect to the community's own Wi-Fi. They can ask by text or voice from a phone, a shared tablet or a kiosk at the community centre. The AI keeps working even if the internet goes down.

The community decides when a separate device can go online. It gets new software and information from a source the community approves. The AI computer checks that each update is genuine. It installs updates only when the community approves them.

From what the community already knows and chooses to share: water meter and tank readings, the solar system's own data, simple sensors where they help, harvest and stock records, and what people enter themselves. We start with a few useful numbers and add more only if people want it.

It will, sometimes. That is why it only advises. Every suggestion shows the numbers and reasons behind it, important decisions stay with people, and nothing that affects shared resources happens automatically. Corrections from residents make it better.

We size the system the other way round: power budget first, then models that fit it. Heavy jobs like forecasts run when the sun is strongest, the batteries cover evenings, and the node drops to a low-power mode in long cloudy spells instead of switching off.

Local people. We train and pay technicians from the community and leave them spare parts. If the community agrees, the separate device can send our team a short report, such as whether the system is running and whether the last update worked. For bigger repairs, our team visits.

We plan for years of service with parts replaced as they wear, and design so one failed component never takes the whole system down. The pilot will tell us real numbers and we will publish them.

It sits in a locked room in a building the community chooses, its storage is encrypted, and it is useless and unreadable once removed. The community decides who holds the keys.

The community, through a written charter agreed before installation. It sets what the node can see, who can ask what, and how rules change. We can advise, but we cannot change the rules or read the data.

The charter is designed against that: open records of what the node suggested and why, rules any resident can read, and changes only through the community's agreed process. Fairness is measured and reported openly as part of the pilot.

Questions, documents and private records stay in the community. We never copy them, use them to train other products or sell them. Our team can see the basic system reports the community shares. Access to the AI stays local. We publish only overall pilot results the community approves.

We work with local authorities from the start and follow the country's data and telecoms rules. Keeping data inside the community makes privacy compliance simpler, not harder.

The first node is funded by this round, with grants where they fit. Long term, we expect a mix: communities and cooperatives paying a modest service fee out of measurable savings in water and energy, municipalities and regional governments contracting for towns, and foundations funding communities that cannot pay yet. Community One is where we test which mix works.

By owning part of the company that builds and supports the nodes. Once the kit and software are proven, each new deployment, service contract and town or city programme is revenue. This is an early, high-risk stage and we will talk honestly with every investor about that.

Before installation we agree measures with the community, such as water saved, energy wasted, node uptime, how many households use it, and whether people feel decisions are fairer. We publish the results openly, good or bad.

Yes. Choose foundation or grant maker in the investor conversation and we will talk about the structure that suits you.

Yes. Once Community One is running, and with the community's agreement, investors and partners are welcome on site.