You Can't Partner on a Blueprint You Didn't Draw
An Ubuntu Reading of the Algorithm Charter.
My first introduction to community development was in Uganda, my home country. It showed me what true community participation looks like, and it has shaped more than 20 years of practice since then.
We went into a village where there was very little: no school, no proper road system, no health facility, and limited economic opportunity. Like many development teams, we gathered the community and asked what they needed. But we also did something important: we spoke separately with the women, the men, and the young people. That was deliberate, because not everyone speaks freely in a mixed room.
What they said at first seemed to pull in different directions. The women said they needed water. The men said they needed income. The young people said they needed something to do. In many systems, that would have been the end of the conversation - someone would have chosen the “most urgent” need, written the report, and called it consultation.
We did not do that.
Instead, we took those answers back to the community and asked them to work through the tension themselves. We did not arrive with a blueprint. We arrived with a clean slate. What they came up with surprised us: the community knew we couldn’t provide everything, so they asked for two things: a well and a lorry.
The well made immediate sense. The lorry did not look like the obvious answer. It was not the neat, textbook solution that outsiders would usually prioritize. But it came from the community, so it was trusted. And in time, that choice changed everything. The lorry carried produce to bigger towns, opened up income, reduced dependence on middlemen, and helped the community build its own future. The well freed up women’s time, which created space for craft, trade, and enterprise. Young people gained skills by handling the trade, the marketing, and the well repairs. The community became stronger from the inside out.
That experience became the foundation of the Ubuntu‑informed lens I work within: a way of designing systems that begins with community knowledge, honors lived experience, and refuses the habit of building solutions for people without first building them with people.
That lesson matters now more than ever, because the same mistake keeps showing up in AI governance: communities are invited to respond to systems they did not help design.
In Aotearoa New Zealand, the Algorithm Charter 2020 is not the only document shaping AI governance, but it is a foundational ethical guide for the public service. It stands as a cross‑government commitment, signaling how agencies should develop and use algorithms - including AI - fairly, ethically, and transparently. It asks agencies to manage risks, mitigate bias, maintain human oversight, and embed Te Ao Māori perspectives into their processes. The question, then, is not whether the words sound good, but whether the Charter actually requires the shared authority those words imply.
Too often, vulnerable communities are not co‑designing the systems that shape their lives. They are being consulted after the fact, asked to comment on a blueprint already drawn somewhere else. And when that happens, consultation becomes a performance of inclusion rather than a transfer of power.
In practice, this is especially visible in how the room treats Māori. Māori are often the only community with a seat at the table - and they hold it by Treaty right, not by grace. Yet even that seat is frequently narrowed to a “perspective” to be embedded, rather than authority to be shared. Everyone else- Pasifika, disabled people, CALD communities, children, and others who bear the system’s effects - is not offered the seat at all. They are flattened into a vague category of “users” or “stakeholders”, their realities are treated as secondary even when the harm is shared. So the document performs two reductions at once: a partner narrowed to a perspective, and a person narrowed to a category.
Imagine this. A government agency invites an iwi trust to comment on a new decision‑making tool that will affect whānau in their community. The agency says it wants Māori input, and the meeting is framed as a partnership. But by the time the trust is brought in, the system’s purpose, risk categories, and core logic have already been set. The iwi representatives are asked for feedback on wording, communication, and “cultural considerations” - not on the design itself. The invitation sounds collaborative, but the architecture of the system is already fixed. The iwi representatives’ input is only within narrow boundaries. Their role is to improve a system they did not shape, and their presence is then used to signal legitimacy. That is not co‑design. That is rubber‑stamping with a Māori face on it.
That is the crack.
If AI-automated systems in social services are deployed in Aotearoa New Zealand without being designed by vulnerable communities - even if they are rubber‑stamped by Māori consultation - then those systems were designed for the vulnerable, not by the vulnerable. This distinction matters. It is the difference between partnership and permission, between co‑design and consultation, between shared authority and symbolic presence. The people bearing the harm are not involved in defining it; the agency defines the risk, the red flag, and the solution. The gatekeeper and the gatekept are the same entity - the agency builds the system, then rates its own risk for it.
Fortunately, the Algorithm Charter 2020 gives us the right language to hold it accountable. Its Partnership commitment asks agencies to “deliver clear public benefit through Treaty commitments” by “embedding a Te Ao Māori perspective in the development and use of algorithms consistent with the principles of the Treaty of Waitangi.” That is the standard it sets for itself - so let us test it against the Treaty principles.
Partnership requires shared authority at the design table. If Māori are only brought in after the system is already built, then there is no partnership - only permission. A perspective is not the same as presence, and presence is not the same as power. You cannot partner on a blueprint you were never there to draw.
Participation requires voice with weight. Consultation alone does not meet that standard if the community can speak only within narrow boundaries, after the core logic has been fixed. And when all other vulnerable communities are flattened into a generic category, participation becomes even thinner. Attendance is not participation. Rubber‑stamping is not voice.
Protection requires the protected to help define the harm. If the gatekeeper decides the risk, the harm, and the safeguards without those most affected in the room, then protection becomes supervision. It may look careful, but it is not relational, and it is not accountable to lived experience.
Tino rangatiratanga / Increasing authority - increasingly recognized as a fourth strand alongside the settled three - requires authority to grow. It cannot grow from absence, nor can it be built on consultation that leaves decision-making power unchanged. If communities are not in the room from the start, authority remains where it has always been - with the institution. Nothing increases from zero if zero is all that is offered. .
That is the problem with the Charter on its own terms. It speaks the language of Treaty alignment, but it does not require the conditions that make Treaty principles real. It allows good intentions. It permits excellent practice in some places. But it compels nothing. Remove the goodwill, and the floor is bare.
Some agencies do go further. Oranga Tamariki, for example, has Māori advisory roles and pockets of genuine co‑design. The truth is that this happens despite the Charter, not because of it. The good practice depends on individual agency goodwill, not on anything the document requires. The Charter permits excellence; it compels nothing.
My practice - Ubuntu‑informed AI governance - would do things differently.
Ubuntu says, “I am because we are.” It refuses the idea that people arrive at their circumstances in isolation. It insists that context, relationships, history, and community are not background noise; they are the data. An Ubuntu‑informed approach to AI governance takes the lesson of the village square seriously: you do not arrive with the answer, you arrive with a clean slate.
Applied to AI, that looks very different from the Charter’s model:
You begin with separate listening. Different groups - iwi, hapū, whānau, Pasifika communities, disabled communities, CALD communities, refugees, children and young people — are never flattened into one homogenous definition; each needs a safe space to define the problem in their own words. Each suffers the harm uniquely.
You surface apparent contradictions and do not rush to resolve them. The tension between “we need income” and “we need protection” might be the place the real design work has to happen. Listen to solve, not just to tick a participation box.
You allow solutions to emerge from the people most affected. The “lorry” in an AI context might be a locally governed data infrastructure, a community‑controlled decision rule, or a veto power - something no external ‘expert’ would have designed alone.
You ensure community ownership of outcomes — continually. The system, the data, and the safeguards are not simply explained to the community; they are shaped, refined, and governed by them. A system that allows for continuous revision - by the people, for the people - acknowledges that people, situations, and dynamics change. To create a robust architecture, you need to plan for this in the design.
In other words, the people bearing the harm are involved in defining it - and in designing the tools meant to address it.
That is the difference between the Charter and the Ubuntu‑informed AI governance model. One treats communities as a source of legitimacy. The other treats them as the source of the system.