System architecture

Noosphere is an infrastructure for collective decisions in which a vote is weighted by the quality of demonstrated argumentation rather than the size of a token stake. Architecturally it combines a blockchain (for the tamper-proof recording of decisions and transactions), a typed argumentation graph (to represent collective thought), and a pluralistic AI infrastructure layer (for assessment, translation, indexing, and work with the graph) — subject to the conditions that every AI decision is contestable through the same mechanism as any other claim in the system, and that the choice of which AI model to work with remains with the participant.

This document describes the system's architecture. Its purpose, scope, and the rationale for the approach are set out in a separate document.

Three architectural theses that frame the system:

First. A capture-resistant network is built not as a registry but as a graph of links between participants with their attached PoI profiles. Seizing the registry leaves an empty shell — the participants move to a fork. The right to fork is a structural defense.

Second. Sybil resistance is an emergent property of the intersection of layers, not of any single textual one. A multitude of empty accounts yields a multitude of zeros in the weight formula; but the quality of an argument is confirmed only by the argument itself, not by a unique human behind it. Identification (a unique, uncoerced participant), an economic ceiling on influence with capture devalued through forking, and live expert peer review close what the textual layer alone no longer holds. An attack requires breaching all layers at once — and by cost it again converges on legitimate participation.

Third. The AI infrastructure is pluralistic and contestable: no single model determines the final result, every judgment it makes becomes part of the graph and can be contested by the same mechanism as any claim.

The architecture addresses a class of problems insufficiently covered by one-token-one-vote models: collective decisions where the weight of a vote should be determined by the quality of argumentation rather than the size of a stake; where argumentation is typed and inseparable from voting; where every system decision is contestable; where capture resistance is provided structurally (the right to fork) rather than by hoping an attack stays expensive; where identity is verified through demonstrated thinking rather than documents; where the AI infrastructure is pluralistic. These requirements are formalized below as eight architectural principles.

Each principle is independent in its rationale, but they are interconnected in operation. Changing one of them changes the consequences for the rest, which is why they are stated explicitly here as the foundation on which the technical components are built.

2.1. Argument over stake

A vote is weighted by the quality of the participant's demonstrated argumentation, not by the size of their stake in the system. Stake is present — as anti-spam, as commitment, as a mechanism of skin in the game — but not as the dominant factor in vote weight.

This solves the fundamental problem of one-token-one-vote DAO models: the impossibility, in principle, of separating the right to vote from the size of capital. In Noosphere the right to vote is earned through the demonstration of thinking; capital can amplify the weight of an already-earned vote, but cannot substitute for its absence.

Architectural consequence: the main weight in the vote formula comes from the PoI Score (Proof of Intelligence) — an assessment of the quality of a participant's argumentation. Stake enters the formula under a square root and with a ceiling (SphereCap), making added capital progressively less effective.

2.2. Contestability of all infrastructure

Every system decision is contestable through the standard argumentation mechanism. This applies not only to votes on substantive questions but to infrastructure-level decisions — clustering of positions, assessments of argument quality, translations, PoI calibration. Including, and especially, the decisions of AI components.

Architecturally this means AI has no privileged role as a final authority. AI makes the initial proposal (faster than people, cheaper, in real time), but that proposal becomes part of the argumentation graph and can be contested by any participant through the same mechanism as any substantive claim. A dispute is resolved through PoI-weighted voting, in which AI decisions have the same status as human arguments.

This is what fundamentally distinguishes the architecture from standard AI-powered systems, where AI is the final authority and the user either accepts the AI's decision or doesn't, but cannot meaningfully contest it within the system.

2.3. Multilingualism as architectural condition

No language is privileged in the system. This is not "support for several languages as a feature," but an architectural condition.

Every claim in the graph is stored in the original language version — the one the author created it in. The original is never replaced by a translation; a translation is a separate object in the graph with its own author (human or AI), its own PoI weight for the translation's author, its own history of contestation. A single original may have several competing translations into the same target language, each of which can be contested through the standard mechanism.

Architectural consequence: the Translation link type is on equal footing with the Argument and Endorsement types in the graph. A Translation is a form of claim about the identity of meaning between two texts in different languages, and that claim is contestable.

This is critical in Spheres where wordings are sensitive to nuances of translation: the choice of translation for a significant formulation is itself a substantive position, and the Sphere does not make that choice for its participants.

2.4. Fork as capture defense

The right to fork a Sphere is a structural defense against any attempt to capture it — including an attempt by the Noosphere team itself.

A Sphere in Noosphere is built not as a registry (a record in the system that can be captured by altering the record) but as a network of links between participants with their attached PoI profiles and argumentation graph. Seizing the registry — should someone gain control over a Sphere's metadata — leaves an empty shell: the participants, with their PoI profiles, move to a fork, taking the real content of the Sphere with them (the argumentation graph, reputation, the participants' trust in one another).

