Tech sovereignty as a principled way of solving technical problems

Tech sovereignty is usually argued as an ethics question: who should own a community’s data, who should be allowed to profit from it. We agree with the ethics. But we use it as an engineering constraint, because in practice it settles technical arguments that would otherwise go in circles.

Three things have to stay under community control.

Data

The information a community generates belongs to that community — its drawings, its costs, its site records, its recorded discussions. Not held on its behalf. Held by it, on terms it set, with the ability to take it elsewhere.

Once that is a fixed requirement, a class of architectural questions answers itself. Whether to route everything through a service we operate. Whether it is acceptable to store one community’s records in a schema that cannot be extracted without us. Whether a convenient third-party integration is worth it. The question stops being “is this a reasonable trade-off” and becomes “does this leave the data in the community’s hands”, which has an answer.

Compute

We believe AI should be built and run locally, close to the people it serves, and shaped around local needs — rather than delivered as a remote service that decides on their behalf.

The ethical argument is straightforward. The technical one is that a remote model you cannot inspect, change or afford is a dependency you cannot design around. In RachchaBanda the processing runs at the panchayat office, and that single decision shapes the model choice, the cost budget and the privacy story all at once. It also makes the system’s limits legible: a village can see what its own machine can and cannot do.

Local compute is harder. It is also the only version that a community can keep running when the funding changes.

Usage

Sovereignty over usage means the community decides what the system is used for and what it will not be used for. This is the part that most often gets conceded, because usage restrictions are inconvenient to whoever wants to scale the tool.

A worked example: RachchaBanda produces patterns broken down by ward, gender, class and caste, because a community needs to see whose voice is missing. The same breakdown, in other hands, is a targeting list. The system is built so individual and group anonymity is preserved and the aggregate stays with the panchayat, because who may query it is a design decision and not a policy document written afterwards.

What it costs us

This is not free. Sovereignty rules out most of the defaults that make software cheap to build — the managed everything, the shared multi-tenant database, the frontier model behind somebody’s API. It means smaller systems, more local installation work, and more time spent training people who will operate the thing.

We think that is the right trade for software at community scale, where the community is small enough to actually exercise the control we are talking about. Custom, community-scale solutions that fit the actual needs of a community beat tools that ask a community to reshape itself to fit the software. Sovereignty is what keeps the first kind from quietly turning into the second.