Documents // 03

QUESTIONS &
ANSWERS

Direct answers to the most common questions about Integral

These are the questions we actually get asked — from skeptics, from curious newcomers, from developers, from cooperative practitioners. We answer them directly, without evasion. If your question is not here, ask it on Discord or open an issue on GitHub.

Integral is an open-source architecture for a federated cooperative economy — a system that organizes production, distribution, and resource management without money, markets, or hierarchical authority, using democratic governance and real-time ecological feedback instead.

Integral was initiated by Peter Joseph — writer, filmmaker, and systems thinker — as a response to what he sees as the structural, rather than moral, failures of market capitalism. The white paper represents several years of research into systems science, cooperative economics, commons governance, and cybernetics.

The project is explicitly designed to be community-owned from the start. No individual, including the founder, holds authority over the architecture beyond what the community's own governance process grants. The goal is a system that belongs to the communities that use it.

It is not aligned with any political party or ideological tradition, and it does not require participants to hold particular political views. It is, however, political in the sense that it takes a clear position on the structural failures of market economies — one that is argued on systems science grounds, not ideological ones.

The system is designed to work for communities with diverse values, as long as they commit to its foundational operating principles: transparent governance, democratic participation, ecological accountability, and non-transferable contribution recognition. People from very different political backgrounds have found the architecture compelling on different grounds.

Phase 0 — Foundations. The white paper has been written. The development guide has been written. The website is being built. The contributor community is being assembled. No software has been built yet.

Phase 1 — the first working node with all five systems operational at minimal scale — is what the current development effort is working toward. Phase 0 is complete when the governance process, repository structure, schema ratification, and technology stack decision are all settled. That work is in progress now.

See what each phase validates

Elements of it have — cooperative economics has a long history, commons governance has been extensively studied and practiced, cybernetic economic management was attempted in Chile in the early 1970s under Stafford Beer's Project Cybersyn. What is new about Integral is the synthesis: combining all of these traditions into a single integrated architecture, designed from the ground up to be federated, ecologically accountable, and cybernetically self-correcting.

The fact that elements have been tried and worked — worker cooperatives, commons institutions, participatory budgeting — is part of the argument. Integral is not a utopian proposal. It is a synthesis of what the empirical record shows can work, integrated through systems science.

Read about the intellectual foundations

CDS (Collaborative Decision System) — the democratic governance layer. Communities raise issues, deliberate, reach consensus, and dispatch decisions to the other systems.

OAD (Open Access Design) — the shared design commons. Production blueprints are submitted, ecologically assessed, certified, and made available to all nodes as a shared resource.

ITC (Integral Time Credits) — contribution accounting without money. Labor and resource contributions generate non-transferable, time-decaying credits that determine access to goods and services.

COS (Cooperative Organization System) — the production layer. Production plans are executed, labor is coordinated, materials are managed, and outputs are tracked.

FRS (Feedback and Review System) — the cybernetic nervous system. It reads the operational reality of the other four systems, diagnoses drift, generates recommendations, and routes them back to CDS — closing the loop.

Explore each system in detail

Three structural differences that are not incidental but architectural:

Non-transferable. ITC credits cannot be given, sold, or traded between participants. They can only be earned through contribution and spent on access. This makes accumulation impossible — you cannot become wealthy in ITC by receiving others' credits.

Time-decaying. Credits lose value over time if not used. This eliminates hoarding and creates a structural incentive for ongoing participation rather than stockpiling.

Ecologically costed. The access cost of goods includes their ecological footprint — not as an external tax but as a built-in component of the credit calculation. This means ecological behavior is structurally rewarded, not morally appealed to.

Together these three properties make ITC incapable of reproducing the dynamics of money — accumulation, speculation, and the conversion of wealth into political power.

Through the CDS governance process and the ITC access cost mechanism, rather than through price signals. When demand for a scarce resource exceeds supply, the FRS detects this and routes it to CDS as a governance issue. The community deliberates and decides — who gets priority, how the shortage is managed, whether production should be increased or access rationed.

This is not a faster or more efficient mechanism than price signals. It is a more democratic and ecologically honest one. Speed of allocation is not the metric that matters. Fairness and ecological sustainability are.

At federation scale, this becomes more complex and is an acknowledged open problem in the current white paper.

Several structural provisions working together. CDS participation is not mediated by financial power — there is no mechanism by which accumulated credits translate into governance influence. Voting weight in the consensus module is based on participation and relevant expertise, not wealth.

The FRS provides a continuous independent signal about whether the system is actually performing as its governance decisions intended — making it structurally difficult to sustain decisions that produce bad outcomes without those outcomes being visible.

All decisions are published in a tamper-evident log. The community can always see who decided what, and when. Capture requires sustained deception in a transparent environment — which is much harder than capture in opaque institutions.

