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.

The node runs its own local Wi-Fi network inside the community, like a private intranet. Residents use their own phones, a few shared tablets or a kiosk at the community centre, by text or by voice. No internet connection is involved.

Updates are delivered in person on physical media, checked against our digital signature before anything is installed, and only applied with the community's approval. The node never opens a connection out.

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, leave a kit of spare parts, and design the node from standard, swappable components. For anything bigger, our team visits on a regular schedule.

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.

No. The data stays on the node in the community. We do not take copies, train other products on it, or sell it. What we publish from the pilot is aggregate results the community has approved.

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.