This changes the economics of an attack. Seizing the registry without seizing the participants is useless; seizing the participants requires their voluntary consent to follow into the captured Sphere, which in a hostile takeover is unlikely.

Architectural consequence: the fork mechanism is a first-class function of the system, available to participants by a vote within the Sphere, rather than a rare emergency action.

2.5. On-chain what matters, off-chain what scales

The architecture uses an explicit division: what is critical for non-forgeability lives on chain (Solana); what is needed for scalability and ease of operation lives off chain, but with a cryptographic link to on-chain.

On chain: hashes of graph nodes, votes and their results, the registry of participants and their PoI profiles, the Sphere treasury, multisig governance of execution, key events (Sphere creation, fork, closure).

Off chain: full argument texts (IPFS for active content, Arweave for permanent storage of important finalized artifacts), graph indexes (Neo4j or Dgraph), search infrastructure, the UI layer.

Cryptographic link: every node and every link has a hash recorded on chain. Altering off-chain content makes it impossible to match against the on-chain hash and is detected automatically.

2.6. Spheres as networks, not registries

This is a restatement of principle 2.4 in its architectural dimension. A Sphere in Noosphere is defined by the set of its participants and their links (a shared argumentation graph, a shared treasury, a shared voting history), not by a record in a single registry.

Architectural consequence: there is no single "center," control over which would mean control over the Sphere. A Sphere's metadata (name, description, parameters) is stored on chain and can be contested or changed through a vote of the Sphere's participants. Seizing any single point — servers, a node, metadata, keys — does not equal seizing the Sphere.

2.7. AI as participant, not authority

AI in the system is one participant among others, with its own type of constraints and its own strengths. AI is faster than people, cheaper, more available in real time; but AI has no privileged role in decision-making.

Every time AI makes a judgment — assessing a participant's PoI, classifying an argument, proposing a translation, detecting a pattern in the graph — that judgment is a visible proposal, contestable by the same mechanism as any claim in the system. If a participant considers an AI assessment wrong, they formulate a counterargument through the standard mechanism, and the dispute is resolved by PoI-weighted voting.

This does not mean every AI decision is necessarily contested — most will pass without dispute, because they will be adequate to the task. But the architectural possibility of contestation changes the status of AI: it ceases to be a final authority and becomes a high-throughput but procedurally checkable participant.

2.8. AI Pluralism

Not one AI model works in the system as part of the infrastructure — but a multiplicity of models, chosen by the participants. Each participant decides which model helps them work with the graph, ranks arguments for them, makes translations, proposes classifications.

This is the completion of the AI-as-participant principle: if AI is a participant, then it is impossible for there to be a single AI. Each human participant chooses their own AI partner, and the divergence between views of the graph through different models becomes visible and discussable.

Architectural consequence: a standardized Noosphere AI Layer interface, through which any model can be connected — cloud APIs (Claude, GPT, Gemini, Mistral), local models on the participant's device (via Ollama, llama.cpp), decentralized inference networks (Bittensor, Ritual). Noosphere is economically neutral to the choice of AI — the participant pays for inference directly to the provider or platform, with no Noosphere intermediation.

This removes the last place of hidden centralization in the system: the AI layer.

This part describes the core components of the system. Each component is presented with the specific technologies it is implemented on, and with explicit architectural forks where they exist.

3.1. Argumentation Graph

The structure of collective thought in Noosphere is represented as a directed acyclic graph (DAG) with typed nodes and links.

Node types:

• Claim — an assertion. The basic unit of content. An assertion of fact, value, forecast, or proposal.

• Argument — an argument for or against a claim. Contains a justification resting on one or more other claims or external evidence.

• Endorsement — support for an existing claim or argument without creating a new one. A lighter-weight form of participation than creating a full argument.

• Translation — a claim about the identity of meaning between two texts in different languages. A standalone node type, because a translation is itself a contestable claim.

Link types between nodes:

• SUPPORTS — A supports B. An argument supports a claim.
• REBUTS — A refutes B. A counterargument against a claim or another argument.
• UNDERCUTS — A undermines the link between C and D, without attacking either C or D directly. An attack on the warrant, not on the claim.
• QUALIFIES — A qualifies the applicability of B, narrowing the domain in which B holds.

Constraints: cycles in the graph are disallowed by definition (it is a DAG). The Translation link is a special case that does not form typical cycles, because it connects nodes in different languages representing identical content.

Storage:

• On-chain (Solana): the hash of each node and each link, metadata (author wallet, timestamp, type), the author's PoI weight at the moment of creation.
• Off-chain: the full text of nodes in IPFS for active content and in Arweave for finalized significant artifacts; the graph structure in Neo4j (the preferred choice) or Dgraph.

Cryptographic link between layers: the hash of the full text (including the original language and metadata) is recorded on chain at the moment a node is created. Any off-chain substitution of the text makes the hash mismatch and is detected automatically.