It shares socialism's critique of private ownership of means of production and its commitment to collective governance of shared resources. But it differs in important ways from most socialist traditions.

It does not rely on state ownership or central planning. It is explicitly federated and decentralized — nodes are autonomous and self-governing, connected voluntarily through shared protocols rather than by administrative authority. It does not use labor vouchers or any currency-like instrument for distribution. And it is built on empirical systems science rather than on the theoretical frameworks of classical Marxism.

The most accurate label is probably "cybernetic commons economics" — but labels matter less than whether the architecture actually works. That is what Phase 1 development exists to test.

The calculation problem — Hayek and Mises's argument that central planners cannot aggregate the distributed knowledge that price signals encode — is a serious objection that Integral takes seriously. But it is an objection to central planning, and Integral is not a centrally planned system.

Integral distributes knowledge through the same mechanism that generates it — the operational record of each node. The FRS aggregates real operational data, not planned allocations. The CDS processes that data democratically within communities that have direct knowledge of their own needs. No central authority attempts to process economy-wide information.

The question of whether this is computationally and institutionally adequate at scale is an open one — acknowledged as such in the white paper. It is what the federation phase exists to test against reality.

The same things that incentivize most meaningful human work — contribution to something that matters, recognition by a community, access to goods and services, and the intrinsic satisfaction of skilled productive activity. ITC credits provide a transparent and fair record of contribution that determines access. That is a real incentive, not an appeal to altruism.

The question assumes that money is uniquely motivating, which the empirical record of voluntary cooperative institutions, open source software development, mutual aid networks, and commons governance does not support. People contribute substantial labor to systems that recognize and value that contribution without paying for it in money, consistently, at scale, across cultures.

The ITC decay mechanism also creates a structural incentive for ongoing participation — credits you do not use lose value, so participation is continuously rewarded over hoarding.

We do not give a timeline because we do not have one that is honest to give. The project is volunteer-driven. Phase 1 development — a working first node with all five systems operational — could take anywhere from six months to several years depending on how many contributors with the right skills engage with the build.

What we can say is that Phase 0 has a defined completion condition: governance process established, repository structure confirmed, schemas ratified, technology stack decided. When those four things are done, Phase 1 development begins. The pace of Phase 1 is entirely a function of who shows up to build it.

Help accelerate the build

Yes — and we encourage it. Proto-node registration is open now. Registering as a proto-node means beginning the organizational, cultural, and relational groundwork that the software will eventually run on. This includes understanding the five systems and how they apply to your community's specific context, beginning to practice some of the governance principles in your existing decision-making, identifying which goods and services your community might produce and consume within the system, and connecting with other proto-node communities.

Communities that do this work before the software is ready will be dramatically better positioned to adopt it effectively when it becomes available — and their real-world experience will directly inform the development.

Register as a proto-node

Early nodes will operate within existing legal frameworks — tax law, employment law, property law — that were designed for a very different kind of economic organization. This creates real friction. ITC-compensated labor may be treated as employment by tax authorities. Property held collectively by a node requires some legal wrapper — cooperative incorporation, nonprofit status, land trust, or similar.

The project does not have a resolved answer to this yet. The node preparation guide addresses what is currently known, and legal design for early nodes is an open problem that domain expertise in cooperative law would significantly help address.

Read the node preparation guide

Yes — and the project genuinely needs non-developer contributors at this stage. The highest-value contributions right now include: rigorous theoretical critique of the white paper's architecture, domain expertise in cooperative economics or ecological assessment or commons governance, documentation and communication, cooperative practice knowledge, and community organizing for proto-node development.

The development guide deliberately describes six distinct contributor types precisely because the assumption that open source projects are only for developers has historically limited their scope and quality.

Find your contributor type

The project uses a three-tier decision process consistent with the CDS principles it is trying to build. Day-to-day technical decisions are made by working groups. Cross-system architectural decisions require broader documented consensus. Foundational decisions require a community-wide process.

No individual, including the project's founder, holds unilateral authority over architectural decisions. The governance process is the authority. This is not just a principle — it is enforced by the structure of the repository and the documented decision record.

See how GitHub governance works

Read the white paper abstract and the development guide preface. Join the Discord server and introduce yourself in the #introductions channel. Browse the open GitHub issues to see what is actively needed. Then pick the smallest useful thing you can do and do it — a critique, a question, a pull request, a connection to a cooperative community that should know about this project.

The best contributors start by doing something small and concrete rather than waiting until they understand everything. Understanding comes through participation.

Join the Discord

YOUR QUESTION NOT HERE?

Ask on Discord for a quick answer, or open a GitHub issue if you think the question and answer should be added to this page permanently.