The Technology of Good
Looking for one technically skilled person to build something specific, small, and real
I am a writer and reader based in Los Angeles. The Technology of Good grew out of a simple observation: the most powerful reasoning tools in human history are being built on a narrow slice of human thought about how to live together. The traditions that actually know something about collective life — commons governance, mutual aid, cooperative economics, indigenous frameworks, anarchist social theory — are functionally absent. This project is the attempt to put them back in.
I am not a technologist. I am the intellectual architecture. I need one person who can build.
What the project is
The technology of good is an initiative to build AI systems that take collective social and economic flourishing as their primary design constraint — not an afterthought, not a guardrail, but the foundational purpose the system is built around.
Most AI tools currently available reason from a narrow slice of human thought about collective life — essentially mainstream Western economics and liberal political philosophy. The frameworks that actually govern how cooperative institutions, commons, and democratic assemblies work — Ostrom's commons principles, Kropotkin's mutual aid, Bookchin's social ecology, feminist and indigenous governance traditions, heterodox economics — are functionally absent. Their absence is not neutral. It means the best available AI tools are structurally misaligned with the institutions that most need them.
We are building the alternative.
What needs to be built first
Not the whole system. A prototype — small, focused, demonstrably useful — that proves the concept and anchors the first real partnership with a real institution.
A retrieval-augmented AI grounded in a specific corpus
A system built on an existing large language model, augmented with a curated library of foundational texts in commons governance, cooperative economics, democratic theory, mutual aid, and heterodox and indigenous economic frameworks. The AI reasons from this corpus as its primary source, not as an occasional reference.
A simple interface for non-technical users
The people who will use this are cooperative governance committees, citizens' assembly facilitators, commons stewards. The interface needs to be plain enough that no technical intermediary is required. Simplicity is a design constraint, not a later refinement.
A first working session with a real institution
The prototype is not finished until it has been used once, in a real working session, on a real problem, with real people. That session — what worked, what didn't, what the institution needed that the system couldn't provide — is the specification for everything that comes next.
The initial corpus — around fifty texts
The founding collaborator will help finalize this list. A starting framework:Elinor Ostrom — Governing the Commons commons governance principles
Peter Kropotkin — Mutual Aid cooperative survival and solidarity
Murray Bookchin — The Ecology of Freedom libertarian municipalism
Karl Polanyi — The Great Transformation embeddedness of economy in society
Kate Raworth — Doughnut Economics social and planetary boundaries
Silvia Federici — Caliban and the Witch feminist commons theory
Arturo Escobar — Designs for the Pluriverse non-Western collective design
Glen Coulthard — Red Skin White Masks indigenous grounded normativity
Yochai Benkler — The Wealth of Networks cooperative networked production
David Bollier — Think Like a Commoner commons as living governance
Hélène Landemore — Open Democracy deliberative collective intelligence
Philip Pettit — Republicanism freedom as non-domination
Case studies — Mondragon, Rojava, Zapatista governance, Kerala, Preston Model living experiments
Selected papers — Mechanism Design for Social Good, P2P Foundation, commons transition current practice
The first use case
Cooperative and commons institutions facing governance design problems — specifically the challenge of making collective decisions across multiple constituencies with different interests, different time horizons, and different relationships to the founding values of the institution.
This problem is live right now in several identified institutions. The first partner conversation is ready to happen the moment a working prototype exists.
What the collaborator brings
Technical capability
Comfortable working with large language model APIs, retrieval-augmented generation, and building simple interfaces. Does not need to be a machine learning researcher — solid engineering skills and familiarity with current AI tooling is enough.
Intellectual alignment
Genuine familiarity with at least some of the traditions in the corpus — not academic expertise, but enough grounding to care about whether the system reasons well from them. Someone who has read Ostrom or Bookchin or Benkler and found it mattered.
Appetite for founding work
The prototype will be imperfect. The first partnership will be uncertain. The collaborator needs to be comfortable with early-stage ambiguity and genuinely interested in shaping what the project becomes, not just executing a defined specification.
What the collaborator gets
Co-founder status
This is a founding collaboration. The technical collaborator's judgment shapes the project from its earliest moment. As the project develops and resources follow, that founding role is recognized structurally.
A real use case from day one
Not a toy problem, not a benchmark, not a demo. A real institution with a real problem that needs what this system can provide. That is rarer than it sounds in applied AI work.
Intellectual partnership
The intellectual architecture of the project is already developed — a serious, cross-disciplinary framework drawing on the best available thinking about collective life. The collaborator joins a conversation already at depth, not a blank slate.
What this is not
This is not a funded startup. There is no salary, no equity structure, no product roadmap. Those things may come — and we intend to pursue funding actively once a prototype exists — but they do not exist now and we will not pretend otherwise.
This is not a research project. There are no publications planned, no academic affiliation required, no conference presentations as the deliverable. The deliverable is a working tool used by real people on real problems.
This is not a large commitment of time upfront. A first conversation, a shared assessment of whether the fit is real, and then a focused sprint to build something small enough to test and honest enough to learn from.
The shape of the first three months
Month one: finalize the corpus together, make technical choices about the prototype architecture, build the first working version of the retrieval system.
Month two: build the interface, run internal tests against real governance questions drawn from the identified use cases, refine based on what the system gets wrong.
Month three: first working session with a partner institution, debrief, produce a clear account of what the system can and cannot do, and decide together what to build next.
If you have read this far and recognize what is being described — if you have the technical skills and share enough of the intellectual commitments to want to find out whether this works — write to me.
rextyranny@gmail.com