Open question (Part 5): the specific IPFS/Arweave hybrid strategy for different classes of content, accounting for cost and long-term reliability.

3.2. PoI Score (Proof of Intelligence)

The PoI Score is an assessment of the quality of a participant's demonstrated argumentation. It is not a reputation score in the ordinary sense (not a count of likes, not a social rating), but an assessment by five structural criteria, applied to the participant's actual argumentative activity.

Five criteria:

• Argument structure — how clearly the claim is stated, how cleanly premises are separated from conclusions, how sound the logical structure is.

• Depth of knowledge — how deep an understanding of the topic the participant demonstrates in their arguments. Not "knows many facts," but "understands the context and its complexity."

• Handling of counterarguments — how the participant responds to counterarguments. Ignoring them, going ad hominem, answering superficially — a low score. Acknowledging the strengths of the opposing position, qualifying one's own, refuting on the merits — a high one.

• Cognitive patterns — stable patterns of thinking visible in the argumentation. Distinguishing cause from correlation, awareness of the limits of one's position, the ability to hold complexity.

• Clarity of expression — how clearly the thought is expressed. Not literary skill, but communicative clarity.

Two modes of assessment:

• General ongoing profile: a cumulative assessment across the participant's entire argumentative activity in the system, with time-weighting (recent activity counts for more).

• Pre-vote assessment: a targeted assessment of the participant's PoI with respect to a specific voting topic, conducted immediately before important decisions. It accounts for the specifics of the topic and the participant's competence in it.

Calibration dialogue: the initial PoI assessment happens through a structured dialogue with an AI component of the system. The dialogue is deliberately designed to be long, branching, with clarifying questions. The textual exchange alone carries no Sybil load — strong argumentation can be generated on the fly by an LLM; the load is carried by the coupling of calibration with the other layers (see 3.6): the identity layer (the dialogue is tied to a unique, uncoerced participant) and the social layer (contested cases escalate to live expert peer review, poorly reproduced by an LLM proxy). The AI model for calibration is chosen by the participant from those available in the system (see Part 3.8 on AI Pluralism), but fixed at the moment of calibration for reproducibility.

Vote weight formula:

weight = (PoI_user / avg_PoI_sphere) × √(min(staked_NOS, SphereCap))

Where:

• PoI_user — the participant's current PoI Score
• avg_PoI_sphere — the average PoI Score of the Sphere's participants
• staked_NOS — the amount of $NOS the participant has staked in this vote
• SphereCap — the stake ceiling, set by each Sphere independently

The first part of the formula (the ratio to the Sphere's average PoI) works against anonymous accounts with zero history of thinking. Their weight is close to zero, regardless of stake size.

The second part (the square root of the stake, capped by SphereCap) works against a purely capital-based attack. The root and the ceiling make added capital progressively less effective.

Contestability of PoI assessments: every PoI assessment is a decision by an AI component, and it can be contested through the standard mechanism. A participant who believes their PoI was assessed incorrectly formulates an argument through the same mechanism, and the dispute is resolved by peer review plus PoI-weighted voting.

Peer review: in contested cases the PoI assessment is verified through a live dialogue between the participant and a topic expert verified within the Sphere. This is not a review of a transcript, but a real two-way conversation in which the expert assesses the participant's thinking.

Open question (Part 5): protecting the calibration dialogue from prompt injection and from passing calibration via an LLM proxy optimized against the scoring prompt — that is, what proportion of contested cases must be forced into the identity and social layers.

3.3. Sphere Lifecycle

A Sphere is a collective subject united by a shared treasury, a shared argumentation graph, and shared voting rules. It has a lifecycle.

Creation: a Sphere is created by an initiating group of participants (the threshold of count and aggregate PoI is set at the protocol level). At creation, parameters are defined: name, description (itself a claim, contestable after creation), initial SphereCap, base voting rules.

Regular operation: participants propose claims, formulate arguments and counterarguments, vote on decisions. All artifacts are on chain (hashes) and off chain (full texts). Sphere decisions are executed through escrow mechanics and multisig.

Escrow and earmarked spending: a Sphere can vote to spend $NOS on a specific purpose. Funds are reserved in escrow, released on completion of the purpose (with confirmation of fulfillment), returned to the treasury on non-fulfillment.

Fork: any Sphere participant can initiate a fork. A fork creates a new Sphere with the same argumentation graph, the same voting history, the same participant PoI profiles. The treasury is split proportionally (the split rule is set by the originating Sphere). Participants decide for themselves which of the two Spheres to continue in. The right to fork acts as a structural defense against any attempts at capture.

Closure: a Sphere can be closed by a vote of its participants. The history remains on chain forever; the treasury is distributed by the rule set by the originating Sphere.

3.4. Treasury and financial mechanisms

$NOS is the internal functional currency of Noosphere. Not a speculative asset; the purpose of its existence is to power mechanisms inside the system.

Functions of $NOS:

• Stake in votes: a participant stakes $NOS, expressing commitment and skin in the game. The stake enters the vote weight formula.

• Escrow for earmarked spending: a Sphere's treasury holds $NOS, allocated by vote to specific purposes.

• Investment in Sphere projects: participants can invest $NOS in specific initiatives within a Sphere, receiving a share in the results (where applicable). This creates a public, non-forgeable history of each participant's investment decisions.

Three layers of reputation (all on-chain, public):

• PoI Score — the quality of argumentation.
• Peer Review track record — a history of expert assessments: which peer reviews the participant took part in, in what capacity, with what result.
• Investment/Contribution History — a public history of investments and contributions to projects within Spheres.

These three layers are independent but visible together. They are not reducible to a single number — each shows a different side of reputation.

Execution multisig: to execute a Sphere's mandate in off-chain actions, a multisig is used — a distributed signature of several holders. Signature holders are appointed by a Sphere vote, distributed geographically, obligated to execute the Sphere's decisions. Failure to fulfill the mandate is grounds for revoking a key through a Sphere vote.

3.5. Contestability Layer

Contestability in Noosphere is not an add-on mechanism but a cross-cutting property of the architecture. Every system decision — from an individual PoI assessment to an architectural proposal from the development team — is contestable by the same mechanism as any claim.

What can be contested:

• The PoI assessment of a specific participant
• The translation of an argument into another language
• A clustering of positions proposed by AI
• The classification of a link between graph nodes
• Protocol parameters (through a vote)
• Architectural decisions of the development team (through proposals with PoI-weighted voting)
• The results of any specific AI model (with the ability to compare against other models — see Part 3.8)

How contestation works:

• The participant formulates a counterargument to the contested decision through the standard Argument mechanism, with a REBUTS or UNDERCUTS link type.
• The counterargument is included in the graph alongside other claims.
• A local dispute arises: the original decision vs the counterargument. Other participants can support one side or the other through their own arguments.
• The dispute is resolved by PoI-weighted voting. If the counterargument wins — the original decision is revisited. If it loses — the decision stands, but the counterargument remains in the record as a fixed attempt at contestation.

What this changes: AI and the development team have only the influence that the participants' PoI-weighted voting grants them. They cannot impose a decision by bypassing the argumentation mechanism.

3.6. Identity and Sybil Resistance

The Noosphere architecture does not require KYC. A participant's identity is their wallet, attached PoI profile, and history of activity in the system.

Pseudonymity as operational norm: participants can use pseudonyms unconnected to their legal identity. The PoI profile and reputation attach to the wallet and pseudonym, not to the person. This reduces the surface for targeted pressure on participants.

Sybil resistance through PoI: creating additional wallets confers no advantage, because each new wallet has zero PoI and must accrue it through the demonstration of thinking. A multitude of empty accounts yields a multitude of zeros in the weight formula.

Sybil resistance as intersection of layers: earlier formulations attributed resistance to the semantic layer — the assumption that quality argumentation cannot be produced at scale without a corresponding number of competent people. With the arrival of cheap text generation, that assumption is no longer self-sufficient: a model produces strong argumentation in a volume limited only by compute, and can be optimized against a known scoring prompt. Resistance persists, but as an emergent property of the intersection of four layers, none of which carries the load alone.

• The semantic layer assesses the quality of an argument (structure, depth, handling of counterarguments, cognitive patterns, clarity), but confirms a property of the text, not the presence of a human behind it.

• The identity layer (the Node: biometrics plus coercion-resistance) confirms a unique, uncoerced participant, but not the source of the text.

• The economic layer (a ceiling on influence per participant, a public investment history, the right to fork) limits weight regardless of argument quality: capture does not scale beyond the influence ceiling and is devalued by forking.

• The social layer (peer review as a live, real-time expert dialogue, the recurrence of PoI) relies on latency, improvisation, and cross-clarification, poorly reproduced by an LLM proxy with a human intermediary.

An attack requires breaching all four layers at once: a unique, uncoerced human, independently conducting an expert dialogue at a high-PoI level, in numbers above the influence ceiling. By aggregate cost this again converges on legitimate participation rather than an attack.

The hardware layer in the long term: the identity layer in its strictest form is implemented through an optional hardware layer (the Node) — a device with LiDAR for coercion-resistance, providing heightened protection in especially sensitive votes. This is not a mandatory condition of participation, but a reinforcement of the identity layer for votes that require heightened protection against coercion.

Coercion-resistance as a class of problem: protection against coercion is not a binary flag (protected / not protected) but a class of problem that can be addressed with varying degrees of strictness. The architecture should raise the cost of a "gun to the head for 30 seconds" class of attack to a level of difficulty unacceptable for mass application.

3.7. Argumentation Interaction Layer

This section describes how a participant's interaction with the argumentation graph is structured during work — what happens when a participant writes a new claim, and how they work with the already-existing graph.

What happens when a participant writes

At the moment a new claim is written, an AI component performs three parallel operations in real time:

• Semantic search across the existing graph. The text is converted into an embedding and compared against the embeddings of existing nodes. The search works multilingually — a semantically close argument in Ukrainian will be found by a query in Russian.

• Classification of the claim type. The AI determines what exactly the person is about to say: a new Claim, support for an existing one, a rebuttal, a qualification, a restatement.

• Construction of a map of the relevant graph fragment. The AI finds not only similar arguments but also their counterarguments, supporting lines, successful rebuttals. The result is a local map of the discussion on the topic.

What is shown to the participant

Three blocks of information:

• Block 1: "Similar claims already in the Sphere". A list of 3–5 semantically close arguments, sorted by semantic proximity and the authors' PoI weight. For each — a short summary, how many times it has been supported, whether there are successful counterarguments.

• Block 2: "The structure of the discussion on this topic". A visualization of how the argumentation has already branched: the main lines, the main counterarguments, the most-supported nodes.

• Block 3: "Possible actions". The AI offers the participant explicit options for what they can do.

Six action options:

• Endorse an existing claim — support without creating a new node; the participant's PoI weight is added to the existing one.

• Sign on with addition — support with a qualification, creating a new node with a QUALIFIES or SUPPORTS link to the existing one.

• Restate in another framing — adding an alternative formulation of the same position with an explicit equivalence link.

• Contest with REBUTS or UNDERCUTS — if the AI has determined that the participant objects to an existing claim, an explicit counter-objection is offered.

• Create new Claim/Argument — creating a full new node, with a warning about close existing ones.

• Ask for clarification — if the formulation is ambiguous, the AI asks the participant to clarify what they mean.

Operating principles:

• The participant's decision is recorded. If the AI proposed a classification and the participant ignored it — that choice is logged, and with systematic disregard of AI prompts the participant's PoI on the "argument structure" criterion suffers.

• AI prompts are contestable. This is an application of the Contestability principle: if a participant believes their argument differs substantively from a similar one — that is a formal objection, recorded in the log.

• Control stays with the participant. The AI never blocks the creation of a new node. The final action is the human's.

Link to PoI Score: a participant who knows how to embed claims correctly into the existing graph — supporting where they agree, contesting where they disagree, seeing the structure — demonstrates a high level of thinking. PoI on the "handling of counterarguments" criterion rises. A participant who ignores the structure and breeds noise loses on that criterion.

Multiplicity of graph representations

Beyond interaction at the moment of writing, a participant works with the graph while viewing it. Here the architecture provides four main modes of sorting and filtering:

• Mode 1: AI-curated. The AI decides what to show first, how to cluster, which arguments to highlight. It uses all the signals available to it. The default mode for a new user.

• Mode 2: Human-curated. Sorting only by explicit human actions — the number of Endorsements (weighted by the endorsers' PoI), success in peer review, voting results. The AI does not influence the order.

• Mode 3: Hybrid. A combination of the previous two with a configurable weight, 50/50 by default.

• Mode 4: Chronological. Chronological order with no content-based sorting.

Plus filters: by language (originals in certain languages only, or including translations), by node type (Claims only, Arguments only), by the author's PoI weight (a minimum threshold), by time.

Principles of representation multiplicity:

• Persistence of user settings. The choice of mode is saved as part of the participant's profile.

• Transparency of what is shown. In any mode the participant sees a label explaining the sorting: "AI-curated, hybrid 70/30, filter: originals in Russian only, minimum author PoI 50."

• Mode comparison in one action. The ability to see, with one button, how the same graph fragment looks in another mode.

• Logging of mode-choice statistics. Statistics of which modes participants choose in which Sphere are public information. The divergence between AI-sorting and Human-sorting is itself substantively valuable.

• Contestability of the modes themselves. If a participant believes the AI-sorting in a Sphere is systematically biased — they can formally contest it through the standard mechanism.

Open questions (Part 5): the exact balance between collapsing and nuance in semantic search; the formalization of the semantic-proximity threshold; the visual design of switching between competing translations in the UI.

3.8. AI Pluralism Layer

The architectural layer through which any AI model can be connected to work with Noosphere. This is where the AI Pluralism principle (Part 2.8) is realized technically.

The standardized Noosphere AI Layer interface

For any model to be connectable, there is a formal API describing what an AI must be able to do in the system:

• Rank graph nodes (for the AI-curated representation mode)
• Perform semantic search (multilingual)
• Classify claims (determining the type of intended link)
• Assess PoI by the five criteria (for the calibration dialogue and for ongoing assessment)
• Produce translations (as a first iteration, contestable by other translations)
• Cluster positions (for the aggregated representation of a Sphere)

Each model implements this interface through a wrapper for commercial APIs, through a local server for open-source models, through a node of a decentralized inference network. Wrappers develop as open-source modules in the Noosphere repository.

Levels of model connection

• Cloud APIs (Claude, GPT, Gemini, Mistral, and others): via an API key provided by the participant. The participant pays for inference directly to the provider.

• Local models on the participant's device: via Ollama, LM Studio, llama.cpp. Free for the participant, but requires a powerful computer.

• Decentralized inference networks (Bittensor, Ritual, Akash): payment in crypto, with no centralized provider. Ideologically aligned with the project.

• The Sphere's default AI: for participants who haven't configured their own, the Sphere may provide a base model for payment in $NOS, as a service. This default is itself contestable by the Sphere — which model is the default is decided by a vote.

Transparency of which model is working

The UI always shows which model produces a given result: "Ranked: Claude Sonnet 4.7," "Translation proposed: GPT-5," "Semantic search: Llama 3 local." This is critical for the participant to understand what they are seeing, and for contestation: if several participants see a different picture because they use different models, the divergence must be attributed.

Contestation of results between models

If different models give different results — that is normal, but visible and contestable. If Claude ranks argument X high and GPT ranks it low, and this matters for understanding the Sphere — participants can record the divergence as a phenomenon and discuss it through the standard argumentation mechanism. This is a new class of meta-argumentation: not "is X right or not," but "different AIs assess X differently, what does that mean."

Caching and reproducibility

The results of a specific model on specific inputs are cached: hash of the input plus model plus result, all with a timestamp. The hash of the cache record is written on chain; off chain — the full result. This ensures reproducibility — another participant saying "Claude ranks it thus" can cite a specific cache record, and any third participant sees the same result.

Noosphere's economic neutrality

Noosphere takes no commission on inference and does not control the flow of money to AI providers. This is fundamental: if Noosphere took a commission on AI usage, it would have an incentive to promote specific models or suppress others. The neutrality of the economics makes the choice of AI truly free.

Model quality affects its usage

AI models are themselves subject to contestation through the PoI mechanics. If a model systematically gives poor results — it receives a low PoI as a participant in the system. Over time, participants don't choose it, and it drops out of active use. This creates an incentive for AI providers to improve the quality of their models' work in the context of Noosphere, rather than merely marketing them.

Protection against manipulation through AI choice

An attack is possible: a participant chooses a model deliberately biased in their favored direction. The defense: the choice of model does not affect voting directly. A vote is weighted by PoI and stake, not by AI assistance. AI works at the level of representation and prompts, but not at the level of formal weight. A participant viewing a Sphere through a biased AI has the same vote weight as one working with another model.

Evolution of the interface

The Noosphere AI Layer is itself versioned. As AI technologies develop (reasoning, agentic work, new modalities), the interface may expand. The development of the interface is a Sphere decision through the standard argumentation mechanism, not a decision of the development team.

Open questions (Part 5): the specific format of the standardized API; the validation mechanism for wrappers of new models; the economics of the "Sphere's default AI" — who pays for inference when a participant hasn't configured their own AI.

The roadmap consists of a stage zero of preparation (the infrastructure minimum) and subsequent technical stages, each with explicit completion criteria. The next stage does not open until the criterion of the previous one is met. These are not deadlines in the calendar sense — they are a sequence with verifiable conditions for transition.

Stage 0. Infrastructure minimum and base protection

A technical MVP with three test Spheres runs on Solana. The execution multisig is deployed and distributed among 5–7 holders. PoI calibration completes a full cycle for at least 50 test participants. All artifacts are on chain and verifiable. The multilingual architecture is validated in real use (at least one argument with a translation, at least one contestation of a translation). The contestability of the AI infrastructure is validated (at least one successful contestation). A base version of the Noosphere AI Layer works with at least two models (one cloud and one local).

Stage 1. First substantive vote

The first substantive Sphere vote — on the mechanism for distributing fees within the protocol. The goal of the stage is to test the mechanism under the load of a real decision with real consequences. The vote completes a full cycle, the decision is technically implemented in the protocol, all stages are documented on chain. Bugs in PoI calibration and voting are caught and logged. At least 200 participants have completed calibration. Argumentation has taken place in at least two languages with working translation contestation.

Stage 2. Spheres for internal decisions

Launch of Spheres for the project's internal questions — development priorities, budget allocation, choice of infrastructure partners. Real spending with real money. At least three cycles of "vote → spend funds → report on fulfillment." A working mechanism for publishing financial reports. At least 1000 participants in the system. The right to fork tested by at least one practice fork. Confirmed: spending on behalf of a Sphere is executed through multisig based on a vote result. The Noosphere AI Layer supports at least four models of different types.

Stage 3. Scaling the number of Spheres

Opening of Spheres for arbitrary domains by third-party initiators. Lowering the Sphere-creation threshold to a level at which the right of exit (fork) is real. Working through inter-Sphere interaction: transfer of reputation between Spheres, citation of decisions, coordination. Load testing of graph indexing and semantic search at increased volume. Stabilization of PoI calibration on a heterogeneous audience. Completion criterion: stable operation with at least ten parallel active Spheres with independent SphereCap parameters.

Stage 4. Own testnet

Launch of an own Noosphere Protocol testnet with PoI as a native element of consensus — a validator's weight depends on their PoI alongside their stake. Transfer of the argument-over-stake principle from the application level to the protocol level. Parallel operation of Solana and the testnet, working through the migration of graphs and reputation between them. Completion criterion: a test Sphere fully functions on the own testnet, including voting, graph, and treasury.

Stage 5. Decentralization of inference and the hardware layer

Moving the AI Layer onto decentralized inference networks as a full option alongside cloud APIs and local models. Opening the Node specification, the dev kit, the release of the first run of node devices with an optional coercion-resistance function. Completion criterion: a significant share of inference passes through decentralized networks; working physical nodes in participants' hands.

Stage 6. Mainnet

Launch of the Noosphere Protocol mainnet. Spheres existing on Solana migrate with their graphs and reputation. Completion criterion: the bulk of activity is moved to the own mainnet, Solana shifts into the role of a bridge or is taken out of the critical path.

This section is an explicit list of what is unresolved in the v0.5 architecture. Open questions are an invitation to substantive discussion, not a sign of the document's weakness. Each question has a context (why it is open), the options considered (what has already been thought through), and a current status.

Architectural questions

5.1. IPFS/Arweave hybrid strategy for different classes of content

Context: off-chain storage of full texts and other significant artifacts has two main options — IPFS (cheaper, requires constant pinning, no 10+ year guarantee) and Arweave (more expensive, permanent storage, a long-term retention guarantee).

Options considered:

• Everything on Arweave — financially unacceptable for active content
• Everything on IPFS with active pinning — insufficiently reliable for finalized significant artifacts
• Hybrid by content type: active discussions on IPFS, finalized decisions and important documents on Arweave

Current leaning: hybrid. But the specific criteria for moving an artifact from "active" to "finalized" are not defined.

5.2. Protecting the PoI calibration dialogue from prompt injection and LLM proxies

Context: PoI calibration is conducted through an AI component. With cheap text generation, an attacker can pass calibration through their own LLM, optimized against the known scoring prompt — texts that pass the filter without any real thinking. The textual layer alone does not cut off this attack (see 3.6); the question is how calibration leans on the identity and social layers.

Options considered:

• Randomizing the order and wording of dialogue questions
• Checking consistency across several calibration sessions separated in time
• Human peer review after the AI's initial assessment in contested cases
• Tying calibration to the identity layer (a unique, uncoerced participant) for higher-sensitivity votes

Current leaning: a combination of approaches with escalation of contested cases to live peer review; the exact balance and escalation threshold are not defined.

5.3. UI for competing translations: visual neutrality

Context: a single original may have several competing translations into the same language. The UI must show the competition without making any one translation visually dominant by default.

Options considered:

• By default, show the translation by the author with the highest PoI weight, with an explicit indicator that alternatives exist
• Show all competing translations simultaneously
• Alternate which translation is shown at random across sessions

Current leaning: the first option with obvious switching, but the visual design needs work.

5.4. Indexing the multilingual graph

Context: off-chain graph indexing must support both full-text search per language and semantic search via multilingual embeddings.

Options considered:

• Separate indexes per language + a separate semantic index
• A single system via multilingual embeddings
• A hybrid prioritizing exact language match over semantic match

Current leaning: hybrid. The exact weighting parameters are not defined.

5.5. Exact balance of collapsing vs nuance in semantic search

Context: AI helps a participant decide whether their claim is new or close to an existing one. Collapsing too aggressively loses nuance; collapsing too weakly creates noise.

Options considered:

• A fixed semantic-proximity threshold as a global parameter
• An adaptive threshold, changeable by each Sphere through a vote
• An "AI confidence" scale with several levels of prompts: from mandatory to advisory

Current leaning: the third option. The exact levels are not defined.

5.6. Specific format of the standardized Noosphere AI Layer API

Context: connecting any models requires a formal interface.

Options considered:

• gRPC with strict typed contracts
• REST API with JSON schemas
• An OpenAI-compatible API as the base standard (extended for Noosphere's needs)

Current leaning: the third option — broad compatibility with existing wrappers and a low barrier to connecting new models.

5.7. Validation mechanism for wrappers of new models

Context: anyone can write a wrapper to connect a new model to Noosphere. How to guard against poorly implemented wrappers that distort results?

Options considered:

• An audit of wrappers by the development team before admission
• Open-source wrappers with public code review
• A standardized test set on which a wrapper must show certain results

Current leaning: a combination of the second and third. Authoritarian auditing by a single team contradicts the project's general principles.

Economic questions

5.8. Specific scheme for distributing $NOS at launch

Status: in development as a separate economic document.

5.9. SphereCap parameters and the logic of setting them

Current leaning: the starting SphereCap value is tied to the average stake of the first cohort of participants; changing SphereCap happens through a Sphere vote with a raised approval threshold.

5.10. Economics of the "Sphere's default AI"

Context: for participants who haven't configured their own AI, the Sphere may provide a base model for payment in $NOS. Who exactly pays? The Sphere from its treasury? The participant from their stake? Both?

Options considered:

• The Sphere pays fully, costs covered from the treasury
• The participant pays themselves through small deductions from their stake
• Hybrid: base usage free (from the treasury), intensive usage at the participant's expense

Current leaning: the third option. The exact thresholds are not defined.

This section describes the direction in which the project develops beyond the horizon of the current roadmap. This is a vision, not a plan. Specific timelines and forms depend on the success of the preceding stages and the project's real dynamics.

6.1. From Solana to an own protocol

Solana is scaffolding for the 0–2 year horizon. It provides the transaction speed and low cost needed at the stage of proving the mechanics work. Solana's architectural constraints (the degree of validator centralization, regulatory exposure) are acceptable for this stage, but in the long term require migration.

On the 2–4 year horizon — the launch of an own Noosphere Protocol testnet with PoI as a native element of consensus. This means the PoI of validator participants influences their weight in validation, alongside stake — which carries the "argument over stake" principle from the application level down to the level of the protocol itself.

On the 4–6 year horizon — the Noosphere Protocol mainnet. Spheres existing on Solana migrate with their graphs and reputation.

6.2. The hardware layer

The Node is a device optimized for mass distribution, with the base functionality of a Noosphere Protocol node and an optional coercion-resistance function (via a LiDAR sensor). This is not a mandatory condition of participation, but an additional protection layer for votes that require heightened resistance to coercion.

The hardware roadmap is tied to the documentary film project "Asymmetry" — the devices appear in the film as part of its world, the dev kit opens during production, the first production run is ready by the time of the premiere.

The long-term hardware trust model: an open specification based on RISC-V + OpenTitan; decentralized production across several independent factories with robotic assembly and on-chain attestation of every device.

6.3. The ecosystem of Spheres

In the long term, Noosphere is not a single platform with several Spheres, but an infrastructure for an arbitrary number of Spheres across different domains: governance, science, education, economics, culture. Inter-Sphere interaction is a separate architectural layer providing the transfer of reputation, the citation of decisions, and coordination between Spheres.

6.4. Evolution of the role of AI

In the v0.5 architecture, AI is a participant in the system with its own type of constraints, and there is a multiplicity of AI models chosen by participants. In the long term, AI components may acquire their own PoI profile, accrued through their argumentative activity, and become full participants in votes alongside humans. The ethical boundaries of such a development are a separate class of open questions, requiring work long before the technical possibility arrives.

6.5. AI Pluralism as an ecosystem

As the system develops, an ecosystem may form around the Noosphere AI Layer: specialized models for different tasks and Spheres (legal, scientific, cultural, sector-specific); competition among wrappers for quality and speed; a market of AI services within Spheres. This means Noosphere becomes not merely a platform for collective decisions, but an infrastructure in which different approaches to working with human thought through AI evolve.

• Sphere — a collective subject of Noosphere, united by a shared treasury, argumentation graph, and voting rules.

• PoI (Proof of Intelligence) — an assessment of the quality of a participant's demonstrated argumentation by five structural criteria.

• Claim — an assertion in the argumentation graph.

• Argument — an argument for or against a claim.

• Endorsement — support for an existing node without creating a new one.

• Translation — a node in the graph representing the translation of another node into another language; itself a contestable claim.

• Relation types — SUPPORTS, REBUTS, UNDERCUTS, QUALIFIES, plus Translation as a special type.

• SphereCap — the stake ceiling in the vote weight formula, set by each Sphere independently.

• Contestability — a property of the architecture whereby every system decision is contestable by the same mechanism as any claim.

• Fork — the creation of a new Sphere on the basis of an existing one, with the transfer of graph and reputation; a defense mechanism against capture.

• $NOS — the internal functional currency of Noosphere.

• Multisig — a mechanism for executing a Sphere's decisions in off-chain actions through the distributed signature of several holders.

• Coercion-resistance — a class of coercion-protection problem, addressed by a combination of software and hardware measures.

• Noosphere AI Layer — a standardized interface through which any AI model can be connected to work with Noosphere.

• AI Pluralism — an architectural principle whereby not one AI model works in the system, but a multiplicity of models chosen by each participant.

• Argumentation Interaction Layer — the architectural layer describing a participant's interaction with the graph at the moment of writing and viewing.